From: Darryl Green (green_at_[hidden])
Date: 2001-09-18 05:03:45
> From: William Kempf [mailto:williamkempf_at_[hidden]]
> Threads never wait. They block. A thread blocking is always
> a side effect
> (until you introduce suspend() and resume() operations).
> When you call
> condition::wait() the *side* effect is that the thread
> blocks, while the
> cause (the actual action taking place) is the condition waiting for a
> signal. If you try and argue that the thread waits for the
> condition then I
> can also turn around and argue that the thread waits for the
> mutex to be
> locked. Doing this turns the operations completely around
> from what they
> are, making the side effect the action and the action the side effect.
Is your point that as you can argue this either way the use of the word wait
in this context is meaningless, or was your first assertion that threads
never wait really what you meant?
FWIW I don't particularly care what the name is - synchronisation object
semantics are hardly the sort of things you are going to guess from the name
(well I'm not). I also think that ultimately it is threads that wait on
things (wait queues for synchronisation primitive objects in particular).
But note that I said "wait on". While they are waiting on something they are
blocked. However it is also relevant that in many cases most synchronisation
calls don't cause a thread to wait on anything/block because the state of
the synchronisation object at the time is such that blocking is not required
(ie. nothing else is holding the mutex or whatever). This means that an
awful lot of synchronisation calls do nothing to the current thread (or try
not to). Which comes around to, who cares what the name is, but making the
"wait" or similar function a member of the synchronisation object makes an
awful lot of sense to me. From watching most of the related discussions, I
think the presence of sleep has led people along some interesting if not
very fruitful paths. Of course, if one were not sleeping but waiting on a
timer object, that would be quite different...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk