keywords
- c++11 std::condition_variable 使用之坑: 时间跳变时，timeout超时时间和预期不一致，有可能无法超时退出
- steady_clock 与 system_clock
- CLOCK_MONOTONIC 与 CLOCK_REALTIME
- ...
0 引言
上一次讲述了 c++ std::mutex 之坑，这次，还是要讲述一下c++使用过程中的巨坑：std::contition_variable wait_for()接口之坑
1 wait_for()
std::condition_variable 是c++ 提供的条件变量，用于实现多线程之间的同步，使用也非常简单，如下：
std::mutex mutex_;
std::unique_lock lock(mutex_);
std::condition_variable condition_;
condition_.wait_for(lock, std::chrono::milliseconds(1000UL));
wair_for()接口的功能是：
如果没有调用notify() 或者 notify_all() ，会一直等到超时时间，wait_for()接口才会结束阻塞
就是这么简单的接口，却藏着坑：
内部使用的是system_clock,系统时间跳变时，并不会按照预期的超时时间退出阻塞
1.1 wait_for() spec
官方的说明
The standard recommends that a steady clock be used to measure the duration. This function may block for longer than timeout_duration due to scheduling or resource contention delays.
官方指出这个接口需要steady clock，但是，预期并不是这样（大家自己可以自己实践看下，写一个脚本设置系统时间跳变即可）
1.2 wait_for() 与 steady_clock/system_clock
std::condition_variable 是gcc编译器提供的，在gcc 10之前，系统使用的还是system_clock，到了gcc 10 及以后，才开始使用steady_clock，下面我们看看gcc某次的提交代码
--- a/libstdc++-v3/include/std/condition_variable
+++ b/libstdc++-v3/include/std/condition_variable
@@ -66,6 +66,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
class condition_variable
{
typedef chrono::system_clock __clock_t;
+ typedef chrono::steady_clock __steady_clock_t;
typedef __gthread_cond_t __native_type;
#ifdef __GTHREAD_COND_INIT
@@ -144,11 +145,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
wait_for(unique_lock& __lock,
const chrono::duration<_Rep, _Period>& __rtime)
{
- using __dur = typename __clock_t::duration;
+ using __dur = typename __steady_clock_t::duration;
auto __reltime = chrono::duration_cast<__dur>(__rtime);
if (__reltime < __rtime)
++__reltime;
- return wait_until(__lock, __clock_t::now() + __reltime);
+ return wait_until(__lock, __steady_clock_t::now() + __reltime);
}
template
部分提交commin
1.3 how to fix (by gcc) ?
既然gcc 10更新了，那要修复这个问题，自然是可以通过更新gcc的版本实现，但是，steady clock 功能依赖 一个接口 pthread_cond_clockwait，该接口是在glibc 2.30版本才加入进来的
On 15/07/19 17:47 +0100, Mike Crowe wrote:
The pthread_cond_clockwait function was recently added[1] to glibc, and is
due to be released in glibc 2.30.
如何查看glibc版本:
ldd --version
输出如下:（前2行的打印， glibc的版本为2.27）
ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
Copyright (C) 2018 Free Software Foundation, Inc.
因此，通过更新gcc版本来解决这个还是比较重的
1.4 fixed
c++ 使用比较方便，但是提供给使用者的灵活性也比较少了。 所以，既然c++走不通，可以绕回c去解决这个问题：通过c的pthread库可以自己封装一个condition_variable接口，我提供一个简单版本的代码，抛砖引玉：
class condition_variable {
public:
enum class ClockType {
CLOCK_SYSTEM = 0,
CLOCK_STEADY = 1,
};
condition_variable(ClockType type) : type_(type) {
pthread_mutex_init(&mutex_, NULL);
pthread_condattr_init(&attr_);
if (ClockType::CLOCK_STEADY == type) {
pthread_condattr_setclock(&attr_, CLOCK_MONOTONIC);
} else {
pthread_condattr_setclock(&attr_, CLOCK_REALTIME);
}
pthread_cond_init(&cond_, &attr_);
future_signal = false;
}
~condition_variable() {
pthread_mutex_destroy(&mutex_);
pthread_condattr_destroy(&attr_);
pthread_cond_destroy(&cond_);
}
int wait_for(long wait_ns) {
struct timespec ts;
int ret;
if (ClockType::CLOCK_STEADY == type_) {
clock_gettime(CLOCK_MONOTONIC, &ts);
} else {
clock_gettime(CLOCK_REALTIME, &ts);
}
long ns = ts.tv_nsec + wait_ns;
ts.tv_nsec = ns % 1000000000;
ts.tv_sec += ns / 1000000000;
pthread_mutex_lock(&mutex_);
if (!future_signal) {
ret = pthread_cond_timedwait(&cond_, &mutex_, &ts);
} else {
ret = 0;
}
future_signal = false;
pthread_mutex_unlock(&mutex_);
return ret;
}
void notify_all() {
pthread_mutex_lock(&mutex_);
future_signal = true;
pthread_cond_broadcast(&cond_);
pthread_mutex_unlock(&mutex_);
}
void notify() {
pthread_mutex_lock(&mutex_);
future_signal = true;
pthread_cond_signal(&cond_);
pthread_mutex_unlock(&mutex_);
}
private:
pthread_mutex_t mutex_;
pthread_condattr_t attr_;
pthread_cond_t cond_;
ClockType type_;
bool future_signal;
};
使用上，跟c++有点不同，不需要传入std:: unique_lock,传入的时间是 ns（PS:想要接口跟std::condition_variable一致，自己重载接口即可）
参考
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00190.html
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=023cee968b768ec0dfcbd35373d6195332d5dd76