[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TechEd 2006 -- "parallelism is the new OO"
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