[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: |
Thu, 17 Jun 2004 15:11:44 +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've implemented VMThread.holdLock in java. It's is probably quite slow,
and wakes up the ocassional thread without much use, but hey, it's in
java, so that's one less method to implement. OK to commit?
Java in theory guarantees that threads are woken up only when
notified via notify(), though not all VMs follow this (typically
because they rely on pthread_cond variables, which don't provide
this guarantee). So it your implementation potentially could produce
bugs in otherwise correct programs.
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)
Also check out doug lea's book on concurrent programming,2nd edition,
section 3.2.3:
http://www.awprofessional.com/articles/article.asp?p=31539&seqNum=2
"Condition checks must be placed in while loops. When an action is
resumed, the waiting task doesn't know whether the condition it is
waiting for is actually true; it only knows that it has been woken up.
So, in order to maintain safety properties, it must check again.
As a matter of programming practice, this style should be used even if
the class contains only a single instance of wait that waits for a
single condition. It is never acceptable to write code that assumes an
object is in some particular state when it resumes after a given wait.
One reason is that such code could fail just because some other
unrelated object invoked notify or notifyAll on the target object by
mistake. (These are public methods defined on all objects.)
Additionally, it is wise to avoid breakage in the case of spurious
wakeups in which waits are released by the system without any explicit
call to a notification method4. However, a more important consideration
is that without re-evaluation, such code will start failing in peculiar
ways if people define additional methods (perhaps in subclasses of your
class) that also use waits and notifications for other purposes."
For another reference, see Joshua Bloch's Effective Java, Item 50:
Never invoke wait outside a loop. [1]
So I think all my implementation could do is to expose bugs in programs
where developers made flawed assumptions about the threading model.
Which is, well, their problem ;)
cheers,
dalibor topic
[1] I've got most of my references from
http://www.cs.rug.nl/~wim/pub/whh241b.pdf
- 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 <=
- 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, 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