Das [40009004] RC 4000 Multiprogramming System ist ein nicht mehr lauffähiges Betriebssystem, das 1969 für den RC 4000-Minicomputer entwickelt wurde. Es ist historisch gesehen der erste Versuch, ein Betriebssystem in eine Gruppe interagierender kommunizierender Programme zu zerlegen über eine Nachricht, die den Kernel passiert. Obwohl der RC 4000 selbst nicht sehr erfolgreich war, war er dennoch äußerst einflussreich und leitete das Mikrokernel-Konzept ein, das die Betriebssystemforschung in den 1970er und 1980er Jahren dominierte. Das System ist auch als Monitor und, etwas verwirrend, einfach RC 4000 bekannt, abhängig von der Referenz. Der Klarheit halber wird in diesem Artikel der Begriff Monitor verwendet.
Monitor wurde größtenteils von einem Programmierer, Per Brinch Hansen, geschaffen, der im Regnecentralen arbeitete, wo der RC 4000 entwickelt wurde. Leif Svalgaard war an der Implementierung und dem Test von Monitor beteiligt. Brinch Hansen stellte fest, dass kein vorhandenes Betriebssystem für die neue Maschine geeignet war und müde war, bestehende Systeme anpassen zu müssen. Seiner Meinung nach wäre es eine bessere Lösung, einen zugrunde liegenden Kernel zu bauen, den er als -Kern bezeichnete, der zum Aufbau eines Betriebssystems aus interagierenden Programmen verwendet werden könnte. Unix verwendet beispielsweise für viele Aufgaben kleine interagierende Programme, die Daten durch ein als Pipes bekanntes System übertragen. Eine große Menge an grundlegendem Code ist jedoch im Kernel selbst vergraben, insbesondere Dateisysteme und Programmsteuerung. Monitor würde auch diesen Code entfernen und fast das gesamte System zu einem Satz interagierender Programme machen, wodurch der Kern (Kern) auf ein Kommunikations- und Unterstützungssystem reduziert wird.
Monitor verwendete ein Pipe-ähnliches System des Shared Memory als Grundlage seiner Kommunikation zwischen Prozessen. Daten, die von einem Prozess an einen anderen gesendet werden sollen, wurden in einen leeren Pufferspeicher kopiert. Wenn das empfangende Programm bereit war, wurde es wieder ausgegeben. Der Puffer wurde dann in den Pool zurückgegeben. Programme hatten eine sehr einfache API zum Übergeben von Daten, wobei ein asynchroner Satz von vier Methoden verwendet wurde. Client-Anwendungen senden Daten mit der Sende-Nachricht und könnten optional die Verwendung der Wait-Antwort blockieren. Server verwendeten eine Spiegelung von Aufrufen, Wartemeldung und Antwort senden . Beachten Sie, dass Nachrichten für jede gesendete Nachricht einen impliziten "Rückweg" hatten, wodurch die Semantik einem Remoteprozeduraufruf ähnlicher ist als das vollständig E / A-basierte System von Mach.
Monitor teilte den Anwendungsraum in zwei Teile; Interne Prozesse waren die Ausführung traditioneller Programme, die auf Anfrage gestartet wurden, während externe Prozesse effektiv Gerätetreiber waren. Externe Prozesse wurden tatsächlich außerhalb des Benutzerraums vom Kern gehandhabt, obwohl sie wie jedes andere Programm gestartet und gestoppt werden konnten. Interne Prozesse wurden im Zusammenhang mit dem "übergeordneten" Starter gestartet, so dass jeder Benutzer sein eigenes Betriebssystem effektiv aufbauen konnte, indem er Programme in seinem eigenen Kontext startete und stoppte.
Wenn überhaupt, wurde die Planung vollständig den Programmen überlassen (in den 1960er Jahren war Multitasking ein umstrittenes Feature). Ein Benutzer kann eine Sitzung in einer vorbeugenden Multitasking-Umgebung starten, während ein anderer Benutzer im Einzelbenutzermodus starten kann, um die Stapelverarbeitung mit höherer Geschwindigkeit auszuführen. Die Echtzeitplanung kann unterstützt werden, indem Nachrichten an einen Zeitgeberprozess gesendet werden, der nur zum richtigen Zeitpunkt zurückgegeben wird.
Der Monitor zeigte eine wirklich schreckliche Leistung. Ein Großteil davon war auf die Kosten für IPC zurückzuführen, ein Problem, das die meisten Mikrokerne inzwischen geplagt hat. Unter Monitor wurden die Daten für jede Nachricht zweimal kopiert, und die Speicherbehandlung auf der RC 4000 war nicht besonders schnell. Ein weiterer Anlass zu ernster Besorgnis war der Start und das Töten von Programmen zur Bearbeitung von Anfragen, die ständig auftraten.
Diese beiden Bereiche wurden seit der Veröffentlichung von Monitor größtenteils weiterentwickelt, wobei neuere Konstruktionen die Verwendung von Hardware zur Unterstützung von Messaging und die Unterstützung von Threads innerhalb von Anwendungen zur Verkürzung der Startzeiten forderten. Zum Beispiel benötigte Mach eine Speicherverwaltungseinheit, um das Messaging durch Verwendung des Copy-on-Write-Protokolls zu verbessern und Daten von Prozess zu Prozess abzubilden (statt zu kopieren). Mach verwendete auch das Threading ausgiebig, wodurch die externen Programme oder -Server in moderneren Begriffen leicht neue Handler für eingehende Anforderungen starten konnten. Trotzdem war Mach IPC zu langsam, um den Mikrokernel-Ansatz praktisch nutzbar zu machen. Dies änderte sich erst, als der L4-Mikrokern von Liedtke eine Verbesserung der IPC-Gemeinkosten um eine Größenordnung zeigte.
Siehe auch [ edit ]
Referenzen [ edit ]
No comments:
Post a Comment