[concurrency-interest] TransferQueue motivation?

Joe Bowbeer joe.bowbeer at gmail.com
Fri Feb 27 22:58:54 EST 2009


On Fri, Feb 27, 2009 at 9:30 AM, Alex Miller wrote:

>
> I was wondering if there was any background on the addition of
> TransferQueue/LinkedTransferQueue for Java 7?  Specifically, what are the
> use cases that motivate its inclusion?
>
> I've used SynchronousQueue in the past to do handoff from one thread to
> another and I kind of get that TransferQueue is an expansion of that idea.
>  But I haven't run into a case where I needed something like that.  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?
>
> Thanks...
>

I don't know the answers, but I'm adding some related information and
quoting a previous response from Doug below...

1. The most descriptive documentation is in the LinkedTransferQueue
implementation, which references the following paper by Bill Scherer, Doug
Lea and Michael Scott:

http://www.cs.rice.edu/~wns1/papers/2006-PPoPP-SQ.pdf<http://www.cs.rice.edu/%7Ewns1/papers/2006-PPoPP-SQ.pdf>

Abstract:

We present two new nonblocking and contention-free implementations of
> synchronous queues ,concurrent transfer channels in which producers wait for
> consumers just as consumers wait for producers. Our implementations extend
> our previous work in dual queues and dual stacks to effect very
> high-performance handoff. We present performance results on 16-processor
> SPARC and 4-processor Opteron machines. We compare our algorithms to
> commonly used alternatives from the literature and from the Java SE 5.0
> class java. util. concurrent. *SynchronousQueue* both directly in
> synthetic microbenchmarks and indirectly as the core of Java's *
> Thread-PoolExecutor* mechanism (which in turn is the core of many Java
> server programs).Our new algorithms consistently outperform the Java SE 5.0
> *SynchronousQueue* by factors of three in unfair mode and 14 in fair mode;
> this translates to factors of two and ten for the *ThreadPoolExecutor*.
>

2. In response to a similar question by Geoffrey Wiseman in 2007, Doug
wrote:

"TransferQueues are a little niche-y, but when you need them, nothing else
will do. One of the motivations is to create a simpler-to-use thread pool,
in which sometimes tasks must be synchronously transferred."

> At that point, it waits for the queue to empty including the transferred
element?

According to LinkedBlockingQueue source, I think the answer is "yes".

Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090227/5b88f94d/attachment.html>


More information about the Concurrency-interest mailing list