id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
4055	gnulib test-lock test can hang on some machines.	ken@…	lfs-book@…	"Specifically, on my current AMD Kaveri - it uses 100% of all the cores, until killed (first time, it did that for several hours).
The old version of the test has been problematic from time to time, and often was very slow on large machines.

This has been fixed upstream in gnulib [https://github.com/coreutils/gnulib/commit/b20e8afb0b2cc9548fac073d71fcd19ede29ce60]
and the iomportant part of that change is
{{{
#define EXPLICIT_YIELD 1
 
 /* Whether to use 'volatile' on some variables that communicate information
-   between threads.  If set to 0, a lock is used to protect these variables.
-   If set to 1, 'volatile' is used; this is theoretically equivalent but can
-   lead to much slower execution (e.g. 30x slower total run time on a 40-core
-   machine.  */
+   between threads.  If set to 0, a semaphore or a lock is used to protect
+   these variables.  If set to 1, 'volatile' is used; this is theoretically
+   equivalent but can lead to much slower execution (e.g. 30x slower total
+   run time on a 40-core machine), because 'volatile' does not imply any
+   synchronization/communication between different CPUs.  */
 #define USE_VOLATILE 0
}}}

i.e. it now mentions sempaphore or lock.

Affected files -

 coreutils
  gnulib-tests/test-lock.c
 findutils
  tests/test-lock.c
 gettext
  gettext-tools/gnulib-tests/test-lock.c

  gettext-runtime/tests/test-lock.c

  The latter has an offset of 111 lines

I am about to run a full test build using seds to stop this particular test being run. The purpose of the ticket is so that we can check newer versions of these packages to see if the sed is still required."	task	closed	normal	Future	Book	SVN	normal	fixed