gnulib test-lock test can hang on some machines.

[ken@…]

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

I am about to run a full test build using seds to stop this particular test being run. The prurpose of the ticket is so that we can check newer versions of these packages to see if the sed is still required.