Re: What is so bad aboud Thread.stop() ?
Arne Vajh=F8j wrote:
taqmcg@gmail.com wrote:
The use of Thread.stop() is strongly deprecated, but I'm a bit confused =
by the explanation given in the documentation: (e.g., http://docs.oracle.co=
m/javase/6/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.htm=
l)
Because it is inherently unsafe. Stopping a thread causes
it to unlock all the monitors that it has locked. (The
Do you know what they mean by a monitor?
monitors are unlocked as the ThreadDeath exception propagates
up the stack.) If any of the objects previously protected by
these monitors were in an inconsistent state, other threads
Inconsistent state is bad.
may now view these objects in an inconsistent state.
Such objects are said to be damaged. When threads operate on
Damaged is bad.
damaged objects, arbitrary behavior can result. This behavior
Arbitrary behavior is bad.
may be subtle and difficult to detect, or it may be pronounced.
Subtle and difficult to detect is bad, really even worse than pronounced, b=
ecause
it confounds one's ability to fix it.
Unlike other unchecked exceptions, ThreadDeath kills threads silently=
;
Killed silently is bad.
thus, the user has no warning that his program may be corrupted.
No warning that the program is corrupted is bad.
The corruption can manifest itself at any time after the actual
damage occurs, even hours or days in the future.
Random timing of corruption is bad.
As I understand this, the ThreadDeath exception is treated exactly as
any other exception -- finally blocks are honored, it can even be
Except for the differences mentioned in the passage you cited.
caught -- that might be thrown unexpectedly. E.g., if we got an
OutOfMemoryError or we happen to explicitly throw a RuntimeException
we're going to see exactly the same behavior with monitors released
progressively as we go up the stack. It's certainly easy enough to
Who said that 'Thread.stop()' release monitors progressively or goes up the=
stack?
catch and rethrow the ThreadDeath in its run method if I really want
to log it and address the one difference.
Who will catch the exception?
So what is the big hullaballoo about? Is there something special
Broken code that fails silently at unexpected times in ways that are diffic=
ult to detect,
let alone diagnose, that causes your program to be useless but you can't fi=
x it.
going on here with Thread.stop(), or is this just a specific instance
Yes.
of the fact the we should be very careful whenever a thread has been
stopped by an unexpected exception?
Even if it were, it wouldn't merit the word "just".
Thread.stop() might be called at any time in the to-be-stopped
thread, and that might be an issue, but at least in principle the
thread that issues the stop could check the to-be-stopped thread and
only stop it at 'appropriate' points where appropriate is defined by
the user.
No, because the starting thread has no insight into where the started threa=
d is,
or what points are appropriate, except for critical sections, which are for=
shit when
a 'stop()' call destroys things.
E.g., suppose I have some concern that a piece of code that I'm about
to run might have an infinite loop in it (say I'm testing somebody
else's regular expression parser with lots of different RE's), but
it's not going to allocate any external resources (e.g., files, DB
connections). I could set/clear a flag as I enter and leave the
suspect code. Could I safely monitor this thread in another thread.
After say 100 seconds if a given expression hasn't parsed can the
monitor thread invoke a Thread.stop() safely if my flag shows that
the RE thread is caught in the parser?
No.
I think this part is the critical part
# If any of the objects previously protected by
# these monitors were in an inconsistent state, other threads
# may now view these objects in an inconsistent state.
There are cases where using it may result in problems.
There may also be cases where it will work fine. But that is
not sufficient to consider something "safe".
Go with the recommended approach of having the external
thread set a flag and the thread itself read it and close
down.
Buy and closely study _Java Concurrency in Practice_ by Brian Goetz, et al.=
You will
not get the in-depth understanding you need from a newsgroup.
--
Lew