# Re: Thread.stop/destroy

Marianne Mueller (Marianne.Mueller@Eng)
Tue, 30 Jun 1998 10:55:46 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Marianne Mueller: "Re: Crypto example miss-typeo"
- Previous message: sckim@corp.rockwell.com: "Help! on Signed Applet Example"
- Maybe in reply to: Godmar Back: "Thread.stop/destroy"

    Date: Tue, 30 Jun 1998 10:55:46 -0700 (PDT)

    From: Marianne Mueller <Marianne.Mueller@Eng>

    Subject: Re: Thread.stop/destroy

    To: java-security@java0.javasoft.com, gback@cs.utah.edu

--Ostentation_of_Peacocks_679_000
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: oPmOt/0HECT518T8B3g9Pg==

> Hi, this is a question concerning Sun's strategy in dealing with
> uncooperative threads. As of 1.2b3, a conformant application has no
> way of stopping these threads: Thread.stop() is deprecated (and wouldn't be
> effective anyway because ThreadDeath can be caught.) and Thread.destroy
> is not deprecated, but also not implemented. Both have known problems
> regarding damaged data structures and deadlock.
>
> So, what is Javasoft's long-term answer as to what the recommended way to
> kill an uncooperative thread is?

There is no way to kill an uncooperative thread, period. This
has nothing to do with Java. It can't be done in Java, C, or
other reasonably powerful languages. There's nothing JavaSoft
can do. Thread.stop was an unsuccessful attempt to do so.

The JDK 1.2 Thread.stop deprecation white paper clearly stated
why we can't kill uncooperative threads. If anyone has ideas of
how to solve the technical problems, we would be interested to
know.

Refer to
http://java.sun.com/products/jdk/1.2/docs/guide/misc/threadPrimitiveDeprecation.
html

or see attached.

--Ostentation_of_Peacocks_679_000
Content-Type: TEXT/html; name="threadPrimitiveDeprecation.html"; charset=us-ascii; x-unix-mode=0444
Content-Description: threadPrimitiveDeprecation.html
Content-MD5: 7cbBYVLVu+280xFHKAegxQ==

Java Thread Primitive Deprecation White Paper

| # Why JavaSoft is Deprecating `Thread.stop`, `Thread.suspend` and `Thread.resume`

### Why is JavaSoft Deprecating `Thread.stop`?

Because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The 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 may now view these objects in an inconsistent state. Such objects are said to be damaged. When threads operate on damaged objects, arbitrary behavior can result. This behavior may be subtle and difficult to detect, or it may be pronounced. Unlike other unchecked exceptions, `ThreadDeath` kills threads silently; thus, the user has no warning that his program may be corrupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future.

### Couldn't I just catch the `ThreadDeath` exception and fix the damaged object?

In theory, perhaps, but it would vastly complicate the task of writing correct multithreaded code. The task would be nearly insurmountable for two reasons:

1. A thread can throw a `ThreadDeath` exception almost anywhere. All synchronized methods and blocks would have to be studied in great detail, with this in mind.
2. A thread can throw a second `ThreadDeath` exception while cleaning up from the first (in the `catch` or `finally` clause). Cleanup would have to repeated till it succeeded. The code to ensure this would be quite complex.

In sum, it just isn't practical.

### What about `Thread.stop(Throwable)`?

In addition to all of the problems noted above, this method may be used to generate exceptions that its target thread is unprepared to handle (including checked exceptions that the thread could not possibly throw, were it not for this method). For example, the following method is behaviorally identical to Java's `throw` operation, but circumvents the compiler's attempts to guarantee that the calling method has declared all of the checked exceptions that it may throw:

        void sneakyThrow(Throwable t) {
            Thread.currentThread().stop(t);
        }

### What should I use instead of `Thread.stop`?

Most uses of `stop` should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. (This is the approach that JavaSoft's Tutorial has always recommended.)

For example, suppose your applet contains the following `start`, `stop` and `run` methods:

        public void start() {
            blinker = new Thread(this);
            blinker.start();
        }

        public void stop() {
            blinker.stop();  // UNSAFE!
        }

        public void run() {
            Thread thisThread = Thread.currentThread();
            while (true) {
                try {
                    thisThread.sleep(interval);
                } catch (InterruptedException e){
                }
                repaint();
            }
        }

You can avoid the use of `Thread.stop` by replacing the applet's `stop` and `run` methods with:

        public void stop() {
            blinker = null;
        }

        public void run() {
            Thread thisThread = Thread.currentThread();
            while (blinker == thisThread) {
                try {
                    thisThread.sleep(interval);
                } catch (InterruptedException e){
                }
                repaint();
            }
        }

### How do I stop a thread that waits for long periods (e.g., for input)?

That's what the `Thread.interrupt` method is for. The same "state based" signaling mechanism shown above can be used, but the state change (`blinker = null`, in the previous example) can be followed by a call to `Thread.interrupt`, to interrupt the wait:

        public void stop() {
            Thread moribund = waiter;
            waiter = null;
            moribund.interrupt();
        }

For this technique to work, it's critical that any method that catches an interrupt exception and is not prepared to deal with it immediately reasserts the exception. We say reasserts rather than rethrows, because it is not always possible to rethrow the exception. If the method that catches the `InterruptedException` is not declared to throw this (checked) exception, then it should "reinterrupt itself" with the following incantation:

        Thread.currentThread().interrupt();

This ensures that the Thread will reraise the `InterruptedException` as soon as it is able.

### What if a thread doesn't respond to `Thread.interrupt`?

In some cases, you can use application specific tricks. For example, if a thread is waiting on a known socket, you can close the socket to cause the thread to return immediately. Unfortunately, there really isn't any technique that works in general. It should be noted that in most situations where a waiting thread doesn't respond to `Thread.interrupt`, it wouldn't respond to `Thread.stop` either. Such cases include deliberate denial-of-service attacks, and I/O operations for which thread.stop and thread.interrupt do not (yet) work properly.

### Why is JavaSoft is Deprecating `Thread.suspend` and `Thread.resume`?

`Thread.suspend` is inherently deadlock-prone. If the target thread holds a lock on the monitor protecting a critical system resource when it is suspended, no thread can access this resource until the target thread is resumed. If the thread that would resume the target thread attempts to lock this monitor prior to calling `resume`, deadlock results. Such deadlocks typically manifest themselves as "frozen" processes.

### What should I use instead of `Thread.suspend` and `Thread.resume`?

As with `Thread.stop`, the prudent approach is to have the "target thread" poll a variable indicating the desired state of the thread (active or suspended). When the desired state is suspended, the thread waits using `Object.wait`. When the thread is resumed, the target thread is notified using `Object.notify`.

For example, suppose your applet contains the following mousePressed event handler, which toggles the state of a thread called `blinker`:

        Public void mousePressed(MouseEvent e) {
            e.consume();

            if (threadSuspended)
                blinker.resume();
            else
                blinker.suspend();  // DEADLOCK-PRONE!

            threadSuspended = !threadSuspended;
        }

You can avoid the use of `Thread.suspend` and `Thread.resume` by replacing the event handler above with:

        public synchronized void mousePressed(MouseEvent e) {
            e.consume();

            threadSuspended = !threadSuspended;

            if (!threadSuspended)
                notify();
        }

and adding the following code to the "run loop":

                    synchronized(this) {
                        while (threadSuspended)
                            wait();
                    }

The `wait` method throws the `InterruptedException`, so it must be inside a `try ... catch` clause. It's fine to put it in the same clause as the `sleep`. The check should follow (rather than precede) the `sleep` so the window is immediately repainted when the the thread is "resumed." The resulting `run` method follows:

        public void run() {
            while (true) {
                try {
                    Thread.currentThread().sleep(interval);

                    synchronized(this) {
                        while (threadSuspended)
                            wait();
                    }
                } catch (InterruptedException e){
                }
                repaint();
            }
        }

Note that the `notify` in the `mousePressed` method and the `wait` in the `run` method are inside `synchronized` blocks. This is required by the language, and ensures that `wait` and `notify` are properly serialized. In practical terms, this eliminates race conditions that could cause the "suspended" thread to miss a `notify` and remain suspended indefinitely. While the cost of synchronization in Java is decreasing as the platform matures, it will never be free. A simple trick can be used to remove the synchronization that we've added to each iteration of the "run loop." The synchronized block that was added is replaced by a slightly more complex piece of code that enters a synchronized block only if the thread has actually been suspended:

                    if (threadSuspended) {
                        synchronized(this) {
                            while (threadSuspended)
                                wait();
                        }
                    }

The resulting `run` method is:

        public void run() {
            while (true) {
                try {
                    Thread.currentThread().sleep(interval);

                    if (threadSuspended) {
                        synchronized(this) {
                            while (threadSuspended)
                                wait();
                        }
                    }
                } catch (InterruptedException e){
                }
                repaint();
            }
        }

### What about `Thread.destroy`?

`Thread.destroy` has never been implemented. If it were implemented, it would be deadlock-prone in the manner of `Thread.suspend`. (In fact, it is roughly equivalent to `Thread.suspend` without the possibility of a subsequent `Thread.resume`.) We are not implementing it at this time, but neither are we deprecating it (forestalling its implementation in future). While it would certainly be deadlock prone, it has been argued that there may be circumstances where a program is willing to risk a deadlock rather than exit outright.

Copyright © 1995-97 Sun Microsystems, Inc. All Rights Reserved. Please send comments to: jdk-comments@java.sun.com | JavaSoft

--Ostentation_of_Peacocks_679_000--

- Next message: Marianne Mueller: "Re: Crypto example miss-typeo"
- Previous message: sckim@corp.rockwell.com: "Help! on Signed Applet Example"
- Maybe in reply to: Godmar Back: "Thread.stop/destroy"