[concurrency-interest] Lock Manager

Oliver Zeigermann ozeigermann@c1-fse.de
Wed, 05 Nov 2003 07:28:16 +0100


Adam Messinger wrote:
 > 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.

That is exactly the szenario I used my locking for.

 > 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.

As I said, I would have loved to have this sort of locking utility 
around, written by experts.

However,
1.) I doubt j.u.c. is the right package for it
2.) it is very hard to match the majority of needs and applications with 
a single, yet simple locking utility

Cheers,

Oliver