Почему занятое ожидание перенесено из раздела ввода в критические разделы прикладных программ? - PullRequest
Новая
       90

Почему занятое ожидание перенесено из раздела ввода в критические разделы прикладных программ?

1 голос
/ 20 сентября 2019

Я читаю «понятия 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 ()

Я могу понять в этом определении, нам также нужен некоторый механизм для защиты критической секции ожидания() и код сигнала ().

Но что значит «мы переместились в ожидании из раздела ввода в критические разделы прикладных программ»?

Почему программист используетсемафору по этому определению нужно использовать занятое ожидание внутри критической секции своего кода?

1 Ответ

0 голосов
/ 28 сентября 2019

Предположим, что есть 10 принтеров и доступ к этим принтерам осуществляется через семафор.Из данного определения wait () и signal () семафор знает только количество свободных принтеров, но не точную информацию о том, какими принтерами они заняты.Поэтому, когда процесс получает семафор, он также должен получить нужный ему принтер.Это происходит в коде приложения (который присутствует после функции wait ()) с использованием мьютекса или некоторых других примитивов синхронизации.Это вызывает активное ожидание в коде приложения.Я надеюсь, что это отвечает на ваш вопрос.

...