Re: MT Design Question
"Scott Meyers" <NeverRead@aristeia.com>
This explains also why condition waiting is so tightly related to mutex
locking in boost::thread; studying the mutex-protected data is (often?
always?) the only reliable way for the waiter thread to find out about
the current state of affairs.
Then I don't see how a condvar can be used at all to let the caller know
that it needs to check the state of the callees
IIRC the pthread dox, it states that after you passed the cond, you MUST
evaluate the condition again, as the system may wake up out of order. It's a
QoI issue to not happen often, but must be considered in design.
Yeah, quoting man for pthread_cond:
" The pthreadcondwait() function is used to block on a condition vari-
able. It is called with mutex locked by the calling thread. The mutex
is released and the calling thread is blocked atomically waiting for
the
associated condition to be signalled by another thread. Upon successful
completion the mutex is re-locked and owned by the calling thread. The
predicate associated with the condition variable should be tested and
the
pthreadcondwait() call repeated if necessary.
"
(i.e., if they have returned something). If it blocks on the condvar, it
will reliably wake only if the condvar is notified, but how can it
guarantee that the workers aren't performing their notifies just before it
blocks on the condvar?
It's not a practical problem (discounting people not aware of the quoted
obligation), you evaluate the same original condition the party that
supposedly did the signal had, and go back if not true.
pthread_cond in NOT the condition itself, just a handy way to poll it as few
times as possible.