RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java
Martin Buchholz
martinrb at google.com
Wed Aug 24 03:02:50 UTC 2016
On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz <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.
More information about the core-libs-dev
mailing list