Why Are Thread.suspend and Thread.resume Deprecated?

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 that your applet contains the following mousePressed event handler, which toggles the state of a thread called blinker:

private boolean threadSuspended; 

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 preceding event handler with:

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

 threadSuspended = !threadSuspended; 

 if (!threadSuspended) 
 notify(); 
} 

You can also add 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 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 to remain suspended indefinitely.

Although 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 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(); 
 } 
} 

In the absence of explicit synchronization, threadSuspended must be made volatile to ensure prompt communication of the suspend request.

Can I Combine the Two Techniques to Produce a Thread That May Be Safely "Stopped" or "Suspended"?

Yes, it's reasonably straightforward. The one subtlety is that the target thread may already be suspended at the time that another thread tries to stop it. If the stop method merely sets the state variable (blinker) to null, the target thread will remain suspended (waiting on the monitor) rather than exiting gracefully, as it should. If the applet is restarted, multiple threads could end up waiting on the monitor at the same time, resulting in erratic behavior.

To rectify this situation, the stop method must ensure that the target thread resumes immediately if it is suspended. Once the target thread resumes, it must recognize immediately that it has been stopped and exit gracefully. Here's how the resulting run and stop methods look:

public void run() { 
 Thread thisThread = Thread.currentThread(); 
 while (blinker == thisThread) { 
 try { 
 thisThread.sleep(interval); 

 synchronized(this) { 
 while (threadSuspended && blinker==thisThread) 
 wait(); 
 } 
 } catch (InterruptedException e){ 
 } 
 repaint(); 
 } 
} 

public synchronized void stop() { 
 blinker = null; 
 notify(); 
} 

If the stop method calls Thread.interrupt, as described earlier, it needn't call notify as well, but it still must be synchronized. This ensures that the target thread won't miss an interrupt due to a race condition.

Getting Started

Object-Oriented Programming Concepts

Language Basics

Object Basics and Simple Data Objects

Classes and Inheritance

Interfaces and Packages

Handling Errors Using Exceptions

Threads: Doing Two or More Tasks at Once

I/O: Reading and Writing

User Interfaces That Swing

Appendix A. Common Problems and Their Solutions

Appendix B. Internet-Ready Applets

Appendix C. Collections

Appendix D. Deprecated Thread Methods

Appendix E. Reference



The Java Tutorial(c) A Short Course on the Basics
The Java Tutorial: A Short Course on the Basics, 4th Edition
ISBN: 0321334205
EAN: 2147483647
Year: 2002
Pages: 125

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net