bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test-lock hang (not 100% reproducible) on GNU/Linux


From: Bruno Haible
Subject: Re: Test-lock hang (not 100% reproducible) on GNU/Linux
Date: Thu, 22 Dec 2016 22:58:36 +0100
User-agent: KMail/4.8.5 (Linux/3.8.0-44-generic; KDE/4.8.5; x86_64; ; )

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?

Bruno

Attachment: test-lock-avoid-volatile.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]