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

[Hamlin Li]

On 2016/8/24 12:53, David Holmes wrote:
> 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.
Hi David,

Got your point.

Thank you
-Hamlin
>
> David
>
>> Thank you
>> -Hamlin