[concurrency-interest]Condition thoughts

David Holmes dholmes@dltech.com.au
Mon, 12 Aug 2002 10:16:50 +1000


Eric Crahen wrote:
> Its a shame that I can't use non-recursive locks, or use locks like
> RecursiveLock whose acquire()s can be interrupted with a Condtion.
<snip>
> If to accomplish this, something would be added that was allowed to do
> unbalanced monitorenter/monitorexits; why not make a Lock wrapper for an
> objects monitor. Something like this could be used,
<snip>
> to provide a Lock interface to an objects monitor. The Condition class
> then might be revised to work with a Lock instead of an Object,
<snip>
> What do you (anyone) think?

There have been many discussions on this in the EG.

My own thoughts for this are to extend the capabilities of the Condition
class rather than defining a special ObjectLock class - but the end results
are the same:

  Condition(Object obj) // Binds the condition to use obj's monitor
  Condition(Lock lock)  // Binds the condition to acquire/release lock

It would be an optimisation to be able to map, say, ReentrantLock directly
onto monitor operations. However there are several issues to resolve:

a) monitor entry is not interruptible while Lock acquisition is supposed to
   be

b) Some VM's won't let you unlock/lock arbitrary monitors in this way.
   They must be properly nested within a scope.

Also note that this isn't as common or useful as you might think. While it
looks neat and balanced you rarely need to use conditions when working in
situations that require stand-alone lock classes.

David Holmes