JDK-4027382 : Cannot distinguish timeout from notification in Object.wait()
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.1,1.2.1,1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,solaris_2.4,solaris_2.5
  • CPU: generic,sparc
  • Submitted: 1997-01-22
  • Updated: 2017-08-11
  • Resolved: 1997-07-08
Related Reports
Duplicate :  
JDK-4365973 - want Object.wait(timeout) that throws exception on timeout
Duplicate :  
JDK-4031615 - Object.wait(long timeout) method should throw an exception when timeout expires
Relates :  
JDK-6176773 - Object.wait(long) should return a long not a void
Description
When Object.wait() returns, there is no direct way to tell whether the
object was notified or whether the timeout occurred.

Customer suggests reporting timeouts by throwing a subclass of
InterruptedException.
Comments
SUGGESTED FIX ----- Begin Included Message ----- >From ###@###.### Tue Jan 21 17:29 EST 1997 From: David Holmes <###@###.###> To: "'###@###.###'" <###@###.###> Subject: Provide a timeout exception for wait/join Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Lines: 31 Content-Type: text/plain; charset="us-ascii" Content-Length: 1451 The current semantics for wait/join allow a timeout value to be specified after which time the operation will return. The problem with the current implementation is that there is no direct way to tell if the return was due to a notify or a timeout. It would make sense for these operations to throw a TimeoutException if the timeout does indeed occur. I would propose that TimeoutException be derived from InterruptedException as: 1. This is semantically correct as a timeout is an interruption from a watchdog timer. 2. It requires no change to the signature of join/wait so will not cause a compatibility problem. 3. As client code must catch or throw an InterruptedException anyway no existing code will need to add a try/catch or throws clause to allow compilation. 4. The only changes to existing code will be to remove workarounds for this limitation. Existing threading models such as POSIX/pthreads, Solaris threads and win32 threads all return either an error upon a timeout occurring. I would have expected Java to do the same thing - using an exception as the preferred method rather than an error value. -- Regards, David Holmes Microsoft Research Institute Building E6A Room: 347 School of Maths, Physics,Comp. & Elec. Phone: +61 2 9850 6343 Macquarie University, FAX: +61 2 9850 9529 Sydney, NSW 2109, Australia http://www.mri.mq.edu.au/~dholmes ----- End Included Message -----
11-06-2004
PUBLIC COMMENTS When Object.wait() returns, there is no direct way to tell whether the object was notified or whether the timeout occurred.
10-06-2004
EVALUATION It makes little sense to throw an exception in the case of a timeout, as this causes an undesirable transfer of control. When you wake up from a timed wait, the first thing you typically want to check is whether the condition you were waiting for is true, not how you were woken up. It is quite possible that you got woken by a signal (or a spurious wakeup) and the condition is not true; it is also possible that you got woken by a timeout, but the condition happens to be true by the time you wake up and get the lock. It's also possible that you got woken up by something other than a timeout, but the specified time interval has elapsed by the time you woke up. In summary, it would have been nice if we returned the requisite bit (true -> we timed out, false -> we woke up for some other reason). As the reporter suggests, pthreads does provide this information. Unfortunately, we can't do that without changing the signature of the function. On the bright side, this information really isn't terribly useful. Much more useful is 1) Is the condition we were wating for true? 2) How long have we been waiting? 1 can be checked directly, and 2 can be computed if the thread records the current time before going to sleep. This is a fine workaround, so I see no reason to pursue this. joshua.bloch@Eng 1997-07-08
08-07-1997