implementation of std::condition_variable::wait_until

implementation of std::condition_variable::wait_until

本文关键字：variable wait until condition of std implementation      更新时间：2023-10-16

我正在阅读std::condition_variable::wait_until的libstdc++实现，这里是源代码:

template<typename _Clock, typename _Duration>
  cv_status
  wait_until(unique_lock<mutex>& __lock,
     const chrono::time_point<_Clock, _Duration>& __atime)
  {
    // DR 887 - Sync unknown clock to known clock.
    const typename _Clock::time_point __c_entry = _Clock::now();
    const __clock_t::time_point __s_entry = __clock_t::now();
    const auto __delta = __atime - __c_entry;
    const auto __s_atime = __s_entry + __delta;
    return __wait_until_impl(__lock, __s_atime);
  }
template<typename _Clock, typename _Duration, typename _Predicate>
  bool
  wait_until(unique_lock<mutex>& __lock,
     const chrono::time_point<_Clock, _Duration>& __atime,
     _Predicate __p)
  {
    while (!__p())
      if (wait_until(__lock, __atime) == cv_status::timeout)
        return __p();
    return true;
  }

第二个函数调用循环中的第一个函数。它会做时钟同步操作。因此，如果调用第二个函数，同步操作可能会运行多次。有必要每次都同步时钟吗?我认为代码可以通过同步时钟只在第二个功能中进行一次改进。我说的对吗?

我认为你是对的。另一方面，使用wait_until的假设通常是事件只会稀疏地发生，并且除了少数不需要的唤醒实例外，谓词对所有唤醒实例返回true。因此，重新同步时钟的开销应该是最小的。还请记住，在这种情况下，线程必须已经被唤醒并分页，这可能比查询时钟更昂贵。

是，也不是。

是的，这段代码可以优化为在循环时不操作time_point s。然而，我不确定这是否真的有必要。

考虑是什么使谓词wait_until循环。

当收到通知时，它检查谓词，看是否有工作要做。

  1. 如果谓词返回true，即条件变量保护的条件为true，则wait_until返回true。
  2. 如果超时，wait_until返回谓词的值，通常是false(否则我们会期望condition_variable已经被通知)。

这样就只剩下一种情况，即当通知了condition_variable，但谓词返回false时，循环才真正循环。

这就是所谓的虚假唤醒，几乎不是典型的情况，所以它并不真正值得优化。

相关文章：