RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

[David Holmes]

On 24/08/2016 1:39 PM, Hamlin Li wrote:
>
> On 2016/8/24 11:02, Martin Buchholz wrote:
>>
>>
>> On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz <martinrb at google.com
>> <mailto:martinrb at google.com>> wrote:
>>
>>     I didn't see this thread before updating the bug.
>>
>>     I think this is Not a Bug, because """The current atomic addAll is
>>     a tradeoff; it's efficient, but at the cost of potential loss of
>>     concurrency if the other collection is slow. It's reasonable for a
>>     subclass to override addAll to add elements eagerly and
>>     non-atomically."""
>>
>>     OTOH it would be reasonable to document the atomicity of the
>>     implementation in CLD and CLQ as @implNote.
>>
>>
>> Right now I'm even back-pedaling on that.  Unless there's an important
>> use case where atomicity of addAll matters, it's not worth the
>> confusion to document that some particular implementation is atomic.
>> The aim of that code was efficiency, not atomicity.  In fact, choosing
>> some batch size and adding in chunks, I/O buffer style, may be a
>> better choice.
> Hi Martin,
>
> Yes, you're right.
> But currently, "For example, an iterator operating concurrently with an
> addAll operation might view only some of the added elements." is a wrong
> statement for ConcurrentLinkedDeque and ConcurrentLinkedQueue, so maybe
> we could just remove just this sentence for now.

It is only an example and it says "might". If we change the 
implementation tomorrow we wouldn't want to have to update the spec to 
add the example back. It is really non-normative text but we don't want 
any users of these classes to rely on any atomicity property.

David

> Thank you
> -Hamlin