[concurrency-interest] Lock Manager

Adam Messinger adam@bea.com
Tue, 4 Nov 2003 17:08:52 -0800


> I think the scheme encourages bad programming practice. That is somebody
> from outside the thread who runs under the lock has the possibility to
call
> the unlock. Well, it should always be the owner thread of the lock that
> always unlocks, as it is the only one who can guarantee the return
> to a known good state.

Costin,

This model is meant to accomodate a higher level of locking, where the
concern is not with multiple threads touching the same data but with
multiple logical bits of work touching the same data.  Take the example of a
transaction with a simple exclusive concurrency model; it needs to lock data
as it accesses it so that other transactions do not change it before it is
commited.  At commit time all of the locks associated with the transaction
are then released.  However, a transaction may last many minutes and
moreover it may span many individual Tasks, potentially even being processed
by many Threads in parallel.  As such a scheme which associates locks with
threads is not appropriate, rather the lock must be associated with a higher
level abstraction such as a transaction.

I do however agree that there is a risk of this scheme being miused by folks
wanting to do thread level locking.  I suggest it only because it seems both
sufficiently common and sufficiently hard to get right, that it seems like
something a utility package might usefully provide.

Cheers!

Adam