On 22/12/16 21:58, Bruno Haible wrote: > Pádraig Brady wrote: >> There was a recent enough report on helgrind reporting issues with it: >> https://lists.gnu.org/archive/html/bug-gnulib/2015-07/msg00032.html > > I would view this as a false positive. The test uses some 'volatile' > variables to communicate among threads, and 'valgrind --tool=helgrind' > does not know about it. There are no mentions of 'volatile' in the > helgrind documentation http://valgrind.org/docs/manual/hg-manual.html, > and there are similar reports at > https://sourceforge.net/p/valgrind/mailman/valgrind-users/thread/5038A955.6060108%40acm.org/#msg29721076 > >> I've seen this test take a minute or so on a 40 core system. > > The running time is a different problem. I observe a long running time > with "#define EXPLICIT_YIELD 0". But the default is "#define EXPLICIT_YIELD > 1". > > When I use the attached patch to avoid the use of 'volatile' and replace it > by a lock, like explained in > http://stackoverflow.com/questions/10091112/using-a-global-variable-to-control-a-while-loop-in-a-separate-thread, > it does not change the run time that I observe on a 4-core system: > > $ time ./test-lock > Starting test_lock ... OK > Starting test_rwlock ... OK > Starting test_recursive_lock ... OK > Starting test_once ... OK > > real 0m1.770s > user 0m1.240s > sys 0m10.268s > > Can someone test how this looks like on a 40-core system?
Wow that's much better on a 40 core system: Before your patch: ================= $ time ./test-lock Starting test_lock ... OK Starting test_rwlock ... OK Starting test_recursive_lock ... OK Starting test_once ... OK real 1m32.547s user 1m32.455s sys 13m21.532s After your patch: ================= $ time ./test-lock Starting test_lock ... OK Starting test_rwlock ... OK Starting test_recursive_lock ... OK Starting test_once ... OK real 0m3.364s user 0m3.087s sys 0m25.477s thanks! Pádraig
