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. > What happens if you use those bits on an older kernel, will there be > an ENOSYS error? Because that would allow us to try the new form, and > fallback to the old. Glibc's nptl-init.c calls futex(.., FUTEX_WAIT_BITSET | FUTEX_CLOCK_REALTIME | FUTEX_PRIVATE_FLAG, ..) and sets __have_futex_clock_realtime based on whether it gets ENOSYS back or not so it looks like it is possible to determine whether support is available. The only such check I can find in libstdc++ is in filesystem/std-ops.cc fs::do_copy_file which can try sendfile(2) on each invocation but then automatically falls back to copying by steam. In that case, the overhead of the potentially-failing sendfile system call is small compared to copying the file. Doing such a check in _M_futex_wait_until means one system call if FUTEX_CLOCK_REALTIME is supported, but three system calls if it is not supported. If we found a way to cache the answer in a thread-safe and cheap manner then this could be avoided. Do you think it's worth trying to cache whether FUTEX_CLOCK_REALTIME is available? Thanks. Mike.
