-
1. Gebiet
der Erfindung
-
Die
vorliegende Erfindung betrifft Computer. Im Besonderen betrifft
die vorliegende Erfindung einen Laufzeitzuweisungstreiber zur Implementierung eines
Protokolls unter Verwendung von Zeitschätzwerten zum Einsatz in Verbindung
einer Vorrichtung, die keine Unterbrechungen erzeugt.
-
2. Beschreibung des Stands
der Technik
-
Allgemein
handelt es sich bei einem Treiber um ein Programm, dass eine Vorrichtung
steuert. Jede Vorrichtung, wie etwa ein Drucker, ein Plattenlaufwerk
oder eine Tastatur, benötigt
einen Treiber, um in Verbindung mit einem Computer eingesetzt werden
zu können.
Viele Treiber, wie etwa Tastaturtreiber, werden mit einem Betriebssystem
ausgeliefert. Bei anderen Vorrichtungen muss ein Treiber geladen
werden, wenn die Vorrichtung an den Computer angeschlossen wird.
Ein Treiber arbeitet wie ein Übersetzer
zwischen der Vorrichtung bzw. dem Gerät und den Anwendungen, welche
die Vorrichtung nutzen. Jede Vorrichtung weist einen eigenen Satz
spezieller Befehle auf, die nur deren Treiber kennt. Im Gegensatz
dazu greifen die meisten Anwendungen unter Verwendung generischer
Befehle auf Vorrichtungen zu. Der Treiber akzeptiert dabei generische Befehle
von einer Anwendung und übersetzt
diese in spezielle Befehle für
die Vorrichtung.
-
Die
meisten Geräte-
bzw. Vorrichtungstreiber behandeln Hardware-Anforderungen unter
Verwendung der folgenden Schrittfolge:
- 1. Einleiten
einer Hardwareanforderung oder Einfügen dieser in eine Warteschlange,
wenn die Vorrichtung bereits beschäftigt ist.
- 2. Wenn die Vorrichtung eine Unterbrechung erzeugt, ist die
aktuelle Anforderung abgeschlossen. An diesem Punkt werden die Ergebnisse
der Anforderung bzw. der Anfrage zu der Anwendung zurückgegeben
und die nächste
Anforderung in der Warteschlange eingeleitet.
-
Für gewöhnlich verwendet
jede Anwendung einen synchronen Aufruf zur Ausführung ihrer Anforderung. Das
Betriebssystem (OS) gibt die Steuerung an die Anwendung zurück, wenn
der Treiber die Anforderung abgeschlossen hat, was passiert, wenn
die Vorrichtung eine Unterbrechung erzeugt.
-
Es
kommt jedoch zu einem Problem, wenn langsame Vorrichtungen betroffen
sind, die keine Unterbrechungen bzw. Interrupts erzeugen. Leider
weisen die meisten in Verbindung mit einer Vorrichtung, die keine
Unterbrechung erzeugt, verwendeten Treiber keine Mechanismen auf,
um den Zugriff zwischen konkurrierenden Anwendungen auf die Vorrichtung fair
zu verteilen, und ferner neigen sie dazu, die Verarbeitungszeit
einer Zentraleinheit (CPU) bei der Behandlung konkurrierender Anwendungen
ineffizient zu nutzen. Bestimmte Treiber, die in Verbindung mit derartigen
Vorrichtungen eingesetzt werden, fragen zum Beispiel Vorrichtungsregister
ab, um die vollständige
E/A-Ausführung
zu bestimmen. Bei derartigen Treibern kommt es leider häufig vor,
dass die Anwendung die Ausführung
unterbricht oder anhält,
um auf die Ausführung
der Ein-Ausgabe-Anforderung (E/A) während der Verarbeitung durch
die Vorrichtung zu warten, oder wobei eine übermäßige Anzahl von E/A-Anforderungen ausgeführt wird,
wobei in beiden Fällen
unnötigerweise
CPU-Verarbeitungszeit verschwendet
wird.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Merkmale und Vorteile der vorliegenden Erfindung werden aus der
folgenden Beschreibung der vorliegenden Erfindung deutlich. In den
Zeichnungen zeigen:
-
1 ein
Diagramm einer beispielhaften Computersystemumgebung, in der ein
Ausführungsbeispiel
der vorliegenden Erfindung ausgeführt werden kann;
-
2 ein
Flussdiagramm eines Verfahrens für
eine Anwendung, die mit einem Laufzeitzuweisungstreiber interagiert
und Zeitschätzwerte
einsetzt, um eine Ein-Ausgabe-Transaktion
(E/A) mit einer Vorrichtung gemäß einem
Ausführungsbeispiel
der Erfindung auszuführen;
-
3 ein
Flussdiagramm eines Verfahrens für
den Laufzeitzuweisungstreiber zum Starten einer E/A-Anforderung
sowie zur Bereitstellung einer geschätzten Verarbeitungszeit für eine E/A-Transaktion an
eine Anwendung gemäß einem
Ausführungsbeispiel
der Erfindung; und
-
4 ein
Flussdiagramm eines Verfahrens für
den Laufzeitzuweisungstreiber zur Bereitstellung der E/A-Operationsergebnisse
an eine Anwendung oder einer verbleibenden geschätzten Verarbeitungszeit für die Ausführung der
E/A-Transaktion an die Anwendung gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung.
-
BESCHREIBUNG
DER ERFINDUNG
-
Vorgesehen
sind gemäß der vorliegenden Erfindung
ein Verfahren und eine Vorrichtung für einen Laufzeitzuweisungstreiber
zur Implementierung eines Protokolls unter Verwendung von Zeitschätzwerten
zum Einsatz in Verbindung mit einer Vorrichtung, die keine Unterbrechungen
erzeugt. Eine Anwendung ruft den Laufzeitzuweisungstreiber auf,
um eine Ein-Ausgabe-Anforderung (E/A-Anforderung) an eine Vorrichtung
zu starten. Der Laufzeitzuweisungstreiber bestimmt, ob die Vorrichtung
beschäftigt ist.
Wenn die Vorrichtung nicht beschäftigt
ist, leitet der Laufzeitzuweisungstreiber die E/A-Anforderung an
die Vorrichtung ein und stellt eine geschätzte Verarbeitungszeit (EPT)
für die
auszuführende
E/A-Anforderung an die Anwendung bereit.
-
Wenn
die Vorrichtung in einem Ausführungsbeispiel
beschäftigt
ist, berechnet der Laufzeitzuweisungstreiber eine geschätzte verbleibende
Zeit (EATL), bis die Vorrichtung für die Anwendung zur Verfügung steht,
und wobei der Treiber diese EATL an die Anwendung bereitstellt.
Wenn die Vorrichtung nicht beschäftigt
ist, ruht die Anwendung über
die geschätzte
Verarbeitungszeit (EPT) und ruft den Laufzeitzuweisungstreiber auf,
um die Ergebnisse der E/A-Operation zu erhalten. Wenn die E/A-Anforderung
abgeschlossen ist, stellt der Laufzeitzuweisungstreiber die E/A-Operationsergebnisse
an die Anwendung bereit.
-
Wenn
die E/A-Anforderung hingegen noch nicht abgeschlossen ist, berechnet
der Laufzeitzuweisungstreiber eine geschätzte verbleibende Verarbeitungszeit
(EPTR) für
die Ausführung
der E/A-Anforderung und stellt die EPTR an die Anwendung bereit.
Die Anwendung ruht danach über
die geschätzte verbleibende
Verarbeitungszeit (EPTR) und ruft den Laufzeitzuweisungstreiber
erneut auf, um die E/A-Operationsergebnisse zu erhalten. Diese
Operationen können
wiederholt werden, bis die E/A-Anforderung vollständig ausgeführt ist.
-
In
der folgenden Beschreibung werden die verschiedenen Ausführungsbeispiele
der vorliegenden Erfindung näher
beschrieben. Die darin enthaltenen Einzelheiten dienen einem besseren
Verständnis der
vorliegenden Erfindung sowie der Beschreibung exemplarischer Ausführungsbeispiele
zur Implementierung der Erfindung. Die Einzelheiten schränken die Erfindung
nicht auf die besonderen beschriebenen Ausführungsbeispiele ein, vielmehr
sind Abänderungen
und Ausführungsbeispiele
im Rahmen des Umfangs der vorliegenden Erfindung möglich. Obwohl zahlreiche
Einzelheiten ausgeführt
sind, um ein umfassendes Verständnis
der vorliegenden Erfindung zu vermitteln, ist es für den Fachmann
auf dem Gebiet ersichtlich, dass die speziellen Einzelheiten nicht erforderlich
sind, um die vorliegende Erfindung auszuführen. In anderen Fällen sind
Einzelheiten, wie zum Beispiel allgemein bekannte elektrische Strukturen
und Schaltungen, in Blockdiagrammform dargestellt, um die vorliegende
Erfindung nicht zu verschleiern.
-
Die
Abbildung aus 1 zeigt ein Diagramm einer beispielhaften
Computersystemumgebung, in der ein Ausführungsbeispiel der vorliegenden
Erfindung ausgeführt
werden kann. Die vorliegende Erfindung kann in einem Host-Computer 100 implementiert
werden. Der Host-Computer 100 kann mindestens eine Zentraleinheit
(CPU) 110, einen Host-Bus 120, einen Speichersteuereinheits-Hub
(MCH) 130, einen Systemspeicher 140, einen Ein-Ausgabe-Steuereinheits-Hub
(ICH) 150, einen nichtflüchtigen Speicher oder System-Flash-Speicher 160 und
mindestens eine Ein-Ausgabe-(E/A)-Vorrichtung 170 umfassen. Die
E/A-Vorrichtungen 170 können
einen Monitor 172, eine Tastatur 174, ein Modem 178,
einen Drucker 180 und Speichervorrichtungen 182 (z.B. CD-ROM, Festplattenlaufwerk,
Floppy-Diskettenlaufwerk, etc.) sowie jede andere Art von E/A-Vorrichtung aufweisen.
-
Der
MCH 130 kann in einen Chipsatz integriert sein, der mehrere
Funktionalitäten
vereint, wie zum Beispiel die Speichersteuerung und eine Host-Peripheriegeräte-Busschnittstelle.
In ähnlicher Weise
kann der ICH 150 gemeinsam mit dem MCH 130 in
einem Chipsatz integriert sein oder getrennt davon, um E/A-Funktionen
auszuführen.
Zur deutlicheren Veranschaulichung sind hierin nicht alle peripheren
Busse abgebildet. Der Host-Computer 100 kann auch periphere
Busse aufweisen, wie zum Beispiel einen PCI-Bus (Peripheral Component
Interconnect-Bus), einen AGP-Bus (Accelerated Graphics Port-Bus),
einen ISA-Bus (Industry
Standard Architecture-Bus) und einen USB-Bus (Universal Serial Bus),
etc.
-
Die
CPU 110 stellt eine Zentraleinheit mit einer beliebigen
Architektur dar, wie etwa eine CISC-Architektur (Rechnerarchitektur
mit komplexem Befehlsvorrat), eine RISC-Architektur (Rechnerarchitektur
mit begrenztem Befehlsvorrat), eine VLIW-Architektur (Architektur
mit sehr langem Befehlswort) oder eine hybride Architektur. In einem Ausführungsbeispiel
ist die CPU mit einem Prozessor mit Intel Architektur (IA) kompatibel,
wie etwa Prozessoren der PentiumTM Serie,
dem IA-32TM und dem IA-64TM.
In einem Ausführungsbeispiel
kann es sich bei dem Host-Computer 100 um ein Einprozessorsystem
handeln, wie etwa einen Desktop-Computer,
der nur eine Hauptzentraleinheit aufweist, z.B. einen Prozessor 110.
In anderen Ausführungsbeispielen
kann der Host-Computer 100 mehrere Prozessoren aufweisen,
wie z.B. die Prozessoren 110, 110a, 110b,
etc. Bei dem Host-Computer 100 kann es sich somit um ein
Computersystem mit mehreren Prozessoren handeln, die eine beliebige
Anzahl von Prozessoren aufweisen. Der Mehrprozessor-Host-Computer 100 kann
zum Beispiel als Teil einer Server- oder Workstation-Umgebung arbeiten.
Die grundlegende Beschreibung und Funktionsweise des Prozessors 110 wird
nachstehend im Text näher
ausgeführt.
Der Fachmann auf dem Gebiet wird erkennen, dass die grundlegende
Beschreibung und der Betrieb des Prozessor s110 für die weiteren
Prozessoren 110a und 110b ebenso gilt wie für jede andere
Anzahl weiterer Prozessoren, die in dem Mehrprozessor-Host-Computer 100 gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung eingesetzt werden können.
-
Der
Host-Bus 120 stellt Schnittstellensignale bereit, die es
dem Prozessor 110 oder den Prozessoren 110, 110a und 110b ermöglicht,
mit anderen Prozessoren oder Vorrichtungen zu kommunizieren, wie zum
Beispiel dem MCH 130. Der MCH 130 stellt die Steuerung
und Konfiguration der Speicher- und Ein-Ausgabe-Vorrichtungen bereit,
wie etwa des Systemspeichers 140 und des ICH 150.
Der Systemspeicher 140 speichert Systemcode und Daten,
wie etwa ein Betriebssystem 184, einen Laufzeitzuweisungstreiber 189 und
Anwendungen 190. Der Systemspeicher 140 kann mit
einem dynamischen Direktzugriffsspeicher (DRAM) oder einem statischen Direktzugriffsspeicher
(SRAM) implementiert werden. Der ICH 150 führt herkömmliche
E/A-Funktionen zur Steuerung der E/A-Vorrichtung(en) 170 aus.
-
Die
E/A-Vorrichtungen 170 können
jede E/A-Vorrichtung aufweisen, um E/A-Funktionen auszuführen. Die
E/A-Vorrichtungen 170 können
einen Monitor 172, eine Tastatur 174, ein Modem 178,
einen Drucker 180 und Speichervorrichtungen 182 (z.B.
eine CD-ROM, ein Festplattenlaufwerk, ein Floppy-Disketenlaufwerk,
etc.) oder jede andersartige E/A-Vorrichtung
aufweisen, wie z.B. Steuereinheiten für Eingabevorrichtungen (Maus,
Trackball, Zeigevorrichtung), Medienkarten (z.B. Audio, Video, Grafik),
Netzwerkkarten und jede andere periphere Steuereinheit. Eine E/A-Vorrichtung 170 kann
kennzeichnenderweise als ein diskretes Element physischer Hardware
definiert werden, das elektrisch mit dem Host-Computer gekoppelt werden kann, so dass auf
einer Host-CPU 110 ausgeführte Software den physikalischen
oder elektrischen Zustand der Vorrichtung unter Verwendung definierter
Befehlsfolgen verändern
kann. Wenn eine E/A-Vorrichtung 170 elektrisch mit dem
Host-Computer 100 gekoppelt
ist, gilt sie als an den Host-Computer angeschlossen.
-
Die
Vorrichtungs-Eingabe und -Ausgabe (E/A) ist ein Prozess, durch den
eine definierte Folge von Maschinenbefehlen bewirkt, dass die Host-CPU 110 den
physikalischen oder elektrischen Zustand der angeschlossenen E/A-Vorrichtung 170 unter
Verwendung elektrischer (für
gewöhnlich
digitaler) Signale verändert.
Bei einer E/A-Anforderung kann es sich um ein von einer Host-CPU
erzeugtes elektrisches Signal handeln, das eine atomare physikalische
oder elektrische Zustandsveränderung
in der E/A-Vorrichtung erzeugt. Für gewöhnlich wird eine E/A-Anforderung
zu dem Zeitpunkt eingeleitet, wenn eine Host-CPU ein Signal erzeugt,
das eine atomare bzw. atomische Zustandsveränderung der Vorrichtung bewirkt
und zu dem Zeitpunkt abgeschlossen wird, wenn eine Vorrichtung die
Zustandsänderung abgeschlossen
hat, und zwar als Reaktion auf ein Signal von einer Host-CPU. Während dem
Zeitraum zwischen der Einleitung einer E/A-Anforderung und deren
vollständigen
Ausführung
verarbeitet die E/A-Vorrichtung die Anforderung.
-
Die
Verarbeitungszeit für
eine E/A-Anforderung ist die Dauer des Zeitraums zwischen der Einleitung
einer E/A-Anforderung und deren vollständigen Ausführung. Die Verarbeitungszeit
einer bestimmen Anforderung ist von der Zeit abhängig, welche die E/A-Vorrichtung 170 benötigt, um
die angeforderte Zustandsänderung
vollständig
zu realisieren. Bei bestimmten Anforderungen ist die Verarbeitungszeit
deterministisch. Die Verarbeitungszeiten für diese Anforderungen können mit
hoher Genauigkeit bestimmt werden, wenn nur die Anforderungsart
und die Parameter der Anforderung bekannt sind. Bei bestimmten Anforderungen
ist die Verarbeitungszeit nicht deterministisch. Die genauen Verarbeitungszeiten
für diese
Anforderungen können
nicht einfach nur anhand der Art und der Parameter der Anforderung
bestimmt werden. Dies bedeutet für
gewöhnlich,
dass die Verarbeitungszeit von einer derartigen Anforderung zu der
anderen wahlfrei oder proportional zu einem oder mehreren Umgebungsfaktoren
variiert. Schätzwerte für die Verarbeitungszeiten
können
mit unterschiedlicher Genauigkeit ermittelt werden, abhängig von
der Beschaffenheit der Anforderung.
-
Wenn
eine E/A 170 beschäftigt
ist, können E/A-Anforderungen
nicht eingeleitet werden, da die Vorrichtung bereits ihre maximale
Anzahl von gleichzeitigen Anforderungen verarbeitet. Die maximale Anzahl
gleichzeitiger Anforderungen liegt bei den meisten E/A-Vorrichtungen
bei 1. Diese Vorrichtungen sind immer dann beschäftigt, wenn sie eine beliebige
Anforderung verarbeiten. Bestimmte Vorrichtungen können zwei
oder mehr Anforderungen gleichzeitig ausführen. Diese Vorrichtungen können das
Einleiten einer neuen Anforderung bearbeiten, während sie andere Anforderungen
ausführen.
Derartige Vorrichtungen sehen für
gewöhnlich
Einschränkungen
in Bezug auf die An der Anforderungen vor, die verarbeitet werden
können,
während
andere Anforderungen verarbeitet werden. Derartige Vorrichtungen
sehen ferner für
gewöhnlich
Einschränkungen
in Bezug auf die An der Anforderungen vor, die gleichzeitig verarbeitet
werden können. Ob
eine Vorrichtung beschäftigt
ist oder nicht, kann somit von der Beschaffenheit der gewünschten
Anforderung abhängig
sein.
-
Der
Systemspeicher 140 speichert Systemcode und Daten, wie
etwa ein Betriebssystem 185, mindestens einen Treiber,
wie etwa den Laufzeitzuweisungstreiber 189, und Anwendungen 190.
Das Betriebssystem 185 stellt eine Sammlung von Softwarekomponenten
dar, die den grundlegenden Systembetrieb bereitstellt. Das Betriebssystem 185 verwaltet
das Erzeugen, Zerstören
und die Laufzeitzuweisung für
Kontext sowie das Laden von Softwarekomponenten als Reaktion auf
Benutzeranforderungen. Das Betriebssystem 185 verwaltet
Ablaufkontext sowie das Laden von Softwarekomponenten als Reaktion
auf Benutzeranforderungen. Das Betriebssystem verwaltet Kontext,
um die Illusion einer willkürlichen
Anzahl aktiver Softwarekomponenten zu erzeugen, die gleichzeitig
auf einem einzigen Host-Computer 100 mit einer begrenzten
Anzahl von CPUs (z.B. 1) ausgeführt
werden. Die Komponenten sind häufig
auf den Einsatz einer kleinen Teilmenge der Systemmerkmale beschränkt.
-
Bei
dem Laufzeitzuweisungstreiber 189 gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung handelt es sich um eine Softwarekomponente,
die primär
so gestaltet ist, dass sie die Vorrichtungs-E/A für andere
Softwarekomponenten ausführt,
einschließlich
des Betriebssystems 185 und der Anwendungen 190.
Der Laufzeitzuweisungstreiber 189 fungiert als Teil des
Betriebssystems. Vorgesehen sind im Besonderen gemäß der vorliegenden Erfindung
ein Verfahren und eine Vorrichtung für einen Laufzeitzuweisungstreiber 189 zur
Implementierung eines Protokolls unter Verwendung von Zeitschätzwerten,
so dass der Laufzeitzuweisungstreiber in Verbindung mit einer Vorrichtung
eingesetzt werden kann, die keine Unterbrechungen erzeugt. In der Abbildung
aus 1 ist nur ein Laufzeitzuweisungstreiber 189 dargestellt,
wobei hiermit jedoch festgestellt wird, dass abhängig davon, wie viele E/A-Vorrichtungen 170 vorhanden
sind, jede beliebige Anzahl von Laufzeitzuweisungstreibern 189 vorgesehen
sein kann.
-
Für gewöhnlich laufen
Vorrichtungs- bzw. Gerätetreiber
auf einer hohen CPU-Privilegebene, so dass sie Zugriff auf die Merkmale
bzw. Funktionen aufweisen können,
die benötigt
werden, um E/A-Anforderungen einzuleiten. Gerätetreiber müssen sorgfältig mit dem Betriebssystem
zusammenarbeiten, um die Stabilität und Performance des Systems
aufrechtzuerhalten. Da der Treiber als Teil des Betriebssystems
arbeitet, stehen zahlreiche Systemmerkmale dem Treibercode nicht
zur Verfügung.
Bei manchen Betriebssystemen können
die Gerätetreiber
aktive Komponenten sein, wobei es sich bei den meisten Betriebssystemen
bei den Gerätetreibern
jedoch um passive Komponenten handelt, wie etwa bei dem Laufzeitzuweisungstreiber 189 gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung. Teile des Treibercodes, die E/A-Anforderungen
erzeugen, werden häufig
in dem Prozesskontext der jeweiligen Anwendung ausgeführt, welche
die Vorrichtungs-E/A angefordert hat. Gerätetreiber existieren, um das Schreiben
von Anwendungen auch ohne spezielles Wissen darüber zu ermöglichen, wie die verschiedenen
Vorrichtungen zu verwenden sind. Die Anwendung verwendet stattdessen
einen definierten Satz von Aufrufen in das Betriebssystem, um die
Vorrichtungs-E/A zu realisieren. Diese Architektur ermöglicht den
Einsatz verschiedener Treiber für
einen Schnittstellenbetrieb mit verschiedenen Vorrichtungen, ohne
dass die Anwendung ausdrücklich
jede Art von verfügbarer
Vorrichtung unterstützen
muss.
-
Die
Anwendungen 190 sind Softwareprogramme (z.B. Textverarbeitungsprogramme,
Datenbanken, Spiele, etc.), die von dem Host-Computer 100 verwendet
werden, und die, wie dies später
im Text näher
beschrieben wird, einen Gerätetreiber
für die
E/A-Verarbeitung verwenden müssen.
Im Allgemeinen ist eine Anwendung 190 jede Softwarekomponente,
die nicht Teil des Kernbetriebssystems 185 ist. Anwendungen
interagieren für
gewöhnlich
nicht direkt mit Vorrichtungen 170. Stattdessen fordern
sie E/A an, indem Betriebssystemkomponenten und/oder Gerätetreiber
aufgerufen werden.
-
Das
Betriebssystem 185, der Laufzeitzuweisungs-Gerätetreiber 189 und
die Anwendungen 190 bestehen alle aus Codestücken. Ein
Codestück
ist eine geordnete Sammlung von CPU-Maschinenbefehlen mit arbiträrer Größe. Ein
Codestück
wird ausgeführt,
wenn eine einzelne Host-CPU 110 dessen Befehl in der richtigen
Reihenfolge nacheinander ausführt.
Jeder Befehl erzeugt eine definierte Zustandsänderung der internen Register
des Prozessors und/oder des Inhalts des Hauptspeichers des Hosts.
Bestimmte Fehler können
die Reihenfolge der Ausführung
verändern,
indem geändert
wird, welcher Befehl als nächster
ausgeführt
wird (eine Übertragung
der Steuerung). Andere Befehle können
es bewirken, dass die CPU 110 E/A-Anforderungen einleitet.
Ein Codestück
kann in Bezug auf die Reihenfolge unterbrochen werden, um es zu
ermöglichen,
dass die CPU andere Aufgaben ausführt (indem andere Codestücke ausgeführt werden),
und wobei das Codestück
danach an dem Punkt der Unterbrechung wieder aufgenommen wird. Eine
CPU führt
bei normalem Betrieb stets ein bestimmtes Codestück aus.
-
Ein
Prozesskontext ist die Softwareumgebung, in der ein Codestück ausgeführt wird.
Der Prozesskontext umfasst die Abbildung zwischen Speicheradressen
in dem Code und physikalische Speicherplätzen (dem Adressraum), dem
Inhalt der CPU-Register und dem Ausführungsstapel (zum temporären Speichern
verwendeter Speicher). Wenn ein Codestück unterbrochen wird, um einer
CPU 110 die Ausführung
anderer Aufgaben zu ermöglichen, wird
dessen Kontext gespeichert, so dass er später wiederhergestellt werden
kann, bevor die Ausführung
des Codes wieder aufgenommen wird. Dieser Mechanismus ermöglicht es,
dass der Code die Ausführung
wieder aufnimmt und so fortfährt,
als wäre
er nicht unterbrochen worden, wobei dies die Erzeugung der Illusion
unterstützen
kann, dass mehr als ein Codestück
gleichzeitig auf einer einzigen CPU 110 ausgeführt wird.
Auf einem Host-Computer 100 mit
mehreren CPUs 110–110b kann
ein Codestück eine
bestimmte Weile auf einer CPU ausgeführt, unterbrochen und die Ausführung auf
einer anderen CPU wieder aufgenommen werden, ohne die Illusion der
Kontinuität
zu zerstören.
Ein einzelner Host-Computer
kann verschiedene Prozesskontexte aufweisen, wobei aber auch nur
ein Prozesskontext gegeben sein kann, der je CPU zu einem bestimmten Zeitpunkt
aktiv ist. Der aktive Prozesskontext ist die Softwareumgebung für den Code,
der gerade auf der CPU ausgeführt
wird. Ein Prozesskontext ist niemals gleichzeitig auf mehr als einer
CPU aktiv.
-
Eine
Softwarekomponente ist ein diskretes Codestück, für das definierte Mechanismen
existieren, die bewirken, dass Code in den Systemspeicher 140 geladen
und von einer Host-CPU 110 ausgeführt wird.
Für gewöhnlich weist
ein Lademechanismus automatisch Speicher für alle globalen Variablen zu (zum
Beispiel Zustandsinformationen), welche die Komponente definiert.
Eine Softwarekomponentenschnittstelle ist eine geladene Instanz
einer Softwarekomponente, die den Code der Komponente aufweist und
Speicher für
globale Variablen in dem Host-Speicher, wobei darauf in einem bestimmten
Adressraum zugegriffen werden kann. Für gewöhnlich wird stets eine bestimmte
Instanz einer Softwarekomponente in einem bestimmten Prozesskontext
ausgeführt,
wobei dies jedoch nicht immer der Fall ist.
-
Eine
Softwarekomponente ist jedes diskrete Codestück oder Codeelement, für das definierte
Mechanismen existieren, um zu bewirken, dass der Code in den Systemspeicher 140 geladen
und durch eine Host-CPU 110 ausgeführt wird. Für gewöhnlich weist ein Lademechanismus
automatisch Speicher für
alle globalen Variablen (z.B. Zustandsinformationen) zu, welche
die Komponente definiert. Eine Softwarekomponenteninstanz ist eine
geladene Instanz einer Softwarekomponente, bestehend aus dem Code
der Komponente und Speicher für
globale Variablen in dem Host-Speicher, wobei ein Zugriff in einem
bestimmten Adressraum möglich
ist. Für
gewöhnlich
wird eine bestimmte Instanz einer Softwarekomponente stets in einem
bestimmten Prozesskontext ausgeführt,
wobei dies jedoch nicht immer der Fall ist.
-
Eine
aktive Softwarekomponente ist so gestaltet, dass sie in einem oder
mehreren dedizierten Prozesskontexten läuft bzw. ausgeführt werden kann.
Wenn eine aktive Softwarekomponente geladen wird, richtet der Ladeagent
einen neuen Prozesskontext ein (der einen neuen Adressraum aufweisen
kann). Er initialisiert diesen Kontext, so dass der Code der Komponente
mit der Ausführung
an einem vordefinierten Haupteintrittspunkt beginnt, wenn der Kontext
zum ersten Mal aktiv wird für
eine Host-CPU. Der neu erzeugte Prozesskontext wird danach dem Betriebssystem
für die
Laufzeitzuweisung bereitgestellt. Jede Instanz einer aktiven Softwarekomponente
ist autonom und unabhängig.
Sie muss ihre Aktivitäten
mit anderen Softwarekomponenten synchronisieren, mit denen sie interagiert. Eine
aktive Softwarekomponente kann Code aufweisen, der so gestaltet
ist, dass er in verschiedenen Prozesskontexten gleichzeitig läuft (mehrere
Ausführungsprozessstränge). Diese
Art des Initialisierungscodes der Komponente richtet die zusätzlichen
Prozesskontexte ein und macht diese für die Ausführung verfügbar. Es ist üblich – aber nicht
erforderlich –, dass
aktive Komponenten automatisch entladen werden, wenn die Ausführung deren
Codes endet (d.h. wenn die CPU das Ende des Komponentencodes erreicht,
für den
die Steuerung auf einen Teil des Systemcodes übertragen werden muss, da kein
Komponentencode zur Ausführung
mehr vorhanden ist. Dieser Systemcode kann so gestaltet sein, dass
er automatisch die Prozessinstanz entlädt).
-
Eine
passive Softwarekomponente ist so gestaltet, dass sie periodisch
in einem Prozesskontext ausgeführt
wird, der für
eine andere, aktive Komponente erzeugt worden ist. Passive Softwarekomponenteninstanzen
werden für
gewöhnlich
in Adressräume
geladen, die für
eine aktive Komponente erzeugt worden sind. Nach der Initialisierung
werden sie nur ausgeführt,
wenn eine andere Komponente die Steuerung unter Verwendung eines
Aufrufbefehls auf sie überträgt. Für gewöhnlich führen passive Komponenteninstanzen
bei jedem Aufruf definierte Aufgaben aus, und wobei sie danach die
Steuerung an die aufrufende Komponente zurückgeben. Eine passive Komponente
kann andere passive Komponenten aufrufen. Das Ziel eines Aufrufs
ist eine Funktion (d.h. die Übertragung
der Steuerung auf ein Codestück
unter Verwendung eines Aufrufbefehls ist als Aufruf einer Funktion
bekannt). Jede Funktion ist ein Codestück das eine definierte Aufgabe
ausführt und
danach die Steuerung an den Code zurückgibt, der den Aufrufbefehl
ausgeführt
hat. Wenn die Steuerung zurückgegeben
wird, fährt
der aufrufende Code mit der Ausführung
fort, beginnend mit dem ersten Befehl nach dem Aufrufbefehl.
-
Das
Betriebssystem (OS) 185 weist einen Scheduler 192 auf,
der ein Codestück
darstellt, das periodisch eine CPU 110 oder CPUs (110–110b)
zwischen Prozesskontexten umschaltet. Dieses Schalten (als Prozesslaufzeitzuweisung
oder Thread-Laufzeitzuweisung bezeichnet) stellt sicher, dass es
den Anschein hat, dass alle aktiven Softwarekomponenten reibungslos
und kontinuierlich ausgeführt
werden, wobei jede ihren angemessenen Teil der CPU-Zeit empfängt. Der
System-Timer 194 ist eine Vorrichtung, deren Zweck es ist,
in regelmäßigen Intervallen
Hardware-Unterbrechungen zu erzeugen. Für gewöhnlich stellen Betriebssysteme
Unterbrechungs-Serviceprogramme (ISRs) bereit, um diese Unterbrechung
zu behandeln. Im Allgemeinen verwendet der Scheduler 192 diese
Hardware-Unterbrechung zur Überwachung
der Zeit und der Laufzeitzuweisung für die Ausführung von Prozesskontext. Ferner
verwendet der Laufzeitzuweisungstreibe 189 einen Treibertakt 196,
um die Zeit zu verfolgen, und wobei er verwendet wird, um die geschätzten Verarbeitungszeiten
zu bestimmen, wie dies nachstehend im Text näher beschrieben wird. Der Treibertakt 196 wird
in einem Spenschritt mit dem System-Timer 194 synchronisiert.
Ein Timer-Tick zeigt den Moment an, in dem der System-Timer 194 und
der Treibertakt 196 gleichzeitig eine Unterbrechung erzeugen.
Bei jedem Timer-Tick wird die Systemzeit aktualisiert, und es können andere
Prozesslaufzeitzuweisungen und Schätzungen von Verarbeitungszeiten
auftreten. Ein Timer-Tickintervall
(TTI) ist der Zeitraum zwischen jeweils zwei benachbarten Timer-Ticks
(der Zeitraum zwischen dem Auftreten eines Timer-Ticks und des Auftretens
des folgenden Timer-Ticks).
-
Wenn
ein Codestück „gesperrt" wird, wird dessen
Ausfuhrung unterbrochen oder angehalten, um auf das Auftreten eines
bestimmten externen Ereignisses zu warten (wie etwa die E/A-Ausführung oder
ein Signal von einer Softwarekomponente, das in einem anderen Porzesskontext
ausgeführt
wird). Für
gewöhnlich
schaltet der Scheduler 192 die CPU 110, die den
Codee ausführt,
in einen anderen Prozesskontext, und der gesperrte Code wird erst
dann wieder zur Ausführung
eingeplant, wenn das externe Ereignis eingetreten ist, auf das gewartet
wurde. Ein Sperraufruf ist ein Aufruf, der an eine Funktion gerichtet
wird, die sperren kann. Ein üblicher
Typ eines Sperraufrufs ist ein sperrender Systemaufruf, bei dem
es sich um einen Systemaufruf handelt, der sperren kann – für gewöhnlich,
um auf die Ausführung
der Vorrichtungs-E/A zu warten.
-
Ein
zusammenwirkender Scheduler schaltet eine CPU nur dann auf einen
anderen Prozesskontext, wenn die in dem aktuellen Kontext ausgeführte Komponente
bestimmte Aktionen ausführt
(wie etwa die Erlangung der Steuerung oder die Ausführung eines
sperrenden Systemaufrufs). Er wird zusammenwirkender Scheduler genannt,
da die Softwarekomponenten an dem Host zusammenwirken müssen, um
sicherzustellen, dass jede ihren angemessenen Anteil der CPU-Zeit
erhält.
Ein preemptiver Scheduler schaltet die CPU auf einen anderen Prozess, wenn
die Komponente, die in dem aktuellen Kontext ausgeführt wird,
ausdrücklich
bestimmte Aktionen ausführt,
oder wenn eine bestimmte Zeit ohne Kontextwechsel abgelaufen ist.
Preemptive Scheduler werden für
gewöhnlich
periodisch während
der Timer-Tick-Verarbeitung ausgeführt, um zu bestimmen, ob ein
anderer Prozesskontext auf einer bestimmten CPU ausgeführt werden
sollte, und um den Kontextwechsel bei Bedarf auszuführen. Betriebssysteme,
die Anwendungsprozesskontexte mit einem preemptiven Scheduler planen,
können
eine sehr überzeugende
Illusion der gleichzeitigen Ausführung
zahlreicher Anwendungen vermitteln.
-
Wenn
eine Anwendung 190 ruht, sperrt sie ausdrücklich für einen
spezifizierten Zeitraum. Für gewöhnlich handelt
es sich beim Ruhen um einen sperrenden Systemaufruf, der die Steuerung
erst nach Ablauf eines bestimmten Zeitintervalls zurückgibt.
Während
diesem Zeitraum können
andere Prozesskontexte auf der CPU 110 ausgeführt werden, wo
der Ruhezustandsaufruf erfolgt ist. Ein Prozesskontext ist ausführbar, wenn
er zur Ausführung
bereit steht. Der Scheduler 192 kann nur aus der Gruppe der
ausführbaren
Prozesskontexte bei dem Laufzeitzuweisung für die CPU-Zeit auswählen. Ein
Prozesskontext, der gesperrt ist, kann erst wieder ausgeführt werden,
wenn das nächste
Ereignis eintritt, auf das er wartet. Zum Beispiel wird ein ruhender
Prozesskontext nach Ablauf eines bestimmten Zeitraums ausführbar.
-
Ein
Ausführungsbeispiel
der vorliegenden Erfindung stellt ein Verfahren und eine Vorrichtung
für einen
Laufzeitzuweisungstreiber 189 zur Implementierung eines
Protokolls unter Verwendung von Zeitschätzwerten bereit, wie etwa des
Laufzeitzuweisungstreibers 189, der in Verbindung mit einer
Vorrichtung 170 eingesetzt werden kann, die keine Unterbrechungen
erzeugt. ei der Implementierung der vorliegenden Erfindung gemäß einem
exemplarischen Ausführungsbeispiel
aus 1 wird angenommen, dass die verbundene E/A-Vorrichtung 170 nur
jeweils eine Anforderung gleichzeitig verarbeiten kann. Wie dies
bereits vorstehend im Text beschrieben worden ist, ist die E/A-Vorrichtung
mit dem Host-Computer 100 mit
einer oder mehr CPUs (110–110b) gekoppelt.
Ferner weist der Host-Computer 100 das
in den Systemspeicher 140 geladene Betriebssystem 185 auf.
In einem Ausführungsbeispiel
verwendet das Betriebssystem 185 einen preemptiven Scheduler
für das
Scheduling der Prozesskontexte, in denen die Anwendungen 190 ausgeführt werden.
Ferner stellt es einen Mechanismus zum Laden der Anwendungen sowie
für deren
Bereitstellung an den Scheduler 192 zur Ausführung bereit. Der
Laufzeitzuweisungstreiber 189 wird in das Betriebssystem 185 geladen,
so dass die Anwendungen 190 den Laufzeitzuweisungstreiber 189 verwenden
können,
um E/A-Anforderungen an die angeschlossene Vorrichtung 170 zu
erzeugen. In einem Ausführungsbeispiel
handelt es sich bei dem Laufzeitzuweisungstreiber 189 um
eine passive Softwarekomponente, und eine einzelne Instanz des Laufzeitzuweisungstreibers 189 wird
von allen Anwendungen 190 gemeinsam genutzt, die auf die
Vorrichtung 170 zugreifen.
-
Selbst
wenn der Host-Computer 100 eine CPU 110 aufweist,
können
mehrere Prozesskontexte gleichzeitig in einer einzigen Treiberfunktion
positioniert werden. Unter diesen Bedingungen wird ein Teil des
Codes der Funktion des Laufzeitzuweisungstreibers 189 ausgeführt, wenn
jeder Prozesskontext für die
Ausführung
auf der CPU 110 aktiviert wird. Dies erzeugt die Illusion
als wäre
die Treiberfunktion von mehr als einer Anwendung 190 gleichzeitig
aufgerufen worden. Somit kann theoretisch zu jedem Zeitpunkt eine
willkürliche
Anzahl von Anwendungen 190 den Laufzeitzuweisungstreiber 189 gleichzeitig
aufrufen, um Vorrichtungs-E/A-Anforderungen zu erzeugen. Auf einem
Host-Computer 100 mit mehr als einer CPU (110–110b)
gilt dies buchstäblich,
da der Treibercode auf mehreren CPUs gleichzeitig ausgeführt werden
kann. Die Anwendungen 190, die eine Vorrichtungs-E/A von dem Laufzeitzuweisungstreiber 189 anfordern,
können
passive oder aktive Softwarekomponenten sein. Der Laufzeitzuweisungstreiber 189 verwaltet
eine „Sperrflagge", die für gewöhnlich durch
die Gegenwart eines bestimmten numerischen Wertes an einer bestimmten
Adresse in dem Systemspeicher 140 dargestellt ist, um anzuzeigen,
ob sich eine E/A-Anforderung in Bearbeitung befindet oder nicht.
Der Laufzeitzuweisungstreiber 189 kann den Zustand einer
Vorrichtung 170 untersuchen bzw. prüfen, um zu bestimmen, ob eine
bestimmte E/A-Anforderung von der Vorrichtung ausgeführt worden
ist. Der Laufzeitzuweisungstreiber 189 verwendet den Treibertakt 196,
um die ablaufende Zeit zu überwachen.
-
Vorgesehen
sind in einem Ausführungsbeispiel
der vorliegenden Erfindung ein Verfahren und eine Vorrichtung für einen
Laufzeitzuweisungstreiber 189 zum Implementieren eines Protokolls
unter Verwendung von Zeitschätzwerten,
so dass der Laufzeitzuweisungstreiber 189 in Verbindung
mit einer Vorrichtung 170 eingesetzt werden kann, die keine
Unterbrechungen erzeugt. Eine Anwendung 190 ruft den Laufzeitzuweisungstreiber 189 auf,
um eine Eingabe/Ausgabe-Anforderung (E/A-Anforderung) an eine Vorrichtung 170 zu
starten. Der Laufzeitzuweisungstreiber 189 bestimmt, ob
die Vorrichtung 170 beschäftigt ist. Wenn die Vorrichtung
nicht beschäftigt
ist, stellt der Laufzeitzuweisungstreiber 189 eine geschätzte Verarbeitungszeit
(EPT) für
die E/A-Anforderung bereit, die von der Anwendung auszuführen ist.
-
Wenn
die Vorrichtung 170 beschäftigt ist, berechnet der Laufzeitzuweisungstreiber 189 eine
geschätzte
noch verbleibende Zeit (EATL), bis die Vorrichtung 170 für die Anwendung 190 bereit
ist und stellt diese EATL an die Anwendung 190 bereit. Wenn
die Vorrichtung 170 nicht beschäftigt ist, ruht die Anwendung 190 für die geschätzte Verarbeitungszeit
(EPT) und ruft den Laufzeitzuweisungstreiber 189 auf, um
die E/A-Operationsergebnisse zu erhalten. Wenn die E/A-Anforderung
abgeschlossen ist, stellt der Laufzeitzuweisungstreiber die E/A-Operationsergebnisse
an die Anwendung bereit.
-
Wenn
die E/A-Anforderung jedoch nicht abgeschlossen ist, berechnet der
Laufzeitzuweisungstreiber 189 eine geschätzte verbleibende
Verarbeitungszeit (EPTR) für
die Ausführung
der E/A-Anforderung und stellt die EPTR an die Anwendung 190 bereit.
Die Anwendung 190 ruht danach für die geschätzte verbleibende Verarbeitungszeit
(EPTR), und ruft wiederum den Laufzeitzuweisungstreiber 189 auf,
die E/A-Operationsergebnisse zu erhalten. Diese Operationen können wiederholt
werden, bis die E/A-Anforderung abgeschlossen ist. In Bezug auf die
Abbildungen der 2 bis 4 erfolgt
eine nähere
Beschreibung der Interaktion zwischen der Anwendung 190 und
dem Laufzeitzuweisungstreiber 189.
-
Die 2 zeigt
ein Flussdiagramm eines Prozesses 200 für eine Anwendung, die mit einem Laufzeitzuweisungstreiber
interagiert und die Zeitschätzwerte
zur Ausführung
einer Ein-Ausgabe-Transaktion
(E/A-Transaktion) mit einer Vorrichtung gemäß einem Ausführungsbeispiel
der Erfindung nutzt. Nach dem Start (Block 205) ruft der
Prozess 200 den Laufzeitzuweisungstreiber auf, um die E/A-Anforderung
zu starten (Block 210). Die Anwendung ruft einen Prozess
des Laufzeitzuweisungstreiber auf, um die E/A-Anforderung zu starten,
und der Prozess 200 springt zu dem Eintrittspunkt 310 des Prozesses 300,
der in 3 veranschaulicht ist (Block 210).
-
Jede
Anzahl von Anwendungen kann gleichzeitig auf den Laufzeitzuweisungstreiber
gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung jederzeit zugreifen, um den Laufzeitzuweisungstreiber
aufzufordern, eine Vorrichtungs-E/A-Anforderung zu erzeugen. Die
Vorrichtung ist jedoch nur in der Lage, eine Anforderung gleichzeitig
zu verarbeiten, so dass die Laufzeitzuweisungstreiber nur eine E/A-Anforderung
der Anwendung gleichzeitig bearbeitet, während bewirkt wird, dass die
anderen Anwendungen warten. Somit wird jede Anwendung behandelt, wenn
sie an der Reihe ist, was zu einem hohen Maß der Fairness führt.
-
In
Bezug auf die Abbildung aus 3 zeigt diese
ein Flussdiagramm eines Prozesses 300 für den Laufzeitzuweisungstreiber
zum Starten einer E/A-Anforderung und zur Bereitstellung einer geschätzten Verarbeitungszeit
für die
Ausführung
einer E/A-Transaktion an eine Anwendung gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung. An dem Eintrittspunkt (Block 310)
bestimmt der Prozess 300, ob die Sperrflagge gesetzt ist.
Wenn die Sperrflagge gesetzt ist, berechnet der Prozess 300 eine geschätzte verbleibende
Zeit (EATL), bis die Vorrichtung wieder frei ist (Block 320).
Die Vorrichtung ist somit aktuell mit der Bearbeitung einer anderen
Anforderung beschäftigt.
Die geschätzte
verbleibende Zeit (EATL) wird berechnet durch Subtraktion der abgelaufenen
Zeit seit dem Start der verarbeiteten aktuellen Anforderung von
der ursprünglich
geschätzten Verarbeitungszeit
(EPT) der Anforderungen. Wenn die EATL-Berechnung negativ ist, wird
die EATL-Berechnung auf Null gesetzt (Block 320). Als nächstes stellt
der Prozess 300 die geschätzte verbleibende Zeit (EATL)
bereit, bis die Vorrichtung für
die Anwendung verfügbar
ist (Block 325). Der Prozess 300 kann ein Signal „beschäftigt" an den Prozess 200 zurückgeben
und wechselt zu dem Block 215 des Prozesses 200 gemäß der Veranschaulichung
in 2 (Block 330).
-
Wenn
die Sperrflagge andererseits nicht gesetzt ist, wird die E/A-Anforderung
eingeleitet (Block 335) und die Sperrflagge wird gesetzt
(Block 340). Ferner wird die geschätzte Verarbeitungszeit (EPT) für die abzuschließende E/A-Anforderung
bestimmt. Wenn die Vorrichtung selbst die geschätzte Verarbeitungszeit (EPT)
für die
auszuführende
E/A-Anforderung
berechnet, so empfängt
der Prozess 300 diesen Wert von der Vorrichtung unmittelbar
nach der Einleitung der Anforderung (Block 345). Alternativ
kann der Prozess 300 die geschätzte Verarbeitungszeit (EPT) selbst
berechnen (Block 345). Der Laufzeitzuweisungstreiber kann
zum Beispiel eine Tabelle der durchschnittlichen EPTs auf der Basis
der Anforderungsart und anderer Parameter aufweisen. Ferner zeichnet
der Prozess 300 die aktuelle Zeit auf, zu der die Anforderung
gestartet wird (Block 345). Als nächstes stellt der Prozess 300 die
geschätzte
Verarbeitungszeit (EPT) für
die auszuführende
E/A-Anforderung
an die Anwendung bereit (Block 350). Der Prozess 300 gibt
danach ein Signal „nicht
beschäftigt" an den Prozess 200 zurück und wechselt
zu dem Block 215 des Prozesses 200, der in der
Abbildung aus 2 veranschaulicht ist (Block 355).
Hiermit wird festgestellt, dass der Code zur Implementierung des
Prozesses 300 für
den Laufzeitzuweisungstreiber einen kritischen Codeabschnitt darstellt
sowie ein Codestück,
dass nicht wieder eingegeben werden kann. Dies bedeutet, dass sobald
der Code die Ausführung
in einem Prozesskontext beginnt, in keinem anderen Prozesskontext
(entweder auf der gleichen CPU oder einer anderen CPU) ausgeführt werden kann,
bis die Ausführung
in dem ursprünglichen
Kontext abgeschlossen ist. Andere Porzesskontexte, die den Code
eingeben möchten,
müssen
gesperrt werden, bis der Kontext, der sich gerade in dem Code befindet,
die Ausführung
abgeschlossen hat.
-
In
erneutem Bezug auf die Abbildung aus 2 bestimmt
der Prozess 200 in dem Block 215, ob die Vorrichtung
beschäftigt
ist auf der Basis der Eingaben von dem Prozess 300. Wenn
die Vorrichtung „beschäftigt" ist, bewirkt der
Prozess 200, dass die Anwendung für eine geschätzte verbleibende
Zeit (EATL) ruht, die durch den Prozess 300 bestimm wird (Block 220).
Wenn der EATL-Wert auf Null gesetzt ist, ruht die Anwendung für ein Timer-Tickintervall (TTI) (Block 220).
Nach dem Ruhen für
den bezeichneten Zeitraum beginnt der Prozess 200 erneut
am Anfang in Block 210.
-
Wenn
die Vorrichtung hingegen „nicht
beschäftigt" ist, bewirkt der
Prozess 200, dass die Anwendung für die geschätzte Verarbeitungszeit (EPT) aus
dem Prozess 300 ruht (Block 225). Wenn der EPT-Wert
auf Null gesetzt ist, ruht die Anwendung für ein Timer-Tickintervall (TTI) (Block 225).
Nach dem Ruhen über
einen bezeichneten Zeitraum ruft der Prozess 200 den Laufzeitzuweisungstreiber
auf, um die E/A-Operationsergebnisse zu erhalten, und der Prozess 200 wechselt
zu dem Eintrittspunkt 410 des Prozesses 400 gemäß der Veranschaulichung
in 4 (Block 230).
-
Der
Laufzeitzuweisungstreiber ist der einzige Agent, der die Zeitsteuerung
zwischen den Anwendungen koordiniert. Jede Anwendung ruht für genau die
Zeiträume,
die durch den Laufzeitzuweisungstreiber spezifiziert sind. Jedes
Mal, wenn der Treiber ein Zeitintervall von Null spezifiziert, erlangt
die Anwendung ihren Zeitschlitz durch Ruhen über ein Timer-Tickintervall (TTI).
Dies lässt
den Betriebssystem-Scheduler die CPU auf die nächste in der Reihe folgende
Anwendung umschalten, wobei die aktuelle Anwendung dabei nicht ausführbar bleibt.
Ferner koordiniert der Laufzeitzuweisungstreiber die Ruhezeiten
so, dass wenn ruhende Anwendungen gegeben sind, diese während dem
gleichen Timer-Tick ausführbar
werden.
-
Die
Abbildung aus 4 zeigt ein Flussdiagramm eines
Prozesses 400 für
den Laufzeitzuweisungstreiber zur Bereitstellung der E/A-Operationsergebnisse
an die Anwendung oder einer geschätzten verbleibenden Zeit für die Ausführung der E/A- Transaktion an die
Anwendung gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung. Nach dem Eintrittspunkt (Block 410)
bestimmt der Prozess 400, ob die Vorrichtung weiter beschäftigt ist mit
der Verarbeitung der E/A-Anforderung (Block 415). Wenn
die Vorrichtung weiter mit der Verarbeitung der E/A-Anforderung
beschäftigt
ist, berechnet der Prozess 400 die geschätzte verbleibende
Verarbeitungszeit (EPTR) (Block 420). Der EPTR-Wert wird
berechnet, indem die abgelaufene Zeit seit Beginn der Anforderung
von der geschätzten
Verarbeitungszeit (EPT) subtrahiert wird. Wenn der EPTR-Wert negativ
ist, so wird der EPTR-Wert auf Null gesetzt (Block 420).
Als nächstes
stellt der Prozess 400 den EPTR-Wert an die Anwendung bereit
(Block 425). Der Prozess 400 gibt ein Signal „arbeitet" an den Prozess 200 zurück und wechselt
zu dem Block 425 des Prozesses 200, wie dies in
der Abbildung aus 2 veranschaulicht ist (Block 430).
-
Wenn
der Prozess 400 andererseits die E/A-Anforderung abgeschlossen
hat, so löscht
der Prozess die Sperrflagge (Block 435). Als nächstes stellt
der Prozess die E/A-Operationsergebnisse
(von der Vorrichtung abgerufen) an die Anwendung bereit (Block 440).
Der Prozess 400 gibt ein Signal „abgeschlossen" an den Prozess 200 zurück und wechselt zu
dem Block 235 des Prozesses 200 gemäß der Veranschaulichung
in 2 (Block 445). Wie für den Code für den Prozess 300 handelt
es sich bei dem Code zur Implementierung des Prozesses 400 für den Laufzeitzuweisungstreiber
um einen kritischen Abschnitt des Codes und ein Codestück, das
nicht neu eingegeben werden kann. Zu jedem gegebenen Zeitpunkt kann
jede Anzahl von Anwendungen darauf warten, dass die Sperrflagge
gelöscht
wird, so dass sie ihre Anforderung einleiten kann.
-
In
erneutem Bezug auf die Abbildung aus 2 bestimmt
der Prozess 200, ob die Vorrichtung weiter arbeitet auf
den Eingaben von dem Prozessor 400. Wenn die Vorrichtung
weiter arbeitet, basierend auf dem Empfang des Signals „arbeitet" von dem Prozess 400,
bewirkt der Prozess 200 ein Ruhen der Anwendung für die geschätzte verbleibende
Verarbeitungszeit (EPTR) (Block 240). Wenn der EPTR-Wert
auf Null gesetzt ist, ruht die Anwendung für ein Timer-Tickintervall (TTI)
(Block 240). Nach dem Ruhen für den bezeichneten Zeitraum
kehrt der Prozess 200 zu dem Block 230 zurück, um erneut
den Laufzeitzuweisungstreiber aufzurufen, um zu versuchen, die E/A-Operationsergebnisse
zu erhalten (Block 230).
-
Wenn
der Prozess 400 die E/A-Anforderung jedoch abgeschlossen
hat und den Prozess 200 mit den E/A-Operationsergebnissen
bereitgestellt und ein Signal „abgeschlossen" an den Prozess 200 bereitgestellt
hat, wird die E/A-Anforderung durch die Anwendung verarbeitet (Block 245).
Als nächstes
bewirkt der Prozess 200 ein Ruhen der Anwendung für ein Timer-Tickintervall (TTI),
bevor fortgefahren wird (Block 250). Dies dient dem Zweck,
es anderen wartenden Anwendungen zu ermöglichen, ausgeführt zu werden,
unmittelbar nachdem die Anwendung die E/A-Anforderung ausgeführt hat,
was erforderlich ist, um die Fairness zu gewährleisten. Der Prozess 200 endet
danach (Block 255).
-
Die
Prozesse für
die Interaktion der Anwendungen mit dem Laufzeitzuweisungstreiber
stellen eine elegante Möglichkeit
für viele
konkurrierende Anwendungen bereit, den Zugriff auf eine Vorrichtung fair
gemeinsam zu nutzen, die keine Unterbrechungen erzeugt. Ferner erreicht
die vorliegende Erfindung dies, ohne Probleme in Bezug auf die Systemleistung
zu verursachen, indem eine Schätzung
eingesetzt wird, wie lange die Vorrichtung für die Ausführung jeder Anwendung benötigt. Da
alle wartenden Anwendungen während
dem gleichen Timer-Tick ausführbar
werden, plant der Laufzeitzuweisungstreiber diese in der gleichen
Reihenfolge, in der sie geplant werden würden, wenn sie alle gesperrt
wären, darauf
wartend, dass die Vorrichtung verfügbar wird. Dabei wird jedoch
angenommen, dass der OS-Scheduler
fair den nächsten
Prozesskontext zur Ausführung
auswählt
aus einer Gruppe von Prozesskontexten, die gerade gleichzeitig ausführbar geworden sind.
Somit basiert die Fairness des Laufzeitzuweisungstreiber auch auf
der Fairness des Schedulings des Prozesskontexts durch den Scheduler
des Betriebssystems. Die Erfindung funktioniert zum Beispiel gut
in Verbindung mit Multilevel-Round-Robin-Schedulern, die von Microsoft
Windows Betriebssystem (z.B. Windows 98, Windows NT 4.0, Windows 2000)
verwendet werden, die fair arbeiten. Im Allgemeinen eignet sich
die vorliegende Erfindung am besten für eine Funktionsweise mit Betriebssystemen,
bei denen die Anwendungen allgemein auf der gleichen Prioritätsebene
bleiben und wenn die jeweilige Prioritätsebene in Round-Robin-Reihenfolge ausgeführt wird.
Hiermit wird jedoch festgestellt, dass die vorliegende Erfindung
auch gut funktionsfähig
ist in Verbindung mit einer umfassenden Vielzahl von Betriebssystem-Schedulern,
die unterschiedliche Prioritätsmodelle
verwenden.
-
Hiermit
wird festgestellt, dass die vorstehend beschriebenen funktionalen
Komponenten in Hardware, Software oder einer Kombination aus Hardware
und Software implementiert werden können. Bei einer Implementierung
in Software handelt es sich bei den Elementen der vorliegenden Erfindung um
die Codesegmente zur Ausführung
der erforderlichen Aufgaben. Die Programm- oder Codesegmente können in
einem maschinenlesbaren Medium gespeichert werden, wie etwa einem
durch den Prozessor lesbaren Medium oder einem Computerprogrammprodukt,
oder sie können
durch ein in einer Trägerwelle
ausgeführtes
Computerdatensignal oder ein durch einen Träger moduliertes Signal über ein Übertragungsmedium übertragen
werden. Das maschinenlesbare Medium kann jedes Medium aufweisen,
das Informationen in einer Form speichern oder übertragen kann, die durch eine
Maschine ausführbar
ist (z.B. einen Prozessor, einen Computer, etc). Zu Beispielen für das maschinenlesbare
Medium zählen
eine elektronische Schaltung, ein Halbleiterspeicherbaustein, ein
ROM, ein Flash-Speicher, ein löschbarer
programmierbare ROM (EPROM), eine Floppy-Diskette, eine Compact
Disk CD-ROM, eine optische Disk, eine Festplatte, ein faseroptisches bzw.
Lichtwellenleitermedium, ein Hochfrequenz-Übermittlungsabschnitt,
etc. Das Computerdatensignal kann jedes Signal aufweisen, das über ein Übertragungsmedium
ausgebreitet werden kann, wie etwa über elektronische Netzwerkkanäle, Lichtwellenleiter,
Luft, elektromagnetische, Hochfrequenz-Übermittlungsabschnitte,
etc. Die Codesegmente können über Computernetzwerk
bzw. Computernetze heruntergeladen werden, wie zum Beispiel das
Internet, ein Intranet, etc.
-
Im
Besonderen kann in einem Ausführungsbeispiel
der vorliegenden Erfindung der Laufzeitzuweisungstreiber 189 allgemein
in dem Host-Computer 100 als ein oder mehrere Computerprogramme implementiert
werden, die gesteuert durch das Betriebssystem 185 ausgeführt werden,
um die vorstehend beschriebenen gewünschten Funktionen auszuführen.
-
Die
Computerprogramme umfassen Befehle (z.B. Codesegmente), die, wenn
sie durch den Computer gelesen und ausgeführt werden, bewirken, dass
der Computer die Operationen ausführt, die erforderlich sind,
um die vorliegende Erfindung zu implementieren und/oder einzusetzen.
Im Allgemeinen werden Computerprogramme greifbar ausgeführt in und/oder
lesbar von einer Vorrichtung, einem Träger oder Medien, wie etwa einem
Speicher, Datenspeichervorrrichtungen und/oder einer entfernten
Vorrichtung, die mit dem Computer über Datenkommunikationsvorrichtungen
gekoppelt ist. Gesteuert durch das Betriebssystem können die
Computerprogramme aus dem Speicher, den Datenspeichervorrichtungen
und/oder einer entfernten Vorrichtungen in den Speicher des Computers
zur Verwendung während Operationen
geladen werden.
-
Der
Laufzeitzuweisungstreiber 189 kann somit gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung als ein Verfahren, eine Vorrichtung oder
ein maschinenlesbares Medium (z.B. ein durch einen Prozessor lesbares
Medium oder ein computerlesbares Medium) unter Verwendung standardmäßiger Programmier-
und/oder Entwicklungstechniken implementiert werden, um Software,
Firmware, Hardware oder eine beliebige Kombination dieser zu erzeugen.
Der hierin verwendete Begriff „maschinenlesbares
Medium" (oder alternativ „Prozessor
lesbares Medium" oder „computerlesbares
Medium" umfasst
ein Medium, auf das jede Maschine, jeder Prozess und jeder Computer
zugreifen kann, um davon zu lesen und Ausführungen vorzunehmen. Der Fachmann
auf dem Gebiet erkennt natürlich,
dass zahlreiche Modifikationen dieser Konfiguration möglich sind,
ohne dabei vom Umfang der vorliegenden Erfindung abzuweichen.
-
Die
Prozess für
die Interaktion von Anwendungen mit dem Laufzeitzuweisungstreiber
gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung stellen eine elegante Möglichkeit
für viele
konkurrierende Anwendungen bereit, um den Zugriff auf eine Vorrichtung,
die keine Unterbrechungen erzeugt, fair zu verteilen bzw. gemeinsam
zu nutzen. Die vorliegende Erfindung erreicht dies, ohne Systemleistungsprobleme
zu bewirken, indem ein Schätzwert
eingesetzt wird, wie lange die Vorrichtung benötigt, um jede Anforderung vollständig auszuführen. Ferner
ist die vorliegende Erfindung mit den meisten Betriebssystemen kompatibel
bzw. einsetzbar. Sie nimmt keinerlei Sperrung in dem Laufzeitzuweisungstreiber
vor – die
vollständige
Sperrung erfolgt in dem Anwendungscode. Obgleich die Synchronisierung
der Vorrichtungsanforderung bei verschiedenen Betriebssystemen auf
unterschiedliche Weise erfolgt, neigen die gemäß der vorliegenden Erfindung
eingesetzten Prozesse ferner dazu, diese besonders portabel zu gestalten.
-
Die
vorliegende Erfindung löst
ferner elegant die erzeugten Probleme, wenn eine Vorrichtung eine sehr
lange Zeit benötigt,
um eine Anforderung zu bedienen (mehrere Sekunden oder länger), da
der Prozesskontext der Anwendung einfach in einem Ruhezustand gesperrt
bleibt während
der Anforderung, und wobei der Laufzeitzuweisungstreiber passiv
ist und ruht. Während
die Anforderung verarbeitet wird, müssen keine Ressourcen des Laufzeitzuweisungstreibers
von einem Prozesskontext in Anspruch genommen werden, so dass für den Fall,
dass ein Prozesskontext während
einer Vorrichtungsanforderung auf nicht normale Weise beendet wird,
das System nicht destabilisiert wird. Im Besonderen sperrt oder ruft
der Code in den kritischen Abschnitten des Laufzeitzuweisungstreibers
nicht ab, was eine schnelle Erregung dieser Abschnitte ermöglicht,
was für
die Systemstabilität,
die Leistung und das Ansprechverhalten wichtig ist. Ferner erfolgt
keinerlei Abrufaktion in dem Laufzeitzuweisungstreiber. Die Host-CPUs können frei
andere Aufgaben während
der E/A-Verarbeitung
ausführen.
-
Die
Anwendungsseite der vorliegenden Erfindung kann leicht in eine Bibliothek
gekapselt werden, was eine Vorrichtungsanforderung wie einen Sperraufruf
aus Sicht sonstigen Anwendungscodes erscheinen lässt. Ferner nutzt die vorliegende
Erfindung Primitive, die allgemein in den meisten Betriebssystemen
verfügbar
sind (d.h. Ruhen, aktuelle Systemzeit ermitteln). Die Prozesse der
vorliegenden Erfindung, die mit dem Laufzeitzuweisungstreiber implementiert
sind, sind sehr fair zu konkurrierenden Anwendungen.
-
Die
vorliegende Erfindung wurde vorstehend in Bezug auf veranschaulichende
Ausführungsbeispiele
beschrieben, wobei diese Beschreibung nicht einschränkend auszulegen
ist. Verschiedene Modifikationen der veranschaulichenden Ausführungsbeispiele
sowie weitere Ausführungsbeispiele
der Erfindung, die für
den Fachmann auf dem Gebiet der Erfindung, an den sich die Erfindung
richtet, dem Umfang der vorliegenden Erfindung angehören.