Questions regarding implementation of std::this_thread::sleep_until


libcxx seems to have a suboptimal implementation of
std::this_thread::sleep_until for Linux.

Currently it's implemented using pthread_cond_timedwait:
template <class _Clock, class _Duration>
sleep_until(const chrono::time_point<_Clock, _Duration>& __t)
  using namespace chrono;
  mutex __mut;
  condition_variable __cv;
  unique_lock<mutex> __lk(__mut);
  while (_Clock::now() < __t)
    __cv.wait_until(__lk, __t);

This leads to unnecessary stores to the stack and useless atomic
operations that can potential cause memory bus traffic. On Linux this
could be implemented using the clock_nanosleep() function with the

For std::chrono::steady_clock there is a specialization:
template <class _Duration>
sleep_until(const chrono::time_point<chrono::steady_clock, _Duration>& __t)
  using namespace chrono;
  sleep_for(__t - steady_clock::now());

This has a race condition where the thread could be preempted after
calling now() but before sleeping. The race window is extremely small,
but will lead to increased jitter in actual deadline. If the thread is
using something like linux SCHED_IDLE or competing with threads using
SCHED_FIFO/SCHED_RR the likelihood of hitting this race could be high.
Using clock_nanosleep() would also help here.

Linux and most BSDs support the clock_nanosleep() function, it makes
sense to add a feature detection for it and use it if supported.

Erik Rigtorp

If you still have interest in fixing that and want to submit a patch, I'd be happy to help review it.


Sorry for the late reply Louis,

I don’t have any interest, I need only efficient sleep on Linux, so it’s easy to work around. Mostly wanted to let people know about this gotcha. Probably most timers are driven from a epoll/kqueue event loop so these C++ APIs are not used much outside demo/example/student code.