Mach ist ein an der Universität von Carnegie Mellon entwickelter Betriebssystemkern, um Betriebssystemforschung, in erster Linie verteilte und parallele Berechnung zu unterstützen. Obwohl Mach häufig als eines der frühsten Beispiele eines Mikrokerns, nicht erwähnt wird, sind alle Versionen des Machs Mikrokerne. Die Ableitungen des Machs sind die Basis der modernen Betriebssystemkerne in Mac OS X (der nicht ein Mikrokern ist), und GNU Hurd (der ein Mikrokern ist).

Das Projekt an Carnegie Mellon ist von 1985 bis 1994 gelaufen, im offenbaren Misserfolg mit dem Mach 3.0 endend, der schließlich ein wahrer Mikrokern war. Mach wurde als ein Ersatz für den Kern in der BSD Version von UNIX entwickelt, so würde kein neues Betriebssystem darum entworfen werden müssen. Heute scheint die weitere experimentelle Forschung über das Mach, geendet zu haben, obwohl Mach und seine Ableitungen im Gebrauch in mehreren kommerziellen Betriebssystemen, wie NeXTSTEP und OPENSTEP und am meisten namentlich Mac OS X sind, der den XNU Betriebssystemkern verwendet, der ein früheres (nichtmikrokern)-Mach als ein Hauptbestandteil vereinigt. Das Mach wurde virtuelles Speicherverwaltungssystem auch von den BSD Entwicklern an CSRG angenommen, und erscheint in modernen BSD-abgeleiteten UNIX Systemen wie FreeBSD. Weder Mac OS X noch FreeBSD erhalten die im Mach den Weg gebahnte Mikrokernstruktur aufrecht, obwohl Mac OS X fortsetzt, Mikrokernzwischenprozess-Kommunikation und Kontrollprimitive für den Gebrauch direkt durch Anwendungen anzubieten.

Mach ist der logische Nachfolger des Akzent-Kerns von Carnegie Mellon. Der Leitungsentwickler auf dem Mach-Projekt, Richard Rashid, hat an Microsoft seit 1991 in verschiedenen Positionen auf höchster Ebene gearbeitet, die um die Abteilung von Microsoft Research kreisen. Ein anderer der ursprünglichen Mach-Entwickler, Avie Tevanians, war früher Leiter der Software an dann dann Hauptsoftwaretechnologieoffizier am Apple Computer bis März 2006.

Geschichte

Name

Gemäß Tevanian kommt "Mach" aus einem mispronounciation. Als er und andere gegangen sind, um an einem regnerischen Pittsburger Tag Mittagessen einzunehmen, Schlamm-Pfützen vermeidend, hat Tevanian scherzend vorgeschlagen, dass sie ihren neuen Mikrokern-DRECK, für den "Mehrbenutzernachrichtenkern" oder "Mehrverarbeiter Universaler Nachrichtenkern" nennen. Ein italienischer Kollege hat DRECK als "Mach" falsch ausgesprochen, das Rashid gemocht hat.

Mach-Konzepte

Seitdem Mach als ein "Störsignal"-Ersatz für den traditionellen UNIX Kern entworfen wurde, konzentriert sich diese Diskussion darauf, was Mach von UNIX unterscheidet. Es ist klar früh geworden, dass das Konzept von UNIX von allem als eine Datei auf modernen Systemen nicht praktisch sein könnte, obwohl einige Systeme wie Plan 9 von Glockenlaboratorien diesen Weg versucht haben. Dennoch haben jene dieselben Entwickler den Verlust der Flexibilität bejammert, die das ursprüngliche Konzept angeboten hat. Ein anderes Niveau der Virtualisierung wurde gesucht, der das System wieder würde "arbeiten" lassen.

Die kritische Abstraktion in UNIX war die Pfeife. Was erforderlich war, war ein einer Pfeife ähnliches Konzept, das an einem viel allgemeineren Niveau gearbeitet hat, einer breiten Vielfalt der Information erlaubend, zwischen Programmen passiert zu werden. Solch ein System hat wirklich mit der Zwischenprozess-Kommunikation (IPC) bestanden: Ein einer Pfeife ähnliches System, das jede Information zwischen zwei Programmen im Vergleich mit der dateiähnlichen Information bewegen würde. Während viele Systeme, einschließlich des grössten Teiles von Unixes, verschiedene IPC Durchführungen im Laufe der Jahre hinzugefügt hatten, zurzeit waren das allgemein für einmalige Aufgaben nur wirklich nützliche Bibliotheken des speziellen Zwecks.

Universität von Carnegie Mellon hat Experimentieren entlang diesen Linien laut des Akzent-Kernprojektes mit einem IPC auf dem geteilten Gedächtnis gestützten System angefangen. Akzent war ein rein experimentelles System mit vielen Eigenschaften, die in ad hoc Mode über eine Zeitdauer von der Zeit mit sich ändernden Forschungsinteressen entwickelt sind. Zusätzlich wurde die Nützlichkeit des Akzents für die Forschung beschränkt, weil es nicht UNIX-vereinbar war, und UNIX bereits die allgemeine Norm für fast die ganze Betriebssystemforschung war. Schließlich wurde Akzent mit der Hardware-Plattform dicht verbunden, auf der er entwickelt wurde, und zurzeit am Anfang der 1980er Jahre es geschienen ist, dass es bald eine Explosion von neuen Plattformen geben würde, passen viele von ihnen massiv an.

Mach hat größtenteils als eine Anstrengung angefangen, einen sauber definierten, UNIX-basierten, hoch tragbaren Akzent zu erzeugen. Das Ergebnis war eine kurze Liste von allgemeinen Konzepten:

• eine "Aufgabe" ist ein Gegenstand, der aus einer Reihe von Systemmitteln besteht, die "Fäden" ermöglichen, zu führen
• ein "Faden" ist eine einzelne Einheit der Ausführung, besteht innerhalb eines Zusammenhangs einer Aufgabe und teilt die Mittel der Aufgabe
• ein "Hafen" ist eine geschützte Nachrichtenwarteschlange für die Kommunikation zwischen Aufgaben; eigene Aufgaben senden und erhalten Rechte auf jeden Hafen
• "Nachrichten" sind Sammlungen von getippten Datengegenständen, sie können nur an Häfen - nicht spezifische Aufgaben gesandt werden oder fädeln ein

Mach hat sich auf den IPC Konzepten des Akzents, aber gemacht das System entwickelt, das viel mehr in der Natur UNIX ähnlich ist, sogar fähig, UNIX Programme mit wenig oder keiner Modifizierung zu führen. Um das zu tun, hat Mach das Konzept eines Hafens eingeführt, jeden Endpunkt eines Zweiwege-IPC vertretend. Häfen hatten Sicherheit und Rechte wie Dateien unter UNIX, einem sehr UNIX ähnlichen Modell des Schutzes erlaubend, auf sie angewandt zu werden. Zusätzlich hat Mach jedem Programm erlaubt, Vorzüge zu behandeln, die normalerweise dem Betriebssystem nur gegeben würden, um Benutzerraumfährten zu erlauben, Dinge zu behandeln, wie, mit Hardware aufeinander zu wirken.

Unter dem Mach, und wie UNIX wird das Betriebssystem wieder in erster Linie eine Sammlung von Dienstprogrammen. Als mit UNIX behält Mach das Konzept eines Fahrers, für die Hardware zu behandeln. Deshalb müssen alle Treiber für die gegenwärtige Hardware in den Mikrokern eingeschlossen werden. Andere Architekturen, die auf der Hardware-Abstraktionsschicht oder exokernels gestützt sind, konnten die Fahrer aus dem Mikrokern bewegen.

Der Hauptunterschied mit UNIX ist, dass statt Dienstprogramme, die Dateien behandeln, sie jede "Aufgabe" behandeln können. Mehr Betriebssystemcode wurde aus dem Kern und in den Benutzerraum bewegt, auf einen viel kleineren Kern und den Anstieg des Begriffes Mikrokern hinauslaufend. Verschieden von traditionellen Systemen unter dem Mach kann ein Prozess oder "Aufgabe", aus mehreren Fäden bestehen. Während das in modernen Systemen üblich ist, war Mach das erste System, um Aufgaben und Fäden auf diese Weise zu definieren. Der Job des Kerns wurde davon reduziert, im Wesentlichen das Betriebssystem zum Aufrechterhalten der "Dienstprogramme" und der Terminplanung ihres Zugangs zur Hardware zu sein.

Die Existenz von Häfen und der Gebrauch von IPC sind vielleicht der grundsätzlichste Unterschied zwischen Mach und traditionellen Kernen. Unter UNIX, den Kern nennend, besteht aus einer Operation bekannt als ein syscall oder Falle. Das Programm verwendet eine Bibliothek, um Daten in eine weithin bekannte Position im Gedächtnis zu legen, und verursacht dann eine Schuld, einen Typ des Fehlers. Wenn das System zuerst angefangen wird, wird der Kern aufgestellt, um der "Dressierer" aller Schulden so zu sein, wenn das Programm eine Schuld verursacht, übernimmt der Kern, untersucht die Information ist dazu gegangen, und befolgt dann die Anweisungen.

Unter dem Mach wurde das IPC System für diese Rolle stattdessen verwendet. Um Systemfunktionalität zu nennen, würde ein Programm den Kern um den Zugang zu einem Hafen bitten, verwende dann das IPC System, um Nachrichten an diesen Hafen zu senden. Obwohl die Nachrichten durch syscalls ausgelöst wurden, wie sie auf anderen Kernen unter dem Mach sein würden, das ziemlich viel ganzer Kernbehandelnder war, würde die wirkliche Bitte bis zu einem anderen Programm sein.

Der Gebrauch von IPC für die Nachricht, die geht, hat Unterstützung für Fäden und Parallelität genützt. Seitdem Aufgaben aus vielfachen Fäden bestanden haben, und es der Code in den Fäden war, die den IPC Mechanismus verwendet haben, ist Mach im Stande gewesen, Fäden einzufrieren und aufzutauen, während die Nachricht behandelt wurde. Das hat dem System erlaubt, über vielfache Verarbeiter, entweder das Verwenden des geteilten Gedächtnisses direkt als in den meisten Mach-Nachrichten, oder durch das Hinzufügen des Codes verteilt zu werden, um die Nachricht an einen anderen Verarbeiter wenn erforderlich zu kopieren. In einem traditionellen Kern ist das schwierig durchzuführen; das System muss sicher sein, dass verschiedene Programme nicht versuchen, demselben Gedächtnis von verschiedenen Verarbeitern zu schreiben. Unter dem Mach wurde das gut definiert und leicht durchzuführen; es war der wirkliche Prozess des Zugreifens auf dieses Gedächtnis, die Häfen, der ein erstklassiger Bürger des Systems gemacht wurde.

Das IPC System hatte am Anfang Leistungsprobleme, so wurden einige Strategien entwickelt, um den Einfluss zu minimieren. Wie sein Vorgänger, Akzent, hat Mach einen einzelnen Mechanismus des geteilten Gedächtnisses für den physisch vorübergehenden die Nachricht von einem Programm bis einen anderen verwendet. Physisch das Kopieren der Nachricht würde zu langsam sein, so verlässt sich Mach auf die Speicherverwaltungseinheit (MMU) der Maschine, um die Daten von einem Programm bis einen anderen schnell kartografisch darzustellen. Nur wenn die Daten dem geschrieben werden, würde es, ein Prozess bekannt als copy-write physisch kopiert werden müssen.

Nachrichten wurden auch für die Gültigkeit durch den Kern überprüft, um schlechte Daten zu vermeiden, die eines der vielen Programme zertrümmern, die das System zusammensetzen. Häfen wurden auf den UNIX Dateisystemkonzepten absichtlich modelliert. Das hat dem Benutzer erlaubt, Häfen mit vorhandenen Dateisystemnavigationskonzepten zu finden, sowie Rechte und Erlaubnis zuteilend, wie sie auf dem Dateisystem würden.

Die Entwicklung unter solch einem System würde leichter sein. Nicht nur würde der Code, der darauf wird arbeitet, besteht in einem traditionellen Programm, das mit vorhandenen Werkzeugen gebaut werden konnte, konnte er auch angefangen, die Fehler beseitigt werden und hat das Verwenden derselben Werkzeuge ausgerottet. Mit einem Monokern würde ein Programmfehler im neuen Code die komplette Maschine abnehmen und einen Neustart verlangen, wohingegen unter dem Mach das nur verlangen würde, dass das Programm wiederangefangen wird. Zusätzlich konnte der Benutzer das System schneidern, um einzuschließen, oder was für Eigenschaften auszuschließen, die sie verlangt haben. Seitdem das Betriebssystem einfach eine Sammlung von Programmen war, konnten sie hinzufügen oder Teile entfernen, indem sie einfach gelaufen sind oder sie getötet haben, weil sie jedes andere Programm würden.

Schließlich, unter dem Mach, wurden alle diese Eigenschaften absichtlich entworfen, um äußerst neutrale Plattform zu sein. Einen Text auf dem Mach anzusetzen:

: Verschieden von UNIX, der ohne Rücksicht auf die Mehrverarbeitung entwickelt wurde, vereinigt Mach in einer Prozession mehrgehende Unterstützung überall. Seine in einer Prozession mehrgehende Unterstützung ist auch im Intervall von geteilten Speichersystemen zu Systemen ohne zwischen Verarbeitern geteiltes Gedächtnis außerordentlich flexibel. Mach wird entworfen, um auf Computersystemen im Intervall von einem zu Tausenden von Verarbeitern zu laufen. Außerdem wird Mach zu vielen verschiedenen Computerarchitekturen leicht getragen. Eine Schlüsselabsicht des Machs ist, ein verteiltes System zu sein, das zur Wirkung auf der heterogenen Hardware fähig ist. (Anhang B, Systemkonzepte Bedienend)

Es gibt mehrere Nachteile jedoch. Ein relativ weltlicher ist, dass es nicht klar ist, wie man Häfen findet. Unter UNIX wurde dieses Problem mit der Zeit behoben, weil sich Programmierer über mehrere "weithin bekannte" Positionen im Dateisystem geeinigt haben, um verschiedenen Aufgaben zu dienen. Während diese dieselbe Annäherung für die Häfen des Machs ebenso unter dem Mach gearbeitet hat, wie man annahm, war das Betriebssystem viel mehr Flüssigkeit, mit dem Hafen-Erscheinen und Verschwinden die ganze Zeit. Ohne einen Mechanismus, Häfen und die Dienstleistungen zu finden, haben sie vertreten, viel von dieser Flexibilität würde verloren.

Entwicklung

Mach wurde als zusätzlicher Code geschrieben direkt ins vorhandene 4.2BSD Kern am Anfang veranstaltet, der Mannschaft erlaubend, am System zu arbeiten, lange bevor es abgeschlossen war. Arbeit hat mit dem bereits funktionellen Akzent IPC/port System angefangen, und ist zu den anderen Schlüsselteilen des OS, der Aufgaben und der Fäden und des virtuellen Gedächtnisses weitergegangen. Da Teile vollendet wurden, wurden verschiedene Teile des BSD Systems umgeschrieben, um ins Mach zu rufen, und eine Änderung zu 4.3BSD wurde auch während dieses Prozesses vorgenommen.

Vor 1986 war das System zum Punkt des im Stande Seins abgeschlossen, selbstständig auf dem DEZ VAX zu führen. Obwohl, wenig vom praktischen Wert tuend, wurde die Absicht, einen Mikrokern zu machen, begriffen. Dem wurde bald von Versionen auf IBM PC/RT und für Sonne-Mikrosysteme 68030-basierte Arbeitsplätze gefolgt, die Beweglichkeit des Systems beweisend. Vor 1987 hat die Liste die Wiederholung Multimax und Folgende Gleichgewicht-Maschinen eingeschlossen, die Fähigkeit des Machs prüfend, auf Mehrverarbeiter-Systemen zu laufen. Eine öffentliche Ausgabe 1 wurde in diesem Jahr, und Ausgabe 2 gefolgt im nächsten Jahr gemacht.

Im Laufe dieser Zeit wurde die Versprechung eines "wahren" Mikrokerns noch nicht geliefert. Diese frühen Mach-Versionen haben die Mehrheit 4.3BSD im Kern, ein als POE Server bekanntes System eingeschlossen, auf einen Kern hinauslaufend, der wirklich größer war als der UNIX, auf dem es basiert hat. Die Idee war jedoch, die UNIX Schicht aus dem Kern in den Benutzerraum zu bewegen, wo es leichter darauf gearbeitet und sogar völlig ersetzt werden konnte. Leider hat sich Leistung erwiesen, ein Hauptproblem zu sein, und mehrere architektonische Änderungen wurden vorgenommen, um dieses Problem zu beheben. Das unhandliche UNIX-Genehmigen von Problemen plagte auch Forscher, so hat diese frühe Anstrengung, eine nichtlizenzierte UNIX ähnliche Systemumgebung zur Verfügung zu stellen, fortgesetzt, Gebrauch gut in die weitere Entwicklung des Machs zu finden.

Das resultierende Mach 3 wurde 1990 veröffentlicht, und hat intensives Interesse erzeugt. Eine kleine Mannschaft hatte Mach gebaut und es zu mehreren Plattformen einschließlich komplizierter Mehrverarbeiter-Systeme getragen, die ernste Probleme für alt-artige Kerne verursachten. Dieses erzeugte beträchtliche Interesse am kommerziellen Markt, wo mehrere Gesellschaften in der Mitte des Betrachtens von sich ändernden Hardware-Plattformen waren. Wenn das vorhandene System getragen werden konnte, um auf dem Mach zu laufen, würde es scheinen, dass es dann leicht sein würde, die Plattform unten zu ändern.

Mach hat eine Hauptzunahme in der Sichtbarkeit erhalten, als Open Software Foundation (OSF) bekannt gegeben hat, dass sie zukünftige Versionen von OSF/1 auf dem Mach 2.5 veranstalten würden, und Mach 3 ebenso untersuchten. Mach 2.5 wurde auch für das System von NeXTSTEP und mehrere kommerzielle Mehrverarbeiter-Verkäufer ausgewählt. Mach 3 hat zu mehreren Anstrengungen geführt, andere Betriebssystemteile für den Mikrokern, einschließlich des Arbeitsplatzes von IBM OS und mehrere Anstrengungen durch den Apple Computer zu tragen, um eine Quer-Plattform-Version des Mac OS zu bauen.

Leistungsprobleme

Mach war ursprünglich beabsichtigt, um ein Ersatz für klassischen monolithischen UNIX zu sein, und hat aus diesem Grund viele UNIX ähnliche Ideen enthalten. Zum Beispiel hat Mach einen permissioning und nach dem Dateisystem von UNIX gestaltetes Sicherheitssystem verwendet. Seitdem der Kern privilegiert wurde (im Kernraum laufend), über andere OS Server und Software, war es für das Stören oder die böswilligen Programme möglich, ihm Befehle zu senden, die dem System Schaden verursachen würden, und aus diesem Grund der Kern jede Nachricht für die Gültigkeit überprüft hat. Zusätzlich sollte der grösste Teil der Betriebssystemfunktionalität in Benutzerraumfährten gelegen werden, so hat das bedeutet, dass es einen Weg für den Kern geben musste, um diesen Programmen zusätzliche Vorzüge zu gewähren, auf der Hardware zum Beispiel zu funktionieren.

Einige von den esoterischeren Eigenschaften des Machs haben auch auf diesem demselben IPC Mechanismus basiert. Zum Beispiel ist Mach im Stande gewesen, Mehrverarbeiter-Maschinen mit der Bequemlichkeit zu unterstützen. In einer traditionellen umfassenden Kernarbeit muss ausgeführt werden, um es einspringend oder unterbrechbar zu machen, wie Programme, die auf verschiedenen Verarbeitern laufen, in den Kern zur gleichen Zeit rufen konnten. Unter dem Mach werden die Bit des Betriebssystems in Servern isoliert, die im Stande sind, wie jedes andere Programm auf jedem Verarbeiter zu laufen. Obwohl in der Theorie der Mach-Kern auch würde einspringend sein müssen, in der Praxis ist das nicht ein Problem, weil seine Ansprechzeiten so schnell sind, kann es einfach warten und Bitten der Reihe nach dienen. Mach hat auch einen Server eingeschlossen, der Nachrichten nicht nur zwischen Programmen, aber sogar über das Netz nachschicken konnte, das ein Gebiet der intensiven Entwicklung gegen Ende der 1980er Jahre und Anfang der 1990er Jahre war.

Leider hat sich der Gebrauch von IPC für fast alle Aufgaben erwiesen, ernsten Leistungseinfluss zu haben. Abrisspunkte auf der 1997-Hardware haben gezeigt, dass Mach 3.0-basierte UNIX Durchführungen des einzelnen Servers um ungefähr 50 % langsamer war als heimischer UNIX.

Studien haben gezeigt, dass die große Mehrheit dieses Leistungserfolgs, 73 % durch ein Maß, wegen der Gemeinkosten des IPC war. Und das wurde auf einem System mit einem einzelnen großen Server gemessen, der das Betriebssystem zur Verfügung stellt; das Brechen des Betriebssystems weiter in kleinere Server würde nur das Problem schlechter machen. Es ist geschienen, dass die Absicht einer Sammlung Server einfach nicht möglich war.

Viele Versuche wurden gemacht, die Leistung des Machs und der einem Mach ähnlichen Mikrokerne zu verbessern, aber durch die Mitte der 1990er Jahre war viel vom frühen intensiven Interesse gestorben. Das Konzept eines auf IPC gestützten Betriebssystems ist geschienen, die selbst rissig gemachte Idee tot zu sein.

Tatsächlich hat die weitere Studie der genauen Natur der Leistungsprobleme mehrere interessante Tatsachen nach oben gedreht. Man war das der IPC selbst war nicht das Problem: Es gab einige, die oben mit dem kartografisch darstellenden Gedächtnis vereinigt sind, mussten es unterstützen, aber das hat nur eine kleine Zeitdauer zum Bilden eines Anrufs hinzugefügt. Der Rest, 80 % der Zeit, die wird ausgibt, war wegen zusätzlicher Aufgaben, die der Kern auf den Nachrichten führte. Primär unter diesen war die Hafen-Recht-Überprüfung und Nachrichtengültigkeit. In Abrisspunkten auf einem 486DX-50 hat ein UNIX Standardsystemanruf einen Durchschnitt 21μs genommen, um, während die gleichwertige Operation mit dem Mach IPC durchschnittlich 114μs zu vollenden. Nur 18μs dessen war verbundene Hardware; der Rest war der Mach-Kern das Laufen verschiedener Routinen auf der Nachricht. In Anbetracht eines syscall, der nichts tut, würde eine volle Hin- und Rückfahrt unter BSD über 40μs verlangen, wohingegen auf einem Benutzerraummach-System es gerade unter 500μs nehmen würde.

Als Mach zuerst in 2.x Versionen ernstlich verwendet wurde, war Leistung langsamer als traditionelle monolithische Betriebssysteme, vielleicht nicht weniger als 25 %. Diese Kosten wurden besonders nicht betrachtet, jedoch beunruhigend seiend, weil das System auch Mehrverarbeiter-Unterstützung und leichte Beweglichkeit anbot. Viele haben gefunden, dass das erwartete und annehmbare Kosten zur Bezahlung war. Als Mach 3 versucht hat, den grössten Teil des Betriebssystems in den Benutzerraum zu bewegen, sind die Gemeinkosten höher noch geworden: Abrisspunkte zwischen Mach und Ultrix auf einem MIPS R3000 haben einen Leistungserfolg als groß als 67 % auf einigen Arbeitspensen gezeigt.

Zum Beispiel ist das Bekommen der Systemzeit mit einem IPC-Anruf zur Benutzerraumserver-Aufrechterhalten-Systemuhr verbunden. Der Anrufer stellt zuerst in den Kern Fallen, einen Zusammenhang-Schalter und kartografisch darstellendes Gedächtnis verursachend. Der Kern überprüft dann, dass der Anrufer Zugriffsrechte verlangt hat, und dass die Nachricht gültig ist. Wenn es tut, gibt es einen anderen Zusammenhang-Schalter und Gedächtnis, das kartografisch darstellt, um den Anruf in den Benutzerraumserver zu vollenden. Der Prozess muss dann wiederholt werden, um die Ergebnisse zurückzugeben, sich auf insgesamt vier Zusammenhang-Schalter und Gedächtnis mappings plus zwei Nachrichtenüberprüfungen belaufend. Das oben vergleicht sich schnell mit komplizierteren Dienstleistungen, wo es häufig Codepfade gibt, die viele Server durchführen.

Das war nicht die einzige Quelle von Leistungsproblemen. Ein anderer hat auf die Probleme des Versuchens im Mittelpunkt gestanden, Gedächtnis richtig zu behandeln, als physisches Gedächtnis niedrig gelaufen ist und Paginierung vorkommen musste. In den traditionellen monolithischen Betriebssystemen hatten die Autoren direkte Erfahrung, mit der Teile des Kerns gerufen haben, den andere, ihnen der feinen Melodie erlaubend, ihr Pager, Paginierung zu vermeiden, codiert, der im Begriff gewesen ist verwendet zu werden. Unter dem Mach war das nicht möglich, weil der Kern keine echte Idee hatte, woraus das Betriebssystem bestanden hat. Stattdessen mussten sie eine einzelne eine Größe verwenden passt die ganze Lösung, die zu den Leistungsproblemen beigetragen hat. Mach 3 hat versucht, dieses Problem durch die Versorgung eines einfachen Pagers, das Verlassen auf Benutzerraumpagers für die bessere Spezialisierung zu richten. Aber das hat sich erwiesen, wenig Wirkung zu haben. In der Praxis wurden irgendwelche Vorteile, die es hatte, durch den teuren IPC weggewischt musste es herbeirufen.

Andere Leistungsprobleme sind mit der Unterstützung des Machs für Mehrverarbeiter-Systeme verbunden gewesen. Von der Mitte der 1980er Jahre bis den Anfang der 1990er Jahre sind Warenzentraleinheiten in der Leistung an einer Rate von ungefähr 60 % pro Jahr gewachsen, aber die Geschwindigkeit des Speicherzugangs ist an nur 7 % pro Jahr gewachsen. Das hat bedeutet, dass die Kosten, auf Gedächtnis zuzugreifen, schrecklich im Laufe dieser Periode gewachsen sind, und seitdem Mach darauf basiert hat, Gedächtnis ringsherum zwischen Programmen, jedes "geheime Lager kartografisch darzustellen, hat Fräulein" IPC-Anrufe langsam gemacht.

Unabhängig von den Vorteilen der Mach-Annäherung waren diese Sorten von wirklichen Leistungserfolgen einfach nicht annehmbar. Da andere Mannschaften dieselben Sorten von Ergebnissen gefunden haben, ist die frühe Mach-Begeisterung schnell verschwunden. Nach einer kurzen Zeit sind viele in der Entwicklungsgemeinschaft geschienen zu beschließen, dass das komplette Konzept, IPC als die Basis eines Betriebssystems zu verwenden, von Natur aus rissig gemacht wurde.

Potenzielle Lösungen

IPC oben ist ein Hauptproblem für das Mach 3 Systeme. Jedoch, das Konzept eines Mehrservers, den Betriebssystem noch verspricht, obwohl man noch etwas Forschung verlangt. Die Entwickler müssen darauf achten, Code in Module zu isolieren, die vom Server bis Server nicht rufen. Zum Beispiel würde die Mehrheit des Netzwerkanschlusscodes in einen einzelnen Server gelegt, dadurch IPC für normale Netzwerkanschlussaufgaben minimierend.

Die meisten Entwickler haben stattdessen mit dem ursprünglichen POE Konzept eines einzelnen großen Servers gesteckt, der die Betriebssystemfunktionalität zur Verfügung stellt. Um Entwicklung zu erleichtern, haben sie dem Betriebssystemserver erlaubt, entweder im Benutzerraum oder in Kernraum zu laufen. Das hat ihnen erlaubt, sich im Benutzerraum zu entwickeln und alle Vorteile der ursprünglichen Mach-Idee zu haben, und dann den die Fehler beseitigten Server in den Kernraum zu bewegen, um sich Leistung zu erholen. Mehrere Betriebssysteme sind mit dieser Methode seitdem gebaut worden, die als Co-Position, unter ihnen Lites, MkLinux, OSF/1 und NeXTSTEP/OPENSTEP/Mac OS X bekannt ist. Der Chor-Mikrokern hat das eine Eigenschaft des grundlegenden Systems gemacht, Servern erlaubend, in den Kernraum mit eingebauten Mechanismen erhoben zu werden.

Mach 4 hat versucht, diese Probleme dieses Mal mit einem radikaleren Satz von Steigungen zu richten. Insbesondere es wurde gefunden, dass Programm-Code normalerweise nicht writable war, waren so potenzielle Erfolge wegen copy-write selten. So hat es Sinn gehabt, das Gedächtnis zwischen Programmen für IPC nicht kartografisch darzustellen, aber stattdessen der Programm-Code abzuwandern, der in den lokalen Raum des Programms wird verwendet. Das hat zum Konzept von "Pendelbussen" geführt, und es ist geschienen, dass sich Leistung verbessert hatte, aber die Entwickler sind mit dem System in einem halbverwendbaren Staat weitergegangen. Mach 4 hat auch eingebaute Co-Positionsprimitive eingeführt, es einen Teil des Kerns selbst machend.

Durch die Mitte der 1990er Jahre war die Arbeit an Mikrokernsystemen trotz des Marktes größtenteils tot allgemein glaubend, dass alle modernen Betriebssysteme durch die 1990er Jahre gestützter Mikrokern sein würden. Der einzige restliche weit verbreitete Gebrauch des Mach-Kerns ist Mac OS X des Apfels und sein Geschwister-EIN/AUSGABE-STEUERSYSTEM, die oben auf einem schwer modifizierten Mach 3 Kern führen.

Mikrokerne der zweiten Generation

Weitere Analyse hat demonstriert, dass das IPC Leistungsproblem nicht so offensichtlich war, wie es geschienen ist. Rufen Sie zurück, dass eine einzelne Seite eines syscall 20μs unter BSD und 114μs auf dem Mach genommen hat, das auf demselben System läuft. Der 114, 11 waren wegen des Zusammenhang-Schalters, der zu BSD identisch ist. Zusätzliche 18 wurden durch den MMU verwendet, um die Nachricht zwischen dem Benutzerraum- und Kernraum kartografisch darzustellen. Das beläuft sich nur 31μs, länger als ein traditioneller syscall, aber nicht durch viel.

Der Rest, die Mehrheit des wirklichen Problems, war wegen der Kernaufführungsaufgaben wie Überprüfung der Nachricht für Hafen-Zugriffsrechte. Während es scheinen würde, dass das eine wichtige Sicherheitssorge tatsächlich ist, hat es nur Sinn in einem UNIX ähnlichen System. Zum Beispiel könnte ein Einzelbenutzerbetriebssystem, das ein Mobiltelefon oder Roboter führt, keine dieser Eigenschaften brauchen, und das ist genau die Sorte des Systems, wo das aufpicken-und-wählen Betriebssystem des Machs am wertvollsten sein würde. Ebenfalls hat Mach Probleme verursacht, als Gedächtnis durch das Betriebssystem, eine andere Aufgabe bewegt worden war, die nur wirklich Sinn hat, wenn das System mehr als einen Adressraum hat. DOS und der frühe Mac OS hatten einen einzelnen großen durch alle Programme geteilten Adressraum, so unter diesen Systemen kartografisch darzustellen, ist eine Zeitverschwendung.

Diese Verwirklichungen haben zu einer Reihe der zweiten Generationsmikrokerne geführt, die weiter die Kompliziertheit des Systems reduziert haben und fast die ganze Funktionalität in den Benutzerraum gelegt haben. Zum Beispiel schließt der L4 Kern (Version 2) nur sieben Systemanrufe ein und verwendet 12k des Gedächtnisses, wohingegen Mach 3 ungefähr 140 Funktionen und Gebrauch über 330k des Gedächtnisses einschließt. IPC Anrufe unter L4 auf einem 486DX-50 nehmen nur 5μs schneller als ein UNIX syscall auf demselben System, und mehr als 20mal so schnell wie Mach. Natürlich ignoriert das die Tatsache, dass L4 permissioning oder Sicherheit, aber durch das Verlassen davon zu den Benutzerraumfährten nicht behandelt, können sie so viel oder so wenig oben auswählen, wie sie verlangen.

Die potenziellen Leistungszunahmen von L4 werden durch die Tatsache gemildert, dass die Benutzerraumanwendungen häufig viele der durch den Kern früher unterstützten Funktionen werden zur Verfügung stellen müssen. Um der Länge nach Leistung zu prüfen, war MkLinux in der co-located Weise im Vergleich zu einem L4 Hafen, der im Benutzerraum läuft. L4 hat ungefähr 5 %-10 % oben, im Vergleich zu 15 % des Machs, das ganze interessantere Betrachten der doppelten erforderlichen Zusammenhang-Schalter hinzugefügt.

Diese neueren Mikrokerne haben die Industrie als Ganzes und Projekte wie das GNU wiederbelebt Hurd hat neue Aufmerksamkeit infolgedessen erhalten.

Betriebssysteme und Kerne auf dem Mach gestützt

• GNU Hurd (gestützt auf dem GNU-Mach)
• Lites
• MkLinux
• mtXinu
• MachTen
• MacMach
• NEXTSTEP
• OSF/1
• Arbeitsplatz OS
• UNICOS MAX
• Kylin
• XNU und Darwin, die Basis von Mac OS X und EIN/AUSGABE-STEUERSYSTEM

Siehe auch

• Mikrokern
• L4 Mikrokernfamilie
• EROS Mikrokernfamilie
• MERT

Links

• Das Mach-Projekt an Carnegie Mellon
• Das Mach-System - Anhang zu Betriebssystemkonzepten (8. Hrsg.) durch Avi Silberschatz, Peter Baer Galvin und Greg Gagne
• Ein Vergleich des Machs, der Amöbe und des Chors
• Zu Echten Mikrokernen - Enthält zahlreiche Leistungsmessungen, einschließlich derjenigen, die im Artikel angesetzt sind
• Die Leistung von µ-Kernel-Based Systemen - Enthält einen ausgezeichneten Leistungsvergleich von Linux, der als ein Monokern, auf dem Mach 3 und auf L4 läuft
• Mach-Kernquellcode - die Version von Browsable der Mach-Kernquelle codiert auf der FreeBSD/Linux Kernquerverweis-Seite