Прерывание процесса в критической секции
При планировании на основе приоритетов я столкнулся с проблемой инверсии приоритетов, которая заключается в том, что процесс с более высоким приоритетом вынужден ждать задачи с более низким приоритетом. Одним из возможных сценариев является рассмотрение трех процессов L,M,H с порядком приоритета L L работает в CS; H также должен работать в CS; H ждет L, чтобы выйти из CS; М прерывает L и начинает бежать; М работает до завершения и отказывается от контроля; L возобновляет работу и начинает работать до конца CS; H входит в CS и начинает работать. Здесь мой вопрос в отношении оператора M, который прерывает L и начинает работать, т. Е. Может ли процесс, выполняющийся в критическом разделе, быть прерван или прерван.
2 ответа
Ответ прост и да. Если какой-либо другой процесс с более высоким приоритетом в вытесняющей системе не нужно запускать в критической секции, то есть не нужно получать блокировку, которая удерживается процессом с более низким приоритетом, то он может выгрузить процесс с более низким приоритетом независимо от того, что это выполняется.
Даже если M требуется CS, он выгрузит L, запустит, заблокирует и переключит на L для продолжения выполнения.
Здесь мой вопрос в отношении оператора M, который прерывает L и начинает работать, т. Е. Может ли процесс, выполняющийся в критическом разделе, быть прерван или прерван.
Это зависит от того, как реализован критический раздел.
В коде операционной системы вы часто найдете критические разделы, реализованные там, где прерывания заблокированы. В такой реализации процесс всегда будет выполнять весь критический раздел без прерывания.
В пользовательском коде, который использует критические разделы, реализованные с помощью системных служб, процесс неизменно может быть прерван. Если бы это было не так, процесс мог бы захватить систему, поместив весь ее код в критическую секцию.
Вы описываете одну из причин, по которой приоритеты процесса должны быть последовательными. Если вы не выполняете обработку в реальном времени или фоновую пакетную обработку, все процессы обычно должны иметь одинаковый базовый приоритет.
Раньше старые ленты DECUS были заполнены приложениями "справедливой доли", которые снизили бы приоритет процессов с высокой загрузкой ЦП и привели бы к хаосу при системном планировании.