![丢失唤醒问题 - UNIX 如何处理它](https://linux22.com/image/9647/%E4%B8%A2%E5%A4%B1%E5%94%A4%E9%86%92%E9%97%AE%E9%A2%98%20-%20UNIX%20%E5%A6%82%E4%BD%95%E5%A4%84%E7%90%86%E5%AE%83%20.png)
(我首先给出我的问题的背景,问题本身位于底部,其中以粗体显示“问题”)。
以两个进程 A 和 B 为例。A 检查条件,发现条件不满足,然后进入睡眠/阻塞状态。 B满足条件并唤醒A。如果一切都按这个顺序发生,那么我们就没有问题。
现在如果调度程序执行以下操作:
- A 检查条件,不满足
- B满足条件,唤醒A
- A 进入睡眠状态/阻塞
那么我们就失去了 B 为 A 执行的唤醒。
我在实现阻塞信号量(即将 wait()ing 线程置于睡眠/阻止它而不是让它旋转等待的信号量)的上下文中遇到了这个问题。多个来源对此提供了解决方案,其中:
Andrew Tanenbaum,《现代操作系统》,第 4 版,第 14 页。 130:
这里问题的本质是发送给尚未休眠的进程的唤醒丢失了。如果没有丢失,一切都会顺利。快速解决方法是修改规则以添加唤醒等待位到图片。当唤醒发送到仍处于唤醒状态的进程时,该位被设置。稍后,当进程尝试进入睡眠状态时,如果唤醒等待位打开,则会将其关闭,但进程将保持唤醒状态。唤醒等待位是用于存储唤醒信号的存钱罐。消费者在循环的每次迭代中清除唤醒等待位。
这篇文章发表在 Linux 杂志上(“Kernel Korner - Sleeping in the Kernel”,Linux Journal #137)提到了类似的内容:
该代码避免了唤醒丢失的问题。如何?在测试条件之前,我们已将当前状态更改为 TASK_INTERRUPTIBLE。那么,发生了什么变化呢?变化在于,每当状态为 TASK_INTERRUPTIBLE 或 TASK_UNINTERRUPTIBLE 的进程调用wake_up_process,并且该进程尚未调用schedule()时,该进程的状态将更改回TASK_RUNNING。
因此,在上面的示例中,即使在检查 list_empty 之后的任何时候进程 B 发出唤醒,A 的状态也会自动更改为 TASK_RUNNING。因此,调用schedule()不会使进程A进入睡眠状态;正如前面所讨论的,它只是将其安排一段时间。因此,唤醒不再丢失。
据我了解,这基本上是说“您可以将一个进程标记为想要进入睡眠/阻止状态,以便稍后的唤醒可以取消稍后的睡眠/阻止调用”。
最后这些讲义在底部的几段中,从“下面的伪代码显示了这种信号量的实现,称为阻塞信号量:”给出了阻塞信号量的代码并使用原子操作“Release_mutex_and_block (csem.mutex);”。他们声称:
请注意,P()ing 进程必须自动变得不可运行并释放互斥体。这是因为存在唤醒丢失的风险。想象一下这是两个不同操作的情况:release_mutex(xsem.mutex) 和 sleep()。如果在release_mutex()和sleep()之间发生上下文切换,则另一个进程可能会执行V()操作并尝试使第一个进程出列_and_wakeup()。不幸的是,第一个进程尚未睡眠,因此它错过了唤醒 - 相反,当它再次运行时,它立即进入睡眠状态,没有人唤醒它。
操作系统通常以 sleep() 系统调用的形式提供这种支持,该调用将互斥体作为参数。然后,内核可以释放互斥锁,并使进程在没有中断(或以其他方式受到保护)的环境中进入睡眠状态。
问题:UNIX 中的进程是否有某种方式将它们标记为“我正计划进入睡眠状态”,或者如 Tanenbaum 所说的“唤醒等待位”?是否有一个系统调用 sleep(mutex) 可以原子地释放互斥体,然后使进程进入睡眠/阻止它?
很明显,我不熟悉系统调用和一般操作系统内部结构;如果我的问题中有任何明显的错误假设或术语的误用,我很乐意让他们向我指出。
答案1
经典的 Unixy 解决方案是让“唤醒”信号包括将一个字节写入等待进程将尝试从中读取的管道。
(如果进程没有可以帮助设置此功能的共同祖先,则可以使用命名管道)。
然后,等待进程可以使用 select() 系统调用(或其最近重新设计的替代方案之一,例如 pselect 或 poll/epoll)原子地执行“等待直到准备好从这样那样的文件描述符中读取”。当它醒来时,它会读取并丢弃所有要读取的内容,并且然后检查哪些工作已准备好进行。