Hi Martin,
Thank you for clarifying and taking the bug.
-Hamlin
On 2016/8/24 0:17, Martin Buchholz 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.
On Tue, Aug 23, 2016 at 5:53 AM, Hamlin Li <huaming...@oracle.com
<mailto:huaming...@oracle.com>> wrote:
On 2016/8/23 17:10, David Holmes wrote:
Hi Hamlin,
On 23/08/2016 6:55 PM, Hamlin Li wrote:
Below doc is not correct, because for
ConcurrentLinkedDeque and
ConcurrentLinkedQueue, addAll is a atomic operation.
No it is not! There is no bug here. Are you perhaps confusing
thread-safe with atomic?
Hi David,
Thank you for review. Please let me clarify.
Although "public boolean addAll(Collection<? extends E> c)" is not
protected by any lock or monitor, the implementation in both
ConcurrentLinked*eque.java still "Atomically append the chain at
the tail of this collection", so I still think addAll is a atomic
method. Even though it's not called atomic at this situation, the
statement "For example, an iterator operating concurrently with an
addAll operation might view only some of the added elements." is
wrong, because either all objects in Collection c are viewed by
iterator, or none of objects in Collection c are viewed by iterator.
Thank you
-Hamlin
David
-----
"Additionally, the bulk operations addAll, removeAll,
retainAll,
containsAll, equals, and toArray are not guaranteed to be
performed
atomically. For example, an iterator operating
concurrently with an
addAll operation might view only some of the added elements."
It should be modified as some thing like below:
"Additionally, the bulk operations removeAll, retainAll,
containsAll,
equals, and toArray are not guaranteed to be performed
atomically."
bug: https://bugs.openjdk.java.net/browse/JDK-8164623
<https://bugs.openjdk.java.net/browse/JDK-8164623>
webrev: http://cr.openjdk.java.net/~mli/8164623/webrev.00/
<http://cr.openjdk.java.net/%7Emli/8164623/webrev.00/>
Thank you
-Hamlin
