This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/5] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait
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.