JDK-6307490 : (spec thread) Thread.State or related doc should clarify valid notifyAll() behavior
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2005-08-08
  • Updated: 2010-05-10
  • Resolved: 2007-11-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Relates :  
Description
what's thread state after it goes out of wait set but cannot win the competition for lock ? the following code gives different answer on Solaris and Windows XP:

class State {
	
	public static void main(String[] args) throws Exception {

		Thread[] ta = new Thread[10];

		for (int i=0; i<10; i++) {
			ta[i] = new Thread() {
				public void run() {
			        	synchronized(Object.class) {
                               			System.out.println(Thread.currentThread().getName() + " enter");
						try {
       		                 	       		 Object.class.wait();
						} catch(Exception e) {
							e.printStackTrace();
						}
                               			System.out.println(Thread.currentThread().getName() + " get lock");
						for(;;);
					}
                        	}
                	};
			ta[i].start();
		}
		Thread.sleep(3000);
		synchronized(Object.class) {
			Object.class.notifyAll();
		}

		Thread.sleep(3000);
		for(int i = 0; i< ta.length; i++) {
			System.out.println(ta[i].getName() + " : " + ta[i].getState());	
		}

	}
}

On both Solaris and Windows, only one thread is RUNNABLE after notifyAll() is called. but on Solaris, the states of other threads are all WAITING while on Windows, the states are all BLOCKED.  As a result, use code depending on Thread.State will not write once, run anywhere.  it will has different behaviour on different platforms.

Comments
EVALUATION As of the fix for CR 6562569 the behavior is still common across all platforms, and the thread state will show BLOCKED. CR 6562569 is currently fixed in JDK7b22 and is planned to be backported to a Java SE 5 and 6 update. Please refer to CR 6562569 for exact update versions. With the change of behavior due to the fix for 6562569 no specification update is required to Thread.State. The reason is highlighted in the following specification for Thread.State.BLOCKED "Thread state for a thread blocked waiting for a monitor lock. A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method ***or reenter a synchronized block/method after calling Object.wait.***" The threads in the testcase are in BLOCKED state as they are trying to reenter a synchronized block after calling Object.wait.
08-11-2007

EVALUATION As of Java 6 there is common behaviour across all patforms, and they will all show the threads as WAITING.
08-06-2007

SUGGESTED FIX +++ Thread.java Mon Nov 27 15:47:38 2006 @@ -1641,11 +1641,13 @@ * perform a particular action. * * For example, a thread that has called <tt>Object.wait()</tt> * on an object is waiting for another thread to call * <tt>Object.notify()</tt> or <tt>Object.notifyAll()</tt> on - * that object. A thread that has called <tt>Thread.join()</tt> + * that object. In response to notifyAll a given thread may or may not + * be observed with a state other than WAITING. + * A thread that has called <tt>Thread.join()</tt> * is waiting for a specified thread to terminate. */ WAITING,
27-11-2006

EVALUATION The difference in behavior noted in the description is not a defect or a violation of Java specifications. Implementations are free to resume all notified threads (with all but one proceeding to block on the monitor) or maintain all but one in a waited state. Sun's Java SE implementation currently uses the former approach on Windows and the latter approach on Solaris and Linux. Although this might change in Sun's Java SE in the future other implementations are absolutely free to use either approach. But the doc for Thread.State can be clarified to explain that threads getting notification may move to RUNNABLE or BLOCKED or remain in WAITING.
11-08-2005