Re: Threads docs updated in CVS

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-13 03:37:55

> Could anything with word "spurious" w/o proofs be
> declared as less dangerous and more easy to use?

yes ;) actually there is nothing (well, almost
nothing) spurious with respect to posix CVs..

posix CVs implement atomic unlock-and-wait
operation (similar to win32 SignalAndWait).

they do not implement "transfer mutex
ownership on signal" operation because
it is really expensive (hurts concurrency/
performance); that is why you have to recheck
the predicate after wakeup (another thread could
have already changed the state of shared data
because this race condition with respect to
signal/relock and other threads is not precluded
by posix CVs).

regards,
alexander.

ps.
http://groups.google.com/groups?as_umsgid=3AF6987B.71CCEF82%40compaq.com

From: Dave Butenhof (David.Butenhof_at_[hidden])
Subject: Re: pthread_cond_wait waking up spuriously?
Newsgroups: comp.programming.threads

Tom Payne wrote:

> Dave Butenhof <David.Butenhof_at_[hidden]> wrote:
> : Patrick Doyle wrote:
> : The intent was to force correct/robust code by requiring predicate
loops. This was
> : driven by the provably correct academic contingent among the "core
threadies" in
> : the working group, though I don't think anyone really disagreed with
the intent
> : once they understood what it meant.
>
> So, "spurious signals" started out as a boogey-man story to frighten
> impressionable programmers into minding ther Ps and Qs.  ;-)

More or less. Good rule to remember. If you can't educate 'em, scare the
heck out of
'em. The results are almost as good, and much easier to achieve. ;-)

> : The second was that it wasn't difficult to abstractly imagine
> : machines and implementation code that could exploit this requirement to
improve
> : the performance of average condition wait operations through optimizing
the
> : synchronization mechanisms.
>
> This is where it gets interesting.  My naive impression is that an
> event can always be turned into a condition (in the sense of
> "predicate") by setting an event-occurred flag.  When one thread
> issues a deliberate signal to a condition variable, it can set a flag
> indicating that a non-spurious signal has occurred, and the signallee
> can check that flag.  It would seem that such a flag could be set and
> checked by the implementation as easily as by the programmer, thereby
> preventing the overhead of spurious context switches and perhaps some
> unnecessary predicate testing.

Not quite that easy, since the issue is really "simultaneous" events across
processors.
You'd need an atomic count rather than just a flag: "so many signals not
yet resulting
in a thread resuming execution". But that, remember, would only account for
internal
thread library "spurious wakes", not application spurious wakes. (Which, in
practice,
are a more significant issue.) The condition variable is not a monitor: the
thread
library doesn't know anything about the application predicate, so
pretending to avoid
spurious wakes seems pointless. If you have to leave a hole in the floor,
make it
obvious; covering it over with thin plaster just guarantees someone's going
to fall in.

Furthermore, an atomic counter isn't free, or even particularly cheap; it's
that sort
of cost we were trying to avoid. Especially since the cost would have
avoided only part
of the problem. (And would have weakened the "scared straight" approach to
teaching
good basic programming practice. ;-) )

/------------------[ David.Butenhof_at_[hidden] ]------------------\
| Compaq Computer Corporation              POSIX Thread Architect |
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/