[concurrency-interest] Lock Manager
Wed, 5 Nov 2003 13:29:00 -0800
Yes, I understand is for something else than typical multithreading
exclusion. However, my commentaries about encouraging bad programming
practices remain valid even for your scenario. The reason is that objects
are locked, and somebody will always have the lock, maybe not the original
thread who aquired the lock, maybe it migrated in another thread, or even
another JVM process, but the point is that there's some activity going on
under that lock.
If a lock is held and no current thread has the potential of doing
something with the state protected by the lock, than I submit such a
situation will indicate a serious design flaw or implementation flaw.
Admitting that at least one thread still has the lock and has the potential
to do something to the protected state, we need to make sure that that
thread exits that part of processing cleanly before the lock is released.
The way you propose looks to me as if the "proof" that the processing has
been exited cleanly is that the caller who executes
has the correct reference to the real owner that the framework can check.
First of all the condition is very weak, serious bugs can still happen even
if the owner is correct.
And second, it doesn't support very important use cases which I happen to
see in my activity and will definitely happen in DB transaction scenarios.
For example it is a supervising thread that decides a problematic thread
(or even group of threads) should exit the protected zone, and all the
locks be released. In this case the supervising thread may very well have
access to who is the opaque lock owner, but calling
LockManager.unlock(lock, owner) accomplishes nothing good, as the
LockManager does not have the abstract interface (for example
CancellableTask) through which it can force that the thread exits safely
from the protected zone, before he releases the lock.
I'm not saying that such a solution cannot be made to work right, but the
problem is that a good framework should make it more difficult for clients
to misuse it and should make it easy and obvious to the clients how to use
good (correct, safe) design patterns. The API you proposed leaves it
almost as hard to get things right as it was without it, but makes it very
easy to write bad concurrent code.
So yes, I understand the need for a lock/unlock mechanism that may work
across threads, but I think a different API is needed that can also solve
Staff Software Engineer (949) 462-6779
Toshiba American Business Solution
Mobile (310) 463-5940
Alternate Email email@example.com
<firstname.lastname@example.org> To: Costin Cozianu/DSE/IRV/TOSHIBA-TABS@TOSHIBA-TABS
Sent by: cc: <email@example.com>
concurrency-interest-admin@cs Subject: Re: [concurrency-interest] Lock Manager
11/04/2003 05:08 PM
> I think the scheme encourages bad programming practice. That is somebody
> from outside the thread who runs under the lock has the possibility to
> 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.
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
transaction with a simple exclusive concurrency model; it needs to lock
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
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
level abstraction such as a transaction.
I do however agree that there is a risk of this scheme being miused by
wanting to do thread level locking. I suggest it only because it seems
sufficiently common and sufficiently hard to get right, that it seems like
something a utility package might usefully provide.
Concurrency-interest mailing list