[concurrency-interest] Lock Manager

Costin.Cozianu@tabs.toshiba.com Costin.Cozianu@tabs.toshiba.com
Tue, 4 Nov 2003 16:11:50 -0800

I think the scheme encourages bad programming practice. That is somebody
from outside the thread who runs under the lock has the possibility to call
the unlock. Well, it should always be the owner thread of the lock that
always unlocks, as it is the only one who can guarantee the return
to a known good state.

The practical problem is what should we do about errand lock owners that
may have enetered a loop (or deadlock), and a supervising process may
decide to forcefulyl remove the lock for other noble goals.

In this case, the running computation should provide a hook for forceful
cancellation, i.e. have an interface:


so that

LockObject.unlock() will call cancel on CancellableTask, and the processing
should be carefully programmed as to detect the cancellation and return the
lock from the thread that actually owns it, when the thread is outside the
mutual exclusion zone, and therefore the protected state is safe. One very
simple example that I use in my work is when I execute the thread with the
lock executes an external process, than the cancel() action will kill the
process causing an exception to be thrown in the thread owning the lock, so
that the thread will exit  from the safety zone and return the lock.

In other words if you want to unlock you have to guarantee some minimum
safety condition, and that is impossible when the framework only know that
the owner is a java.lang.Object.

Costin Cozianu
Senior Software Engineer                 (949) 462-6779
Toshiba American Business Solution
Mobile                                              (310) 463-5940
Alternate Email                                 c_cozianu@hotmail.com

                      "Adam Messinger"                                                                                                       
                      <adam@bea.com>                        To:      <concurrency-interest@altair.cs.oswego.edu>                             
                      Sent by:                              cc:                                                                              
                      concurrency-interest-admin@cs         Subject: [concurrency-interest] Lock Manager                                     
                      11/04/2003 02:35 PM                                                                                                    

Please excuse if this is something which has already been discussed and
found to be out of scope.  I looked back through the archives and couldn't
find a record of it.  I believe that a number of programs have need for
functionality that looks something like this:

public interface LockManager {
  public void lock(Object key, Object owner);
  public void tryLock(Object key, Object owner, long time, TimeUnit unit);

  public void unlock(Object key, Object owner);

An example of this in the real world can be found here:


In addition similar schemes are present in WebLogic Server internals.  In
some places we use a non-blocking variation of this which looks something

public interface NonBlockingLockManager extends LockManager {
  public Future tryLock(Object key, Object owner, long time, TimeUnit unit,
Listener l);
  public Future unlock(Object key, Object owner, Listener l);

  public interface Listener {
    // called whenever f.isDone() would start returning true
    public void done(Future f);

The non-blocking tryLock variation allows us to avoid blocking threads
while trying to gain contended locks.  The non-blocking unlock is needed
mostly for situations where the unlock operation requires I/O.

I know that many other applications have need for one or both of these
variations as well.

All this is similar, but subtly different, than having a j.u.Map full of
j.u.c.Locks.  One important difference is that the locks may be owned by
something other than a Thread (an example use case is a transaction).
Another difference is that some subtlety is required to remove unused locks
without race conditions which cause simultaneous lock attempts to deadlock.
Finally supporting the Futures is also outside the scope of what the
current Locks can do.

What do folks think?  Is it a general enough problem to be included in JSR
166?  Is it too out of place given that it decouples locking from