Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-13 07:51:40

> - some lock in my code requires
> lock/unlock mutex + set event call
> - in Programming with POSIX Threads
> lock/unlock mutex + CV management
> I am by no means a threading expert but from the above I can not make
> deduction that event's price is higher.

your code does require set/reset to be done with
mutex locked to achieve correct behavior.

with condition variables you do not have to
do signal with mutex locked to achieve correct
behavior (actually, signalling after mutex.unlock
should result in more efficient execution).. it
has some special meaning, however. on uniprocessor
with priority scheduling you could achieve predictable
scheduling doing signaling with mutex locked. that is
what "hard-realtime" applications sometime really need..

> Anyway, I have mentioned event-based solutions just to object that it
> always result either to race conditions or to CV-equivalent.

well, i think it does ;) WaitForMultiple( mutex,event...)
is a sort of inefficient monitor which should better be
implemented as CV-based "equivalent" (another solution
could be based on SignalAndWait "equivalent" but then you
would have a problem with respect to win32 thread suspension,


Boost list run by bdawes at, gregod at, cpdaniel at, john at