18

我正在尝试在 C++11 中实现一些跨平台代码。此代码的一部分使用std::condition_variable实现信号量对象。当我需要对信号量进行定时等待时，我使用wait_until或 wait_for。

我遇到的问题是，在基于 POSIX 的系统上，condition_variable 的标准实现似乎依赖于系统时钟，而不是单调时钟（另请参阅：this issue against the POSIX spec）

这意味着如果系统时钟更改为过去的某个时间，我的条件变量将阻塞的时间比我预期的要长得多。例如，如果我希望我的 condition_variable 在 1 秒后超时，如果有人在等待期间将时钟调回 10 分钟，则 condition_variable 会阻塞 10 分钟 + 1 秒。我已经确认这是 Ubuntu 14.04 LTS 系统上的行为。

我需要依靠这个超时至少有点准确（即，它可能在一定的误差范围内不准确，但如果系统时钟发生变化，仍然需要执行）。看来我需要做的是编写我自己的 condition_variable 版本，它使用 POSIX 函数并使用单调时钟实现相同的接口。

这听起来像是很多工作——而且有点乱。有没有其他方法可以解决这个问题？

4

4 回答 4

4

我遇到了同样的问题。我的一位同事给了我一个提示，让我可以使用某些 C 函数<pthread.h>，这对我来说效果很好。

例如，我有：

std::mutex m_dataAccessMutex;
std::condition_variable m_dataAvailableCondition;

其标准用法：

std::unique_lock<std::mutex> _(m_dataAccessMutex);
// ...
m_dataAvailableCondition.notify_all();
// ...
m_dataAvailableCondition.wait_for(...);

以上可以用pthread_mutex_tand代替pthread_cond_t。优点是您可以将时钟指定为单调的。简要使用示例：

#include <pthread.h>

// Declare the necessary variables
pthread_mutex_t m_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_condattr_t m_attr;
pthread_cond_t m_cond;

// Set clock to monotonic
pthread_condattr_init(&m_attr);
pthread_condattr_setclock(&m_attr, CLOCK_MONOTONIC);
pthread_cond_init(&m_cond, &m_attr); 

// Wait on data
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
ts.tv_sec += timout_in_seconds; 
pthread_mutex_lock(&m_mutex);
int rc = pthread_cond_timedwait(&m_cond, &m_mutex, &ts);
if (rc != ETIMEDOUT)
    ; // do things with data
else 
    ; // error: timeout
// ...
pthread_mutex_unlock(&m_mutex); // have to do it manually to unlock
// ...

// Notify the data is ready
pthread_cond_broadcast(&m_cond);
于 2018-08-28T17:00:41.433 回答
3

集中注册您的活动条件变量。

做一些努力来检测时钟错误，即使它是当前时钟 (ick) 上的线程自旋锁定或其他方式。

当您检测到时钟错误时，戳一下条件变量。

现在将您的条件变量包装在一个薄包装器中，该包装器还支持检测时钟滑动。它调用wait_until但用检测到时钟滑动的谓词替换谓词，并且当发生这种情况时会中断等待。

当你的实现被破坏时，你必须做你必须做的事情。

于 2018-06-26T18:15:26.523 回答
3

在考虑了这个问题的可能解决方案之后，似乎最有意义的一个是禁止使用 std::condition_variable （或者至少明确说明它总是会使用系统时钟）。然后我必须以尊重时钟选择的方式自己重新实现标准库的 condition_variable。

由于我必须支持多个平台（Bionic、POSIX、Windows 以及最终的 MacOS），这意味着我将维护此代码的多个版本。

虽然这很糟糕，但似乎替代方案更糟糕。

于 2018-07-05T03:02:30.090 回答
1

这可能不是最好的解决方案，也不是一个很好的解决方案，但您确实说“解决”而不是“很多工作”，所以：

  • 使用您的发行版的工具来监控系统时钟的变化（我不太确定这些工具是什么；在最坏的情况下，您可以每 5 分钟运行一次 cron 作业以检查时钟是否在其预期值附近）。
  • 在检测到系统时钟更改后，向您有等待/睡眠线程的进程传达一些信息。您可能会使用信号；或管道；或 unix 域套接字；甚至一些共享内存。
  • 在进程端，确保您收到此消息（即编写信号处理程序，或让线程在管道上执行阻塞 I/O；或std::condition_variable分别使用非睡眠轮询共享内存）
  • 在收到有关系统时钟更改的通知后，请在您的进程中进行调整，唤醒睡眠线程，并根据更改的时间重新评估需要做什么。也许它和以前完全一样，在这种情况下，你只需让你的线程再次使用条件变量。

不是很优雅，并且涉及大量开销 - 但这确实是有道理的，并且不是一些疯狂的黑客行为。

于 2018-06-25T22:33:22.567 回答