RE: TechEd 2006 -- "parallelism is the new OO"

[Denis A Nicole <dan@xxxxxxxxxxxxxxx>]

On Sat, 2 Sep 2006, P.H.Welch wrote:

>   (a) either some other thread acquires the relevant monitor lock,
>       issues a "notify()" and the waiting thread is chosen for
>       release (and, then, has to re-acquire the monitor) ...
>   
>   (b) or some other thread acquires the relevant monitor lock and
>       issues a "notifyAll()", whereupon the waiting thread competes
>       with everyone to re-acquire the monitor ...
>   
>   (c) or some other thread has reference to the waiting "Thread"
>       and invokes "interrupt()" ...
>   
>   (d) or for no reason at all.
> 
> The last clause above is the spurious wakeup.  The Java people swear
> blind that this is a *deliberate* design decision - not a bug resulting
> from broken OS threading support that they didn't fix for some reason.

Perhaps one crude way to look at it is to view wait/notify as an almost 
non-busy polling mechanism. Think of it as an improvement on the interrupt 
mechanisms of early PCs where lost interrupts, as well as spurious 
interrupts, were a problem. Everything had to have a timeout as well as 
accept spurious interrupts.

I do understand correctly, don't I? As the wait and the notify are issued
within the monitor, there is a well-defined total order between all waits
and all notifies on a given object. The Java semantics guarantees that a
notify is delivered to exactly one waiting thread (if there are any) and
that notifyAll is delivered to every one, eventually.

Java guarantees the absence of lost-notify deadlocks, I think?

> PS. do .NET/c# have semantic quirks like (d) and (e) above?

I'm busy looking into some of these details. As I understand it, there are
two .NET memory models, the old ECMA one and the new .NET 2.0 one. I think
they are both different from either Java model and from either the iA32 or
iA64 processor models.

The wait/notify stuff is easier.

The .NET methods for wait/notify are Wait/Pulse. From what I can
understand, Wait responds to Pulse and Interrupt, the latter by throwing
an exception. Monitor.Wait(Object) returns a bool. I don't think it can
ever return false. Does anybody know? False would mean we don't have the
Object lock... I also don't think that spurious wakeups can happen.

Denis A Nicole              WWW:   http://www.hpcc.ecs.soton.ac.uk/~dan
School of Electronics       Email: dan@xxxxxxxxxxxxxxx
       & Computer Science   Phone: +44 23 8059 2703
University of Southampton   Fax:   +44 23 8059 3045
SO17  1BJ
United Kingdom