Re: [Valgrind-users] valgrind pthreads mutex bug

[Jeremy F. <je...@go...>]

On Thu, 2003-05-29 at 17:28, Andraz Tori wrote:

> well.. i don't know why it works. but fact is that the whole program
> (heavily multithreaded) is written in such manner, and up to now there
> were no problems with it...
> Maybe it is not what POSIX says, but it seems that it works... 

That's an illusion.  There's no certainty until you fix your code.  I
suspect that even if pthread mutexes were working in the way you think
they should, your code would still have race-conditions and/or be
deadlock-prone.

Condition variables are pretty easy to use: a pthread_cond_t is always
paired with a pthread_mutex_t.  To sleep on one, waiting for an event to
happen, you use:

        pthread_mutex_lock(&mutex);
        while(!test_condition()) {
        	// cond_wait() atomically released the mutex and
        	// goes to sleep on the condvar
        	pthread_cond_wait(&condvar, &mutex);
        }
        // act on event
        pthread_mutex_unlock(&mutex);

At the other end, when you want to generate your event, you do:

        pthread_mutex_lock(&mutex);
        set_condition_true();
        pthread_cond_signal(&condvar);	// or cond_broadcast()
        pthread_mutex_unlock(&mutex);
        
> Does this mean that pthreads do not do what they should? i don't know. I
> am not an expert, just an user with a problem, so i am sorry if i say
> something stupid. :)

By default pthread mutexes are "fast" which means they don't check for
errors, and don't report them; they just behave in undefined ways.  It
so happens in this case it seems to be behaving in the way you expect,
but you can't rely on it: someone might upgrade their library and
completely break the program.

If you create an error-checking pthread mutex, it should start reporting
errors.

        J