Re: [Valgrind-users] valgrind pthreads mutex bug

[Andraz T. <And...@gu...>]

V pet, 30.05.2003 ob 01:37, je Jeremy Fitzhardinge poslal(a):
> On Thu, 2003-05-29 at 16:23, Andraz Tori wrote: 
> > Maybe worth mentioning is, that thread 25 wasn't the thread that created
> > & locked the mutex at the first place, but this should not be an issue,
> > since this is vaild behaviour in pthreads.
> No it isn't.  You can't lock with one thread and unlock with another -
> pthread_mutex_unlock should return EPERM (calling thread does not own
> mutex).

Thanks, I didn't know that. De facto this is vaild behaviour in
pthreads... Everything works as expected if valgrind is not run...

If this is true than mutexes are useless for interthread synchronisation
of 'data ready' states?


> The bug is that Valgrind should flag this as an error.

The whole cinelerra (quite a huge program) is based upon this kind of
behaviour. It uses mutexes in order to synchronize 'data delivery':
When data is ready, the server thread unlocks A-'data ready for
processing mutex' and blocks on B-'data is processed mutex'. Before that
client thread is waiting on blocked A. When server thread unlocks it,
client thread can go on untill it finishes. When it finishes, it locks A
again, unlocks B, and locks (and this time blocks) on A again. Server
thread was waiting on blocking B and since it has now been unlocked by
client, it knows data is ready and can happily continue.

So my question is... would it be possible for Valgrind to support this
bugous behaviour by some switch or something?

The problem is that cinelerra works just fine if it is run without
valgrind... 

Bye
Andraz