Admission Controlled Sink

Hi,
Actually, SinkIF support methods [get|set]EnqueuePredicate(), so the 
admission control policy is exposed to the handlers.

I'm wondering if it would be better to not expose theses methods to the 
handlers.  I think that changing the admission control policy is the 
responsability of the SS owner, not the handlers.  So, we could move 
methods [get|set]EnqueuePredicate() in a new AdmissionControlledSinkIF 
(smaller name?) that would be accessed by the SW and used by the RTC.


Also I'm wondering if the enqueue predicate should be volatile? 
Declaring it volatile ensure that it is up-to-date, but add overhead to 
each method call.  By exemple:

public class AdmissionControlledSink implements AdmissionControlledSinkIF {

	volatile EnqueuePredicateIF pred;
	BlockingSinkIF sink;

	public AdmissionControlledSink(BlockingSinkIF sink) {
		this.sink = sink;
	}


	public synchronized void setEnqueuePredicate(EnqueuePredicateIF pred) {
		this.pred = pred;
	}

	public EnqueuePredicateIF getEnqueuePredicate() {
		return pred;
	}

	public void blocking_enqueue(QueueElementIF element) throws 
InterruptedException {
		pred.blockingAccept(element);
		sink.blocking_enqueue(element);
	}

	public void enqueue(QueueElementIF element) throws SinkException {
		if (!pred.accept(element))
			throw new SinkFullException();
		sink.enqueue(element);
	}

  	...


One solution to ensure up-to-date predicate could be to restart 
automatically the stage when the enqueue predicate is changed.  What do 
you think?



-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click