场景一:释放互斥体然后等待场景二:等待然后释放互斥体
试图从概念上理解它的作用。
如果互斥锁在调用线程被认为在条件变量上“阻塞”之前被释放,那么另一个线程可以锁定互斥锁,更改谓词所基于的状态,并在等待线程永远不会醒来的情况下调用(因为它pthread_cond_signal
不是仍然被阻止)。那就是问题所在。
场景 2,等待然后释放互斥体,是任何现实世界实现必须在内部工作的方式,因为没有必要行为的原子实现。但是从应用程序的角度来看,如果不释放互斥锁,就无法观察到线程是阻塞集的一部分,因此在“抽象机器”的意义上,它是原子的。
编辑:更详细地说,条件变量等待的实际实现通常如下所示:
因此,“阻塞”行为分为两个步骤,其中一个发生在互斥锁解锁之前(获得阻塞集中的成员资格),另一个发生在互斥锁解锁之后(可能休眠并将控制权交给其他人)线程)。正是这种拆分能够使抽象机器中的“条件等待”操作“原子”。