c++ - 我是否有在C++中使用std::condition_variable将线程置于死锁的风险？

Question

这是更多理论上的问题。我已经看到了std::condition_variable的几个示例，似乎它使线程进入休眠状态，直到满足条件为止。这是比赛的标志，很有意义。
但是，似乎如果始终更改变量，则可能会唤醒线程以检查条件并再次进入休眠状态，因为当谓词为true时，它无法跟上情况，因此我可以将线程置于“昏迷状态” 。
那么，在我总是更改它的情况下使用std::condition_variable是不安全的吗？

Answer 1

您似乎在谈论某种“活锁”。死锁是指一个或多个线程在等待释放锁时没有任何进展的情况。
Livelock相似，但是进程的状态在不断变化，但仍然没有进展。我们也可以谈论“实际上是活锁的”，其中线程没有足够的机会取得足够的进展。
对于观察者来说，活锁和实际的活锁通常看起来像真正的死锁。
您应设计程序逻辑以避免发生活锁。它可以是不平凡的。例如，许多形式的锁都不是“公平的”。那就是当多个线程正在等待释放的锁时，不能保证首先请求该锁的锁接下来会接收它。
实际上，许多操作系统锁本质上是不公平的，例如，将锁授予更容易唤醒(例如，加载到内核并挂起)而不是更难(从内核中卸载并需要重新加载以恢复执行)的线程。
这个问题没有提供很多细节，因此很难诊断出这种情况。
如果某个特定线程(或线程类)需要优先级，则可以引入一个标志，该标志告诉低优先级线程在优先级线程正在等待(并且可以运行)时不获取锁，例如(c && !(p && priority_waiting))，其中c是低优先级的逻辑条件。优先级线程和p是优先级线程的逻辑条件。
当然，您应该避免在线程等待潜在 transient 条件的情况下使用逻辑。
假设您有一些监视线程，该线程每1000个周期产生一次输出。像(cycles%1000 == 0)这样的等待条件很容易会错过计数器的点击。他们应该更喜欢(cycles-lcycles >=0)之类的内容，其中lcycles是监视器上次恢复处理后的周期数。这样可以确保为监视器通常提供一个锁(实际上是出于实用目的)，它几乎永远不会挂住。
在该示例中，线程正在等待(a)获得锁定的机会和(b)某些暂时情况。存在这样的风险:这两种情况很少同时发生，线程可能被锁住或实际上被锁住，并且进度不足，
简而言之，要确保线程在条件通过时恢复，而不是在条件完全通过时恢复。
您可以引入严格的队列以使线程轮流。只是不要以为这就是您所拥有的，除非文档对公平做出明确的 promise 。