Race condition in TimerTask KillThread test

Gary Adams gary.adams at oracle.com
Wed Nov 9 19:36:17 UTC 2011


  Here's a revised diff for the KillThread timing problem :
    - added current CR# to @bug tag
    - capture the thread from the timer task
    - wait for the timertask thread to be visible to the main thread
      then join the thread before fall through to attempt the second
      timertask schedule call.

diff --git a/test/java/util/Timer/KillThread.java 
b/test/java/util/Timer/KillThread.java
--- a/test/java/util/Timer/KillThread.java
+++ b/test/java/util/Timer/KillThread.java
@@ -23,7 +23,7 @@

  /*
   * @test
- * @bug 4288198
+ * @bug 4288198 6818464
   * @summary Killing a Timer thread causes the Timer to fail silently on
   *          subsequent use.
   */
@@ -31,21 +31,27 @@
  import java.util.*;

  public class KillThread {
+    static Thread tdThread;
      public static void main (String[] args) throws Exception  {
+    tdThread = null;
          Timer t = new Timer();

          // Start a mean event that kills the timer thread
          t.schedule(new TimerTask() {
              public void run() {
+        tdThread = Thread.currentThread();
                  throw new ThreadDeath();
              }
          }, 0);

          // Wait for mean event to do the deed and thread to die.
          try {
+        do {
              Thread.sleep(100);
+        } while(tdThread == null);
          } catch(InterruptedException e) {
          }
+    tdThread.join();

          // Try to start another event
          try {


On 11/ 6/11 08:46 PM, David Holmes wrote:
> On 5/11/2011 8:37 AM, Alan Bateman wrote:
>> On 04/11/2011 15:52, Gary Adams wrote:
>>> :
>>>
>>> I'll attempt a simple fix for the KillThread case by replacing :
>>>
>>> Thread.sleep(100);
>>>
>>> with a simple loop
>>>
>>> do {
>>> Thread.sleep(100);
>>> } while (waiting);
>>>
>>> where the TimerTask runnable will clear the flag
>>> with "waiting = false " once it has been launched.
>>>
>> I don't think this will guarantee that the timer thread will have
>> terminated before the main thread schedules the second event. I think
>> this test would be robust if you capture a reference to the timer thread
>> in the first task and have the main thread wait or poll until it has a
>> reference to the thread. Once it has a reference to the thread then it
>> can wait for it to terminate before attempting to schedule the second task.
>
> Agreed. As soon as waiting is set we can switch back to the main thread and 
> proceed to the next phase of the test - but the timer thread is still alive at 
> that point. If the issue is checking for thread termination then we must track 
> that directly.
>
> David
> -----
>
>> -Alan.




More information about the core-libs-dev mailing list