[concurrency-interest] Is there a ConcurrentBlockingQueue ??

Hanson Char hanson.char at gmail.com
Tue Mar 20 18:43:56 EDT 2007


Hi Gregg,

> 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
false.

Not good enough ?

Hanson


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
> 97
> 98
> 99
> 100
>                      65
>                      66
>                      67
>                      68
>                      69
>                      70
>                      71
>                      72
>                      73
> 101
> 102
> 103
> 104
> 105
> 106
> 107
> 108
> 109
> 110
> 111
> 112
> 113
> 114
> 115
> 116
> 117
>
> 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 mailing list