ArrayBlockingQueue and addAll()

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ArrayBlockingQueue and addAll()

Kasper Nielsen-2
Hi,

Any reason for not letting ArrayBlockingQueue.addAll() use a more
efficient implementation then the one inherited from AbstractCollection?

- Kasper
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ArrayBlockingQueue and addAll()

Doug Lea
Kasper Nielsen wrote:
> Hi,
>
> Any reason for not letting ArrayBlockingQueue.addAll() use a more
> efficient implementation then the one inherited from AbstractCollection?
>

It is mainly because there's not a huge possibility for improvement.
Suppose for example a queue with capacity 100 gets calls from two different
threads to addAll with 200 elements each. At best you could put in the
first 100 for the first one, and let the others contend one-by-one as
consumers remove elements. This and other small improvements aren't
usually enough faster that letting all of them contend one-by-one
to deserve explicit coding. Although people who frequently hit cases
where it would be enough faster to bother, might feel differently.
So it is a good suggestion for a potential small performance improvement,
that we ought to take up someday. Thanks!

-Doug

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ArrayBlockingQueue and addAll()

Kasper Nielsen-2

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?
>>
>
> It is mainly because there's not a huge possibility for improvement.
> Suppose for example a queue with capacity 100 gets calls from two different
> threads to addAll with 200 elements each. At best you could put in the
> first 100 for the first one, and let the others contend one-by-one as
> consumers remove elements.
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.
So what would happen would be
T1 : inserts 100 elements and throws IllegalStateException("Queue full");
T2 : throws IllegalStateException("Queue full");

- Kasper
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ArrayBlockingQueue and addAll()

Doug Lea
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


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest