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 ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
