# [concurrency-interest]RE: RE :RE: JSR 166 draft API
(David Holmes)
Jerry Schwarz
jerry.schwarz@oracle.com
Wed, 07 Aug 2002 22:45:39 -0700
At 09:01 PM 8/7/2002, David Holmes wrote:
> > Is the Condition class now less like a POSIX condition variable and more
> > like an abstraction for a monitor? It just adding the ability to wait
> > uninterruptably or will there be subclasses that sort waiter lists or
> > something along those lines?
>
>I'm not sure what you mean by this last part but the Condition class is used
>to provide the effect of multiple condition/wait queues per monitor.
>
>To use a classic example of the BoundedBuffer:
>
> public class BoundedBuffer {
> Condition notFull = new Condition(this);
> Condition notEmpty = new Condition(this);
>
> int size = 0;
> final int CAPACITY = 10;
>
> public synchronized void put(Object o) {
> while (size == CAPACITY)
> notFull.await();
>
> // store o
> size++;
> notEmpty.signalAll();
> }
>
> public synchronized Object get() {
> while (size ==0)
> notEmpty.await();
> size--;
> Object temp = ... // remove
> notFull.signalAll();
> return temp;
> }
>}
Is notFull.await() releasing the synchronization lock on "this"? If not,
then no other Thread could execute get, and there would be a deadlock. And
you obviously can get rid of the synchronization without creating
races. I'm sure you can clean this up, but by the time you do I suspect it
will be complicated enough that you would be better off using some
alternative to Condition's.
>Condition also allows uninterruptible waiting and timedwaits that don't
>require you to jump through hoops to see if you timed out.
>
>The order in which waiting threads are signalled is not specified - as per
>Object.wait().
>
>A Condition class with ordering guarantees would have to use a "specific
>notification" style approach.
>
>David Holmes
>
>
>_______________________________________________
>Concurrency-interest mailing list
>Concurrency-interest@altair.cs.oswego.edu
>http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest