Re: [Valgrind-users] Multicore/multithreading and memory trace

[Dave G. <go...@mc...>]

On Jan 6, 2010, at 8:54 PM, tom fogal wrote:

> Side note to the valgrind devs: does the documentation need to be
> updated here?  The last paragraph in "Support for Threads" (linked
> below) says that the "use of atomic instruction sequences in shared
> memory between processes will not work reliably", yet the 3.5.0
> release notes say that the "lock" prefix on certain instructions is
> now respected [1].  Due to the ambiguity between threads and processes
> (i.e., clone), I'm not sure if this is referring to shared address
> spaces in threads (in which case it probably needs updating) or atomic
> instructions on data in sysv/posix shmem -- i.e. shm_open'd memory.
> I've never heard of anyone using the latter, but then again I don't
> interact with many people that use even posix shared memory anyway.
>
> -tom
>
> [1] http://valgrind.org/docs/manual/dist.news.html

FWIW, MPICH2 uses atomic instructions in posix mmap'ed shared memory  
to manipulate some lock-free queues for communication.  OpenMPI  
probably does too, although I'm not particularly familiar with OMPI  
internals.

The release notes also say that "communication with other processes  
[...] through shared memory and coordinated with such atomic  
instructions" should work:

-------8<------
* Genuinely atomic support for x86/amd64/ppc atomic instructions

   Valgrind will now preserve (memory-access) atomicity of LOCK-
   prefixed x86/amd64 instructions, and any others implying a global
   bus lock.  Ditto for PowerPC l{w,d}arx/st{w,d}cx. instructions.

   This means that Valgrinded processes will "play nicely" in
   situations where communication with other processes, or the kernel,
   is done through shared memory and coordinated with such atomic
   instructions.  Prior to this change, such arrangements usually
   resulted in hangs, races or other synchronisation failures, because
   Valgrind did not honour atomicity of such instructions.
-------8<------

So I suspect that last paragraph in "Support for Threads" isn't right  
about the atomic instruction support.

-Dave