archive/jdk
1
0
Fork 0
mirror of https://github.com/openjdk/jdk.git synced 2025-08-27 06:45:07 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

8320532: Remove Thread/ThreadGroup suspend/resume

Browse source 
Reviewed-by: dholmes, jpai, sspitsyn, smarks
This commit is contained in:
Alan Bateman 2023-12-08 07:10:20 +00:00
parent cb7e3d263a
commit af5c49226c
8 changed files with 36 additions and 350 deletions
Download patch file Download diff file Expand all files Collapse all files

170
src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html
View file

@ -1,6 +1,6 @@
<!doctype html>
<!--
Copyright (c) 2005, 2022, Oracle and/or its affiliates. All rights reserved.
Copyright (c) 2005, 2023, Oracle and/or its affiliates. All rights reserved.
DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
This code is free software; you can redistribute it and/or modify it
@ -158,173 +158,5 @@ wouldn't respond to <code>Thread.stop</code> either.</em> Such
cases include deliberate denial-of-service attacks, and I/O
operations for which thread.stop and thread.interrupt do not work
properly.</p>
<hr>
<h2>Why are <code>Thread.suspend</code> and
<code>Thread.resume</code> deprecated and the ability to suspend or
resume a thread removed?</h2>
<p><code>Thread.suspend</code> was inherently deadlock-prone. If the
target thread held a lock on a monitor protecting a critical
system resource when it is suspended, no thread could access the
resource until the target thread was resumed. If the thread intending
to resume the target thread attempted to lock the monitor prior
to calling <code>resume</code>, deadlock resulted. Such deadlocks
typically manifest themselves as "frozen" processes.</p>
<hr>
<h2>What should I use instead of <code>Thread.suspend</code> and
<code>Thread.resume</code>?</h2>
<p>As with <code>Thread.stop</code>, 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 <code>Object.wait</code>. When
the thread is resumed, the target thread is notified using
<code>Object.notify</code>.</p>
<p>For example, suppose your applet contains the following
mousePressed event handler, which toggles the state of a thread
called <code>blinker</code>:</p>
<pre>
private boolean threadSuspended;
Public void mousePressed(MouseEvent e) {
e.consume();
if (threadSuspended)
blinker.resume();
else
blinker.suspend(); // DEADLOCK-PRONE!
threadSuspended = !threadSuspended;
}
</pre>
You can avoid the use of <code>Thread.suspend</code> and
<code>Thread.resume</code> by replacing the event handler above
with:
<pre>
public synchronized void mousePressed(MouseEvent e) {
e.consume();
threadSuspended = !threadSuspended;
if (!threadSuspended)
notify();
}
</pre>
and adding the following code to the "run loop":
<pre>
synchronized(this) {
while (threadSuspended)
wait();
}
</pre>
The <code>wait</code> method throws the
<code>InterruptedException</code>, so it must be inside a <code>try
... catch</code> clause. It's fine to put it in the same clause as
the <code>sleep</code>. The check should follow (rather than
precede) the <code>sleep</code> so the window is immediately
repainted when the thread is "resumed." The resulting
<code>run</code> method follows:
<pre>
public void run() {
while (true) {
try {
Thread.sleep(interval);
synchronized(this) {
while (threadSuspended)
wait();
}
} catch (InterruptedException e){
}
repaint();
}
}
</pre>
Note that the <code>notify</code> in the <code>mousePressed</code>
method and the <code>wait</code> in the <code>run</code> method are
inside <code>synchronized</code> blocks. This is required by the
language, and ensures that <code>wait</code> and
<code>notify</code> are properly serialized. In practical terms,
this eliminates race conditions that could cause the "suspended"
thread to miss a <code>notify</code> and remain suspended
indefinitely.
<p>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:</p>
<pre>
if (threadSuspended) {
synchronized(this) {
while (threadSuspended)
wait();
}
}
</pre>
<p>In the absence of explicit synchronization,
<code>threadSuspended</code> must be made <code>volatile</code> to ensure
prompt communication of the suspend-request.</p>
The resulting <code>run</code> method is:
<pre>
private volatile boolean threadSuspended;
public void run() {
while (true) {
try {
Thread.sleep(interval);
if (threadSuspended) {
synchronized(this) {
while (threadSuspended)
wait();
}
}
} catch (InterruptedException e){
}
repaint();
}
}
</pre>
<hr>
<h2>Can I combine the two techniques to produce a thread that may
be safely "stopped" or "suspended"?</h2>
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 <code>stop</code> method merely sets
the state variable (<code>blinker</code>) 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.
<p>To rectify this situation, the <code>stop</code> 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
<code>run</code> and <code>stop</code> methods look:</p>
<pre>
public void run() {
Thread thisThread = Thread.currentThread();
while (blinker == thisThread) {
try {
Thread.sleep(interval);
synchronized(this) {
while (threadSuspended &amp;&amp; blinker==thisThread)
wait();
}
} catch (InterruptedException e){
}
repaint();
}
}
public synchronized void stop() {
blinker = null;
notify();
}
</pre>
If the <code>stop</code> method calls <code>Thread.interrupt</code>, as
described above, it needn't call <code>notify</code> as well, but it
still must be synchronized. This ensures that the target thread
won't miss an interrupt due to a race condition.
</body>
</html>