为什么 pthread_cond_wait 需要锁？

Question

据我了解，它pthread_cond_t是一个信号对象，类似于windows 平台上的事件。

所以基本功能pthread_cond_t应该是等待它并发出信号。界面应该如下：

int pthread_cond_wait(pthread_cond_t* cone);
int pthread_cond_singal(pthread_cond_t* cond);

但实际上，pthread_cond_wait需要一个mutex*与其功能不直接相关的类型参数。所以你需要一个互斥锁，即使只是想为线程之间的通信创建一个信号，它不会同时访问相同的数据。

那么为什么界面设计成这样，最终给用户增加开销呢？

Edit1： 我知道互斥是用来保护条件数据的，但是如果设计没有互斥的接口，你也可以通过结合互斥和pthread_cond来实现你的目标。而且您也可以仅pthread_cond用于通知没有在它们之间共享数据的另一个线程。

例如，您可以有一个生产者线程创建文件，完成后通知另一个消费者处理文件，没有数据需要互斥锁保护。

Answer 1

条件变量+互斥量组合中互斥量的根本原因是为谓词数据提供保护。

请仔细阅读。

条件变量是一种信号机制。仅此而已。他们发出信号，你的事情的是一些外部谓词条件是你，作为一个服务员，已订阅感兴趣的预期的变化。当你终于苏醒你自己的互斥体，因此它的独家代理权的断言数据。这是至关重要的。只要所有需要访问谓词数据的线程都按规则运行，并且没有线程在不拥有底层互斥锁的情况下以任何方式访问谓词数据，一切正常。

对您、应用程序开发人员来说值得注意的部分同样重要：以原子方式等待条件变量的操作（就您而言，无论如何）开始等待并解锁互斥锁以允许其他等待者访问获取它，因此批准访问谓词数据。在 Server 2008 和 Vista 之前，通用 Windows 事件没有类似的内容）。我能描述它如何在 Windows 上工作的最接近的事情是解锁 ahMutex 并开始以hEvent原子方式等待，从而消除了在两个操作之间潜行更改的可能性。

这很重要，因为它消除了典型的无保护设置和测试的竞争条件。没有原子解锁和等待的所述竞争条件会导致重大问题。例如：您拥有互斥锁，检查数据，而不是您需要的数据，因此您解锁互斥锁并等待事件。可以想象，在您解锁互斥锁和实际开始等待操作之间，您正在等待的条件发生在这段时间内。而你错过了。使用 cvar-mtx 组合正确等待时不会发生这种情况。

最重要的是记住这一点。条件变量并不像您想象的那样保持“状态”。谓词状态保存在您自己设计的数据变量中。保护该状态是关联互斥锁的主要工作。您不需要拥有谓词数据互斥体来发出条件更改的信号。但是您确实需要拥有互斥锁才能真正进行更改。如果你不这样做，你就是在玩火。

编辑：考虑到问题的现在编辑的前提（只有没有共享谓词数据的信号机制），我首先不会使用条件变量 + 互斥组合。当需要发送“信号”时，我会使用阻塞管道并向其写入一个字节。并且您不能设计带有耦合的 cvar+mutex“实体”的接口，因为有时您想要更改谓词数据而不是向预期的服务员发出信号。您可以只锁存互斥锁并在不调用信号的情况下进行更改。如果他们结合在一起，你就没有那么奢侈了。