std::condition_variable::wait_until 的实施
implementation of std::condition_variable::wait_until
我正在阅读 std::condition_variable::wait_until
的 libstdc++ implementation,这是来源:
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;
}
第二个函数调用第一个函数loop.which会做时钟同步operation.So如果我们调用第二个函数,同步操作可能运行很多times.It每次都需要同步时钟吗?我认为代码可以通过同步时钟在第二秒内改进一次 function.Am 对吗?
我认为你是对的。另一方面,使用 wait_until 的假设通常是事件只会稀疏地发生,并且谓词对于除了少数不需要的唤醒实例之外的所有实例都返回 true。因此,重新同步时钟的开销应该是最小的。还请记住,在这种情况下,线程必须被唤醒并已经分页,这可能比查询时钟更昂贵。
是,也不是。
是的,此代码可以优化为在循环时不操纵 time_point
s。但是,我不确定是否真的有必要。
考虑是什么使得谓词 wait_until
循环。
当 notified 时,它检查谓词以查看是否有工作要做。
- 如果谓词returns为真,即条件变量保护的条件为真,
wait_until
returns true
.
- 如果超时,
wait_until
returns 谓词的值,通常为 false
(否则我们会期望 condition_variable
有已通知)。
这只剩下循环实际循环的一种情况:当 condition_variable
被通知,但谓词 returns false
.
这被称为 spurious wakeup 并且几乎不是典型情况,因此不值得优化。
我正在阅读 std::condition_variable::wait_until
的 libstdc++ implementation,这是来源:
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;
}
第二个函数调用第一个函数loop.which会做时钟同步operation.So如果我们调用第二个函数,同步操作可能运行很多times.It每次都需要同步时钟吗?我认为代码可以通过同步时钟在第二秒内改进一次 function.Am 对吗?
我认为你是对的。另一方面,使用 wait_until 的假设通常是事件只会稀疏地发生,并且谓词对于除了少数不需要的唤醒实例之外的所有实例都返回 true。因此,重新同步时钟的开销应该是最小的。还请记住,在这种情况下,线程必须被唤醒并已经分页,这可能比查询时钟更昂贵。
是,也不是。
是的,此代码可以优化为在循环时不操纵 time_point
s。但是,我不确定是否真的有必要。
考虑是什么使得谓词 wait_until
循环。
当 notified 时,它检查谓词以查看是否有工作要做。
- 如果谓词returns为真,即条件变量保护的条件为真,
wait_until
returnstrue
. - 如果超时,
wait_until
returns 谓词的值,通常为false
(否则我们会期望condition_variable
有已通知)。
这只剩下循环实际循环的一种情况:当 condition_variable
被通知,但谓词 returns false
.
这被称为 spurious wakeup 并且几乎不是典型情况,因此不值得优化。