RE: Owned Locks

Richard,

This seems more a token-based access control mechanism: if you pass the
right token you are allowed to perform a particular function; if you don't
have the right token then you can't. This is different to locks where one
thread may hold the lock and another tries to acquire it, blocking until it
is available--if your threads don't have the right token then blocking will
not change that (unless you have a token-passing scheme :) ). Your problem
then boils down to one of token management: how are they defined, how can
they be used (can more than one thread hold the token at a time) etc. Within
that token management system you may need to use "normal" locks, but I'm not
quite seeing where the "owned-lock" comes into play.

Doug Lea covers this sort of transactional model in Section 3.6 of
Concurrent Programming in Java 2nd Edition. You can add transaction id's as
your tokens to all method calls, or you can make the transaction id implicit
such as through a ThreadLocal value.

Apologies if I'm not seeing your problem from the right perspective.

Regards,
David Holmes

> -----Original Message-----
> From: concurrency-interest-admin@xxxxxxxxxxxxx
> [mailto:concurrency-interest-admin@xxxxxxxxxxxxx]On Behalf Of Richard
> Zschech
> Sent: Wednesday, 9 February 2005 8:30 AM
> To: concurrency-interest@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [concurrency-interest] 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/
>
>
>