[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
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
- Patch: Thread.holdLock implementation in java, Dalibor Topic, 2004/06/16
- Re: Patch: Thread.holdLock implementation in java, Archie Cobbs, 2004/06/16
- Re: Patch: Thread.holdLock implementation in java, Dalibor Topic, 2004/06/17
- Re: Patch: Thread.holdLock implementation in java, Archie Cobbs, 2004/06/17
- Re: Patch: Thread.holdLock implementation in java,
Dalibor Topic <=
- Re: Patch: Thread.holdLock implementation in java, Archie Cobbs, 2004/06/18
- Re: Patch: Thread.holdLock implementation in java, Dalibor Topic, 2004/06/18
- Re: Patch: Thread.holdLock implementation in java, Archie Cobbs, 2004/06/18
- Re: Patch: Thread.holdLock implementation in java, Dalibor Topic, 2004/06/18
Re: Patch: Thread.holdLock implementation in java, Steven Augart, 2004/06/18
Re: Patch: Thread.holdLock implementation in java, Mark Wielaard, 2004/06/28