Что такое инверсия приоритетов?

представьте себе три (3) задачи разного приоритета: tLow, tMed и tHigh. tLow и бедро получают доступ к одному и тому же критическому ресурсу в разное время; tMed делает свое дело.

1. tLow работает, tMed и бедро в настоящее время заблокированы (но не в критической секции).
2. tLow приходит и входит в критическую секцию.
3. бедро разблокируется, и поскольку это самая приоритетная задача в системе, она запускается.
4. бедро затем пытается войти критический ресурс, но блоки, как tLow находится там.
5. tmed разблокируется, и поскольку теперь это самая приоритетная задача в системе, она запускается.

бедро не может работать, пока tLow не откажется от ресурса. tLow не может работать до tmed блоков или заканчивается. Приоритет задач был инвертирован; бедро, хотя оно имеет самый высокий приоритет, находится в нижней части цепочки выполнения.

чтобы" решить " инверсию приоритета, приоритет tLow должен быть увеличен, чтобы быть на по крайней мере, до бедра. Некоторые могут поднять свой приоритет до максимально возможного уровня приоритета. Так же важно, как повышение уровня приоритета tLow, сбрасывает уровень приоритета tLow в соответствующее время(ы). Разные системы будут использовать разные подходы.

когда отбросить приоритет tLow ...

1. никакие другие задачи не блокируются ни на одном из ресурсов, которые имеет tLow. Это может быть связано с тайм-аутами или высвобождением ресурсов.
2. нет другие задачи, способствующие повышению уровня приоритета tLow, блокируются на ресурсах, которые есть у tLow. Это может быть связано с тайм-аутами или высвобождением ресурсов.
3. при изменении того, какие задачи ожидают ресурс (ы), отбросьте приоритет tLow, чтобы он соответствовал приоритету задачи самого высокого уровня приоритета, заблокированной на ее ресурсе(ах).

Способ № 2 является улучшением по сравнению с методом № 1 в том, что оно сокращает продолжительность tLow был уровень приоритета подскочил. Отметим, что его приоритетный уровень остается на прежнем уровне в течение этого периода.

Метод #3 позволяет уровню приоритета tLow понижаться с шагом, если это необходимо, а не на одном шаге "все или ничего".

различные системы реализуют различные методы в зависимости от того, какие факторы они считают важными.

• объем памяти
• сложности
• реальном времени отзывчивость
• знания разработчика

надеюсь, что это помогает.

Проблема Инверсии Приоритетов:
Рассмотрим один пример: Задачи:
Высокий Приоритет (З)
Средний Приоритет (М)
Низкий Приоритет (Л)

и замок X, может быть semaphore_lock (X).

сценарий:
1. L работает и приобретает X
2. Затем H пытается получить доступ к X, пока L имеет его, из-за семафора, H спит.
3. M прибывает, опережает L и бежит. По сути, компания H & М были двух процессов, ожидающих выполнения, но М. побежал за ч ждал на замке и не мог бежать.
4. M заканчивается, H не может войти, потому что у L есть замок, поэтому L работает.
5. Л отделку, сняв блокировку. Теперь H получает блокировку и выполняет.

H имел самый высокий приоритет, но выполнялся после запуска процессов с более низким приоритетом. Это инверсия приоритетов.

теперь решение инверсии приоритета.
Когда процесс с низким приоритетом работает и имеет блокировку, и если высокоприоритетный процесс пытается получить блокировку, приоритет низкоприоритетного процесса повышается до приоритета высокоприоритетного процесса. То есть, если L работает и имеет блокировку, когда H пытается ее получить, приоритет L будет повышен до приоритета H на время L удерживает блокировку. Таким образом, M не может предвосхитить его. После, L заканчивает, H бежит и приобретает замок. После того, как H будет сделано, M запускается с сохранением приоритетного порядка.

Это проблема, а не решение.

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

общее решение состоит в том, чтобы иметь низкоприоритетные потоки временно наследуют высокий приоритет всех, кто ожидает блокировки, которые они держат.

предположим, что приложение имеет три потока:

Thread 1 has high priority.
Thread 2 has medium priority.
Thread 3 has low priority.

предположим, что поток 1 и поток 3 имеют один и тот же код критического раздела

поток 1 и поток 2 спят или заблокированы в начале примера. Поток 3 запускается и входит в критическую секцию.

в этот момент поток 2 начинает работать, вытесняя поток 3, потому что поток 2 имеет более высокий приоритет. Таким образом, поток 3 продолжает иметь решающее значение раздел.

позже, поток 1 начинает работать, вытесняя поток 2. Поток 1 пытается войти в критический раздел, который принадлежит потоку 3, но поскольку он принадлежит другому потоку, поток 1 блокируется, ожидая критического раздела.

в этот момент, поток 2 начинает работать, потому что он имеет более высокий приоритет, чем поток 3 и поток 1 не работает. Поток 3 никогда не освобождает критический раздел, который ожидает поток 1, потому что поток 2 продолжает бежать.

таким образом, поток с самым высоким приоритетом в системе, поток 1, блокируется в ожидании запуска потоков с более низким приоритетом.

[ предположим, низкий процесс = LP, средний процесс = MP, высокий процесс = HP]

LP выполняет критический раздел. При входе в критическую секцию LP должен был получить блокировку на каком-либо объекте, скажем OBJ. LP теперь находится внутри критической секции.

между тем, HP создается. Из-за более высокого приоритета CPU Выполняет переключение контекста, и HP теперь выполняет (не тот же критический раздел, но какой-то другой код). В какой-то момент во время выполнения HP ему нужна блокировка тот же OBJ (может быть или не быть в той же критической секции), но блокировка OBJ по-прежнему удерживается LP, поскольку она была упреждена при выполнении критической секции. LP не может отказаться сейчас, потому что процесс находится в состоянии готовности, а не работает. Теперь HP перемещается в состояние блокировки / ожидания.

теперь MP входит и выполняет свой собственный код. MP не нуждается в блокировке OBJ, поэтому он продолжает работать нормально. Компания HP ожидает ЛП, чтобы освободить замок, и LP ждет МП до завершения выполнения, так что ЛВ может вернитесь в запущенное состояние (.. и выполнить и отпустить блокировку). Только после того, как LP освободил блокировку, HP может вернуться к готовности (а затем перейти к запуску, предварительно опережая задачи с низким приоритетом.)

таким образом, фактически это означает, что до тех пор, пока MP не завершится, LP не может выполнить и, следовательно, HP не может выполнить. Таким образом, похоже, что HP ждет MP, хотя они напрямую не связаны ни с какими блокировками OBJ. - > Инверсия Приоритетов.

решение для инверсии приоритета является Приоритет Наследования -

увеличить приоритет процесса (A) до максимального приоритета любого другой процесс ожидает любой ресурс, на котором A имеет блокировку ресурса.

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

например: FileA должен быть доступен по Proc1 и Proc2. Proc 1 имеет более высокий приоритет, чем Proc2, но Proc2 удается открыть FileA первым.

обычно Proc1 будет работать, возможно, в 10 раз чаще, чем Proc2, но ничего не сможет сделать, потому что Proc2 держит файл.

Итак, что в конечном итоге происходит, это то, что блоки Proc1 до тех пор, пока Proc2 не закончит работу с FileA, по существу их приоритеты "инвертированы", а Proc2 держит дескриптор FileA.

Что касается "решения проблемы", инверсия приоритетов является проблемой сама по себе, если она продолжает происходить. В худшем случае (большинство операционных систем не позволит этому произойти), если Proc2 не было разрешено работать до тех пор, пока Proc1 не было. Это приведет к блокировке системы, поскольку Proc1 будет продолжать получать назначенный процессор время, и Proc2 никогда не получит время процессора, поэтому файл никогда не будет выпущен.

инверсия приоритета происходит как таковая: Данные процессы H, M и L, где названия обозначают высокие, средние и низкие приоритеты, только H и L имеют общий ресурс.

скажем, L сначала получает ресурс и начинает работать. Поскольку H также нуждается в этом ресурсе, он входит в очередь ожидания. M не разделяет ресурс и может начать работать, поэтому он делает. Когда L прерывается любым способом, M принимает состояние выполнения, так как оно имеет более высокий приоритет, и оно работает в данный момент это прерывание происходит. Хотя H имеет более высокий приоритет, чем M, поскольку он находится в очереди ожидания, он не может получить ресурс, подразумевая более низкий приоритет, чем даже M. После завершения M, L снова возьмет на себя процессор, заставляя H ждать все время.

инверсии приоритета можно избежать, если заблокированный высокоприоритетный поток передает свой высокий приоритет низкоприоритетному потоку, который удерживает ресурс.

проблема планирования возникает, когда процесс с более высоким приоритетом должен считывать или изменять данные ядра, к которым в настоящее время обращается процесс с более низким приоритетом-или цепочка процессов с более низким приоритетом. Поскольку данные ядра обычно защищены блокировкой, процесс с более высоким приоритетом должен будет дождаться завершения процесса с более низким приоритетом с ресурсом. Ситуация усложняется, если низкоприоритетный процесс вытесняется в пользу другого процесса с более высоким приоритетом. В качестве примера, предположим у нас есть три процесса-Л, М, а H-чьи приоритеты следить за порядком Л

рассмотрим систему с двумя процессами,H с высоким приоритетом и L с низким приоритетом. Правила планирования таковы, что H запускается всякий раз, когда он находится в состоянии готовности из-за ее высокого приоритета. В определенный момент с L в своей критической области,H становится готовым к запуску (например, завершается операция ввода-вывода). H сейчас начинается напряженное ожидание, но так как L никогда не планируется в то время как H работает, L никогда не получает шанс покинуть критический раздел. Так что H петли навсегда.

эта ситуация называется Priority Inversion. Потому что процесс с более высоким приоритетом ожидает процесс с более низким приоритетом.

позвольте мне сделать это очень просто и понятно. (Этот ответ основан на ответах выше, но представлен четким способом).

скажем, есть ресурс R и 3 процессы. L,M,H. где p(L) < p(M) < p(H) (где p(X) - это приоритет X).

сказать

• L начинает выполнение первым и поймать держит на R. (эксклюзивный доступ к R)
• H приходит позже, а также хотите эксклюзивный доступ к R и с L держит он, H приходится ждать.
• M после H и не нужно R. И с тех пор M есть все, что он хочет, чтобы выполнить его силы L оставить, как это имеет высокий приоритет по сравнению с L. Но H не может сделать это, так как он имеет ресурс заблокирован L что ему нужно для выполнения.

теперь делает проблему более понятной, на самом деле M должны ждать H как p(H) > p(M) что не произошло, и это само по себе является проблемой. Если много процессов, таких как M приходите и не позволяйте L выполнить и отпустить блокировку H никогда не будет выполнена. Что может быть опасно во времени критические применения

а для решения обратитесь к приведенным выше ответам:)