Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24854 > unrolled thread

What is so bad aboud Thread.stop() ?

Back to article view | Back to comp.lang.java.programmer

Contents

  What is so bad aboud Thread.stop() ? taqmcg@gmail.com - 2013-07-31 06:36 -0700
    Re: What is so bad aboud Thread.stop() ? Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-07-31 18:31 +0200
    Re: What is so bad aboud Thread.stop() ? Arne Vajhøj <arne@vajhoej.dk> - 2013-07-31 12:35 -0400
      Re: What is so bad aboud Thread.stop() ? Lew <lewbloch@gmail.com> - 2013-07-31 14:13 -0700
        Re: What is so bad aboud Thread.stop() ? usvirtualobservatory@gmail.com - 2013-08-01 07:38 -0700
          Re: What is so bad aboud Thread.stop() ? Lew <lewbloch@gmail.com> - 2013-08-01 14:07 -0700
            Re: What is so bad aboud Thread.stop() ? Steven Simpson <ss@domain.invalid> - 2013-08-01 23:15 +0100
              Re: What is so bad aboud Thread.stop() ? taqmcg@gmail.com - 2013-08-01 16:16 -0700
                Re: What is so bad aboud Thread.stop() ? "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-08-02 18:35 +0100
                  Re: What is so bad aboud Thread.stop() ? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-08-03 19:21 -0700
                Re: What is so bad aboud Thread.stop() ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-02 21:58 -0400
                  Re: What is so bad aboud Thread.stop() ? taqmcg@gmail.com - 2013-08-03 05:08 -0700
    Re: What is so bad aboud Thread.stop() ? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-07-31 21:09 -0700
      Re: What is so bad aboud Thread.stop() ? usvirtualobservatory@gmail.com - 2013-08-01 08:00 -0700
        Re: What is so bad aboud Thread.stop() ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-01 11:25 -0400
          Re: What is so bad aboud Thread.stop() ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-01 11:49 -0400
            Re: What is so bad aboud Thread.stop() ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-02 21:51 -0400
          Re: What is so bad aboud Thread.stop() ? taqmcg@gmail.com - 2013-08-01 09:30 -0700
            Re: What is so bad aboud Thread.stop() ? markspace <markspace@nospam.nospam> - 2013-08-01 10:01 -0700
            Re: What is so bad aboud Thread.stop() ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-02 21:55 -0400
    Re: What is so bad aboud Thread.stop() ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-01 18:28 +0300
    Re: What is so bad aboud Thread.stop() ? "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-08-02 18:50 +0100
      Re: What is so bad aboud Thread.stop() ? taqmcg@gmail.com - 2013-08-02 11:34 -0700
        Re: What is so bad aboud Thread.stop() ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-02 22:04 -0400
          Re: What is so bad aboud Thread.stop() ? "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-08-03 10:10 +0100
        Re: What is so bad aboud Thread.stop() ? "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-08-03 10:28 +0100
          Re: What is so bad aboud Thread.stop() ? taqmcg@gmail.com - 2013-08-03 05:00 -0700
            Re: What is so bad aboud Thread.stop() ? blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2013-08-11 17:46 +0000
              Re: What is so bad aboud Thread.stop() ? taqmcg@gmail.com - 2013-08-13 11:47 -0700
                Re: What is so bad aboud Thread.stop() ? blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2013-08-13 20:18 +0000
                  Re: What is so bad aboud Thread.stop() ? Patricia Shanahan <pats@acm.org> - 2013-08-13 13:51 -0700
                    Re: What is so bad aboud Thread.stop() ? blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2013-08-14 22:42 +0000
                  Re: What is so bad aboud Thread.stop() ? taqmcg@gmail.com - 2013-08-13 14:10 -0700
                    Re: What is so bad aboud Thread.stop() ? Lew <lewbloch@gmail.com> - 2013-08-13 15:22 -0700
                      Re: What is so bad aboud Thread.stop() ? Arivald <NOSPAMarivald@interia.pl> - 2013-08-14 01:08 +0200
                        Re: What is so bad aboud Thread.stop() ? markspace <markspace@nospam.nospam> - 2013-08-13 16:45 -0700
                          Re: What is so bad aboud Thread.stop() ? Arivald <NOSPAMarivald@interia.pl> - 2013-08-14 08:42 +0200
                        Re: What is so bad aboud Thread.stop() ? Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-08-14 09:48 +0200
                      Re: What is so bad aboud Thread.stop() ? taqmcg@gmail.com - 2013-08-14 08:55 -0700
                        Re: What is so bad aboud Thread.stop() ? markspace <markspace@nospam.nospam> - 2013-08-14 19:10 -0700
                          Re: What is so bad aboud Thread.stop() ? taqmcg@gmail.com - 2013-08-15 06:51 -0700
                            Re: What is so bad aboud Thread.stop() ? Lew <lewbloch@gmail.com> - 2013-08-15 17:35 -0700
                              Re: What is so bad aboud Thread.stop() ? taqmcg@gmail.com - 2013-08-16 06:30 -0700
                    Re: What is so bad aboud Thread.stop() ? blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2013-08-14 22:43 +0000
                      Re: What is so bad aboud Thread.stop() ? taqmcg@gmail.com - 2013-08-15 12:12 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#24998

On Wednesday, August 14, 2013 10:10:23 PM UTC-4, markspace wrote:
> On 8/14/2013 8:55 AM, taqmcg@gmail.com wrote:
> 
> 
> > The cooperative Thread.interrupt() approach implies that the code
> > that might be interrupted knows about this, i.e., the worker code is
> > aware that there is some monitor.  It needs to  periodically check
> > the interrupt flag and do something.  This couples the invoker to the
> > invoked in a way that's a bit unattractive.
> 
> Several low level APIs in Java check for the interrupt flag, so if your 
> library is calling these methods, it will check for interrupts implicitly.
> Object.wait(), Thread.sleep(), most of the IO library, probably some 
> more which I don't recall at the moment.
> 
> Also, if you're going to be dealing with threads at all, get yourself a 
> copy of Java Concurrency in Practice.  It's *the* state of the art for 
> working with threads in Java.
> 
> I'll also link to this article by its author:
> 
> 
> 
> <http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html>
> 

It's an interesting article, but I think it tends to undercut your thesis that the check for interrupt in some basic calls [I don't think most normal I/O calls are included though, just some NIO ones] means that we don't need to couple the monitoring code and the worker thread.  Since InterruptedException is a declared exception, we need to either declare it in any method that calls these, or we need to handle it in some way -- that's what Goetz is basically talking about. If you want to handle thread interrupts then you will often need to do more than swallow the interrupted exception.  Just for grins, if we consider your worker thread as having three lines of code try, wait and catch, 66% of the worker code had to deal with handling the interrupt -- not especially decoupled.
 
> 
> OTOH hand if your library never makes any calls that do check for the  
> interrupt flag, well I'm pretty sure there's no chance of this working. 
>   I'd still really prefer you find a way to make it work though;  you're 
> spending a lot of time here to implement something that is fundamentally 
> broken (i.e., Thread.stop()).

Which brings us back to my original question: In what way is it 'fundamentally' broken?  That suggests that there is something inherently unsafe and unfixable in all circumstances not just dangerous and easily misused.

Your right though that I need to get the book...

    Regards,
    Tom McGlynn

[toc] | [prev] | [next] | [standalone]

#25010

taq...@gmail.com wrote:
> markspace wrote:
>> Also, if you're going to be dealing with threads at all, get yourself a 
>> copy of Java Concurrency in Practice.  It's *the* state of the art for 
>> working with threads in Java.
> 
>> I'll also link to this article by its author:
>> 
>> <http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html>
> 
> It's an interesting article, but I think it tends to undercut your thesis that the check for interrupt in some basic calls [I don't think most normal I/O calls are included though, just some NIO ones] means that we don't need to couple the monitoring code and the worker thread.  Since InterruptedException is a declared exception, we need to either declare it in any method that calls these, or we need to handle it in some way -- that's what Goetz is basically talking about. If you want to handle thread interrupts then you will often need to do more than swallow the interrupted exception.  Just for grins, if we consider 

Goetz and others point out that you should never swallow InterruptedException, but re-interrupt the 
thread after handling it.

> your worker thread as having three lines of code try, wait and catch, 66% of the worker code had to 
> deal with handling the interrupt -- not especially decoupled.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#25032

On Thursday, August 15, 2013 8:35:39 PM UTC-4, Lew wrote:
> taq...@gmail.com wrote:
> 
> > markspace wrote:
> 
> >> Also, if you're going to be dealing with threads at all, get yourself a 
> 
> >> copy of Java Concurrency in Practice.  It's *the* state of the art for 
> 
> >> working with threads in Java.
> 
> > 
> 
> >> I'll also link to this article by its author:
> 
> >> 
> 
> >> <http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html>
> 
> > 
> 
> > It's an interesting article, but I think it tends to undercut your thesis that the check for interrupt in some basic calls [I don't think most normal I/O calls are included though, just some NIO ones] means that we don't need to couple the monitoring code and the worker thread.  Since InterruptedException is a declared exception, we need to either declare it in any method that calls these, or we need to handle it in some way -- that's what Goetz is basically talking about. If you want to handle thread interrupts then you will often need to do more than swallow the interrupted exception.  Just for grins, if we consider 
> 
> 
> 
> Goetz and others point out that you should never swallow InterruptedException, but re-interrupt the 
> 

Never is a bit too strong.  The referenced article indicates that there is one circumstance under which it's OK to swallow the interrupt -- where the thread is about to terminate.  That's actually the case in the example Mark gave which swallows the exception.  But overall that right and it just emphasizes the point that reliance upon the fact that a few methods will throw an InterruptedException doesn't go very far in getting a thread to terminate.

I did get a chance to look at Java Concurrency in Practice.  It doesn't talk about Thread.stop except in a footnote that says not to use it.  But the only justification given is a reference to the very text that I found to be unconvincing at the start of this thread.  Their view of this isn't surprising.  I suspect these are the very people whose input led the class to be deprecated in the first place -- they may have written that text!  [This doesn't in any way mean to 'deprecate' their comment, just to note that it's likely not an independent statement of the badness of Thread.stop from the deprecation itself.]

Nonetheless there are some interesting tidbits to be gleaned from the their chapter on terminating threads that might be relevant to this discussion.

Overall in discussing thread interrupts they note that one needs to set up a policy for handling interrupts.  The whole chapter is addressing policies for how to handle interrupts and other terminations.  That same would surely be true for Thread.stop.  It could only be used robustly within some clear policy. 

They dismiss the need for preemptive termination of threads with:
 "The cooperative approach is required because we rarely want a task, thread, or service to stop immediately, since that could leave shared data structures in an inconsistent state."  This suggests that a stop policy might include: "we want the thread stopped immediately, and we have no further interest in any shared any data structures".

Finally, in their discussion of the handling of exceptions thrown in threads, they note that task processing threads are the only places where it is appropriate for RunTimeExceptions to be handled.  We have yet another footnote:

"There is some controversy over the safety of this technique; when a thread throws an unchecked exception, the entire application may possibly
be compromised. But the alternative, shutting down the entire application, is usually not practical."

As discussed very early in this thread, it seems like handling Thread.stop is very similar to handling RuntimeExceptions.  It's not coincidental that task managers are the primary area in which I could see Thread.stop being used effectively.  If one is capable of handling a RuntimeException in a thread, it may not be much different handling Thread.stop.

   Regards,
   Tom McGlynn

[toc] | [prev] | [next] | [standalone]

#24981

In article <5f47910f-5450-4578-818c-cac2d4b6f436@googlegroups.com>,
 <taqmcg@gmail.com> wrote:
> On Tuesday, August 13, 2013 4:18:52 PM UTC-4, blmblm @ myrealbox. com wrote:
> > In article <7cb96188-91ce-4c2b-ace8-5eeb1b30815e@googlegroups.com>,
> > 
> >  <taqmcg@gmail.com> wrote:
> > 
> > > On Sunday, August 11, 2013 1:46:49 PM UTC-4, blmblm @ myrealbox. com wrote:
> > 
> > > > In article <ede0c691-85eb-4977-8644-27078248ed9d@googlegroups.com>,
> > 
> > > > 
> > > >  <taqmcg@gmail.com> 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.


Yes, I understood that part -- I was wondering whether part of the danger
might be ill-defined interaction with the memory model.


> 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
> it could 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 the
> memory model, but I am trying to see what is new that Thread.stop brings to
> that consideration versus other mundane and accepted Thread interactions.
> 

Yes ....  I think I'm still not quite getting your point about effects
*before* Thread.stop() is called, but I don't know that it's very
important anyway.

I think the point I might have been overlooking is that you're
proposing to be very careful not to use any objects potentially
modified by the stopped thread, and given that, maybe my concern
about whether their state is visible to other threads is a red
herring.

>   Regards,
>   Tom McGlynn
> 

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [prev] | [next] | [standalone]

#25002

On Wednesday, August 14, 2013 6:43:51 PM UTC-4, blmblm @ myrealbox. com wrote:
> In article <5f47910f-5450-4578-818c-cac2d4b6f436@googlegroups.com>,
> 
...
> 
> Yes ....  I think I'm still not quite getting your point about effects
> *before* Thread.stop() is called, but I don't know that it's very
> important anyway.

Well that was mainly intended to be humorous, but it is important to understand how 'time' flows in the threads.   We don't need to do anything special
until after we've invoked Thread.stop and at least in the two thread case both threads can easily know when to begin being careful.
> 
> 
> 
> I think the point I might have been overlooking is that you're 
> proposing to be very careful not to use any objects potentially
> modified by the stopped thread, and given that, maybe my concern
> about whether their state is visible to other threads is a red
> herring.
> 
...
> 
> B. L. Massingill
> 

Right.  That's one suggestion for how we might do things safely.  That seems feasible to me, even natural.  Typically my threads just do one thing that creates some object.  If I discard the thread, I can ignore what it was starting to create.

   Regards,
   Tom McGlynn

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.java.programmer

csiph-web