问是否仍在忙于等待信号量的进程阻塞实现？

EN

操作系统概念讨论信号量的两种实现，即在5.5节中忙于等待，在第5.6节中阻塞当前进程：

第5.5节信号量S是一个整数变量，除了初始化之外，只能通过两个标准原子操作访问该变量: wait()和signal()。wait()操作最初被称为P(来自荷兰proberen，“test”)；signal()最初被称为V(从verhogen，“到增量”)。wait()的definition如下:等待(S ){ while (Sfi0)；//繁忙等待fi-；}信号(fi)的definition ()如下:信号(fi){ S++；}第5.6节回忆第5节中讨论的互斥锁的实现受到繁忙等待的影响。刚才描述的wait()和signal()信号量操作的definitions也出现了同样的问题。为了克服繁忙等待的需要，我们可以修改wait()和signal()操作的definition，如下所示:当进程执行wait()操作和信号量值不为正的finds时，它必须等待。然而，与其忙于等待，这个过程还可以阻止自己。块操作将进程放置到与信号量相关联的等待队列中，并且进程的状态被切换到等待状态。然后将控制转移到CPU调度器，由CPU调度器选择另一个进程执行。为了在这个definition下实现信号量，我们定义了一个信号量，如下所示:fi结构{ int值；struct进程*列表；}信号量；每个信号量有一个整数值和一个进程列表列表。当进程必须等待信号量时，它将被添加到进程列表中。信号()操作从等待进程列表中删除一个进程，并唤醒该进程。现在，wait()信号量操作可以是defined (信号量*S) {S->value-；if ( it >value< 0) {将此进程添加到23->列表；块()；}和信号()信号操作作为信号(信号量*){->值++；如果(->值<= 0) {从->列表中删除进程P；唤醒(P)；}}块()操作暂停调用它的进程。唤醒( P )操作恢复被阻塞进程P的执行。这两个操作由操作系统作为基本系统调用提供。至关重要的是，信号量操作必须以原子方式执行。我们必须确保没有任何两个进程能够同时在同一个信号量上执行wait()和signal()操作。这是一个关键部分问题；重要的是要承认，我们还没有完全消除等待和信号()操作的defi虚无。相反，我们已经将繁忙的等待从入口部分转移到应用程序的关键部分。此外，我们将繁忙的等待限制在wait()和signal()操作的关键部分，并且这些部分很短(如果正确编码，它们应该不超过10个指令)。因此，关键部分几乎从来没有被占用，繁忙的等待很少发生，然后只有很短的时间。

关于最后一段的问题：

1. 在“将繁忙的等待从输入部分移到应用程序的关键部分”中，假设“应用程序”是: do { section> (S) // entry区段<临界section>信号(S) // exit区段<剩余的section>} while (真)；
   • 在从输入部分移出的“应用程序的关键部分”中，繁忙的等待者在哪里？

2. 在“我们有限地忙着等待等待()和信号()操作的关键部分”中，
   • 什么是“等待()和信号()操作的关键部分”？它们是wait()和signal()的整个功能体吗？(我想是这样的，因为这两个函数必须是原子的，在最后一段中提到的。)
   • “繁忙等待”在哪里，它仅限于等待()和信号()操作的关键部分？(在wait()和signal()中没有循环，所以我猜它们中没有忙着等待吗？)

谢谢。