[concurrency-interest] TransferQueue motivation?

Doug Lea dl at cs.oswego.edu
Sat Feb 28 10:57:09 EST 2009

Alex Miller wrote:
> I was wondering if there was any background on the addition of
> TransferQueue/LinkedTransferQueue for Java 7?  

The simplest answer is that we realized that we should
have had this in the first place in Java5 rather than
some others, but didn't know it. Better late than never.

The capabilities are a superset of those in
  * ConcurrentLinkedQueue,
  * SynchronousQueue, in "fair" mode,
  * LinkedBlockingQueues that are not capacity bounded.
And better not only because you can now mix these capabilities,
but also because the implementation includes better techniques
we've discovered. So it seems like a good choice to place
in java.util.concurrent. The fact that there are already a bunch
of queues in j.u.c makes it a little confusing,
but we cannot pull out the others. However, as I mentioned in a
previous post, we'll probably kill some of the internals
of some of these classes and delegate to LTQ.

There are only a few common cases where you really need
the full combination of methods offered by LTQ. For example
if you are using them for messaging, and have combinations
of asynchronous and synchronous messages. Also, they
are needed for EvenBetterThreadPools we aim to supply someday.

> I miss a
> little bit what the expected behavior is if the queue has stuff in it already
> and transfer is called.  At that point, it waits for the queue to empty
> including the transferred element?

Yes, it waits for all items up to and including the offered item.


More information about the Concurrency-interest mailing list