Re: [Valgrind-users] Execution of a dirty helper: atomic?

[Philippe W. <phi...@sk...>]

On Sun, 2012-12-30 at 22:45 +0100, Emilio Coppa wrote:
> Thank both of you for your answers.
> 
> 
>         Each CPU core may switch logical threads only at a superblock
>         boundary,
>         but mutual exclusion between threads on different CPU cores is
>         not guaranteed.
>         For some purposes this will look like "interleaving".
> 
> 
> I will be very interested on how memcheck will approach this
> interleaving :)
Currently, the "really" multi-threaded valgrind
(see https://bugs.kde.org/show_bug.cgi?id=301830)
is blocked.

There are many global data structures in Valgrind which are
not thread safe, but I think most of them can easily
be made thread safe (typically by a mutex).

However, the main memcheck data structure (which maintains the V-bit)
is accessed so often that it is not acceptable (perf wise) to use a
mutex.
It is even not ok to use an atomic instruction : first tests have
shown that having one atomic instruction on this path makes a
multi-threaded Valgrind slower than a serialised Valgrind.

So, in summary, there is no solution for a multi-threaded memcheck.
Ideas welcome :).

(a prototype of the "none" tool worked reasonably well in
multi-threaded, but that is quite useless).

Philippe