[PATCH 2/5] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait

[Jonathan Wakely]

On 12/01/18 14:18 +0100, Torvald Riegel wrote:
>On Tue, 2018-01-09 at 17:54 +0000, Mike Crowe wrote:
>> On Tuesday 09 January 2018 at 13:50:54 +0000, Jonathan Wakely wrote:
>> > On 07/01/18 20:55 +0000, Mike Crowe wrote:
>> > > The futex system call supports waiting for an absolute time if
>> > > FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT. Doing so provides two
>> > > benefits:
>> > >
>> > > 1. The call to gettimeofday is not required in order to calculate a
>> > >   relative timeout.
>> > >
>> > > 2. If someone changes the system clock during the wait then the futex
>> > >   timeout will correctly expire earlier or later. Currently that only
>> > >   happens if the clock is changed prior to the call to gettimeofday.
>> > >
>> > > According to futex(2), support for FUTEX_CLOCK_REALTIME was added in the
>> > > v2.6.28 Linux kernel and FUTEX_WAIT_BITSET was added in v2.6.25. There is
>> > > no attempt to detect the kernel version and fall back to the previous
>> > > method.
>> >
>> > I don't think we can require a specific kernel version just for this.
>>
>> What is the minimum kernel version that libstdc++ requires? Since it's
>> already relying on NPTL it can't go back earlier than v2.6, but I suppose
>> that's a while before v2.6.28.
>
>I'm not aware of any choice regarding this, but Jonathan will know for
>sure.

I don't think we currently have a documented minimum, although there
is an implied one, which I guess is 2.6.0 ... I can't think of
anything else that places requirements on the kernel. Apart from NPTL
we use SYS_futex and SYS_clock_gettime, but there are alternative code
paths for both of those.

>Generally, I think choosing a minium kernel version might be helpful, in
>particular if we want to optimize more often specifically for Linux
>environments; this may become more worthwhile in the future, for example
>when we look at new C++ features such as parallel algorithms, or
>upcoming executors.
>The gthreads abstraction may is a nice goal, but we can benefit a lot
>from knowing what the underlying platform really is.

Agreed. Gthreads is the cause of a few problems for libstdc++.

>Another option might be to require a minimum glibc version on Linux, and
>build libstdc++ for that.  That would yield a minimum kernel version as
>well, and we may can make use of other things in return such as syscall
>wrappers.

We document that we require glibc 2.3, but that is ancient. It's
possible we've unintentionally introduced an implicit requirement on a
newer version.