[concurrency-interest] Lock Manager

Adam Messinger adam@bea.com
Tue, 4 Nov 2003 14:35:55 -0800


This is a multi-part message in MIME format.

------=_NextPart_000_10DE_01C3A2E0.F438C100
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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:

http://www.javagroups.com/javagroupsnew/docs/javadoc/org/jgroups/blocks/L=
ockManager.html

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

public interface NonBlockingLockManager extends LockManager { =20
  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 =
threading?

Cheers!

Adam
------=_NextPart_000_10DE_01C3A2E0.F438C100
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Please excuse if this is something =
which has=20
already been discussed and found to be out of scope.&nbsp; I looked back =
through=20
the archives and couldn't find a record of it.&nbsp; </FONT><FONT =
face=3DArial=20
size=3D2>I believe that a number of programs have need for functionality =
that=20
looks something like this:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>public interface LockManager =
{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; public void lock(Object key, =
Object=20
owner);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; public void tryLock(Object key, =
Object=20
owner, long time, TimeUnit unit);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; public void unlock(Object key, =
Object=20
owner);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>An example of this in the real world =
can be found=20
here:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.javagroups.com/javagroupsnew/docs/javadoc/org/jgroups/=
blocks/LockManager.html">http://www.javagroups.com/javagroupsnew/docs/jav=
adoc/org/jgroups/blocks/LockManager.html</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In addition similar schemes are present =

in&nbsp;WebLogic Server internals.&nbsp; In some places we use a =
non-blocking=20
variation of this which looks something like:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>public interface NonBlockingLockManager =
extends=20
LockManager {</FONT><FONT face=3DArial size=3D2>&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; public Future tryLock(Object =
key, Object=20
owner, long time, TimeUnit unit, Listener l);</FONT></DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2></FONT></DIV><FONT face=3DArial =
size=3D2>&nbsp; public=20
Future unlock(Object key, Object owner, Listener l);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; public interface Listener =
{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; // called whenever =
f.isDone()=20
would start returning true</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; public void =
done(Future=20
f);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; }</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The non-blocking tryLock variation =
allows us to=20
avoid blocking threads while trying to gain contended locks.&nbsp; The=20
non-blocking unlock is needed mostly for situations where the unlock =
operation=20
requires I/O.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I know that many other applications =
have need for=20
one or both of these variations as well.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>All this is similar, but subtly =
different, than=20
having a j.u.Map full of j.u.c.Locks.&nbsp; One important difference is =
that the=20
locks may be owned by something other than a Thread (an example use case =

is&nbsp;a transaction).&nbsp; Another difference is that some subtlety =
is=20
required to remove unused locks without race conditions which cause =
simultaneous=20
lock attempts to deadlock.&nbsp; Finally supporting the Futures is also =
outside=20
the scope of what the current Locks can do.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>What do folks think?&nbsp; Is it a =
general enough=20
problem to be included in JSR 166?&nbsp; Is it too out of place given =
that it=20
decouples locking from threading?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>Cheers!<BR><BR>Adam</FONT></DIV></BODY></HTML>

------=_NextPart_000_10DE_01C3A2E0.F438C100--