Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

2016-08-23 Thread Hamlin Li
On 2016/8/24 12:53, David Holmes wrote: 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 mailto:marti...@google.com>> wrote: I didn't see this thread before updating the bug. I think this is Not a Bu

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

2016-08-23 Thread David Holmes
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 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 i

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

2016-08-23 Thread Hamlin Li
On 2016/8/24 11:02, Martin Buchholz wrote: On Tue, Aug 23, 2016 at 9:17 AM, 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 a

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

2016-08-23 Thread Martin Buchholz
On Tue, Aug 23, 2016 at 9:17 AM, 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

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

2016-08-23 Thread Hamlin Li
On 2016/8/24 9:22, David Holmes wrote: Hi Hamlin, On 23/08/2016 10:53 PM, Hamlin Li 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 op

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

2016-08-23 Thread David Holmes
Hi Hamlin, On 23/08/2016 10:53 PM, Hamlin Li 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

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

2016-08-23 Thread Hamlin Li
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 con

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

2016-08-23 Thread Martin Buchholz
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 eager

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

2016-08-23 Thread Hamlin Li
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 ato

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

2016-08-23 Thread David Holmes
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? David - "Additionally, the bu

RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

2016-08-23 Thread Hamlin Li
Below doc is not correct, because for ConcurrentLinkedDeque and ConcurrentLinkedQueue, addAll is a atomic operation. "Additionally, the bulk operations addAll, removeAll, retainAll, containsAll, equals, and toArray are not guaranteed to be performed atomically. For example, an iterator operati