Re: Patch: Thread.holdLock implementation in java

[Archie Cobbs]

Dalibor Topic wrote:
> > 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.

Dalibor you get an A+ for research :-)

So it's clear that now they have resolved the issue as allowing
spurious wakeups, but it's also clear that in the past this was
not made clear (like a lot of other "small details" in the spec).

Personally, I think that nothing should ever be "spurious", but
it looks like I already lost that argument :-)

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com