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

Hamlin Li huaming.li at oracle.com
Wed Aug 24 06:09:23 UTC 2016

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
> David
>> Thank you
>> -Hamlin

More information about the core-libs-dev mailing list