[concurrency-interest] spurious wakeups semantics

Joshua Bloch josh at bloch.us
Fri Nov 4 16:19:51 EST 2005


As I understand it, the wording was due to Butehof, and he knew full
well what he was doing.  He simply thought the API led to better
client code.  But you can check with Butenhof, and get the answer
straight from the horse's mouth.

       Josh

On 11/4/05, Jeremy Manson <jmanson at cs.purdue.edu> wrote:
> Alexander Terekhov wrote:
> > Jeremy Manson <jmanson at cs.purdue.edu> wrote:
> > [...]
> >
> >>>: The POSIX rationale shows a piece of broken code and uses that to
> >>>: justify the possibility of spurious wakeups.
> >>>
> >>>I have no idea what piece of broken code in the POSIX rationale David
> >>>was talking about.
> >>>
> >>
> >>Okay.  I was specifically thinking of the one on this page:
> >>
> >> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_signal.html
> >
> > Ah that. Well, do you see anything truly broken in
> >
> > http://www.terekhov.de/DESIGN-futex-CV.cpp
> > http://www.terekhov.de/DESIGN-futex-CV-with-async.cancelable-wait.txt
> >
> > then? ;-)
> >
>
> Actually, I was just using the word "broken" to quote David.  As far as
> I am concerned, code that is "broken" is code that does not work
> according to spec.  It is therefore impossible for code that is
> specifically listed in the spec to be broken.
>
> It is, of course, possible for a spec to be broken, but that is a
> different issue.
>
> I was just re-asking the original question - what was the original
> rationale for spurious wakeups?  The code described in the paper that
> you indicated was the same as the code on the POSIX page.  David implied
> there was something mysterious and ancient which required spurious
> wakeups, and existed prior to the POSIX spec.  Anyone know what it was?
>
>                                         Jeremy
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>



More information about the Concurrency-interest mailing list