[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch: Thread.holdLock implementation in java

From: Dalibor Topic
Subject: Re: Patch: Thread.holdLock implementation in java
Date: Fri, 18 Jun 2004 14:59:04 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040608

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

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 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 :

"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:


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;)


"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 topic

reply via email to

[Prev in Thread] Current Thread [Next in Thread]