Re: BlockingQueue and capacity issue

Case A:

The whole predicate thing is about admission control.
Writers block on a write semaphore, not because queue is full
but because they don't have access yet (which specializes into queue being full, is a case.)
Readers notify the write semaphore.
I guess predicates just need access to the same write semaphore if the admission policy changes.

There is a potential need for an intimate API (between predicates and queue) about those
semaphores. Technically, I guess the semaphore (the actual object on which the .wait/.notify are
called) should have been in the predicate in the first place.

The predicate API could be more than just accept() and could support: writers wait, writers
notify. It looks strange but the ultimate decision maker to unblock enqueuing would be the
predicate, not the queue.

Case B:

On the other hand, for me, right now, if the enqueue was allowed by the predicate, but the queue
was full, then the event is still accepted. It should only unblock when there is space from
dequeue. Too late to change mind about admission control; the event passed the gate. Any change in
queue capacity should only affect subsequent enqueues.

How far extends the admission control will tell you which case you need to implement.
I think the simpler case (B) is enough. 




--- Jean Morissette <[email protected]> wrote:
---------------------------------
Now that we want to support BlockingQueue operations, we have some issue with the queue capacity.
Presently, queue capacity is handled by ThreesholdPredicate and can be changed dynamically by
ResponseTimeConctrollerIF.  So, the queue is not aware of its capacity.
Suppose that threads are waiting to enqueue because the queue is full (see blocking_enqueue
method).  If the capacity increase, we must notify the threads because the queue is now not full. 
How to achieve that?
One possibility could be to make aware the queue of its capacity with a method Queue.setCapacity
and remove ThreesholdPredicate.  That is, the ResponseTimeConctrollerIF could change the queue
capacity by calling directly Queue.setCapacity instead of using ThreesholdPredicate. 



		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/