[concurrency-interest] Proposal WeightedLinkedBoundedQueue

Brian Goetz brian at quiotix.com
Thu Nov 30 21:27:18 EST 2006

That's what I meant -- the implementation _should_ reject it out of 
hand.  If it doesn't, it is subject to deadlock.

David Holmes wrote:
> But if the bound of 100 is a hard-bound then the enqueue of 101 should be
> rejected out of hand.
> David Holmes
>> -----Original Message-----
>> From: concurrency-interest-bounces at cs.oswego.edu
>> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Brian
>> Goetz
>> Sent: Friday, 1 December 2006 10:07 AM
>> To: Dawid Kurzyniec; concurrency-interest
>> Subject: Re: [concurrency-interest] Proposal WeightedLinkedBoundedQueue
>> Although there's a really unfortunate deadlock interaction if you use a
>> fair semaphore: you have a queue with a bound of 100 and someone tries
>> to enqueue an object of weight 101.  With a fair semaphore, it's game
>> over -- no one will ever succeed in enqueuing again.
>>> Just one more thing - I am not sure if this is going to be a problem in
>>> your case, but are you aware of potential starvation scenarios? E.g. if
>>> your queue is full most of the time, and if you have a requestor that
>>> wants to put a really large object in the queue, it might never get a
>>> chance to do so (losing competition with other requestors putting
>>> smaller objects, so that there is never enough space available for the
>>> big guy). In the semaphore-based approach, you could prevent this by
>>> using a fair semaphore. If you're doing it by hand, you might want to be
>>> careful about this.
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at altair.cs.oswego.edu
>> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list