为什么忙等待从应用程序的入口部分转移到了应用程序的关键部分？答案

【问题标题】：Why busy waiting moved from the entry section to the critical sections of application programs?为什么忙等待从应用程序的入口部分转移到了应用程序的关键部分？
【发布时间】：2020-01-21 17:52:38
【问题描述】：

我正在阅读“操作系统概念第 10 期”。

它给出了信号量的非忙等待定义：

typedef struct {
  int value;
  struct process *list;
} semaphore;



wait(semaphore *S) {
  S->value--;
  if (S->value < 0) {
    add this process to S->list;
    sleep();
  }
}

signal(semaphore *S) {
  S->value++;
  if (S->value <= 0) {
    remove a process P from S->list;
    wakeup(P);
  }
}

上面写着：

承认我们并没有完全消除忙碌是很重要的使用 wait() 和 signal() 操作的这个定义等待。相反，我们已将忙碌等待从入口部分移至关键部分应用程序的部分。此外，我们有限的忙碌等待 wait() 和 signal() 操作的关键部分

这个定义我可以理解，我们还需要一些机制来保护wait()和signal()代码的临界区。

但是“我们已经将繁忙的等待从应用程序的入口部分转移到了关键部分”是什么意思？

为什么程序员使用这个定义下的信号量需要在他们代码的关键部分使用忙等待？

【问题讨论】：

标签： operating-system semaphore critical-section

【解决方案1】：

假设有 10 台打印机，并且这些打印机是使用信号量访问的。根据给定的 wait() 和 signal() 定义，信号量只知道空闲打印机的数量，但不知道哪些打印机忙的确切信息。因此，当一个进程获得一个信号量时，它还必须获得它需要的特定打印机。这种获取发生在使用互斥锁或其他一些同步原语的应用程序代码中（出现在 wait() 函数之后）。这会导致应用程序代码忙于等待。

【讨论】：