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