揭开条件背后的秘密：notify_one()加锁还是不加锁

问题：

为了确保高效的线程协调，std::condition_variables发挥着关键作用。然而，在调用notify_one()之前获取锁的必要性存在不确定性：它是强制性的，还是可选的做法？

解开谜团：

答案很明确：在调用notify_one()之前并不强制要求持有锁。然而，在某些情况下，获取锁是一种好的做法。让我们深入研究一下这背后的原因。

为什么要锁？

• 悲观方法：虽然持有锁可能看起来多余，这可以被认为是一种悲观策略。通过在通知等待线程之前释放锁，被通知的线程将立即尝试重新获取它。这可能会导致争用和潜在的性能下降，因为两个线程都竞争相同的资源。
• 维护一致性：某些用例要求严格遵守条件变量使用指南。在整个更新和等待操作过程中持有锁可确保锁所保护的数据的一致性。这种做法可以最大限度地减少竞争条件或数据损坏的风险。

示例：两个通知的故事

提供的示例提出了有关不一致锁定的问题后续notify_one() 调用的行为。初始调用没有锁的原因是后面的等待操作：等待函数将自动获取和释放锁，确保被通知的线程可以继续执行。然而，后续的notify_one()调用会受到锁的保护，因为它们不涉及等待操作。

总而言之，在调用notify_one()之前持有锁并不是普遍要求，但这是推荐的做法某些场景。它可以减轻潜在的性能问题并确保数据完整性。