Wird die Kooperationsplanung von Suspendierungsprozessen bei einer E/A -Operation durchführen?

Question

Viele Referenzen für Betriebssysteme sagen, dass ein Prozess mit kooperativer (im Gegensatz zu präventivem) Multitasking die CPU hält, bis sie sich explizit freiwillig ausnimmt. Wenn ein laufender Prozess eine E/A -Anfrage ausführt, die nicht sofort erfüllt werden kann (z. B. einen wichtigen Schlaganfall, der noch nicht verfügbar ist), sperrt der Scheduler ihn oder hält er die CPU wirklich, bis die Anfrage gewartet werden kann?

Bearbeitet, um "Blöcke auf I/O" durch "durchzuführen, führt eine E/A -Anfrage aus, die nicht sofort erfüllt werden kann."

Answer 1

In einer wirklich "kooperativen" Einstellung und wenn es keinen Hardwareschutz gab, könnte ein Prozess sicherlich die I/A blockieren und die Kontrolle nicht aufgeben, bis das I/A abgeschlossen war (oder die Kontrolle überhaupt nie aufgeben). Zum Beispiel war Windows 3.1 so: Wenn ein einzelner Benutzerprozess den gesamten Computer übernehmen wollte und etwas anderes ausführt, könnte dies.

Aber auf einem System mit Multitasking erwarten Sie, dass die System -API -E/A -Befehle die Kontrolle des Prozessors aufgeben, wenn sie aufgerufen werden. Wenn also ein Laufprozess auf der E/A blockiert wird, unter der Annahme, dass der Prozess die normalen System -APIs verwendet, dürfen andere Prozesse ausgeführt werden, bis die E/A abgeschlossen ist, und schließlich wird der ursprüngliche Prozess wieder aufgenommen, sobald die E/A abgeschlossen ist . Mit anderen Worten, es ist eine Möglichkeit, eine blockierende E/A -Funktion aufzurufen, wie ein Prozess auf einem kooperativen System sich freiwillig aussetzen kann.

Answer 2

Wenn ein Laufprozess auf I/O blockiert

Das Blockieren auf IO entspricht ziemlich gleichbedeutend mit der Aufnahme Ihres Prozesses. Im Zusammenhang mit dem Linux -Kernel, der einige IO -Systemaufrufe wie z. read() wird a verursachen sysenter Oder unterbrechen Sie den Handler, um sich um das IO zu kümmern, und rufen Sie an do_sys_read() letzten Endes. Wenn die aktuelle Anfrage nicht sofort erfüllt werden kann, ruft die Funktion auf sched() was dann einen anderen Prozess ausführen kann.

Im Zusammenhang mit einem kooperativen System würde ich erwarten, dass, wenn Sie einen System für einen IO-Grund anstellen, wenn die Anfrage nicht erfüllt werden kann, der Kernel eine andere Aufgabe auswählt und dies ausführt. Dieses Dokument Bietet Hintergrund - wenn Sie auf IO gewartet haben, könnten Sie für immer darauf aufgehängt werden. Die Idee der kooperativen Planung ist, dass Sie häufig anrufen sched() oder die äquvalente Relinquish-the-CPU-Methode, wenn CPU-intensive Aufgaben erledigen.

Kernel-Mode-Überlegungen werden interessanter. Auf Architekturen, in denen sie verfügbar sind, z. Bestimmte eingebettete Plattformen, Interrupts -Handler werden weiterhin als Reaktion auf Hardware- oder Software -Interrupts aufgerufen. Es ist normalerweise möglich, implementierungsweise, zu deaktivieren Interrupt -Handhabung, aber das hat auch Nachteile.

Answer 3

In der kooperativen Planung (vorzugsweise cooperative multitasking) Modell, es gibt kein Konzept eines Schedulers in dem Sinne, dass das Betriebssystem keine Kontrolle darüber hat, wie lange der Prozess ausgeführt wird.

Eine korrekt programmierte Anwendung würde die CPU auf I/A freiwillig aufgeben. Aber schlecht geschriebene Bewerbungen warten möglicherweise immer wieder auf die I/A, wodurch andere Prozesse blockiert werden.

PS: Dieser Ansatz wurde später vom größten Teil des Betriebssystems zugunsten der Präventiv-Planung (die einen externen Zeitplaner hatte) aufgegeben, und jetzt haben wir alle möglichen Zeitplanungsalgorithmen, die von verschiedenen Betriebssystemen verwendet werden.

BEARBEITEN: Meine Antwort basierte auf der Planung, wie in ihrer ursprünglichen Form beschrieben (vor Jahren: P). Da Gilles kommentierte, verwenden einige Systeme immer noch kooperative Planung. Und es gibt einen Scheduler. Ich bin mir nicht sicher, ob diese Systeme COS in ihrer reinen und originellen Form verwenden.

Answer 4

Kooperatives Multitasking impliziert, dass ein ausführender Kontext die Kontrolle explizit an den Scheduler abgeben muss und wenn er wünscht, kann ein Kontextschalter verhindern.

Die meisten Implementierungen führen explizit einen Kontextschalter für einen Systemaufruf durch, der nicht sofort zurückgibt, und selbst wenn dies häufig der Fall ist, um die Fairness der Prozessorzuweisung zu erhöhen.

Normalerweise ist es nur möglich, fehlgeschlagene Prozesse (oder absichtlich den Dienst für den Rest des Systems zu verweigern), um häufige Aufgabenanwechseln zu verhindern.

Die Prämption, wie von Gilles erläutert, ist eine Einschränkung der Architektur des Systems, die eine zeitgesteuerte Unterbrechung der aktiven Aufgabe und erzwungene Kontextschalter verhindert.