Re: Patch: Thread.holdLock implementation in java

[Dalibor Topic]

Hi Archie,

Archie Cobbs wrote:
> Dalibor Topic wrote:
>
> > I don't think Java's threading model guarantees that. The new Java 
> > Memory model spec explicitely allows spurious wakeups, from what I've 
> > seen by googling their mailing list.
> >
> > In any case JDK 1.5's javadoc is very clear that spurious wakepus can 
> > happen. See
> > http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#wait(long)
>
>
> That description is ambiguous. It seems to me that "spurious wakeups"
> are an artifact of certain programming practices, not the VM itself.
>
> E.g., I don't see spurious wakeups listed in the four bullet points that
> descripe the possible wakeup conditions, which seems like the more
> normative list. The fact that they refer to books about good programming
> practice would seem to bolster my point.
>
> So at best, it's not clear what the "spec" is. I'd be conservative.
>
> (In any case, it's not a big deal to me personally because JC already
> implements this method natively).

Wait, I've got more :) The JSR 133 (the java memory model) drafts 
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf explicitely list 
spurious wakeups, page 38.

"Otherwise, the following sequence occurs: 1. Thread t is added to the 
wait set of object m, and performs n unlock actions on m. 2. Thread t 
does not execute any further Java instructions until it has been removed 
from m s wait set. The thread may be removed from the wait set due to 
any one of the following actions, and will resume sometime afterward.
  A notify action being performed on m in which t is selected for 
removal from the wait set.
  A notifyAll action being performed on m.
  An interrupt action being performed on t.
  If this is a timed wait, an internal action removing t from m s wait 
set that occurs after at least millisecs milliseconds plus nanosecs 
nanoseconds elapse since the beginning of this wait action.
  An internal action by the Java JVM implementation. Implementations 
are permitted, although not encouraged, to perform  spurious wake-ups 
 to remove threads from wait sets and thus enable resumption without 
explicit Java instructions to do so. Notice that this provision 
necessitates the Java coding practice of using wait only within loops 
that terminate only when some logical condition that the thread is 
waiting for holds."

Looking at the pthreads spec, yep, pthread_cond_wait explicitely allows 
spurious wakeups 
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_wait.html 
:

"When using condition variables there is always a Boolean predicate 
involving shared variables associated with each condition wait that is 
true if the thread should proceed. Spurious wakeups from the 
pthread_cond_timedwait() or pthread_cond_wait() functions may occur. 
Since the return from pthread_cond_timedwait() or pthread_cond_wait() 
does not imply anything about the value of this predicate, the predicate 
should be re-evaluated upon such return."

Finally, from the Bug Database for Java: 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4308396

"Evaluation        

The spec should and will be clarified to indicate that spurious wakeups 
can occur.  This is one of the many reasons that wait should *always* be 
used inside a loop (See Item 50 in Bloch's "Effective Java.")

Note that this does not affect the JLS, which no longer contains the 
specifications for the core libraries.  It will affect only the 
documentation of the Object.wait method.

 address@hidden  2003-01-21"

Looks like a bug/omission in the spec to me. I  particular after reading 
a lot of the mail on the Java memory model mailing list regarding 
spurious wakeups. Some people have been fighting hard against them being 
explicitely allowed in the specification while others have heavily 
argued for it;)

See http://www.cs.umd.edu/~pugh/java/memoryModel/archive/1721.html

"Spurious wakeups should always have been allowed.
There was no deliberate intent in the API docs to preclude spurious
wakeups, the lack of mention of them was simply an omission. I wish we
had fixed this back in 1996/1997 but we didn't. :( "

from David Holmes, for example. There are also some nice quotes from 
Doug Lea in the mailing list archives.

cheers,
dalibor topic