Re: Owned Locks

Richard Zschech wrote:
> I previously posted a question [1] over a year and a half ago ... about
> owned locks. Doug Lea responded [2] saying that they were intentionally
> left out and suggested using a ThreadLocal to track the owner of the
> lock and a special implementation of the Lock interface which works with
> the ThreadLocal. I am trying to figure out how to best leverage the
> current built in locks to achieve owned locks. Any help or suggestions
> would be appreciated.
>
> http://altair.cs.oswego.edu/pipermail/concurrency-interest/2003-July/000497.html
> http://altair.cs.oswego.edu/pipermail/concurrency-interest/2003-July/000498.html

This feels very much like another example of what I called GenderLock in an
earlier posting, but have since learned is known as "room synchronization".
See http://www-2.cs.cmu.edu/afs/cs/project/pscico/www/rooms.html for more,
but the basic idea is that any number of threads can enter a room, and only
one room at a time can be entered. That sounds a lot like having a lock
that can have one owner at a time, but is not tied to one thread.

https://dev.priorartisans.com/repos/jcip/trunk/src/main/jcip/rrlock/RRLock.java

(For "gender", read "room" in this code.)

But Doug's suggestion of using ThreadLocals is interesting, because
it leads to an entirely different implementation with very similar
behavior:

https://dev.priorartisans.com/repos/jcip/trunk/src/main/jcip/rrlock/OwnedLock.java

Caveat lector: I have done only primitive testing of this class;
in particular, I haven't tried out the Condition support at all.

Can you expand a bit on the two applications of owned locks that
you mentioned, session ID and transaction ID?

--tim