[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch: Thread.holdLock implementation in java
From: |
Archie Cobbs |
Subject: |
Re: Patch: Thread.holdLock implementation in java |
Date: |
Fri, 18 Jun 2004 09:24:47 -0500 (CDT) |
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
- 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, 2004/06/18
- Re: Patch: Thread.holdLock implementation in java,
Archie Cobbs <=
- 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