|
From: Russ F. <rus...@ho...> - 2004-06-23 18:14:33
Attachments:
vmtest.C
|
Hello,
I am debugging a multithreaded application that uses a C++ wrapper around
POSIX threads and mutexes. In one usage scenario, I have two threads that
deal with a single mutex, one will lock it and the other will unlock it. I
have declared this kind of mutex as PTHREAD_MUTEX_FAST_NP, which permits
this kind of thing.
The other kind of mutex is PTHREAD_MUTEX_ERRORCHECK_NP which results in a
return value of EPERM from the call to pthread_mutex_unlock (and various
other mutex functions) if the unlocker of the mutex is a different thread
than the locker of that mutex. This is useful for debugging certain
mutexes, and I use that, too. As a result, my Mutex class allows me to
specify the type of mutex, and it also carefully checks the results of
pthread_mutex_{un}lock calls and will throw asserts as appropriate.
The problem I'm having is that a certain FAST mutex, that works well when
the program is run stand-alone, is throwing asserts and behaving like an
ERRORCHECK mutex when I run it with Valgrind. My initial conclusion is that
Valgrind is coercing all mutexes to the ERRORCHECK kind.
I didn't see any mention of this in the documentation; is this normal
behavior? If so, what can I do to inhibit the ERRORCHECK-ification of my
mutexes when Valgrinding?
Attached is sample code that can recreate the problem.
Thanks for your help,
Russ
PS: This is a personal communication from an account that has keyword-based
spam filtering enabled. Please preserve the original subject line when
replying. (Adding "Re:" is okay.)
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-23 21:48:07
|
On Wed, 23 Jun 2004, Russ Fink wrote: > I am debugging a multithreaded application that uses a C++ wrapper around > POSIX threads and mutexes. In one usage scenario, I have two threads that > deal with a single mutex, one will lock it and the other will unlock it. I > have declared this kind of mutex as PTHREAD_MUTEX_FAST_NP, which permits > this kind of thing. Are you sure about that? AFAICT all the FAST attr means is that if a thread relocks an already locked mutex, it will hang forever. What resource told you that FAST mutexes acted this way? I could be wrong, but it doesn't sound standard. > My initial conclusion is that Valgrind is coercing all mutexes to the > ERRORCHECK kind. > [snip] > I didn't see any mention of this in the documentation; is this normal > behavior? Yes. I think you're right that it does coerce all mutexes to a single kind, but I think the kind is a cross between ERRORCHECK and RECURSIVE. > If so, what can I do to inhibit the ERRORCHECK-ification of my mutexes > when Valgrinding? Nothing, short of writing some new code for coregrind/vg_libpthread.c. But, as I said, I'm not sure if your use of FAST mutexes is valid. N |
|
From: Tom H. <th...@cy...> - 2004-06-23 23:06:55
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 23 Jun 2004, Russ Fink wrote:
>
> > I am debugging a multithreaded application that uses a C++ wrapper around
> > POSIX threads and mutexes. In one usage scenario, I have two threads that
> > deal with a single mutex, one will lock it and the other will unlock it. I
> > have declared this kind of mutex as PTHREAD_MUTEX_FAST_NP, which permits
> > this kind of thing.
>
> Are you sure about that? AFAICT all the FAST attr means is that if a
> thread relocks an already locked mutex, it will hang forever. What
> resource told you that FAST mutexes acted this way? I could be wrong, but
> it doesn't sound standard.
Well FAST_NP isn't a mutex type that POSIX defines, so it must be
a linux extension I guess. Certainly none of the defined POSIX mutex
types allows unlocking by a different thread.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-24 00:03:46
|
On Thu, 24 Jun 2004, Tom Hughes wrote: > > Are you sure about that? AFAICT all the FAST attr means is that if a > > thread relocks an already locked mutex, it will hang forever. What > > resource told you that FAST mutexes acted this way? I could be wrong, but > > it doesn't sound standard. > > Well FAST_NP isn't a mutex type that POSIX defines, so it must be > a linux extension I guess. Certainly none of the defined POSIX mutex > types allows unlocking by a different thread. But I'm not sure what Linux extension it is... the LinuxThreads man pages I have mention FAST_NP but don't say you can lock/unlock with different threads. N |
|
From: Igmar P. <mai...@jd...> - 2004-06-27 13:20:19
|
> I am debugging a multithreaded application that uses a C++ wrapper around
> POSIX threads and mutexes. In one usage scenario, I have two threads that
> deal with a single mutex, one will lock it and the other will unlock it. I
> have declared this kind of mutex as PTHREAD_MUTEX_FAST_NP, which permits
> this kind of thing.
Not as I read the manpages. The above flags only specifies what happens
when a thread calls a pthread_mutex_lock() on a mutex it already owns : In
case of PTHREAD_MUTEX_FAST_NP, the thread is simply suspended forever (and
causing a deadlock as a consequence).
The manpage does not say that mutexes can be unlocked by a different
thread. I'm referring to man 3 pthread_mutexattr_init.
The pthread_mutex_init manpage says this about locking an already locked
mutex :
If the mutex is already locked by the calling thread, the
behavior of pthread_mutex_lock depends on the kind of the
mutex. If the mutex is of the ``fast'' kind, the calling
thread is suspended until the mutex is unlocked, thus
effectively causing the calling thread to deadlock.
> The other kind of mutex is PTHREAD_MUTEX_ERRORCHECK_NP which results in a
> return value of EPERM from the call to pthread_mutex_unlock (and various
> other mutex functions) if the unlocker of the mutex is a different thread
> than the locker of that mutex. This is useful for debugging certain
> mutexes, and I use that, too. As a result, my Mutex class allows me to
> specify the type of mutex, and it also carefully checks the results of
> pthread_mutex_{un}lock calls and will throw asserts as appropriate.
If you need a mutex that can be locked / unlocked from different threads
use a POSIX mutex.
Igmar
|