Asynchrone Systemfalle - Asynchronous System Trap

Asynchronous System Trap ( AST ) bezieht sich auf einen Mechanismus, der in mehreren Computerbetriebssystemen verwendet wird, die von der ehemaligen Digital Equipment Corporation (DEC) in Maynard , Massachusetts, entwickelt wurden .

Mechanismus

Verschiedene Ereignisse innerhalb dieser Systeme können optional werden signalisiert zurück zu den Benutzerprozesse über den AST - Mechanismus. Diese ASTs verhalten sich wie Unterprogrammaufrufe, werden jedoch asynchron bereitgestellt, dh ohne Rücksicht auf den Kontext des Hauptthreads. Aus diesem Grund ist Vorsicht geboten:

  • um sicherzustellen, dass jeder Code, der zwischen dem Hauptthread und dem AST geteilt wird, so ausgelegt sein muss, dass er wiedereintritt , und
  • Alle Daten, die gemeinsam genutzt werden, müssen vor Beschädigung geschützt sein, wenn sie jederzeit vom AST geändert werden. Andernfalls müssen die Daten durch Blockieren von ASTs in kritischen Abschnitten geschützt werden .

ASTs treten am häufigsten auf, wenn QIO- Aufrufe an den Kernel ausgegeben werden . Der Abschluss der E / A kann durch die Ausgabe eines AST an den aufrufenden Prozess / die aufrufende Aufgabe signalisiert werden. Bestimmte Laufzeitfehler können auch mithilfe des AST-Mechanismus signalisiert werden. In OpenVMS werden spezielle Kernel-Modus-ASTs als Standardmechanismus verwendet, um einen relativ bequemen Zugriff auf einen Prozesskontext zu erhalten (einschließlich des Paging des Prozesses in den physischen Speicher, falls erforderlich). Diese Arten von ASTs werden mit der höchstmöglichen Priorität pro Prozess ausgeführt, wenn der Scheduler diesen Prozess das nächste Mal auf den neuesten Stand bringt, und werden unter anderem zum Abrufen von Informationen auf Prozessebene verwendet (als Antwort auf ein $ GETJPI-System "getjob / process information") call) und zum Löschen von Prozessen.

Die folgenden Betriebssysteme implementieren ASTs:

ASTs sind ungefähr analog zu Unix- Signalen . Die wichtigen Unterschiede sind:

  • ASTs sind keine "Signalcodes" zugewiesen: Anstatt einem Signalcode einen Handler zuzuweisen und diesen Code zu erhöhen, wird der AST direkt durch seine Adresse angegeben. Dadurch können beliebig viele ASTs gleichzeitig anstehen (vorbehaltlich der Prozesskontingente).
  • ASTs brechen niemals einen laufenden Systemaufruf ab . Tatsächlich ist es möglich, dass sich ein Prozess in einen "Ruhezustand" versetzt (mit dem Systemaufruf $ HIBER) oder auf ein Ereignisflag wartet, indem er z. B. $ WAITFR aufruft, woraufhin er nur auf ASTs wartet geliefert. Wenn ein AST geliefert wird (ausgelöst durch einen E / A-Abschluss, einen Zeitgeber oder ein anderes Ereignis), wird der Prozess vorübergehend aus der Wartezeit für die Ausführung des AST genommen. Nach Abschluss der AST-Prozedur wird der Aufruf, der den Prozess in den Ruhezustand versetzt, oder das Warten auf das Ereignisflag erneut ausgeführt. Im Wesentlichen wird der Grund für das Warten neu bewertet. Die einzige Möglichkeit, aus dieser Schleife herauszukommen (abgesehen vom Löschen des Prozesses), besteht darin, einen Systemaufruf $ WAKE oder $ SETEF auszuführen, um das Warten zu befriedigen. Dies kann durch den Prozess selbst erfolgen, indem $ WAKE oder $ SETEF innerhalb des AST oder (wenn ein globales Ereignisflag verwendet wird) $ SETEF innerhalb eines anderen Prozesses aufgerufen werden.

VAX / VMS V4 und höher implementierten eine interessante Optimierung für das Problem der Synchronisierung zwischen Code auf AST-Ebene und Code auf Nicht-AST-Ebene. Ein Systemdienst namens $ SETAST könnte die Lieferung von Ästen für die aktuellen und all weniger privilegierten zu deaktivieren oder aktiviert verwendet werden Zugriffsmodi (der OpenVMS Begriff für Ring-basierten Sicherheitsfunktionen). Wenn der kritische Abschnitt , der vor ASTs geschützt werden muss, nur wenige Anweisungen lang ist, kann der Aufwand für die Ausführung der $ SETAST-Aufrufe die Zeit für die Ausführung dieser Anweisungen bei weitem überwiegen.

Daher wurde nur für den Benutzermodus (der Ring mit den geringsten Berechtigungen, der normalerweise von normalen Benutzerprogrammen verwendet wird) ein Paar Bitflags an einem vordefinierten, vom Benutzer beschreibbaren Speicherort (im pro Prozess "P1" -Raum) bereitgestellt. Die Bedeutung dieser beiden Flags könnte als "keine ASTs liefern" und "ASTs wurden deaktiviert" ausgelegt werden. Anstelle des üblichen Paares von $ SETAST-Aufrufen würde der Benutzermoduscode das erste Flag setzen, bevor die Befehlssequenz ausgeführt wird, während der ASTs blockiert werden müssen, und es nach der Sequenz löschen. Dann (beachten Sie die Reihenfolge hier, um Rennbedingungen zu vermeiden ) würde es das zweite Flag überprüfen , um festzustellen, ob es während dieser Zeit gesetzt wurde: Wenn ja, dann sind ASTs wirklich deaktiviert worden, und $ SETAST sollte aufgerufen werden, um sie wieder zu aktivieren . Im häufigsten Fall wären während dieser Zeit keine ASTs ausstehend gewesen, sodass $ SETAST überhaupt nicht aufgerufen werden müsste.

Der Kernel-AST-Übermittlungscode überprüft seinerseits das erste Flag, bevor versucht wird, einen AST im Benutzermodus zu übermitteln. Wenn es gesetzt wäre, würde es direkt das ASTs-deaktivierte Bit im Prozesssteuerungsblock setzen (dasselbe Bit, das durch einen expliziten $ SETAST-Aufruf aus dem Benutzermodus gesetzt würde) und auch das zweite Flag setzen, bevor es zurückkehrt und geht der AST nicht zugestellt.

Der asynchrone Prozeduraufrufmechanismus in der Windows NT- Betriebssystemfamilie ist ein ähnlicher Mechanismus.

Verweise

Weiterführende Literatur

  • OpenVMS Alpha Interna und Datenstrukturen: Planung und Prozesskontrolle: Version 7.0, Ruth Goldenberg, Saro Saravanan, Denise Dumas, ISBN  1-55558-156-0