Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > What is so bad aboud Thread.stop() ?

Reply
Thread Tools

What is so bad aboud Thread.stop() ?

 
 
taqmcg@gmail.com
Guest
Posts: n/a
 
      08-03-2013
On Saturday, August 3, 2013 5:28:41 AM UTC-4, Chris Uppal wrote:
> http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>
>
>
> > unless and until I kill it, I can communicate with it using any standard
> > method for interthread communication (e.g., shared objects).

>
> But that's my point here (or one of them): The objects you use to communicate
> with the other thread are necessarily both shared and mutable by that thread
> (or else how can it use them to communicate ?). Given that, it's hard tomake
> /those objects/ safe if you are considering killing the other thread
> asynchronously -- since it may be in the middle of /using/ (modifying) them
> when it's killed.


You can use objects that are readonly to the stoppable thread to send information to that thread, and use objects that are read by the monitor (or other threads) only after the thread has successfully finished (or at least completed the tasks during which it may be stopped) to get information back.
The fact that I might have stopped the thread in some circumstances doesn'tmean I can't use objects created by it when I do let it finish.

>
> I'm not saying it's impossible to create an efficient, Thread-stop()-safe,
> shared communication channel, but I don't think it's easy (polling is probably
> the best bet). And I doubt if you'll find ant *semi-)"official" ones -- why
> would anyone bother when Thread.stop() is so widely shunned ?
>
>

I wasn't really thinking about a dialog between threads, but that shouldn't
be too hard either. Suppose you use an object X to carry on the dialog, mutable by both threads. No special problems before you stop the thread. After stopping a thread you recognize that X is damaged and throw it away. Any object that the monitor thread can access that could have been mutated by the stopped thread is suspect, but simply discarding them is easy enough.I don't think a damaged object has cooties and affects a program just by being there. It has to be used in some way that lets the damaged state manifest itself. That could be subtle (say it does something in its finalizer), but it should be knowable.

>
> -- chris


Thanks for your comments. I'm playing the devil's advocate here to try to draw out specifics of why it would be so difficult to handle the consequences of stopping a thread, but since it has been, as you say, widely shunned,it doesn't seem like there is too much experience actually using it. Of course the fact that people haven't had to use it does mean that at least most of the time there are alternatives, though some (e.g., a separate JVM) may be very heavyweight.

Regards,
Tom
 
Reply With Quote
 
 
 
 
taqmcg@gmail.com
Guest
Posts: n/a
 
      08-03-2013
On Friday, August 2, 2013 9:58:46 PM UTC-4, Arne Vajh°j wrote:
> On 8/1/2013 7:16 PM, (E-Mail Removed) wrote:
>
> > On Thursday, August 1, 2013 6:15:23 PM UTC-4, Steven Simpson wrote:
>>

> Lew is an experienced programmer.
> He would never waste hours investigating something that is
> known to be a bad solution from the beginning.
>
> Arne


My point is not to disparage anyone here, but to point out that even very skilled programmers sometimes have an incorrect knowledge of how something they haven't used works. That may affect their evaluation of its utility.

Regards,
Tom
 
Reply With Quote
 
 
 
 
Kevin McMurtrie
Guest
Posts: n/a
 
      08-04-2013
In article <(E-Mail Removed)>,
"Chris Uppal" <(E-Mail Removed)-THIS.org> wrote:

> (E-Mail Removed) wrote:
>
> > I think Lew shares the apprehension I had had that it does something
> > magical and brings the thread down instantly, it seems clear that its
> > behavior is dangerous but bounded.

>
> Can the behaviour of Thread.stop() be relied on ? For an API that has been
> deprecated since the early Pleistocene, (and which -- if my very vague memory
> is roughly correct -- has never been implemented correctly anyway) it seems
> that implementers have the right to do practically anything. It's not as if
> we
> haven't been warned.
>
> -- chris


Native thread stopping is definitely implemented in some way. It's
what's called when the JVM is quitting. What's not guaranteed is that
Thread.stop() is connected to it.

You can maybe use Thread.stop() with design patterns based on
compare-and-set. CAS is an atomic operation at the CPU level used for
non-blocking multithreading. It exactly runs or does not run, with
nothing in between. The design is essentially:

ImmutableThing originalThing, newThing;
do
{
originalThing = atomicRef.get();
if (originalThing.hasData(myChanges))
break;
newThing= new ImmutableThing (originalThing, myChanges);
} while (!atomicRef.compareAndSet(originalThing, newThing));

Of course you're still completely screwed if you happen to call
Thread.stop() while some line of code is invoking the ClassLoader or a
static initializer.
 
Reply With Quote
 
blmblm@myrealbox.com
Guest
Posts: n/a
 
      08-11-2013
In article <(E-Mail Removed)>,
<(E-Mail Removed)> wrote:
> On Saturday, August 3, 2013 5:28:41 AM UTC-4, Chris Uppal wrote:
> > (E-Mail Removed) wrote:
> >
> >
> >
> > > unless and until I kill it, I can communicate with it using any standard
> > > method for interthread communication (e.g., shared objects).

> >
> > But that's my point here (or one of them): The objects you use to communicate
> > with the other thread are necessarily both shared and mutable by that thread
> > (or else how can it use them to communicate ?). Given that, it's hard to make
> > /those objects/ safe if you are considering killing the other thread
> > asynchronously -- since it may be in the middle of /using/ (modifying) them
> > when it's killed.

>
> You can use objects that are readonly to the stoppable thread to send
> information to that thread, and use objects that are read by the
> monitor (or other threads) only after the thread has successfully
> finished (or at least completed the tasks during which it may be
> stopped) to get information back. The fact that I might have stopped
> the thread in some circumstances doesn't mean I can't use objects
> created by it when I do let it finish.
>


That *sounds* plausible .... But it occurs to me that assigning values
to variable is no longer a simple matter -- with smart compilers and
caches and so forth, it's hard to be sure when the value will actually
be visible to other threads, which is presumably why the Java memory
model (with its "happens before" and so forth) exists. Can someone who
knows that model comment on how it might apply here?

>
> >
> > I'm not saying it's impossible to create an efficient, Thread-stop()-safe,
> > shared communication channel, but I don't think it's easy (polling is probably
> > the best bet). And I doubt if you'll find ant *semi-)"official" ones -- why
> > would anyone bother when Thread.stop() is so widely shunned ?
> >
> >

> I wasn't really thinking about a dialog between threads, but that
> shouldn't be too hard either. Suppose you use an object X to carry on
> the dialog, mutable by both threads. No special problems before you
> stop the thread. After stopping a thread you recognize that X is
> damaged and throw it away. Any object that the monitor thread can
> access that could have been mutated by the stopped thread is suspect,
> but simply discarding them is easy enough. I don't think a damaged
> object has cooties and affects a program just by being there. It has
> to be used in some way that lets the damaged state manifest itself.
> That could be subtle (say it does something in its finalizer), but it
> should be knowable.
>
> >
> > -- chris

>
> Thanks for your comments. I'm playing the devil's advocate here to
> try to draw out specifics of why it would be so difficult to handle
> the consequences of stopping a thread, but since it has been, as you
> say, widely shunned, it doesn't seem like there is too much experience
> actually using it. Of course the fact that people haven't had to use
> it does mean that at least most of the time there are alternatives,
> though some (e.g., a separate JVM) may be very heavyweight.
>


--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
 
Reply With Quote
 
taqmcg@gmail.com
Guest
Posts: n/a
 
      08-13-2013
On Sunday, August 11, 2013 1:46:49 PM UTC-4, blmblm @ myrealbox. com wrote:
> In article <(E-Mail Removed)>,
>
> <(E-Mail Removed)> wrote:
>
> ...
> > You can use objects that are readonly to the stoppable thread to send
> > information to that thread, and use objects that are read by the
> > monitor (or other threads) only after the thread has successfully
> > finished (or at least completed the tasks during which it may be
> > stopped) to get information back. The fact that I might have stopped
> > the thread in some circumstances doesn't mean I can't use objects
> > created by it when I do let it finish.

>
>
> That *sounds* plausible .... But it occurs to me that assigning values
> to variable is no longer a simple matter -- with smart compilers and
> caches and so forth, it's hard to be sure when the value will actually
> be visible to other threads, which is presumably why the Java memory
> model (with its "happens before" and so forth) exists. Can someone who
> knows that model comment on how it might apply here?
>
>
> B. L. Massingill
>

It's certainly true that the memory model is abstruse, but that's true of interthread communications generally and not specific to killed threads.

If I have an object that is mutable by a thread that I might kill at some point, it would be pretty nifty if the fact that the thread was going to be killed in the future affected it before I killed it...a thiotimoline thread! And after the monitor kills a thread, it seems like discarding all potentially mutated objects should be a pretty robust way to limit the effects.

But I'd agree that if there is a third thread involved, things get a lot more complex -- though again that's true of thread communication generally.

Tom McGlynn





might be killed in the future could affect it before I kill it
 
Reply With Quote
 
blmblm@myrealbox.com
Guest
Posts: n/a
 
      08-13-2013
In article <(E-Mail Removed)>,
<(E-Mail Removed)> wrote:
> On Sunday, August 11, 2013 1:46:49 PM UTC-4, blmblm @ myrealbox. com wrote:
> > In article <(E-Mail Removed)>,
> >
> > <(E-Mail Removed)> wrote:
> >
> > ...
> > > You can use objects that are readonly to the stoppable thread to send
> > > information to that thread, and use objects that are read by the
> > > monitor (or other threads) only after the thread has successfully
> > > finished (or at least completed the tasks during which it may be
> > > stopped) to get information back. The fact that I might have stopped
> > > the thread in some circumstances doesn't mean I can't use objects
> > > created by it when I do let it finish.

> >
> >
> > That *sounds* plausible .... But it occurs to me that assigning values
> > to variable is no longer a simple matter -- with smart compilers and
> > caches and so forth, it's hard to be sure when the value will actually
> > be visible to other threads, which is presumably why the Java memory
> > model (with its "happens before" and so forth) exists. Can someone who
> > knows that model comment on how it might apply here?
> >
> >
> > B. L. Massingill
> >

> It's certainly true that the memory model is abstruse, but that's true of
> interthread communications generally and not specific to killed threads.



Agreed. (Do I seem to be saying otherwise?) Indeed, that's
the point I was trying to make in saying "that's why the Java
memory model exists" -- meaning that without a model, it would
be difficult if not impossible to say anything meaningful about
when one could rely on values being visible to other threads.

>
> If I have an object that is mutable by a thread that I might kill at some
> point, it would be pretty nifty if the fact that the thread was going to be
> killed in the future affected it before I killed it...a thiotimoline thread!



Um, I don't get the connection between this and what I wrote. ?


> And after the monitor kills a thread, it seems like discarding all
> potentially mutated objects should be a pretty robust way to limit the
> effects.
>



Um, yes .... So you're saying if thread A kills thread B, to be
safe thread A should also discard any objects potentially mutated
by thread B?


>
> But I'd agree that if there is a third thread involved, things get a lot more
> complex -- though again that's true of thread communication generally.
>



Third thread? Now I'm really confused.


But to get back to your presumably-safe scenario, in which thread B
finishes normally. It seems reasonable to assume that all values
assigned in thread B should then be visible to other threads.
What I'm wondering, though, is whether that's explicitly required
by the Java memory model. (Yeah, yeah, really I should probably
just go read up on the memory model myself, but I thought someone
else might know, and that this might be an interesting point to
raise anyway.)


>
> Tom McGlynn
>
>
> might be killed in the future could affect it before I kill it
>


--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
 
Reply With Quote
 
taqmcg@gmail.com
Guest
Posts: n/a
 
      08-13-2013
On Tuesday, August 13, 2013 4:18:52 PM UTC-4, blmblm @ myrealbox. com wrote:
> In article <(E-Mail Removed)>,
>
> <(E-Mail Removed)> wrote:
>
> > On Sunday, August 11, 2013 1:46:49 PM UTC-4, blmblm @ myrealbox. com wrote:

>
> > > In article <(E-Mail Removed)>,

>
> > >
> > > <(E-Mail Removed)> wrote:
> > >
> > > ...
> > > > You can use objects that are readonly to the stoppable thread to send
> > > > information to that thread, and use objects that are read by the
> > > > monitor (or other threads) only after the thread has successfully
> > > > finished (or at least completed the tasks during which it may be
> > > > stopped) to get information back. The fact that I might have stopped
> > > > the thread in some circumstances doesn't mean I can't use objects
> > > > created by it when I do let it finish.
> > >

>
> > > That *sounds* plausible .... But it occurs to me that assigning values
> > > to variable is no longer a simple matter -- with smart compilers and
> > > caches and so forth, it's hard to be sure when the value will actually
> > > be visible to other threads, which is presumably why the Java memory
> > > model (with its "happens before" and so forth) exists. Can someone who
> > > knows that model comment on how it might apply here?
> > >
> > > B. L. Massingill

>
> > It's certainly true that the memory model is abstruse, but that's true of
> > interthread communications generally and not specific to killed threads..

>
>
>
>
>
> Agreed. (Do I seem to be saying otherwise?) Indeed, that's
> the point I was trying to make in saying "that's why the Java
> memory model exists" -- meaning that without a model, it would
> be difficult if not impossible to say anything meaningful about
> when one could rely on values being visible to other threads.
>
>
> > If I have an object that is mutable by a thread that I might kill at some
> > point, it would be pretty nifty if the fact that the thread was going to be
> > killed in the future affected it before I killed it...a thiotimoline thread!

>
> Um, I don't get the connection between this and what I wrote. ?
>
> > And after the monitor kills a thread, it seems like discarding all
> > potentially mutated objects should be a pretty robust way to limit the
> > effects.

>
> Um, yes .... So you're saying if thread A kills thread B, to be
> safe thread A should also discard any objects potentially mutated
> by thread B?
>
> > But I'd agree that if there is a third thread involved, things get a lot more
> > complex -- though again that's true of thread communication generally.
> >

>
> Third thread? Now I'm really confused.
>
> But to get back to your presumably-safe scenario, in which thread B
> finishes normally. It seems reasonable to assume that all values
> assigned in thread B should then be visible to other threads.
> What I'm wondering, though, is whether that's explicitly required
> by the Java memory model. (Yeah, yeah, really I should probably
> just go read up on the memory model myself, but I thought someone
> else might know, and that this might be an interesting point to
> raise anyway.)
>
>
> > Tom McGlynn

>
>
> B. L. Massingill
>

Sorry if I have confused things -- I'm not disagreeing with you I think. I'd be delighted to get an informed response that clearly referenced the formal memory model. However my particular issue in this thread is trying to understand what is especially dangerous about using Thread.stop(). The general complexity of inter-thread communications is a given, but not the topic I was hoping to explore.


In the two thread scenario we have four situations to consider:

1. Interactions between two threads where no stop occurs.
- Presumably not affected by Thread.stop()!
Monitor will stop thread:
2. ... but it hasn't happened yet.
In this case it's difficult to see how Thread.stop() can have an
effect before it is called -- unless the effect travels backward in time
hence the reference to thiotimoline. For these two threads there
should not be any difficulty in knowing if we are before or after
the method call (in the case of the monitor) or before or after the
initiation of the ThreadDeath interruption (in the case of the stopped
thread)
3. ...after the Monitor has invoked the stop method.
If any object the thread could have mutated is discarded immediately
upon return from the stop call it's hard to see how any invalid state
could get transferred to the monitor without some real weirdness in
the memory model or some kind of tbd magic.
We do need to make sure that the stopped thread dies.
4. ...While stop is running.
I didn't refer to this in the earlier message, but
the way stop is described, it doesn't actually do anything that should
directly affect the memory (it just throws an exception). But I'd agree
that an informed opinion would be helpful.

My reference to three threads was intended to note that if we had other threads that could see to the objects the stopped thread could mutate, that itcould be harder to ensure that invalid state did not escape, nothing more.

So again, I don't think I'm disagreeing with your basic point regarding thememory model, but I am trying to see what is new that Thread.stop brings to that consideration versus other mundane and accepted Thread interactions.

Regards,
Tom McGlynn
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      08-13-2013
(E-Mail Removed) wrote:
> I am trying to see what is new that Thread.stop brings to that consideration
> versus other mundane and accepted Thread interactions.


Seems to me that
http://docs.oracle.com/javase/6/docs...precation.html
explains it rather well.

I found it fast via
http://lmgtfy.com/?q=Java+dangers+of+Thread.stop

You've cited part of this, presumably from the Javadocs:
"This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the
monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception
propagating up the stack). If any of the objects previously protected by these monitors were in an
inconsistent state, the damaged objects become visible to other threads, potentially resulting in
arbitrary behavior."

I'm not sure what else you need to know here. This is both normative and complete.

--
Lew
 
Reply With Quote
 
Arivald
Guest
Posts: n/a
 
      08-13-2013
W dniu 2013-08-14 00:22, Lew pisze:
> (E-Mail Removed) wrote:
>> I am trying to see what is new that Thread.stop brings to that consideration
>> versus other mundane and accepted Thread interactions.

>
> Seems to me that
> http://docs.oracle.com/javase/6/docs...precation.html
> explains it rather well.
>
> I found it fast via
> http://lmgtfy.com/?q=Java+dangers+of+Thread.stop
>
> You've cited part of this, presumably from the Javadocs:
> "This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the
> monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception
> propagating up the stack). If any of the objects previously protected by these monitors were in an
> inconsistent state, the damaged objects become visible to other threads, potentially resulting in
> arbitrary behavior."
>
> I'm not sure what else you need to know here. This is both normative and complete.
>


So, if You can write thread in a way when it never create "inconsistent
objects" that are accessible from other threads, calling Thread.stop()
will be safe.

And how to make sure such condition?
For example, by using specialized queues for input and output data from
thread. Queues written in a way that guarantee that it never is
inconsistent. Yes, it is possible, using java.util.concurrent.atomic it
is possible to write lock-free and thread safe queues.

http://www.ibm.com/developerworks/library/j-jtp04186/

--
Arivald


 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      08-13-2013
On 8/13/2013 4:08 PM, Arivald wrote:

> And how to make sure such condition?
> For example, by using specialized queues for input and output data from
> thread. Queues written in a way that guarantee that it never is
> inconsistent. Yes, it is possible, using java.util.concurrent.atomic it
> is possible to write lock-free and thread safe queues.
>
> http://www.ibm.com/developerworks/library/j-jtp04186/



That's a clever idea, but I'm not sure I'd want to rely on it working in
production code. How much trouble is it really to not call
Thread.stop()? That's what I see as the principle argument here. I'm
not really convinced of the need for Thread.stop(), so all these
workarounds seem moot.

If one were really desperate, ok I can see having to resort to something
like this, but it seems like there has to be several bad engineering and
management decisions to get there.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
oh perlbal you!!! you got what i need....but you dotn work with 5 16 johannes falcone Perl Misc 6 05-16-2013 08:11 PM
xmp, what to use instead of. myphplists@yahoo.com HTML 9 04-29-2013 03:35 PM
What is the reason for defining classes within classes in Python? vasudevram Python 6 04-24-2013 01:29 PM
what is the advantage of using maven for java standalone app mcheung63@gmail.com Java 13 04-16-2013 01:42 AM
What Linux freeware will blur faces & show all frames of a 30second AVI video? Danny D. Digital Photography 8 04-14-2013 10:18 PM



Advertisments