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
-Hamlin
>
> David
>
>> Thank you
>> -Hamlin
More information about the core-libs-dev
mailing list