|
Re: ArrayBlockingQueue and addAll(): msg#00039java.jsr.166-concurrency
Kasper Nielsen wrote: > > Doug Lea wrote: >> Kasper Nielsen wrote: >>> Hi, >>> >>> Any reason for not letting ArrayBlockingQueue.addAll() use a more >>> efficient implementation then the one inherited from AbstractCollection? >>> > I can't see how they can contend one-by-one, the contract of add is to > throw a RuntimeException() if any element cannot be added. Yes; sorry. I was thinking about blocking cases. However, variants of the same issue hold: Suppose that there is a very fast consumer that removes elements as fast as they are added. In this case, adding 200 elements one-by-one in a 100-capacity queue may succeed, whereas if 100 are put in, in bulk, and then an exception is thrown for the rest, only 100 will be transferred. Of course, since there are no promises about these things either way, this would be equally legal. And sometimes faster in practice, so it is still a useful suggestion. -Doug
|
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: ArrayBlockingQueue and addAll(), Kasper Nielsen |
|---|---|
| Next by Date: | Deamon thread Factory, Kasper Nielsen |
| Previous by Thread: | Re: ArrayBlockingQueue and addAll(), Kasper Nielsen |
| Next by Thread: | Escaping "this" reference in constructors, Kasper Nielsen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |