Message-ID: <575533cf-bb08-4071-af67-93432bfa71e4@siemens.com>
Date: Fri, 23 May 2025 18:11:32 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
 Alison Chaiken <alison@...-devel.com>, triegel@...hat.com
Cc: corbet@....net, gratian.crisan@...com, rostedt@...dmis.org,
 linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org,
 achaiken@...ora.tech, Florian Bezdeka <florian.bezdeka@...mens.com>,
 Felix Moessbauer <felix.moessbauer@...mens.com>
Subject: Re: [PATCH] Documentation: locking: update libc support status of PI
 futexes

On 23.05.25 17:00, Sebastian Andrzej Siewior wrote:
> On 2025-01-11 10:55:55 [-0800], Alison Chaiken wrote:
>>> 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.
> 
> I've been looking at this again for other reasons and looked at the
> code again…
> 
> Back then we use futex-requeue API and required both futex-object to
> have the PI bit set. This wasn't the case originally, hence the patch by
> Darren which did not make it into the official libc.
> 
> With the rework by Riegel, the mutex within pthread's condvar
> implementation is gone also the usage of the requeue API. The
> pthread_cond_wait()/ pthread_cond_signal() API is back to use futex'
> wait/ wake.
> The glibc comments write something about important ordering constrains.
> The futex wait enqueues the waiter according to its priority. So the
> task with highest priority gets always a front seat. The futex wake
> function wakes always the first waiter in the queue.
> 
> With all this I would say that the glib'c condvar implementation does
> not have any issues since the rework.
> There were a few loops, with a 0 retry counter (basically dead) and they
> have been removed.
> 

That would be good news.

Which would be the minimal glibc version needed then, already 2.25? And
could we ensure that future versions will maintain these properties by
sneaking some related testcase(s) into glibc?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Powered by blists - more mailing lists