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

Groups > comp.lang.java.programmer > #24981

Re: What is so bad aboud Thread.stop() ?

Show all headers | View raw

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.

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web