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

David Holmes david.holmes at oracle.com
Wed Aug 24 04:53:41 UTC 2016


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


More information about the core-libs-dev mailing list