|
From: Bart V. A. <bar...@gm...> - 2009-06-07 10:05:11
|
There is a section in the manual that may have to be updated, namely section 2.7 (Support for Threads). Currently this section contains the following text: <quote> Your program will use the native libpthread, but not all of its facilities will work. In particular, synchronisation of processes via shared-memory segments will not work. This relies on special atomic instruction sequences which Valgrind does not emulate in a way which works between processes. Unfortunately there's no way for Valgrind to warn when this is happening, and such calls will mostly work. Only when there's a race will it fail. Valgrind also supports direct use of the clone() system call, futex() and so on. clone() is supported where either everything is shared (a thread) or nothing is shared (fork-like); partial sharing will fail. Again, any use of atomic instruction sequences in shared memory between processes will not work reliably. </quote> Regarding atomic instructions: some atomic instructions are already supported by Valgrind 3.4, namely the LOCK prefix on x86/amd64 and load locked / store conditional on ppc. Direct use of clone(), futex() etc. will confuse the thread checking tools. Bart. |
|
From: Julian S. <js...@ac...> - 2009-06-07 10:48:45
|
> Regarding atomic instructions: some atomic instructions are already > supported by Valgrind 3.4, namely the LOCK prefix on x86/amd64 and > load locked / store conditional on ppc. It depends what you mean by "supported". 3.4 is no different from earlier releases in the 3.x series: it accepts LOCK-prefixed insns and passes (kludgey) hints to the tool that they are LOCK-prefixed. Ditto for LL/SC on ppc. But it doesn't preserve the atomicity in the generated code, so the stuff about synchronisation via shared memory is still correct. This gives some very bad behaviour (basically, failure) for eg MPI tasks on the same node, trying to communicate via shared memory. Or, as has been observed on FreeBSD, synchronisation failures between Valgrindised userspace code and the kernel. branches/DCAS fixes this; it really does preserve atomicity all the way through. J |