Ist dies ein Beispiel für ein Livelock oder Deadlock oder Hungertod? Scheduling Preemptive Priorität</p> <p>Situation::

Question

Scheduling Scheme

Verfahren L (niedrige Priorität) erwirbt eine spinlock auf einer Ressource (R). Während sich L immer noch im kritischen Abschnitt befindet, wird L aufgrund des Eintretens eines anderen Prozesses - H (höhere Priorität) in die Bereit-Warteschlange - vorweggenommen. .

Allerdings muss H auch auf die Ressource R zugreifen und versucht so, eine Spin-Sperre zu erhalten, die dazu führt, dass H zu beschäftigt wird. Da Spinlocks verwendet werden, geht H niemals tatsächlich in Wait und ist immer im Running-Status oder Ready-Zustand (falls ein Prozess mit höherer Priorität in die Ready-Warteschlange gelangt), wodurch verhindert wird, dass L oder ein Prozess mit einer Priorität niedriger als H ausgeführt wird.

A) Alle Prozesse mit Priorität kleiner als H angesehen werden kann unter Starvation

B) alle Prozesse mit Priorität auf weniger als H sowie den Prozess H, in Betracht gezogen werden kann, in einem Stillstand sein. [Aber müssen sich die Prozesse nicht im Wartezustand befinden, damit das System als in einem Deadlock befindlich angesehen wird?]

C) Alle Prozesse mit Priorität kleiner als H sowie der Prozess H können sein man betrachtet sie als in einem Livelock. [Aber dann ändert sich nur der Zustand von H ständig, alle Prozesse mit niedriger Priorität bleiben nur im Bereitschaftszustand. Muss sich der Zustand aller Prozesse nicht ständig ändern (als Teil eines Spinlocks), wenn das System im Livelock ist?]

D) H allein kann als Livelock betrachtet werden, alle Prozesse mit niedrigerer Priorität sind unter Hunger, nicht in Livelock.

E) H geht nicht weiter, kann aber nicht als Livelock betrachtet werden. Alle Prozesse mit niedrigerer Priorität stehen gerade unter Hunger, nicht im Livelock.

Welche der obigen Aussagen sind richtig? Können Sie erklären?

Answer 1

Dies ist kein Livelock, da die Definition von Livelock "states of the processes involved in the livelock constantly change with regard to one another" erfordert, und hier werden die Zustände effektiv nicht geändert.

Der erste Prozess kann als Prozessorverknappung betrachtet werden, denn wenn ein zusätzlicher Prozessor vorhanden wäre, könnte er darauf ausgeführt werden und schließlich die Sperre freigeben und den zweiten Prozessor ausführen lassen.

Die Situation kann auch als Deadlock betrachtet werden, mit 2 Ressourcen im Ressourcendiagramm und 2 Prozessen, die versuchen, diese Ressourcen in entgegengesetzten Richtungen zu erwerben: Der erste Prozess besitzt die Sperre und der Prozessor muss fortfahren, während der zweite Prozess besitzt den Prozessor und benötigt die Sperre, um fortzufahren.