[concurrency-interest] Is there a ConcurrentBlockingQueue ??

Hanson Char hanson.char at gmail.com
Tue Mar 20 18:11:54 EDT 2007


Hi Gregg,

Not sure if I 100% understand you correctly.

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

First of all, according to the javadoc, the call to LockSupport.park()
can spuriously (that is, for no reason) return, regardless.

Any thread could be spuriously unparked but that is taken care of.
When Thread 1 is unparked (for whatever reason) within the take()
method, the method would either return with an element if one could be
found from q, or Thread 1 would simply park again if there q was
empty, except that the associated ThreadMarker of Thread 1 would be
placed at the tail of parkq.  So Thread 1 could be delayed from
unparking upon subsequent offer's (if we ignore the case of spurious
returns.)

> 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?

I don't see why parkq should be emptied.   parkq won't be emptied if
there were more take's than offer's.  In such case, the threads
executing the take method would be parked at queued at parkq, awaiting
items to be offered at q.

I also don't see why Thread 1 needs to peek at parkq and remove
itself.  The invocation of the offer method would always remove the
head of parkq, if there is one, and would result in either unparking a
parked thread (which even though may end up parking again if q was
found empty), or removing all ThreadMarker's that have already been
unparked at the head of parkq.

Hanson Char

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