[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 18:02:02 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040608 |
Archie Cobbs wrote:
Dalibor you get an A+ for research :-)
Thanks Archie ;)
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).
Yep.[1]
Personally, I think that nothing should ever be "spurious", but
it looks like I already lost that argument :-)
I've got a reference for that, too :)
http://www.lambdacs.com/cpt/FAQ.html#Q94
"Spurious wakeups may sound strange but on some multiprocessor systems,
making condition wakeup completely predictable might substantially slow
all condition variable operations. [Butenhof]"
"Perhaps more importantly, your own program's logic can introduce
spurious wakeups which cannot be eliminated. This can start happening as
soon as there are more than two threads.
You see, a condition waiting thread which has been signaled may have to
compete with another thread in order to re-acquire the mutex. If that
other thread gets the mutex first, it can change the predicate, so that
when finally the original thread acquires it, the predicate is false.
This is also a spurious wakeup, for all purposes. To make this form of
spurious wakeup go away, the semantics of condition variables would have
to change in troublesome ways, back to the original monitors and
conditions concept introduced by Quicksort father C. A. R. Hoare. Under
Hoare's monitors and conditions signaling a condition would atomically
transfer the monitor to the first task waiting on the condition, so that
woken task could just assume that the predicate is true: if
(!predicate()) wait(&condition); /* okay */"
"Also, such atomic transfers of lock ownership are wasteful, especially
on a multiprocessor; the ownership transfer spans an entire context
switch from one task to another, during which that lock is not available
to other tasks. The switch can take thousands of cycles, inflating the
length of a small critical region hundreds of times!"
cheers,
dalibor topic
[1] It has taken both C and C++ around 15 years to get standardized, and
get somewhat well specified. So I'd expect a nice Java standard by 2010 ;)
- 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, 2004/06/18
- 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, Steven Augart, 2004/06/18
Re: Patch: Thread.holdLock implementation in java, Mark Wielaard, 2004/06/28