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

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?

Thanks,
Calum

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