In Mutex, wie der Prozessor (CPU) wissen, welchen Prozess zu entsperren?

Question

nach meinem Wissen, der Prozess, der den Mutex sperrt, ist derjenige, der den Mutex freischalten muss.Mein Zweifel ist wie der Prozessor wissen, welchen Prozess zu entsperren? Gibt es eine Datenstruktur, die die PID (oder) etwas davon speichert bestimmter Prozess (intern) im Wartezustand, so dass der Prozessor nur den bestimmten Prozess entsperren kann.

bitte geben Antwort..dies d Frage in einem meiner Interviews gefragt.

Answer 1

Der Thread/Prozess, der den Mutex hat, ist der einzige, der sich im Code vorwärts bewegt. Später im Code für diesen Thread sollte es eine Freigabe des Mutex geben. Die anderen Threads/Prozesse, die nicht über den Mutex verfügen, werden darauf warten, so dass sie es weder aufnehmen noch freigeben, bis der 1-laufende Prozess zur Mutex-Version gelangt.

Answer 2

Wie der Prozessor wissen, welchen Prozess zu entsperren?

Der Prozessor weiß nichts; es führt nur blind die Kette von Maschinenanweisungen aus, die ihm zur Verfügung gestellt wurden.

Die Threading-Bibliothek, auf der anderen Seite wurde sorgfältig entwickelt, um mit dieser Art von Sache umzugehen. Außerdem enthält jedes moderne/Multitasking-Betriebssystem einen Thread-Scheduler, der beim Booten in den Speicher geladen wird, und verwaltet, welche Threads wann ausgeführt werden. Es arbeitet mit der Threading-Bibliothek zusammen, um Probleme beim Sperren/Entsperren korrekt zu behandeln.

Die Frage lautet also: Woher weiß die Betriebssystem-Software, welcher Thread als nächstes aufwachen soll, wenn ein Mutex entsperrt wird?

Natürlich variiert die tatsächliche Implementierung mit dem Betriebssystem, aber konzeptionell können Sie sich jedes Mutex-Objekt mit einer Linked-List vorstellen, und wenn ein Thread versucht, einen Mutex zu sperren, der bereits gesperrt ist, fügt sich der Thread zum Tail hinzu der verknüpften Liste und teilt dem Scheduler dann mit, dass er (der Thread) in den Ruhezustand versetzt wird. Später, wenn der Mutex entsperrt ist, öffnet die Entsperrroutine den ersten schlafenden Thread (falls vorhanden) aus der verknüpften Liste, ordnet dem Thread den Eigentümer des Mutex erneut zu und fordert dann den Scheduler auf, aufzuwachen diesen Thread so schnell wie möglich.

(Vorbehalte: Eine reale Implementierung wäre wahrscheinlich ein bisschen komplexer als das, da es darauf achten muss, Rennbedingungen zu vermeiden und die Leistung zu maximieren, aber ich denke, das gibt Ihnen eine Vorstellung davon, wie es gemacht werden könnte Beachten Sie, dass in dieser Beispielimplementierung Threads den Mutex in der Reihenfolge "first-come/first-served" erhalten, dh in der gleichen Reihenfolge, in der sie lock() aufgerufen haben, aber in vielen Implementierungen der realen Welt ist diese Reihenfolge nicht garantiert. also sollten Sie sich nicht darauf verlassen)