Re: test-pthread-rwlock failure on Pop!_OS 22.04 LTS

[Bruno Haible]

Paul Eggert wrote:
> >1. Install a toolchain for creating binaries linked against musl-libc:
> >   $ sudo apt install musl-gcc
> >2. Create a testdir for the module 'pthread-rwlock'.
> >3. Build it with CC="gcc". You should still see the test failure after
> >   10 minutes.
> >4. Build it with CC="musl-gcc". Run
> >   $ time gltests/test-pthread-rwlock
> > 
> > If 4. takes more than 30 seconds, your OS is probably running on top of
> > a hypervisor, and that is causing the problem.
> > 
> > If 4. takes just a few seconds, it looks like a glibc bug.
> 
> 4. takes just a few seconds on my platform.

Thanks. So, it looks like a glibc bug.

I have investigated this from three different angles.

1) In maint-tools/ I have added a directory test-programs/pthread-rwlock/
   with a test program that analyzes how an implementation of POSIX rwlocks
   handles the wait queue.

   This is based on the same idea as m4/pthread_rwlock_rdlock.m4, but where
   that extracts only a single bit of information about one particular
   situation, the new test program exercises many situations, analyzes them,
   and provides a textual summary.

   Find here attached the results of this analysis.

   glibc ≥ 2.25 with the default pthread_rwlock_t initializer is particular:
   It is the *only* implementation for which the result contains the statement
 "This implementation always prefers readers."

2) I have redone the timings of most platforms, each in a VirtualBox VM with
   paravirtualization set to "minimal" (so as to avoid the bug mentioned in
   ).

   Find here attached the timings.

   While there is sometimes a big difference between the columns "1 CPU" and
   "2 CPUs", it can be attributed to single-thread optimizations. Therefore,
   what we need to look at are the columns "2 CPUs", "4 CPUs", "8 CPUs".
   While some platforms (Cygwin, Solaris 11, gnulib on mingw) show a moderate
   increase of the times in this progression, the result is:
   glibc ≥ 2.25 with the default pthread_rwlock_t initializer is particular:
   It is the *only* implementation for which the times in this progression
   grow by a factor of more than 10.

So far, there is a correlation between the analysis results and the timings.
Is this correlation a causal relation?

3) To investigate this question, I modified the gnulib implementation on mingw
   to prefer readers. Namely, in lib/windows-rwlock.c, lib/windows-timedrwlock.c
   in function glwthread_[timed]rwlock_unlock I changed the line

  if (lock->waiting_writers.count > 0)

   to

  if (lock->waiting_writers.count > 0 && lock->waiting_readers.count == 0)

   As expected, the analysis results are:

 "This implementation always prefers readers."

   And the timings are:

 gnulib on mingw, modified to prefer readers
   1 CPU   2 CPUs  4 CPUs  8 CPUs
   0.787   2.962 385.999   > 7200

   That is, a steep increase in running time from 2 CPUs to 8 CPUs.

This provides enough justification for gnulib to override the glibc behaviour
here. I will therefore go ahead and override
  PTHREAD_RWLOCK_INITIALIZER
  pthread_rwlock_init
  pthread_rwlock_attr_init
to use PREFER_WRITER or PREFER_WRITER_NONRECURSIVE, which both behave in a
sane way even in glibc ≥ 2.25.

We knew about the problem since 2018
,
but had not realized the impact that it has on systems with 8 or more CPUs.
Thanks for your report, Paul!

Bruno

How do the implementations work?

glibc/Linux <2.25 default, glibc/Linux PREFER_WRITER, AIX, Android
  When releasing the last reader lock:
If at least one of the enqueued lock attempts is for reading, the
first one of them is granted.
Otherwise, the first of the waiting write attempts is granted.
  When releasing a writer lock:
If at least one of the enqueued lock attempts is for writing, the
first one of them is granted.
Otherwise, one of the waiting read attempts is granted.
  This implementation does not globally prefer readers, only when releasing
  a reader lock.
  This implementation does not globally prefer writers, only when releasing
  a writer lock.

glibc/Linux PREFER_WRITER_NONRECURSIVE, FreeBSD, Cygwin
  When releasing the last reader lock:
The first of the enqueued lock attempts is granted.
  When releasing a writer lock:
If at least one of the enqueued lock attempts is for writing, the
first one of them is granted.
Otherwise, one of the waiting read attempts is granted.
  This implementation does not prefer readers.
  This implementation does not globally prefer writers, only when releasing
  a writer lock.

glibc/Linux ≥2.25 default
  When releasing the last reader lock:
If at least one of the enqueued lock attempts is for reading, the
first one of them is granted.
Otherwise, the first of the waiting write attempts is granted

Re: We can not run gnulib-tool in the MinGW.

[anlex N]

my prefix=/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/built,
make
install do not work.

me@DOOR UCRT64 /e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make
$ make install
Making install in gllib
make[1]: Entering directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gllib'
make  install-recursive
make[2]: Entering directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gllib'
make[3]: Entering directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gllib'
make[4]: Entering directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gllib'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Leaving directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gllib'
make[3]: Leaving directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gllib'
make[2]: Leaving directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gllib'
make[1]: Leaving directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gllib'
Making install in glm4
make[1]: Entering directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/glm4'
make[2]: Entering directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/glm4'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/glm4'
make[1]: Leaving directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/glm4'
Making install in gltests
make[1]: Entering directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gltests'
make  install-recursive
make[2]: Entering directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gltests'
Making install in .
make[3]: Entering directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gltests'
make[4]: Entering directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gltests'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Leaving directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gltests'
make[3]: Leaving directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gltests'
make[2]: Leaving directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gltests'
make[1]: Leaving directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/gltests'
make[1]: Entering directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make'
make[2]: Entering directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make'
make[1]: Leaving directory
'/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make'

me@DOOR UCRT64 /e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make
$ ls
Makefile  config.h  config.log  config.status  gllib  glm4  gltests  stamp-h1



On Fri, Jul 5, 2024 at 11:33 AM anlex N  wrote:

> However, it can create in the /tmp folder, but can not build, so crazy:
>
> hello@world UCRT64 /tmp/my-testdir2
> $ MSYS2_ENV_CONV_EXCL=* 
> LDFLAGS=/e/workspace/github.com/gnu/ncurses/build/make/built/lib ./configure
> configure: loading site script /etc/config.site
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a race-free mkdir -p... /usr/bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking for gcc... gcc
> checking whether the C compiler works... no
> configure: error: in '/tmp/my-testdir2':
> configure: error: C compiler cannot create executables
> See 'config.log' for more details
> hello@world UCRT64 /tmp/my-testdir2
> $ cat config.log
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
>
> It was created by dummy configure 0, which was
> generated by GNU Autoconf 2.72.  Invocation command line was
>
>   $ ./configure
>
> ## - ##
> ## Platform. ##
> ## - ##
>
> hostname = DOOR
> uname -m = x86_64
> uname -r = 3.5.3.x86_64
> uname -s = MINGW64_NT-10.0-22631
> uname -v = 2024-06-03 06:22 UTC
>
> /usr/bin/uname -p = unknown
> /bin/uname -X = unknown
>
> /bin/arch  = x86_64
> /usr/bin/arch -k   = unknown
> /usr/convex/getsysinfo = unknown
> /usr/bin/hostinfo  = unknown
> /bin/machine   = unknown
> /usr/bin/oslevel   = unknown
> /bin/universe  = unknown
>
> PATH: /ucrt64/bin/
> PATH: /usr/local/bin/
> PATH: /usr/bin/
> PATH: /bin/
> PATH: /c/Windows/System32/
> PATH: /c/Windows/
> PATH: /c/Windows/System32/Wbem/
> PATH: /c/Windows/System32/WindowsPowerShell/v1.0/
> PATH: /usr/bin/site_perl/
> PATH: /usr/bin/vendor_perl/
> PATH: /usr/bin/core_p

Re: We can not run gnulib-tool in the MinGW.

[Bruno Haible]

anlex N wrote:
> my prefix=/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/built,
> make install do not work.

https://www.gnu.org/software/gnulib/manual/html_node/Building-gnulib.html
does not say that "make install" does anything useful in this situation.

What are you trying to do?

Which parts of the manual have you already read?

Re: We can not run gnulib-tool in the MinGW.

[Paul Eggert]

On 7/8/24 06:22, anlex N wrote:

1. After I make successfully, I want to place those built files to
/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/built.


I don't know why that would be useful, but you could use 'cp' to copy 
them whereever you want.


If the goal is to create some sort of library that you can reuse, 
gnulib-tool isn't set up for that directly. It is a source-code library 
only. If you want to create an object-code library you must do it 
yourself, following the instructions in the manual (or looking at other 
examples of how it's done).



2. I have read all parts of the manual.

Because make install does not work, I also tried this command, but
sigprocmask still is not recognized.
[image: image.png]


Please use text to report commands that run and fail, instead of images. 
This is partly for convenience of the reader, partly for security 
reasons. Thanks.

Re: We can not run gnulib-tool in the MinGW.

[Bruno Haible]

anlex N wrote:
>2. I have read all parts of the manual.

Don't lie. (The gnulib manual is too large to read in its entirety by any
individual.)

>1. After I make successfully, I want to place those built files to
>/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/built.

This is not a high-level answer.

> Because make install does not work, I also tried this command, but
> sigprocmask still is not recognized.
> [image: image.png]

The image tells me that you want to port GNU readline to native Windows.

If you were attempting to port some other package to native Windows, I
would recommend to read the gnulib manual's chapter "Invoking gnulib-tool".

But GNU readline is special: it relies heavily on the behaviour of Unix
ttys, as specified by POSIX. Native Windows does not implement Unix ttys,
and Gnulib does not either. Therefore there is no easy way to port GNU
readline to native Windows.

IMO, porting GNU readline to native Windows would require
  - 3 months of work or more
  - by an experienced developer (which you are not).

You will not succeed to port GNU readline to native Windows. Try something
else.

Bruno

Re: We can not run gnulib-tool in the MinGW.

[anlex N]

As you say, only `cp /my-gnulib/you/build/make/gllib/signal.h /e/workspace/
github.com/gnu/readline` ??

On Mon, Jul 8, 2024 at 1:13 PM Bruno Haible  wrote:

> anlex N wrote:
> >2. I have read all parts of the manual.
>
> Don't lie. (The gnulib manual is too large to read in its entirety by any
> individual.)
>
> >1. After I make successfully, I want to place those built files to
> >/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/built.
>
> This is not a high-level answer.
>
> > Because make install does not work, I also tried this command, but
> > sigprocmask still is not recognized.
> > [image: image.png]
>
> The image tells me that you want to port GNU readline to native Windows.
>
> If you were attempting to port some other package to native Windows, I
> would recommend to read the gnulib manual's chapter "Invoking gnulib-tool".
>
> But GNU readline is special: it relies heavily on the behaviour of Unix
> ttys, as specified by POSIX. Native Windows does not implement Unix ttys,
> and Gnulib does not either. Therefore there is no easy way to port GNU
> readline to native Windows.
>
> IMO, porting GNU readline to native Windows would require
>   - 3 months of work or more
>   - by an experienced developer (which you are not).
>
> You will not succeed to port GNU readline to native Windows. Try something
> else.
>
> Bruno
>
>
>
>

Re: We can not run gnulib-tool in the MinGW.

[anlex N]

As you say, I can only run the command: cp
/my-gnulib/you/build/make/gllib/signal.h /e/workspace/
github.com/gnu/readline ??

On Mon, Jul 8, 2024 at 1:58 PM anlex N  wrote:

> As you say, only `cp /my-gnulib/you/build/make/gllib/signal.h /e/workspace/
> github.com/gnu/readline`  ??
>
> On Mon, Jul 8, 2024 at 1:13 PM Bruno Haible  wrote:
>
>> anlex N wrote:
>> >2. I have read all parts of the manual.
>>
>> Don't lie. (The gnulib manual is too large to read in its entirety by any
>> individual.)
>>
>> >1. After I make successfully, I want to place those built files to
>> >/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/built.
>>
>> This is not a high-level answer.
>>
>> > Because make install does not work, I also tried this command, but
>> > sigprocmask still is not recognized.
>> > [image: image.png]
>>
>> The image tells me that you want to port GNU readline to native Windows.
>>
>> If you were attempting to port some other package to native Windows, I
>> would recommend to read the gnulib manual's chapter "Invoking
>> gnulib-tool".
>>
>> But GNU readline is special: it relies heavily on the behaviour of Unix
>> ttys, as specified by POSIX. Native Windows does not implement Unix ttys,
>> and Gnulib does not either. Therefore there is no easy way to port GNU
>> readline to native Windows.
>>
>> IMO, porting GNU readline to native Windows would require
>>   - 3 months of work or more
>>   - by an experienced developer (which you are not).
>>
>> You will not succeed to port GNU readline to native Windows. Try something
>> else.
>>
>> Bruno
>>
>>
>>
>>