Comments on: Java 7 TransferQueue

By: yongboy

yongboy — Thu, 02 Feb 2012 04:27:22 +0000

Hi, Alex:
Thanks for your response.
I understood wrong with the transfer method, with my test, your are right.
With some item already in the queue, when call the transfer method, the producer thread will wait util the other items have been consumed.

By: Alex Miller

Alex Miller — Wed, 01 Feb 2012 04:00:50 +0000

@yongboy: I think it is correct as written. If you are putting a new item in the queue, then it cannot be consumed until all of the other items already in the queue have been consumed (as that’s the FIFO guarantee).

By: yongboy

yongboy — Wed, 01 Feb 2012 03:18:47 +0000

Hi, Alex:
Thanks for your post. I like it. But I wondered that if the line “In the case where items are already in the queue, calling transfer will guarantee that all existing queue items will be processed before the transferred item” is right ? maybe is “after the transferred item” ?

By: Kirk

Kirk — Wed, 04 Mar 2009 08:17:02 +0000

Right, but with work-stealing/fork-join, the idea is to place the contended memory location on the left and the uncontended memory location on the right. Large chunks of work go to the left and small chunks to the right. Net result, uncontented end will never suffer from CAS failure while contended end shouldn’t be visited that often. This implementation looks to be well tuned to support that use case but at the possible expense of others.

By: Alex

Alex — Tue, 03 Mar 2009 02:35:13 +0000

Well, I’m no guru. My understanding of the fork/join stuff is that it is more tuned for this use case of fine-grained parallelism of a large number of light-weight tasks, work-stealing, and all that. Sounds like a good question for Doug Lea in any case.