Hi Bart,
>
> I had a look at the file thread_wrappers_pthread.h. I was surprised to
> find a class with the name Mutex that has both a mutex and a condition
> variable as members.
This is made to implement methods like LockWhen that are equivalent to a
sequence
MU.Lock(); while(cond==false)) CV.Wait(); ANNOTATE_COND_WAIT
Consider it as a syntax sugar.
If you don't use methods like LockWhen, Mutex/CondVar is *exactly* the same
as pthread_mutex_t/pthread_convar_t.
> Are you aware of the monitor concept that was
> defined by C.A.R. Hoare ? See e.g.
> http://en.wikipedia.org/wiki/Monitor_(synchronization)<http://en.wikipedia.org/wiki/Monitor_%28synchronization%29>
>
Sort of :)
>
> Furthermore, using a condition variable by itself (class CondVar) is
> *very* error prone and can easily introduce race conditions. A pthread
> condition variable should always be used in combination with a
> pthread mutex.
Sure. CondVar::Signal()/Wait() should always be called under Mutex.
If this is not the case, the test is incorrect.
--kcc
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
