问互斥实现和信令

EN

简而言之:是的，也许..。

这是实现细节，如果不知道您正在讨论的是哪个操作系统，就很难说出来。通常，互斥锁的解锁只会将等待的线程标记为"runnable"，而不是(不一定)在那个时候调用调度器--即使调用了调度程序，也并不意味着T2将是下一个要运行的线程。

在Linux中，代码进入检查是否存在等待任务的mutex_unlock() (通过检查锁计数是否小于零-它从1开始解锁，单个锁请求使其为零，进一步的锁定尝试将使其为负值)。如果还有一个进一步的等待过程，它会调用一个“慢速路径解锁”，它通过两个重定向函数来允许实现细节，最终在__mutex_unlock_common_slowpath中结束--再往下几行，就会调用wake_up_process，最终在try_to_wake_up中结束--这实际上只是将任务排在“准备好运行”的队列中，然后调用调度程序(通过几层函数！)

这取决于你的操作系统。我看到了yield的旋转、旋转、内核中的通用条件变量、用户控制的调度以及支持内核的专用锁定原语。

用yield纺丝和纺丝的性能都很差。理论上说，用户控制的调度(参见调度程序激活)应该具有最好的性能，但据我所知，在所有情况下都没有人使它正常工作。内核中的通用条件变量和具有内核支持的专用锁定原语应该在Linux中对富特执行多少相同的操作，作为后者的最佳示例。

在有些情况下，纺纱可以有更好的性能。在Solaris中，内核中的一些锁定原语具有自适应模式，只要持有锁的进程在不同的cpu上运行，锁就会旋转。如果锁主睡觉或被抢占，锁侍者也会睡觉。在其他内核中，有一些锁类，锁所有者在持有锁时不能被抢占或睡眠，因此在这些情况下旋转也很好。但是，通常情况下，特别是在userland中，旋转有如此可怕的退化情况(旋转过程一直转到被抢占以让锁所有者运行为止)，这对性能非常不利。注意，像futex这样的专用锁定原语可以实现这样的优化，这是一般条件变量通常无法实现的。

假设我们有以下情况：

 1. T1 got M1. M1 locked.
 2. T2 tries to get M1 and gets blocked as M1 is locked.
 3. T3 tries to get M1 and gets blocked as M1 is locked.
 4. ...some time later...
 5. T1 unlocks M1.*
 6. T2 got M1.
 7. T3 is unblocked and tries to get M1 but is blocked again as T2 got M1 first.

*系统调用-- unlock，应由通知在互斥锁的锁调用上被阻塞的所有阻止的。然后执行计划的。这并不意味着他们会被执行，因为可能已经有人在执行。正如其他人所说的，这取决于如何实现。如果你真的想学好这个，我会推荐这个书