Захист від інверсії пріоритетів

Отже, проблема інверсії пріоритетів виявилася настільки важливою для ОСРЧ, що реалізацію в системі механізмів захисту від цієї проблеми винесли в окрему функціональну вимогу до операційних систем реального часу. Розберемося, що ж це таке? Інверсія пріоритетів виникає, коли два потоки, високопріоритетний (В) і низькопріоритетний (Н) розділяють якийсь загальний ресурс (Р). Припустимо, також, що в системі присутній третій потік, пріоритет якого знаходиться між пріоритетами В и Н. Назвемо його середнім (С). Якщо потік В переходить у стан готовності коли активний потік Н, і Н заблокував ресурс Р, то потік В витисне потік Н, і Р залишиться заблокований. Коли В знадобиться ресурс Р, то він сам перейде в заблокований стан. Якщо в стані готовності знаходиться тільки потік Н, то нічого страшного не відбудеться, Н звільнить заблокований ресурс і буде витиснутий потоком В. Але якщо на момент блокування потоку В, у стані готовності знаходиться потік С, пріоритет якого вище ніж у Н, то активним стане саме він, а Н знову буде витиснутий, і одержить керування тільки після того, як С закінчить свою роботу. Подібна затримка цілком може привести до того, що критичний час обслуговування потоку В буде пропущено. Якщо В – це потік жорсткого реального часу, то подібна ситуація неприпустима.

Які ж механізми захисту від цієї проблеми використовують розроблювачі операційних систем реального часу? Найбільш широко розповсюджений і перевірений механізм – це спадкування пріоритетів.

Суть цього методу полягає в спадкуванні низькопріоритетним потоком, що захопив ресурс, пріоритету від високопріоритетного потоку, якому цей ресурс потрібний. В описаному прикладі це означає наступне. Якщо Н блокував ресурс Р, що потрібний Н, то при блокуванні В його пріоритет привласнюється потокові Н, і, таким чином, він не може бути витиснутий потоком, з меншим ніж у В пріоритетом. Після того, як потік Н розблокує ресурс Р, його пріоритет знижується до вихідного значення і він витісняється потоком В.

Механізм спадкування пріоритетів, на жаль, не завжди може вирішити проблеми, пов’язані з блокуванням високопріоритетного потоку на заблокованому ресурсі. У випадку, коли декілька середньо- і низькопріоритетних потоків розділяють деякі ресурси з високопріоритетним потоком, можлива ситуація, коли високопріоритетному потоку прийдеться занадто довго чекати, поки кожний з молодших потоків не звільнить свій ресурс, і критичний строк обслуговування буде загублений. Однак такі ситуації (поділу ресурсів високопріоритетного потоку) повинні відслідковуватися розроблювачами прикладної системи. У принципі, спадкування пріоритетів є найбільш розповсюдженим механізмом захисту від проблеми інверсії пріоритетів.

Інший, менш розповсюджений метод, називається Протокол Граничного Пріоритету (Priority Ceiling Protocol). Метод полягає в додаванні до стандартних властивостей об’єктів синхронізації параметра, обумовленого максимальним пріоритетом потоків, які звертаються до об’єкта. Якщо такий параметр установлений, то пріоритет будь-якого потоку, що звертається до даного об’єкта синхронізації, буде збільшений до зазначеного рівня, і, таким чином, не зможе бути витиснутий ніяким потоком, що може мати потребу в заблокованому їм ресурсі. Після розблокування ресурсу, пріоритет потоку знижується до початкового рівня. Таким чином, виходить щось схоже на попереднє спадкування пріоритетів. Однак цей метод має ряд серйозних недоліків. У першу чергу, на розроблювача лягає робота з "навчання" об’єктів синхронізації їхньому рівню пріоритетів. По-друге, можливі затримки в запуску високопріоритетних потоків на час відпрацьовування низькопріоритетних потоків. У цілому, максимально ефективно цей механізм може бути використаний у випадку, коли є один потік жорсткого реального часу і декілька менш пріоритетних потоків, які розділяють з ним ресурси.

Дата добавления: 2014-01-07