Auf der Mutex-Beschreibungsseite der FreeRTOS-Website findet sich folgender Satz:
Die Prioritätsvererbung heilt die Prioritätsumkehrung nicht
Soweit ich weiß, dachte ich, dass die Prioritätsvererbung ein Heilmittel für die Prioritätsumkehr ist. Wenn die Task A mit hoher Priorität durch die Task B mit niedriger Priorität blockiert wird, erbt Task B bei der Prioritätsvererbung die Prioritätsstufe von Task A (hoch). Das bedeutet, dass keine Aufgabe mit mittlerer Priorität die Ausführung von Aufgabe A verzögern kann. Folglich tritt keine Prioritätsumkehr auf. Was ist an meiner Überlegung falsch?
Gemeint ist, dass es Situationen geben kann, die eine Prioritätsumkehr sind und nicht durch Prioritätsvererbung gelöst werden.
Ein Beispiel: Die verwendete Normalsituation ist, dass Task A , B , C in abnehmender Priorität sind. C nimmt einen Mutex, dann wird B bereit und läuft. Nun wird A fertig. A braucht den Mutex, also blockt darauf. Dann läuft B weiter, was C daran hindert , den Mutex freizugeben. Dadurch hat B effektiv genug Priorität, um A an der Arbeit zu hindern.
Die Prioritätsvererbung würde dazu führen, dass C die gleiche Priorität wie A hat . Betrachten Sie jedoch den Fall, in dem C seine Arbeit zum Freigeben des Mutex nicht abschließen kann, ohne dass B Arbeit leistet. Dann haben Sie wegen der Prioritätsvererbung einen Deadlock.
Daher kann es zu einer Prioritätsumkehr kommen, und es kann schwierig sein, potenzielle Fehler zu erkennen. Die Lösung besteht darin, zu versuchen, dies so weit wie möglich durch Design zu vermeiden.
Hier ist der gesamte Klappentext von der Freertos-Site:
Prioritätsvererbung heilt keine Prioritätsumkehrung! Es minimiert nur seine Wirkung in manchen Situationen. Harte Echtzeitanwendungen sollten so gestaltet werden, dass es gar nicht erst zu einer Prioritätsumkehr kommt.
Wenn Aufgabe C Aufgabe B benötigt, um eine Arbeit abzuschließen, damit Aufgabe C den ersten Mutex freigeben kann, muss es eine zweite Sperr-/Mutex-Verbindung zwischen den Aufgaben C und B geben, die die Prioritätsvererbung verwenden könnte, um die Priorität von Aufgabe B zu erhöhen, was Aufgabe B ermöglicht um die von Task C benötigte Arbeit abzuschließen, damit der erste Mutex freigegeben werden kann.