[concurrency-interest] Use of blocked queues

Calum MacLean cnmaclean at hotmail.com
Mon May 30 16:17:58 EDT 2005

Hi Doug

OK, I understand that there still might be that race condition.  In my case 
it's OK - the event is, in effect, just an indication that the message 
wasn't read instantly (i.e. there wasn't a reader which was waiting for it), 
but without any guarantee that it wasn't read pretty soon after that, and 
possibly even before the notification was sent out.  So it's a conservative 

So, regarding being able to check how many readers are blocked waiting on a 
queue, you're basically saying that I can't do that using 
java.util.concurrent, and I will have to do it myself?


----- Original Message ----- 
From: "Doug Lea" <dl at cs.oswego.edu>
To: "Calum MacLean" <cnmaclean at hotmail.com>
Cc: <concurrency-interest at altair.cs.oswego.edu>
Sent: Monday, May 30, 2005 2:43 PM
Subject: Re: [concurrency-interest] Use of blocked queues

> Calum MacLean wrote:
>> I can achieve this relatively easily directly, by using a common object 
>> for synchronising around, and keeping a note of the number of readers.
> Except that the reader count will not include any thread currently
> blocked on that lock waiting to get in while you are checking, which is
> exactly the race condition you'd have otherwise. So, while you might
> be able to reduce unnecessary events using something like this,
> you can't eliminate them, and if this lock becomes highly contended,
> you might find that it is faster overall to just unconditionally
> issue events. Or maybe not. But I don't see anything that adding
> any capability to java.util.concurrent would help with here.
> -Doug

More information about the Concurrency-interest mailing list