Инверсия приоритета: какого черта!
Давайте сначала поместим «инверсию приоритета» в контекст общей картины, то есть откуда это взялось.
В операционной системе одним из важных понятий является планирование задач. Существует несколько методов планирования, таких как обслуживание в порядке очереди, циклический перебор, планирование на основе приоритетов и т. Д. Каждый метод планирования имеет свои плюсы и минусы. Как вы могли догадаться, Инверсия приоритета относится к планированию на основе приоритета. По сути, это проблема, которая иногда возникает, когда ОС использует планирование на основе приоритетов. При планировании на основе приоритета разным задачам назначается разный приоритет, поэтому задачи с более высоким приоритетом могут вмешиваться в задачи с более низким приоритетом, если это возможно.
Таким образом, при планировании на основе приоритета, если выполняется задача с более низким приоритетом (L) и если также необходимо запустить задачу с более высоким приоритетом (H), задача с более низким приоритетом (L) будет вытеснена задачей с более высоким приоритетом (H). Теперь предположим, что задачи с более низким и более высоким приоритетом должны совместно использовать общий ресурс (например, доступ к одному и тому же файлу или устройству) для выполнения своей работы. В этом случае, поскольку существует совместное использование ресурсов и требуется синхронизация задач, для обработки таких сценариев можно использовать несколько методов / приемов. Ради нашей темы об инверсии приоритета, позвольте нам упомянуть метод синхронизации, скажем, мьютекс. Напомним, что мьютекс: задача получает мьютекс перед входом в критическую секцию (CS) и освобождает мьютекс после выхода из критической секции (CS). Во время работы в CS задача обращается к этому общему ресурсу. Подробнее об этом можно прочитать здесь. Теперь предположим, что и L, и H имеют общую критическую секцию (CS), т.е. для этой CS требуется один и тот же мьютекс.
Переходя к обсуждению инверсии приоритета, давайте рассмотрим несколько сценариев.
1) L работает, но не в CS; H нужно бежать; H вытесняет L; H начинает работать; H отказывается от контроля или освобождает его от контроля; L возобновляет и начинает работать
2) L работает в CS; H нужно запустить, но не в CS; H вытесняет L; H начинает работать; H отказывается от контроля; L возобновляет работу и начинает бежать.
3) L работает в CS; H также необходимо запускать в CS; H ждет, пока L выйдет из CS; L выходит из CS; H входит в CS и начинает работать
Обратите внимание, что в приведенных выше сценариях не обнаружена проблема инверсии приоритета (даже сценарий 3). По сути, пока задача с более низким приоритетом не выполняется в общей CS, задача с более высоким приоритетом может ее вытеснить. Но если L работает в совместно используемой CS, а H также необходимо работать в CS, H ждет, пока L не выйдет из CS. Идея состоит в том, что CS должен быть достаточно маленьким, чтобы H не ждал долгое время, пока L находился в CS. Вот почему написание кода CS требует тщательного рассмотрения. В любом из вышеперечисленных сценариев инверсия приоритета (т. Е. Изменение приоритета) не происходила, потому что задачи выполняются согласно проекту.
Теперь давайте добавим еще одну задачу со средним приоритетом, скажем M. Теперь приоритеты задач находятся в порядке L <M <H. В нашем примере M не использует одну и ту же Критическую секцию (CS). В этом случае следующая последовательность выполнения задачи приведет к проблеме «Инверсия приоритета».
4) L работает в CS; H также необходимо запускать в CS; H ждет, пока L выйдет из CS; M прерывает L и начинает работать; M работает до завершения и отказывается от управления; L возобновляет работу и начинает работать до конца CS; H входит в CS и начинает работать.
Обратите внимание, что ни L, ни H не разделяют CS с M.
Здесь мы видим, что выполнение M задерживает выполнение как L, так и H. Точнее говоря, H имеет более высокий приоритет и не разделяет CS с M; но H пришлось ждать M. Здесь планирование на основе приоритетов не сработало, как ожидалось, потому что приоритеты M и H были инвертированы, несмотря на то, что они не разделяли никакой CS. Эта проблема называется инверсией приоритета. Вот какая, черт возьми, была инверсия приоритета! В системе с планированием на основе приоритета с этой проблемой могут столкнуться задачи с более высоким приоритетом, что может привести к неожиданному поведению / результату. В ОС общего назначения это может привести к снижению производительности. В ОСРВ это может привести к более серьезным последствиям. Самая известная проблема «инверсии приоритета» - это то, что произошло на Mars Pathfinder.
Если у нас есть проблема, для этого должно быть решение. Для инверсии приоритета также есть различные решения, такие как наследование приоритета и т. Д. Это будет наша следующая статья
А вот для стационарных пациентов это можно направить на время.
Пожалуйста, напишите комментарии, если вы обнаружите что-то неправильное, или вы хотите поделиться дополнительной информацией по теме, обсужденной выше.
Вниманию читателя! Не прекращайте учиться сейчас. Получите все важные концепции теории CS для собеседований SDE с курсом теории CS по доступной для студентов цене и будьте готовы к отрасли.