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

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

Date	2013-07-31 18:31 +0200
From	Marcel Müller <news.5.maazl@spamgourmet.org>
Newsgroups	comp.lang.java.programmer
Subject	Re: What is so bad aboud Thread.stop() ?
References	<8fe57dc2-a323-4821-941c-4036663cbce5@googlegroups.com>
Message-ID	<51f93bdd$0$6559$9b4e6d93@newsspool4.arcor-online.net> (permalink)
Organization	Arcor

Show all headers | View raw

On 31.07.13 15.36, 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.com/javase/6/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html)

Do you know about race conditions in multi-threaded programming?
Thread.stop() can cause race conditions because it interrupts the thread
at any arbitrary location. So code that is executed under protection of
a mutex (=monitor) can be forced to release the mutex without a chance
to complete its work. This breaks the happens-before relation that the
mutex introduced.

Think of the following pseudo instruction sequence.

// interrupted thread
1. mutex.enter();
2. staticVar = new MyClass();
3. staticVar.setParent(some_parent_window);
4. mutex.exit();

// other thread
1. mutex.enter();
2. if (staticVar == null) continue at step 5
3. MyClass parent = staticVar.getParent();
4. do_somthing_with(parent);
5. mutex.exit();

This fragment is perfectly valid under normal conditions but it has a
race condition if the first thread can be stopped. If it happens that
the first thread is stopped after step 2 then the class referred by
staticVar might only be partially initialized, because Thread.stop
forces the execution of step 4 but not step 3. This causes the other
thread to fail badly because it may use a null reference at its step 4.

Indeed, strictly speaking the above code is not exception safe. I
setParent() throws the result is the same. But most real world code is
not exception safe (at any point). Simply because trivial functions like
getters usually don't throw. In Java most exceptions therefore can't be
thrown without declaration.

> As I understand this, the ThreadDeath exception is treated exactly as any other exception -- finally blocks are honored, it can even be 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 catch and rethrow the ThreadDeath in its run method
> if I really want to log it and address the one difference.

True, but no one expects a program to do anything reasonable after an
out of memory exception. Most likely Java does not reasonable recover
from that anyway, because subsequent new operators are likely to fail too.

> 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?

You could do that under certain conditions.

First accessing any side effects of the interrupted code (like static
vars or modified objects) might result in undefined behavior. You might
ensure this in your case.

Secondly the executing code must not have spawned own threads e.g. for
using more than one CPU core. This cannot be more than a convention,
because you never know what the used libraries do behind the scenes.
E.g. calling an FFT-library might result in parallel threads. It may
also schedule the computing to the graphics hardware if the hardware and
the drivers are suitable for that.

So for testing purposes a separate task is significantly safer. Of
course, if you are testing your own code and you know what you are
doing, just use Thread.stop. Hey, it's just a test case, and if it
succeeds Thread.stop has never been called, so this result is reliable.
But further tests in the same run /might/ not be reliable anymore if you
aborted the test.

Marcel

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