Re: stop() boundaries
On 12/26/2010 5:06 AM, 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.
They also say in the documentation that ThreadDeath will
unravel synchronized statements. So under the hood they
must have some boundaries and some finally blocks.
So when I use the native monitors, I will have what
stop() boundaries here?
A;
synchronized (obj) {
B;
}
C;
Assume I am now using something like:
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.
It is possible that stop() causes the exception to be thrown just before
"lock.unlock" is executed, but after B has executed. So, your "finally"
may be bypassed. Oops.
Even worse, it could be that your lock is *half* unlocked, because it
isn't expecting to be interrupted in the middle of its operation, but
Thread.stop() does just that.
So, just don't do it. There are good reasons its been deprecated.
Is it possible that a ThreadDeath is injected after
lock.lock() and before try, so that lock.unlock() is
not called?
Bye
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>