Защо изпреварването не решава инверсията на приоритета?

Добре, да кажем, че имаме два процеса. Нека също приемем, че процесът с по-нисък приоритет получава заключване. Когато процесът с по-висок приоритет стане готов, той изпреварва другия процес. Ако процесът с по-висок приоритет се нуждае от това заключване, той не може да го получи поради другия процес, който има по-нисък приоритет. Това означава, че процесът с по-нисък приоритет блокира този с по-висок приоритет. Той предотвратява изпълнението на процес с по-висок приоритет. Това се нарича "инверсия на приоритета".

Очевидно изпреварването не е решение за инверсия на приоритета. Решението е "Приоритетно наследяване". Това означава, че трябва временно да увеличим приоритета на процеса, когато той получи заключване, което също е необходимо на процес с по-висок приоритет. Това трябва да е процесът с най-висок приоритет сред другите процеси, които може да искат същото заключване.

Нека 3 нишки A, B, C със съответния приоритет Висок, Среден, Нисък.

C получава процесора и взема ключL. Тогава B се събужда от някои събития и изпреварва C. Сега A се събужда и получава процесора чрез изпреварване на B. A иска ключалката L, но не успява, защото L вече е собственост на C. A се изключва поради липса на заключване и връща процесора на B. Трябва да изчакаме B да завърши, което в крайна сметка ще завърши с връщане на процесора на C. Cще завърши и освободи заключването, което най-накрая ще събудиA.

Това е инверсия на приоритет, защото B се изпълнява, докато имаме нишка A в системата с по-висок приоритет, чакаща завършване на нишка с по-нисък приоритет (C в този случай).

Между другото, решението е приоритетно наследяване.

Изпреварването означава отнемане на процесора, така че дадена задача да не се изпълнява повече.

Това не е достатъчно, защото задачата с нисък приоритет съдържа ресурс, от който се нуждае задачата с висок приоритет.

Сега, ако ресурсът може просто да бъде отнет (различен вид "изпреварване"), тогава това наистина ще реши инверсията на приоритета. Но това обикновено не е възможно, тъй като полузавършеното действие на задачата с нисък приоритет би довело до несъответствия.

Да предположим, че имате 3 процеса:

• А - висок приоритет
• B - нормален приоритет
• C - нисък приоритет

и също така, че A и C използват, да речем, един и същ файл (това може да е всеки споделен ресурс), чието използване трябва да бъде синхронизирано.

Сега да предположим, че нито A, нито B са готови за изпълнение, а C се изпълнява и получава заключването за използване на файла. Докато C държи заключването на файла, A се подготвя за изпълнение и операционната система изпреварва C и изпълнява A . A се изпълнява до степен, че също има нужда от файла и когато се опита да получи заключването, се блокира, защото C държи заключването. Ако междувременно B е готов за изпълнение, той ще бъде изпълнен вместо A, защото A не е готов за изпълнение. За да бъде готов A, заключването на файла трябва да бъде освободено от C, а C няма да стартира и да освободи заключването, защото по-високо изпълнява се приоритетен процес B. Така A чака C, който на свой ред чака B. Самото изпреварване на B в тази ситуация няма да е от полза, защото A не е готов и няма да бъде, освен ако C не стартира и C не може да се изпълни, тъй като току-що избраният по-висок приоритет B е готов за изпълнение.

От Wiki

Обмисли,

L --> Задача с нисък приоритет
H --> Задача с висок приоритет
M --> Задача със среден приоритет
R --> Ресурс

Стъпка 1: L придобива R
Стъпка 2: H иска R (В момента се използва с L. така че H ще изчака L да се откаже от R.)
Стъпка 3: M пристига (M е неблокиран Задача, т.е. не изисква R)
Стъпка 4: L е изместен от M. (така че L не може да се откаже от R. Поради това H не може да стартира.)

След като M приключи с изпълнението си, L ще се откаже от R. След това само H може да продължи. В сценария по-горе задача със среден приоритет (M) се изпълнява преди задача с висок приоритет (H).

Това е действителният сценарий за инверсия на приоритета в превантивното ядро.

инверсията на приоритета е проблематичен сценарий при планирането, когато задача с по-висок приоритет е индиректно изпреварена от задача с по-нисък приоритет, което ефективно "инвертира" относителните приоритети на двете задачи.

Помислете, че има задача L с нисък приоритет. Тази задача изисква ресурс R. Помислете, че L работи и придобива ресурс R. Сега има друга задача H с висок приоритет. Тази задача също изисква ресурс R. Помислете, че H започва, след като L е придобил ресурс R. Сега H трябва да изчака, докато L се откаже от ресурс R. Всичко работи според очакванията до този момент, но възникват проблеми, когато нова задача M (която не използва R) стартира със среден приоритет през това време. Тъй като R все още се използва (от L), H не може да работи. Тъй като M е деблокирана задача с най-висок приоритет, тя ще бъде планирана преди L. Тъй като L е изтеглен от M, L не може да се откаже от R. Така че M ще работи, докато не приключи, след това L ще се изпълнява - поне до момент, в който може да се откаже от R - и тогава H ще изпълни. По този начин, в сценария по-горе, задача със среден приоритет се изпълнява преди задача с висок приоритет, което на практика ни дава приоритетна инверсия.