[concurrency-interest] Owned Locks

Richard Zschech richard.zschech@cqrdata.com
Fri, 25 Jul 2003 10:03:48 +0100


Currently in jsr-166 the locks are all "owned" and managed by the 
current thread.

If for example in a multi threaded client server application, where each 
request may
be handled by a thread in a thread pool, and a session id is allocated 
to a particular
client, thread based locking is not too useful. Locking based on the 
session id would
be ideal.

Another example is in a transaction based resource manager a transaction 
id (Xid in jta)
it is possible to suspend a transaction and resume it on another thread 
based on the
id. Again locking based on the transaction id would be better.

Would it be possible to change the lock class so that the methods take 
an Object
parameter say called "caller" which is used for the ownership of the 
lock as follows:

public interface Lock {
    void lock(Object caller);
    void lockInterruptibly(Object caller);
    Condition newCondition();
    boolean tryLock(Object caller);
    boolean tryLock(Object caller, long time, TimeUnit unit);
    void unlock(Object caller);
}

Then we could have an interface ThreadBasedLock which is equivalent to 
the Lock
interface possibly extending Lock possibly not with out the caller 
parameters as
follows:

public interface ThreadBasedLock extends Lock {
    void lock();
    void lockInterruptibly();
    boolean tryLock();
    boolean tryLock(long time, TimeUnit unit);
    void unlock();
}

an ThreadBasedLock implementation could wrap a lock or extend a lock for 
example:

public class ThreadBasedWrapperLock implements ThreadBasedLock {

    private Lock wrapped;

    public void lock() {
        wrapped.lock(Thread.currentThread());
    }
}

or:

public class ThreadBasedReentrantLock implements ReentrantLock {

    public void lock() {
        super.lock(Thread.currentThread());
    }
}

It may even be better to make ThreadBasedLock a class that just wraps a 
lock like
my example ThreadBasedWrapperLock.

I think this would add extra functionality and extra uses cases for the 
locking api
without complicating it too much.

Any comments?

 From Richard.