|
From: Russ F. <rus...@ho...> - 2004-07-02 15:43:07
|
The problem in my original post has been resolved. This message summarizes
the outcome. Since it's been a while, I'm restating my original post:
>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?
Summary - I solved the problem by changing the code from the client
depending on an unlock of a mutex by the execution thread in order to
progress, to waiting on a condition variable and using pthread_cond_signal
in the execution thread to get the client to resume. Everything I have
(since) read indicates this is the way to go. [This is one of the
liabilities of relying solely on man pages.]
Additionally, I have found that in more than one case, Valgrind's
intercepted implementation of threads differs from Linux threads (RH 9,
kernel 2.4.20-19.9, gcc 3.2.2 20030222, libc 2.3.2). The differences are
slight, including return values on certain functions (see my other post) and
the like. IMHO, this is a benefit because I get to debug against a
different implementation of threads making the end result more portable and
robust.
Following are snippets of replies and my comments:
>>>
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.
<<<
This is an important distinction and should be noted for the record.
>>>
I'm not sure if your use of FAST mutexes is valid.
<<<
Yes, and that's been fixed. Thanks. I admit I was wrong. (If my wife is
reading this, don't ever say I can't admit I'm wrong sometimes...)
>>>
Certainly none of the defined POSIX mutex types allows unlocking by a
different thread.
<<<
The Linux implementation and PTHREAD_MUTEX_FAST_NP *does* allow a different
thread to unlock a mutex. ERRORCHECK_NP does *not*.
>>>
This is what a condition variable is designed for, and that would be the
normal way of performing this sort of signalling from one thread to another.
<<<
Correct.
>>>
Carpe quod tibi datum est
<<<
My Latin translator is fried, can someone clarify this??
Thanks again,
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.)
_________________________________________________________________
MSN Life Events gives you the tips and tools to handle the turning points in
your life. http://lifeevents.msn.com
|
|
From: Igmar P. <mai...@jd...> - 2004-07-06 21:13:24
|
> Additionally, I have found that in more than one case, Valgrind's > intercepted implementation of threads differs from Linux threads (RH 9, > kernel 2.4.20-19.9, gcc 3.2.2 20030222, libc 2.3.2). The differences are > slight, including return values on certain functions (see my other post) and > the like. IMHO, this is a benefit because I get to debug against a > different implementation of threads making the end result more portable and > robust. You're sure you're not experiencing the differences between LinuxThreads and NPTL ? RH90 uses NTPL by default, and Valgrind only emulates LinuxThreads, not NPTL. You might try to set LD_ASSUME_KERNEL=2.2.5, and see if the program runs differently. > The Linux implementation and PTHREAD_MUTEX_FAST_NP *does* allow a different > thread to unlock a mutex. ERRORCHECK_NP does *not*. However, don't rely on this to be portable. > Thanks again, > Russ Igmar |
|
From: Tom H. <th...@cy...> - 2004-07-06 21:30:48
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
> > Additionally, I have found that in more than one case, Valgrind's
> > intercepted implementation of threads differs from Linux threads (RH 9,
> > kernel 2.4.20-19.9, gcc 3.2.2 20030222, libc 2.3.2). The differences are
> > slight, including return values on certain functions (see my other post) and
> > the like. IMHO, this is a benefit because I get to debug against a
> > different implementation of threads making the end result more portable and
> > robust.
>
> You're sure you're not experiencing the differences between LinuxThreads
> and NPTL ? RH90 uses NTPL by default, and Valgrind only emulates
> LinuxThreads, not NPTL. You might try to set LD_ASSUME_KERNEL=2.2.5, and
> see if the program runs differently.
Actually valgrind doesn't emulate either, it emaulates pthreads, which
is what both linuxthreads and NPTL are supposed to be implementing.
The need for LD_ASSUME_KERNEL wasn't really to do with NPTL at all, it
was to do with TLS support, and recent versions of valgrind can handle
that just fine.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-06 21:36:42
|
On Tue, 6 Jul 2004, Tom Hughes wrote: > Actually valgrind doesn't emulate either, it emaulates pthreads, which > is what both linuxthreads and NPTL are supposed to be implementing. Yep. But the implementation is probably closer to LinuxThreads, since that's what Valgrind's implementation was based on. For example, various struct layouts mirror those of LinuxThreads. N |
|
From: Julian S. <js...@ac...> - 2004-07-06 23:12:28
|
On Tuesday 06 July 2004 22:31, Tom Hughes wrote: > > > You're sure you're not experiencing the differences between LinuxThreads > > and NPTL ? RH90 uses NTPL by default, and Valgrind only emulates > > LinuxThreads, not NPTL. You might try to set LD_ASSUME_KERNEL=2.2.5, and > > see if the program runs differently. > > Actually valgrind doesn't emulate either, it emaulates pthreads, which > is what both linuxthreads and NPTL are supposed to be implementing. I think Valgrind at least tries to conform to the POSIX pthreads spec, rather mimic LinuxThread's behaviour, which doesn't always conform exactly to the spec. > The need for LD_ASSUME_KERNEL wasn't really to do with NPTL at all, it > was to do with TLS support, and recent versions of valgrind can handle > that just fine. Er, ah, ok. Good. So does that mean we can get rid of the LD_ASSUME_KERNEL hack that the old valgrind startup shell script used to do? Or perhaps it's already gone, post full-virtualisation? J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-06 23:22:45
|
On Wed, 7 Jul 2004, Julian Seward wrote: > Er, ah, ok. Good. So does that mean we can get rid of the > LD_ASSUME_KERNEL hack that the old valgrind startup shell > script used to do? Or perhaps it's already gone, post > full-virtualisation? It's long gone. N |
|
From: Igmar P. <mai...@jd...> - 2004-07-14 14:42:16
|
> I know all that. The point is that under valgrind it will always > be choosing the valgrind libpthread.so and not either of the system > ones! > > What LD_ASSUME_KERNEL normally does is to make it choose between either > /lib/libpthread.so or /lib/i686/libpthread.so or /lib/tls/libpthread.so > depending on the ABI version. But under valgrind it will always be > using /usr/lib/valgrind/libpthread.so which does not have multiple > versions for the different ABIs. Ugh.. I should have thought about this. Ah well, that rules out the NTPL differences :) Igmar |