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 <marti...@google.com
<mailto:marti...@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
