Re: stop() boundaries
Jan Burse wrote:
Lew schrieb:
"... it is inherently unsafe."
"Inherently" is a pretty strong word.
What are you trying to accomplish?
Proper use of java.util.concurrent in the same sense
as synchronized works.
Remember that stop is deprecated because it is inherently unsafe. I
don't think you are going to be able to base anything "proper" on such a
shaky foundation.
The flag-and-interrupt approach provides a much more solid foundation.
A;
ReentrantLock lock=new ReentrantLock();
lock.lock();
try {
B;
} finally {
lock.unlock()
}
C;
Will it *always* unravel my lock when using stop()?
Under the assumption that B does not throw any exception
except when it gets a ThreadDeath injected.
Is it possible that a ThreadDeath is injected after
lock.lock() and before try, so that lock.unlock() is
not called?
You seem to be thinking of lock.lock() as an atomic unit that cannot be
partly executed before a stop. Is that right? If so, do you have any
basis for that assumption? I don't see anything in the relevant code
that would prevent a stop and ThreadDeath.
If that assumption is not justified, you need to consider cases such as
the stop hitting with the return from lock.lock() as the next statement.
The lock is locked, but control has not returned to your code, and
execution is still outside your try-finally block. Even worse, the stop
may hit in the middle of ReentrantLock.Sync.nonfairTryAcquire(), leaving
the lock in an inconsistent state.
I believe this sort of issue lead to the recognition that stop() could
not be used safely, and the decision get rid of the problem by
deprecating it.
Patricia