[concurrency-interest] Is there a ConcurrentBlockingQueue ??
hanson.char at gmail.com
Tue Mar 20 18:43:56 EDT 2007
> It seems like parkq should always be emptied
I think I see what you mean. Yes there is a chance that some unparked
items are left over in parkq, if an item is placed to q after a
ThreadMarker is placed to parkq but before the thread (of the
associated ThreadMarker) is parked. In such case, the left-over
ThreadMarker's would have "parked" set to false.
The logic in the offer method attempts to minimize the left-over in
parkq by removing all consecutive ThreadMarker with "parked" set to
Not good enough ?
On 3/20/07, Gregg Wonderly <gregg at cytetech.com> wrote:
> Hanson Char wrote:
> > Have you checked this out ?
> > http://hansonchar.blogspot.com/2006/09/concurrentlinkedblockingqueue.html
> Hanson, it looks like there is a pretty good chance that a thread can be left in
> the parkq and be the incorrect target of an unpark on the next offer.
> Thread 1 take: Thread 2 offer:
> Line Line
> it seems that parkq is left with a marker for Thread 1, and if thread 1 doesn't
> come back, but another thread does, and then another offer is made that the
> other thread will not be unparked, and Thread 1 may be spuriously unparked from
> somewhere else.
> It seems like parkq should always be emptied, or some different logic needs to
> be in place to allow Thread 1 to peek parkq, and remove itself if it is at the head?
> Gregg Wonderly
More information about the Concurrency-interest