Re: [PATCH] Documentation: locking: update libc support status of PI futexes

[Alison Chaiken]

On 2025-01-07 07:31, Sebastian Andrzej Siewior wrote:
> On 2024-12-28 10:15:46 [-0800], alison@xxxxxxxxxxxxx wrote:
> > From: Alison Chaiken <alison@xxxxxxxxxxxxx>
> >
> > Update the text of futex-requeue-pi.rst to explain that, because of a
> > conflict between POSIX requirements and ABI constraints, glibc does
> > not support requeueing of PI futexes.  Add some information about
> > librtpi, a library which provides an implementation of condition
> > variables which supports priority inheritance.
>
> Are you sure? My memory is that glibc avoided using the internal mutex.
> The old problem should be gone and pthread_cond_signal() and
> pthread_cond_wait() should work.

Ignoring support for 64-bit time, the last substantive change to 
pthread_cond_wait() and pthread_cond_signal() was Torvald Riegel's  
commit ed19993b5b0d05d62cc883571519a67dae481a14 "New condvar 
implementation that provides stronger ordering guarantees," which fixed 
problems with waking of ineligible futex waiters and with ABA issues 
concerning the futex word.    What the patch does not do is made clear 
by the commit message:

     This condvar doesn't yet use a requeue optimization (ie, on a 
broadcast,
     waking just one thread and requeueing all others on the futex of 
the
     mutex supplied by the program).

What futex-requeue-pi.rst directs is

     In order to support PI-aware pthread_condvar's, the kernel needs to
     be able to requeue tasks to PI futexes.

Riegel and Darren Hart discussed Riegel's patch in at length at the 2016 
RT Summit:

    
https://wiki.linuxfoundation.org/realtime/events/rt-summit2016/schedule

The related glibc bug report by Darren may be found at

    https://sourceware.org/bugzilla/show_bug.cgi?id=11588

The last comment on the bug from 2017 is by Riegel:

    So far, there is no known solution for how to achieve PI support 
given the current constraints we have (eg, available futex operations, 
POSIX requirements, ...).

I ran the bug reproducer posted by Darren in Qemu and found that it did 
not fail.   I'm not sure if the result is valid given the peculiarities 
of Qemu, or whether I made some other mistake.

> > Signed-off-by: Alison Chaiken <alison@xxxxxxxxxxxxx>
>
> Sebastian

-- Alison Chaiken
    Aurora Innovation