Re: Owned Locks

Sorry I previously sent the response to Tim not the list.


Hmm, I'm not sure how the room example applies and the OwnedLock example 
dosen't seem to allow for the owner of the lock to change overtime.

The desired behavior is still a reentrant mutual exclusion the only 
problem is that I want to access the lock based on a owner not based the 
current thread.
In the Java Transaction API [1] when implementing an XAResource there 
are number of methods which take an Xid which any locking needs to be 
based around.
A rather contrived example is if I have an implementation of an 
XAResource which also has a method to update a variable pool based on an 
expression e.g. foo = foo++. This code is called as follows:

resource.start(xid);
result = resource.update("foo", "++");
resource.prepare(xid);
// "foo" is now locked
resource.commit(xid, false /*two phase commit*/);
// "foo" is now unlocked and result is now filled in

The implementation of the prepare and commit would look something like 
this:

public StringBuilder update(String variable, String expression) {
Variable v =  variablePool.get(variable);
StringBuilder result = new StringBuilder();
getCurrentTransactionContext().addUpdateRequest(v, expression, result);
return result;
}

public void prepare(Xid xid) {
// acquire the lock
for(all update requests associated with this xid) {
  updateRequest.getVariable().getLock().lock(xid);
}
}

public void commit(Xid xid, boolean onePhase) {
if(onePhase) {
  prepare(xid);
}
// do the update
for(all update requests associated with this xid) {
  updateRequest.doUpdate();
}

// release lock
for(all update requests associated with this xid) {
  updateRequest.getVariable().getLock().unlock(xid);
}
}

There is more plumbing which I have omitted to associate the Xids with 
the update call. The problem is that the prepare which obtains any 
required locks and the commit doesn't have to be called on the same 
thread so the locking of foo cant be thread based.

I don't mind that the owned lock doesn't implement the Lock interface 
and has an extra owner parameter. I already have an implementation of 
the owned locks, I was just hoping I could leverage the built in locking.

[1] http://java.sun.com/products/jta/



Tim Peierls wrote:

> 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