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 03:39:50 UTC 2016


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.

Thank you
-Hamlin


More information about the core-libs-dev mailing list