Re: Patch: Thread.holdLock implementation in java

[Dalibor Topic]

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