-
Hintergrund
des Standes der Technik
-
Das
Internet weist eine sehr hohe Anzahl an Computern und Computernetzwerken
auf, welche über Kommunikationslinks
bzw. -verbindungen miteinander verbunden sind. Die Kommunikationslinks
tauschen digitale Informationen aus, wobei das bekannte Standard-Übertragungssteuerprotokoll/Internetprotokoll (TCP/IP)
benutzt wird. Anwendungsprotokolle, wie z.B. Hypertext-Übertragungsprotokoll
(HTTP) und File-Übertragungsprotokoll
(FTP) werden auf dem TCP/IP benutzt. Ähnliche oder identische Übertragungsprotokolle
und Applikationsprotokolle werden auch von modernen Computern benutzt,
um über
private Netzwerke zu kommunizieren, wie z.B. Inteanets und lokale
Flächenetzwerke
(LANs). Diese Applikationsprotokolle gestatten einem Server-Computersystem,
Informationen zu einem fernen Client-Computersystem zu senden. Das entfernte
Client-Computersystem kann dann die Information anzeigen oder auf
andere Weise davon Gebrauch machen. Im Falle des HTTP kann die Information
in Form einer so genannten World-Wide-Web-Seite angezeigt werden.
-
Die
dramatische Zunahme im Gebrauchen des Internets und in anderen Formen
der Client/Server-Kommunikation in den letzten Jahren bedeutet,
dass Server mehr und mehr Anforderungen bzw. Anfragen empfangen
und mehr und mehr Verbindungen und Antworten verarbeiten. Deshalb
wurde die Geschwindigkeit, bei welcher Server bezüglich der
Anzahl von Anforderungen, welche in einer gegebenen Zeitperiode
bearbeitet werden, arbeiten, für
die Gesamtgeschwindigkeit und die Leistungsfähigkeit des Internets und anderer Computer-Kommunikationssysteme
sehr wichtig.
-
Ein
Prozess, welcher die Leistungsfähigkeit
eines Betriebssystems und von Applikationen, welche auf einem Server
installiert sind, verlangsamt, ist der Prozess des Schaltens des
Kontextes einer Ausführung.
Der Kontext einer Ausführung
wird auch einfach als der "Kontext", "Prozess", "Thread" oder "Task" bzw. "Aufgabe" bezeichnet. Der
Kontext ist eine Basiseinheit des mehrprogrammfähigen Betriebssystem-Kernels
bzw. -kerns. Der Betriebssystem-Kernel ist der Teil des Betriebssystems,
welcher Hardware-Quellen handhabt und die grundlegenden Operationen
des Betriebssystems durchführt.
Einige gegenwärtige
Betriebssystem-Kernels beinhalten einige Protokollfunktionen auf
niedrigem Niveau, wie z.B. TCP/IP-Funktionen. In jedem Fall dient ein
Kontextschalter zum "Schalten" zwischen zwei oder
mehr Prozessen, so dass jeder Prozess die zentrale Verarbeitungseinheit
(CPU) benutzen kann.
-
Kontextschalter
sind "fruchtlos" in dem Sinn, dass
keine nützliche
Applikationsarbeit durch Kontextumschaltung durchgeführt wird.
Einige Operationen innerhalb eines mehraufgabenfähigen Betriebssystems oder die
Applikationen, welche auf einem derartigen System installiert sind,
können
ohne Kontextumschaltung durchgeführt
werden. Derartige Operationen werden oft "Atomare"-Operationen genannt. Jedoch erfordern Operationen,
welche einen Eingang und einen Ausgang oder "I/O" bzw. "E/A" beinhalten, normalerweise
einen Kontextschalter. Derartige Operationen beinhalten Medienzugriffsvorrichtungen
und unglücklicherweise
das Kommunizieren über
ein Netzwerk, wobei ein Applikationsprotokoll benutzt wird.
-
Das
System, welches veröffentlicht
ist in:
- – TIMOTHY: "Answers From Planet
TUX: Ingo Molnar Responds" SLASHDOT.ORG,
20 July 2000 – 21
July 2000, http://slashdot.org/articles/00/07/20/1440204.shtml,
- – MOLNAR
INGO: "TUX MAN-PAGE.TXT:
TUX Programmer's
Manual: tux – interact
with the TUX kernel subsystem" STANDARD
PERFORMANCE EVALUATION CORPORATION, 26 June 2000, http://www.spec.org/osg/web99/results/api-src/Dell-20000626.tar.gz,
- – MOLNAR
INGO: "TUX.H: TUX – Scalable
Integrated Web Cache and Web Server: tux.h; TUXAPI – TUX interface
to userspace" STANDARD
PERFORMANCE EVALUATION CORPORATION, 26 June 2000, http://www.spec.org/osg/web99/results/apisrc/bell-20000626.tar.gz,
und
- – MOLNAR
INGO: "CRD.C: TUX – Scalable
Integrated Web Cache and Web Server; CAD.c: Implementation of the
SPECweb99 dynamic application using TUXAPI." STANDARD PERFORMANCE EVALUATION CORPORATION,
26 June 2000, http://www.spec.org/osg/web99/results/api-src/Dell-20000626.tar.gz
gestattet
es, dass Applikationsprotokollanforderungen, welche über ein
Netzwerk empfangen wurden, an einem Server behandelt und beantwortet
werden, ohne eine Kontextumschaltung auszulösen. Dieses System gestattet
diese Funktionalität
durch Liefern eines Applikationsprotokoll-Subsystems und von Protokollmodulen innerhalb
des Betriebssystem-Kernels.
-
Die
vorliegende Erfindung befähigt
ein Protokoll-Subsystem, einen "Im-Kernel"- bzw. "Im-Kern"-Applikationsprotokollstapel
zu schaffen, welcher Information bezüglich der Applikationsprotokollanforderungen
in einer Kernel-Anforderungsstruktur speichert. Eine Anwender-Space-
bzw. -Platz-Applikation kann dann das Ausführen fortsetzen, während das
Betriebssystem auf die Applikationsprotokollanforderung ohne Kontextumschaltung
antwortet. Die Erfindung wird durch das Verfahren, welches im Anspruch
1 spezifiziert ist, und durch das Gerät, welches im Anspruch 7 spezifiziert
ist, definiert.
-
In
beispielhaften Ausführungsformen
der Erfindung wird ein Computerprogrammcode benutzt, um die Erfindung
zu implementieren, wie dies in Anspruch 4 spezifiziert ist. Das
Computerprogramm kann auf einem Medium gespeichert werden. Das Medium
kann magnetisch sein, wie z.B. eine Diskette, ein Band oder eine Festplatte,
oder optisch, wie z.B. eine CD-ROM oder DVD-ROM. Der Computerprogrammcode kann auch
in einer Halbleitervorrichtung gespeichert werden. Zusätzlich kann
das Computerprogramm über
das Internet oder einen anderen Typ von Netzwerk geliefert werden.
Eine Workstation bzw. Arbeitsstation oder ein Rechnersystem, welches
typischerweise mit einem Netzwerk verbunden ist, lässt den
Computerprogrammcode laufen, welcher als Teil eines Computerprogrammprodukts
geliefert wird. Dieses Computersystem kann auch als ein "Programmausführungssystem" oder "Instruktionsausführungssystem" bezeichnet werden.
Der Computerprogrammcode in Verbindung mit dem Computersystem bildet
die Vorrichtung, um das Verfahren der Erfindung auszuführen.
-
Kurze Beschreibung
der Zeichnungen
-
1 ist
ein Blockschaltbild, welches einige Eigenschaften der Software darstellt,
welche eine Ausführungsform
der Erfindung implementiert.
-
2 ist
ein Flussdiagramm, welches ein Verfahren darstellt, welches durch
Software ausgeführt
wird, welche eine Ausführungsform
der Erfindung implementiert.
-
3 ist
ein anderes Flussdiagramm, welches ein Verfahren darstellt, welches
durch Software ausgeführt
wird, welche eine Ausführungsform
der Erfindung implementiert.
-
4 ist
ein Blockdiagramm, welches einige Merkmale der Software darstellt,
welche eine Ausführungsform
der Erfindung implementiert.
-
5 ist
ein Flussdiagramm, welches ein Verfahren darstellt, welches durch
die Software durchgeführt
wird, welche eine Ausführungsform
der Erfindung implementiert.
-
6 ist
ein Blockschaltbild eines Computersystems, welches eine Ausführungsform
der Erfindung implementiert.
-
Beste
Vorgehensweise(n), die Erfindung auszuführen Die vorliegende Erfindung
ist typischerweise in einer Computersoftware oder einem Computerprogrammprodukt
verkörpert.
Es sollte eingesehen werden, dass nicht jedes Merkmal der be schriebenen
Software notwendig ist, um die Erfindung zu implementieren, wie dies
in einem speziellen der angefügten
Ansprüche
beansprucht wird. Das vollständige
Softwareprodukt wird vielmehr beschrieben, um voll die Erfindung
möglich
zu machen. Es ist auch davon auszugehen, dass durch diese Veröffentlichung,
dort wo ein Softwareprozess oder -verfahren gezeigt oder beschrieben
wird, die Schritte des Verfahrens in beliebiger Reihenfolge oder
gleichzeitig durchgeführt
werden können,
wenn nicht klar aus dem Kontext hervorgeht, dass ein Schritt von
einem anderen abhängt,
welcher zuerst durchgeführt
wird.
-
Die
Ausführungsformen
der vorliegenden beschriebenen Erfindung sind in einer Rechenplattform,
basierend auf dem Computerbetriebssystem, allgemein als "Linux" bekannt, implementiert,
welches als offene Quelle direkt über das Internet verfügbar ist.
Linux ist auch über
verschiedene Händler
verfügbar,
welche Service und Unterstützung
für das
Linux-Betriebssystem liefern. Unter diesen Händlern sind Red Hat, Inc.,
von Research Triangle Park, North Carolina, der Bevollmächtigte
der vorliegenden Erfindung. Ein Beispiel eines derartigen Computerprogrammcodes
im Patch- bzw. Direktkorrekturformat, welches Teile der Erfindung
implementiert, wird am Ende dieser Spezifikation beigefügt, und
dessen Gebrauch wird später
diskutiert. Gewiss sind mehrere Kurzcode-Beispiele in dieser Spezifikation
beinhaltet, um spezifische Konzepte, welche diskutiert werden, zu
erläutern.
All diese Beispiele werden schließlich von Fachleuten verstanden.
Es ist auch davon auszugehen, dass die Linux-Beispiele nur zur Erläuterung
gezeigt werden. Die erfinderischen Konzepte, welche hier beschrieben
werden, können
an jede Rechenplattform angepasst werden, basierend auf irgendeinem Betriebssystem,
wobei jene eingeschlossen sind, welche auf MacintoshTM,
UnixTM und WindowsTM basieren.
-
Schließlich sollte
eingesehen werden, dass einige Blockdiagramme und Flussdiagramme,
welche benutzt werden, um die erfinderischen Konzepte zu erläutern, nicht
wechselseitig exklusiv sind. Vielmehr wurde jedes maßgeschneidert,
um ein spezielles diskutiertes Konzept zu erläutern. In vielen Fällen treten
die Elemente oder Schritte, welche in einer speziellen Zeichnung
gezeigt werden, zusammen mit anderen auf, welche in einer unterschiedlichen
Zeichnung gezeigt werden, aber nur gewisse Elemente oder Schritte
werden der Klarheit wegen gezeigt. Beispielsweise zeigen die Blockdiagramme
der 1 und 4 beide Elemente innerhalb eines
Betriebssystem-Kernels und eines Nutzerraumes. In einer aktuellen
Software können
alle diese Elemente in beiden Zeichnungen präsent sein. Jedoch werden nur
diejenigen, welche relevant für
ein spezielles Merkmal sind, in der jeweiligen Zeichnung der Klarheit
wegen gezeigt.
-
Mit
Bezug auf 1 wird ein Blockdiagramm geliefert,
welches verschiedene Elemente eines Softwaresystems darstellt, welches
einen Betriebssystem-Kernel 100 und einen Nutzerraum 101 besitzt.
Die Merkmale, welche in 1 dargestellt sind, sind für eine Computerplattform
oder ein Instruktionsausführungssystem
wichtig, welches als ein Server zu nutzen ist, und so kann das Softwaresystem
der 1 als ein "Serversystem" bezeichnet werden.
Der Betriebssystem-Kernel oder einfach "der Kernel" ist der Teil der Betriebssystem-Software,
welcher die Hardware-Quellen handhabt, grundlegende Funktionalität liefert
und grundlegende Programmier-Interfaces für Applikationen liefert. Ein
derartiges Programmier-Interface wird oft als ein "Applikationsprogramm-Interface" oder "API" bezeichnet. In der
vorliegenden Ausführungsform
der Erfindung beinhaltet der Betriebssystem-Kernel 100 die
Fähigkeit,
einen Kommunikationsprotokollstapel durch das Nutzen eines Im-Kernel-Applikationsprotokoll-Subsystems 102 beizubehalten.
Es ist wichtig, ein Applikationsprotokoll, wie z.B. HTTP oder FTP,
von Protokollen mit niedrigerem Niveau, wie z.B. TCP/IP, zu unterscheiden.
Verlässliche
Protokollmodule 103 sind auch im Kernel beinhaltet und
liefern Applikationsprotokollinformation und Funktionalität für das Protokoll-Subsystem 102.
Die Protokolle, welche beinhaltet sind, können HTTP, FTP oder irgendein
anderes Applikationsprotokoll sein, welches für Netzwerkkommunikationen benutzt
wird, wobei so genannte "Meta-Applikationsprotokolle", wie z.B. ausgedehnte
Markup-Sprache (XML) und Hypertext-Markup-Sprache (HTML), welche
HTTP nutzen, beinhaltet sind. Es ist davon auszugehen, dass Bezugnahmen
auf HTTP, wel che hier beinhaltet sind, bedeuten, dass sie HTML und
XML beinhalten. Ein generischer Betriebssystem-Cache 104 ist
auch in dem Kern angesiedelt und kann benutzt werden, Files oder
Seiten an Information zu puffern. Schließlich ist auch ein Protokollobjekt-Cache 105 in
dem Kernel und ist operativ mit dem Protokoll-Subsystem 102 verbunden.
Der Protokollobjekt-Cache
kann für
gewisse Merkmale des Softwaresystems wichtig sein, das später zu diskutieren
ist. Man beachte, dass, wie in 1 gezeigt
wird, das Protokoll-Subsystem in dieser beispielhaften Ausführungsform
ein direktes allgemeines Gateway-Interface
(CGI) und transparente Sockelumleitung liefert.
-
Es
kann nicht überbetont
werden, dass die Betriessystem-Architektur,
welche mit 1 diskutiert wird (und welche
später
mit Bezug auf 4 diskutiert wird), repräsentative
Beispiele sind. Einige Betriebssysteme gestatten es, dass gewisse
Applikationen im Kernelraum ablaufen, andere aber im Nutzerraum
ablaufen. Es ist auch unter einigen Umständen möglich, dass eine Applikation
in beiden Plätzen
abläuft,
wobei einige Codes im Kernelraum ablaufen und andere Codes im Nutzerraum
ablaufen.
-
Der
Nutzerraum 101 der 1 beinhaltet
unverlässliche
Module oder andere Ablauffähigkeiten, 106. Es
ist an diesem Punkt nützlich
zu erklären,
was mit "trusted" gegenüber "untrusted" Software-Modulen
gemeint ist. Wie bei Fachleuten bekannt ist, sind moderne Betriebssysteme
so gestaltet, dass Applikationen oder die Software-Module im Nutzerraum
in einer "Sandbox" von Sorten untergebracht
sind. Diese Sandbox garantiert, dass Module in dem Betriebssystem
nicht verfälscht
oder umgekehrt beeinflusst werden können durch das, was im Nutzerraum
vor sich geht. Dieses Konzept ist durch das Gestalten des Betriebssystems
implementiert, so dass Module im Nutzerraum als "untrusted" bzw. unverlässlich betrachtet werden können, so
dass ihr Zugriff zu Betriebssystemfunktionen begrenzt ist. Module
innerhalb des Betriebssystem-Kernels im Gegensatz dazu sind "trusted" bzw. verlässlich und
haben vollen Zugriff zu Betriebssystemfunktionen. In dieser beispielhaften
Ausführungsform
der Erfindung können
Kommunikationsprotokoll- Applikationen
von hohem Niveau als verlässliche
Module innerhalb des Betriebssystem-Kernels angesiedelt sein. Diese
Im-Kernel-Protokollmodule
und das Im-Kernel-Protokoll-Subsystem befähigen ein Server-System, auf
Applikationsprotokollanforderungen zu antworten, ohne dass das Betriebssystem
Kontextumschaltungen durchführt.
Es ist wichtig zu beachten, dass nicht alle Betriebssysteme einen
getrennten Nutzerraum besitzen. Einige Betriebssysteme führen Applikationen
innerhalb des Betriebssystem-Kernelraums aus. In diesen Fällen jedoch
ist die funktionale Beziehung zwischen dem Betriebssystem und der
Applikation die gleiche. Das Betriebssystem handhabt Hardware und
liefert APIs, und die Applikation nutzt ein API, um die Applikationsaufgaben
auszuführen.
-
Operationen
in einem Computersystem, welche keine Kontextumschaltungen oder
irgendwelche andere Prozessablaufunterbrechungen auslösen, werden
häufig
als "atomare" Operationen bezeichnet.
Mit der eben beschriebenen Architektur können Kommunikationsapplikationen
das ausführen,
was normalerweise "nicht
atomare" Arbeit
ohne Kontextumschaltung ist. Wenn eine Antwort erzeugt werden muss,
wird Information über
die Applikationsprotokollanforderung in einer Im-Speicher-im-Kernel-Anforderungsstruktur
gespeichert, welche den Kernel in die Lage versetzt, die Ausführung fortzusetzen,
sobald eine angemessene Nutzerraum-Anforderungsstruktur aktualisiert
ist, als ob die Antwort bereits stattgefunden hat. Eine beispielhafte
Anforderungsstruktur für
eine HTTP-Anforderung wird nachfolgend gezeigt. In diesem speziellen
Fall wird die Nutzeranforderungsstruktur gezeigt. Jedoch ist die
Kernel-Anforderungsstruktur sehr ähnlich und kann leicht von
der Nutzerraum-Anforderungsstruktur
abgeleitet werden.
-
-
-
2 ist
ein Flussdiagramm, welches das Verfahren des Antwortens auf eine
Anforderung ohne Kontextumschaltung darstellt. Im Schritt 201 wird
die Nutzerraum-Anforderungsstruk tur geschaffen. Im Schritt 202 tritt
die Ausführung
durch das Instruktionsausführungssystem,
welches als ein Server-System arbeitet, in den Betriebssystem-Kernel
ein. Im Schritt 203 wird eine neue Kernel-Anforderungsstruktur
geschaffen, um die Anforderung handzuhaben. Die Kernel-Anforderungsstruktur
wird mit Daten gefüllt,
welche in Verbindung mit der Anforderung erhalten werden, gewöhnlicherweise
von einem Client-System, welches die Anforderung über das
Netzwerk macht. Im Schritt 204 wird die Kernel-Anforderungsstruktur
in den Nutzerraum durch Befüllen der
Nutzerraum-Anforderungsstruktur kopiert. Diese "Kopie" wird sehr effizient durch Bewegen der
Daten durchgeführt,
welche nur auf benutzte Teile der Anforderungsstrukturen bezogen
sind. In diesem Fall würde auch
ein so genanntes "privates
Feld" der Anforderungsstruktur
bewegt. Das private Feld ist ein undurchsichtiger Zeiger, welcher
von Applikationen als Referenz benutzt werden kann. Im Schritt 205 kehrt
die Ausführung zum
Nutzerraum zurück,
und die Nutzerraumapplikation fährt
mit Operationen fort, als ob die Anforderung gehandhabt worden wäre. Die
Nutzerraum-Anforderungsstruktur wird überschrieben, wenn eine andere
Anforderung gehandhabt werden muss. Der Kernel handhabt die Anforderung
normalerweise zur rechten Zeit (dieser Schritt wird der Klarheit
wegen nicht gezeigt). Bei 206 zeigt das Betriebssystem
die Anforderung an. Wenn die Anforderung vollendet ist oder eine
Auszeit auftritt, betritt die Ausführung den Betriebssystem-Kernel im Schritt 207,
und die Kernel-Anforderungsstruktur wird bei 208 gelöscht, um
Speicherquellen zu sparen. Wenn die Anforderung nicht vollendet
werden kann, jedoch keine Auszeit aufgetreten ist, wird das System
die Anforderung beibehalten, und die Anforderung wird als die aktuelle
Anforderung an den Nutzerraum zurückgegeben, nachdem die I/O-
bzw. E/A-Operation(en) für
diese Anforderung beendet ist bzw. sind. Eine "hängende" Anforderung wird
keine Ausführung
auslösen,
welche aufzuschieben ist. Es sollte beachtet werden, dass die Anforderung
aufgeschoben wird – nicht
die Aufgabe, so dass die Ausführung
im Nutzerraum fortfährt.
Es ist auch für eine
Anforderung möglich,
um mehr als eine I/O- bzw. E/A-Operation aufgeschoben zu werden.
-
3 stellt
einen anderen Prozess dar, welcher in dem Betriebssystem, welches
die Erfindung verkörpert,
beinhaltet ist; denjenigen des Einbettens statischer Protokollobjekte
in Antworten, wie z.B. HTTP-Web-Seiten, welche an eine Client-Applikation in Antwort
auf eine Applikationsprotokollanforderung gesandt wurden. Es sollte
beachtet werden, dass diese Darstellung nur beispielhaft auf HTTP-Web-Seiten
beruht. Es kann möglich
sein, die Erfindung mit anderen Applikationsprotokollen zu implementieren,
wie z.B. FTP. In dieser Ausführungsform
der Erfindung werden die statischen Protokollobjekte in dem Protokollobjekt-Cache 105 der 1 gespeichert,
aber sie können
auch in dem generischen Betriebssystem-fache angesiedelt sein. Im
Schritt 301 der 3 empfängt der Server die Applikationsprotokollanforderung
und analysiert sie. Eine beispielhafte Applikationsprotokollanforderung
in Form einer HTTP-Anforderung wird nachfolgend gezeigt. Eine derartige
Anforderung wird normalerweise durch zwei Neuzeilen-Kennungen terminiert.
GET
/ HTTP/1.0
User-Agent: Wget/1.6
Host: www.redhat.com
Accept:
*/*
-
Im
Schritt 302 wird eine Präambel zurück an den Client gesandt. Die
Präambel
ist der Überschriftsteil einer
HTTP-Antwort oder
-Erwiderung. Ein beispielhaftes Überschriftsteil
wird nachfolgend gezeigt.
HTTP/1.1 200 OK
Date: Tue, 03
Jul 2001 10:45:31 GMT
Server: Apache/1.3.19 (Unix) (Red-Hat/Linux)
mod
ssl/2.8.1 OpenSSL/0.9.5a
Connection: close
Content-Type:
text/html
-
Im
Schritt 303 werden die optionalen dynamischen Teile der
Antwortseite innerhalb eines Speicherpuffers auf dem Server geschaffen.
Die dynamischen Teile bestehen aus dynamischen Protokollobjekten,
welche den Teil der Antwort bilden. Die Antwort kann auch statische
Protokollobjekte, welche innerhalb einbettet sind, besitzen. Die
dynamischen Protokollobjekte werden an die Client-Applikation im
Schritt 304 gesandt. Im Schritt 305 werden die
statischen Teile der Antwortseite, oder statische Protokollobjekte,
von dem Protokollobjekt-Cache oder dem generischen Betriebssystem-Cache
zurückgeholt.
Die statischen Objekte werden an die Client-Applikation im Schritt 306 gesandt,
wo sie in die Antwort eingebettet werden, so dass eine vollständige Antwort
am Client-System angezeigt werden kann.
-
4 ist
ein anderes Blockschaltbild einer Ausführungsform des Betriebssystems
der Erfindung. In diesem Fall ist das Blockdiagramm so aufgebaut,
dass es die Operation des atomaren File-Look-up-Merkmals darstellt. 4 beinhaltet
drei Hauptsegmente einer Betriebssystemumgebung: File-System 400,
Nutzerraum 401 und Betriebssystem-Kernel 402.
Das File-System 400 beinhaltet File-System-Objekte 403 in
dem File-System-Raum. File-System-Objekte, oder einfach "Files", sind die Baublöcke des
File-System-Raumes. Tatsächlich
sind sie die Container der Information. Es gibt verschiedene Typen
von File-System-Objekten, welche reguläre Files, Directories und symbolische
Links beinhalten. Ein symbolischer Link liefert einen Weg, einen
neuen File zu schaffen, welcher in der Tat gerade auf ein existierendes
File zeigt. Ein symbolischer Link wird auch als ein Soft Link bezeichnet.
Das "Linking" bzw. Verknüpfen wird über eine
Zeichenkette durchgeführt,
welche Trennzeichen aufweist. Das Trennglied ist der "/" (Slash bzw. Schrägstrich) auf Linux- und Unix-Systemen
und für
Internet URL's und
ist der "\" (Backslash bzw.
Rückstrich)
bei Windows-Systemen.
-
Man
beachte, dass der Objektname des File-Systems oder der Filename
eine Kette von Zeichen ist, welche keine Trennzeichen beinhaltet,
z.B. "homework.doc". Jedes File-System-Objekt
hat einen File-System-Objektnamen. Ein File-System-Objektpfad oder "File-Pfad" ist eine Kette von
Zeichen, welche gewöhnlich mit
dem Trennzeichen startet, und spezifiziert verschiedene Teile eines
Pfades, welche das File ausfindig machen. In einigen Systemen kann
dieser File-Pfad auch als Directory- bzw. Verzeichnispfad oder Folder-
bzw. Ordnerpfad bezeichnet werden, z.B. "/home/joe/docs/homework.doc".
-
Das
File-System der 4 beinhaltet auch den File-System-Namensraum 404.
Der File-System-Namensraum bezieht sich auf alle File-Pfade innerhalb
des Systems. Die Pfade für
alle Files sind typischerweise auf der File-System-Vorrichtung in
Form von Directories gespeichert. Der Nutzerraum 401, welcher
in 4 gezeigt wird, ist dort, wo die Applikationen 405 typischerweise
angesiedelt sind. Diese Applikationen gebrauchen die File-System-Objekte 403,
welche innerhalb des File-Systems 400 gehalten werden.
Um ein bisher noch nicht benutztes File zu benutzen, führt das
Applikations- und Betriebssystem eine File-System-Namensraum-Operation
aus. Eine derartige Operation wird z.B. durchgeführt, um ein File zu öffnen, zu
lesen oder zu schreiben, ein File umzubenennen oder es zwischen
Directories zu bewegen. Es gibt auch andere wohl bekannte File-System-Namensraum-Operationen.
Für die
Zwecke dieser Erfindung werden einige dieser File-System-Namensraum-Operationen
generell als "Öffnen eines
Files", Bearbeiten
einer "File-Öffnungsanforderung", Ausführen einer
File-Operation o.Ä.
genannt. Entsprechend dem Stand der Technik, falls eine Applikation
die ersten tausend Bytes des "/home/joe/docs/homework.doc"-Files lesen soll,
würde es
den Computerprogrammcode ähnlich
zu dem enthalten, was in dem folgenden C-Beispiel gezeigt wird.
-
-
Nach
Ausführung
dieser drei Systemrufe wird der Betriebssystem-Kernel die ersten
tausend Bytes des Files in den Speicherpuffer, "buf",
gegeben haben.
-
Der
Betriebssystem-Kernel beinhaltet einen File-System-Namensraum-Cache 406.
Der "offene" Systemruf, wie oben
gezeigt, wird intern auf den File-System-Namensraum-Cache zugreifen,
um das Zugreifen auf die Files zu beschleunigen, wenn einmal deren
Pfad in dem File-System-Namensraum-Cache gespeichert ist. Der File-System-Namensraum-Cache
wird auch manchmal als "Dentry-Cache" bezeichnet. Man
beachte, dass der Namensraum-Cache keine File-Inhalte versteckt
bzw. speichert. Er kann File-Attribute verstecken bzw. speichern.
File-Inhalte werden in einer getrennten Datenstruktur gespeichert,
wie z.B. in dem generischen fache, welcher in 1 gezeigt
wird, häufig
als "Seiten-Cache" bezeichnet, wie
dies sehr wohl bekannt ist, und dies wurde der Klarheit wegen in 4 weggelassen.
-
Im
Stand der Technik, wie es oben dargestellt wurde, kommt der Kernel
zu dem File, was immer es bezüglich
der Zeit und der Ressourcen in Anspruch nimmt, und er ist offen
für die
Applikation, gleichgültig
ob der File-Pfad mit dem File-Namen bereits in dem Namensraum-Cache
vorhanden war oder nicht. Falls nicht, würde der Kernel Details des
File-Pfades von der Festplatte lesen, und die Bearbeitung, welche
mit der Applikation verbunden ist, wird aufgeschoben und Kontextschalter
treten auf, bis der I/O bzw. die E/A beendet wurde, was einen ernsten
Leistungseingriff schafft.
-
Im
Gegensatz zum Stand der Technik, welcher eben beschrieben wurde,
beinhaltet das System der 4 eine atomare
Look-up-Operation, 407,
welche den atomaren File-Look-up entsprechend dieser Ausführungsform
der Erfindung implementiert. Der atomare File-Look-up befähigt eine
Applikation 405, zu detektieren, ob ein File bereits innerhalb
des Namensraum-Cache gespeichert ist oder nicht. Der folgende Code
zeigt, wie das Merkmal in der Praxis gebraucht wird.
-
-
-
Man
beachte die "O ATOMICLOOKUP"-Kennzeichnung und
den neuen "-EWOULDBLOCKIO"-Return-Code für den offenen
Systemaufruf. Während
des Lernvorgangs, dass der File-Pfad noch nicht gespeichert ist,
kann die Applikation das File, welches offen für einen anderen Prozess ist,
stürzen
oder zurückführen, wie
dies geeignet bzw. richtig durch den Applikationsentwickler bestimmt
wurde. In einigen Fällen
kann dieser Prozess ein Prozess sein, welcher das Handhaben des
Blockierpunktes durchführt.
-
Der
Prozess des Handhabens des Blockierpunktes kann in dem Nutzerraum
bei 408 der 4 oder in dem Kernel bei 409 der 4 angesiedelt
sein. Ein "Blockierpunkt" ist ein Punkt, bei
welchem ein Look-up ein mögliches
Kontextschalten auslösen
würde.
Das "Handhaben des
Blockierpunktes" kann
das Springen dieses Look-up zu einem anderen Prozess/Teilprozess
beinhalten, welchen das File offen in einer Weise managen kann,
welche die Leistungsfähigkeit
verbessert.
-
5 stellt
ein Beispiel der atomaren Look-up-Operation in Form eines Flussdiagramms
dar. Beim Schritt 501 bestimmt eine Applikation, welcher
File-Name, wie durch eine Zeichenkette bezeichnet, geöffnet werden
soll. Bei 502 wird die Anforderung zum File-Öffnen gegenüber dem
Betriebssystem durchgeführt.
Beim Schritt 500 empfängt
der Betriebssystem-Kernel die Anforderung und versucht, das File
atomar zu öffnen.
Um das atomare Öffnen
zu versuchen, überprüft der Kernel
den File-System-Namensraum-Cache
nach dem geeigneten File-Pfad. Der Schritt 503 ist ein
Entscheidungspunkt, welcher nach Fehlern prüft bzw. sucht, z.B. nach dem
Nichtvorhandensein eines derartigen Files. Dieser Prozess wird in
der gleichen Weise wie im Stand der Technik gehandhabt. Wenn ein
Fehler auftritt, wird er durch eine Fehlerhandhabungsroutine bei 504 behandelt.
Wenn kein Fehler vorhanden ist, fährt die Bearbeitung fort. Der
Betriebssystem-Kernel benachrichtigt die Applikation im Schritt 505,
ob das File atomar geöffnet
wurde oder wird, da sein Pfad in dem File-System-Namensraum-Cache
gespeichert wurde. Falls das File atomar geöffnet wurde, wird das File
im Schritt 506 benutzt. Falls nicht, da die Applikation
von der Tatsache Kenntnis erlangte, dass ein atomares Öffnen im
Schritt 505 nicht möglich
war, wird ein möglicher
Blockierpunkt im Schritt 507 angewandt.
-
Man
beachte, dass in dieser Ausführungsform
die Applikation keine Anforderung sendet, ob der File-Pfad gespeichert
ist. Sie setzt einfach den Betriebssystem-Kernel in Kenntnis, dass
sie ein File atomar öffnen
will. Falls der Kernel zustimmt, da der File-Pfad gespeichert ist,
wird das File geöffnet,
und eine Kennung wird an die Applikation zurückgegeben. Falls der File-Pfad
nicht gespeichert ist, wird dann das File nicht geöffnet, und
-WOULDBLOCKIO wird an die Applikation zurückgegeben. Mit Bezug auf die
Diskussion dieses Merkmales hier wird die Terminologie "wurde geöffnet", "könnte geöffnet werden", "wird geöffnet" und Ähnliches
austauschbar verwendet. In ähnlicher
Weise wird die Terminologie bezogen auf eine File-Operation, wie z.B. "wurde ausgeführt", "wird ausgeführt", "könnte ausführt werden", und Ähnliches austauschbar benutzt.
Die Arbeitsweise der Erfindung ist die gleiche, ungeachtet des exakten
Zeitverlaufs des Prüfens
des Cache, des File-Öffnens
und des Erkennens vom Betriebssystem-Kernel aus für eine Applikation.
-
Es
gibt viele Variationen der Betriebssystemarchitektur, welche oben
beschrieben wurden, eine jede davon kann auch die atomare Look-up-Operation
beinhalten. Beispielsweise muss die File-System-Vorrichtung nicht
auf dem Computersystem angesiedelt sein, welches den Betriebssystem-Kernel
enthält,
sondern auf sie kann stattdessen über ein Netzwerk zugegriffen
werden. In diesem Fall kann der File-System-Namensraum mit der File-System-Vorrichtung
vom Netzwerk ausfindig gemacht werden, welche auf dem System platziert
ist, welches den Betriebssystem-Kernel
enthält,
oder auf beide Plätze
aufgeteilt sein. Es ist auch wichtig zu beachten, dass nicht alle
Betriebssystemumgebungen einen Nutzerraum als eine getrennte Schutzdomäne besitzen.
Bei einigen Betriebssystemen, z.B. bei welchen diese im Allgemeinen
mit eingebetteten Prozessoren benutzt werden, bleiben die Applikationen
erhalten und werden innerhalb des Betriebssystem-Kernel ausgeführt. In
diesem Fall liefert das Betriebssystem noch die APIs für die Applikationen,
und das Betriebssystem kommuniziert mit einer Applikation über sein
API, in der gleichen Weise, als ob die Applikation in einem Nutzerraum
laufen würde.
-
Am
Ende dieser Spezifikation, vor den Ansprüchen, ist ein Beispiel einer
Quellcode-Auflistung eingefügt,
welche einen Code zeigt, welcher das atomare Look-up-Merkmal implementiert.
Diese Quellcode-Auflistung trägt
den Titel "Quellcode-Beispiel". Der Quellcode ist
in dem gut bekannten differentiellen Patch- bzw. Korrekturformat. Er korrigiert
bzw. setzt die öffentlich
erhältliche
Version 2.4.2 des Linux-Betriebssystems in Stand, ein offenes Quellbetriebssystem,
welches über
das Internet bezogen werden kann, und von Firmen, welche Unterstützung für dieses
liefern, wie z.B. Red Hat, Inc., der Bevollmächtigte der vorliegenden Anmeldung.
-
Wie
vorher diskutiert, wird bei einigen Ausführungsformen die Erfindung über einen
Computerprogrammcode implementiert, welcher auf einem programmierbaren
Computersystem oder Befehlsausführsystem,
wie z.B, einem Personal Computer oder einer Workstation oder einer
anderen Mikroprozessor-basierten Plattform läuft. 6 stellt
ein weiteres Detail eines Computersystems dar, welches die Erfindung
in dieser Weise implementiert. Der Systembus 601 verbindet
die Hauptkomponenten miteinander. Das System wird durch den Mikroprozessor 602 gesteuert,
welcher als zentrale Verarbeitungseinheit (CPU) für das System dient.
Der Systemspeicher 605 ist typischerweise in viele Typen
von Speicher oder Speicherflächen,
wie z.B. Read-only-Speicher
(ROM), Zugriffsspeicher (RAM) und andere getrennt. Der Systemspeicher
kann auch ein Basis-Eingangs-/Ausgangssystem (BIOS) beinhalten.
Eine Vielzahl von allgemeinen Eingangs/Ausgangs-(I/O-)Adaptern oder
-Vorrichtungen 606 sind vorhanden. Der Klarheit wegen werden
nur drei gezeigt. Diese sind mit verschiedenen Vorrichtungen verbunden,
welche ein Festplattenlaufwerk 607, ein Diskettenlaufwerk 608,
ein Netz werk 610 und einen Monitor 609, beinhalten.
Die Computerprogrammcode-Instruktionen zum Implementieren der Funktionen
der Erfindung werden auf der Festplatte 607 gespeichert.
Wenn das System arbeitet, werden die Instruktionen partiell in den
Speicher 605 geladen und durch den Mikroprozessor 602 ausgeführt. Optional
ist eines der I/O- bzw. E/A-Vorrichtungen ein Netzwerkadapter oder
Modem für
die Verbindung mit dem Netzwerk 610, welches das Internet
sein kann. Es sollte beachtet werden, dass das System der 6 nur
als erläuterndes
Beispiel dienen soll. Verschiedene Arten von allgemein gebräuchlichen
Computersystemen sind erhältlich
und können
benutzt werden.
-
Elemente
der Erfindung können
in Hardware und/oder Software als ein Computerprogrammcode (welcher
Firmware, gespeicherte Software, Microcode, etc. beinhaltet) verkörpert sein.
Außerdem
kann die Erfindung die Form eines Computerprogrammproduktes annehmen,
auf einem computernutzbaren oder computerlesbarem Speichermedium,
welches einen computernutzbaren oder computerlesbaren Programmcode
in dem Gebrauchsmedium beinhaltet mit oder in Verbindung mit einem
Befehlsausführsystem,
wie z.B. dem, welches in 6 gezeigt wird. Ein derartiges
Medium wird graphisch in 6 dargestellt, um das Diskettenlaufwerk wiederzugeben.
Ein computernutzbares oder computerlesbares Medium kann irgendein
Medium sein, welches das Nutzerprogramm enthalten, speichern, kommunizieren
oder transportieren kann durch oder in Verbindung mit einem Befehlsausführungssystem.
Das computernutzbare oder computerlesbare Medium ist z.B. ein elektronisches,
magnetisches, optisches, elektromagnetisches, infrarotes oder Halbleitersystem.
Das Medium kann auch einfach ein Informations- bzw. Datenstrom sein,
welcher zurückgeholt
bzw. herausgeholt wird, wenn das Computerprogramm über ein
Netzwerk, wie z.B. das Internet, "heruntergeladen" wird. Man beachte, dass das computernutzbare
oder computerlesbare Medium auch Papier oder ein anderes geeignetes
Medium sein kann, auf welchem ein Programm gedruckt ist.
-
Der
Quellcode im differentiellen Patch-Format, welches die Merkmale
implementiert, welche in dieser Spezifikation beschrieben werden,
ist öffentlich
erhältlich,
ab dem Regist rierdatum dieser Anmeldung unter www.redhat.com/~mingo/TUX/.
Ein kompletter Quellcode für
ein Softwaresystem, welches die Erfindung implementiert, kann auch
ab dem Registrierzeitpunkt dieser Anmeldung von Red Hat, Inc., dem
Bevollmächtigten dieser
Anmeldung, angefordert werden. Der Quellcode, welcher unter der
obigen Internet-Adresse platziert ist, dient dazu, eine Version
des Linux-Betriebssystems zu korrigieren bzw. in Stand zu setzen,
ein offenes Quellcode-Betriebssystem, welches über das Internet angefordert
werden kann, und von Firmen, welche Unterstützung für dieses liefern, wie z.B.
-
Red
Hat, Inc., dem Bevollmächtigten
der vorliegenden Anmeldung. Der Code soll die Version 2.4.5 des Linux-Betriebssystems korrigieren,
welche bereits durch die bekannte so genannte "ac4"-Patch
korrigiert wurde.
-
Die
Version 2.4.5 von Linux ist neben anderen Orten erhältlich unter:
www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.5.tar.gz. Der oben erwähnte bekannte
ac4-Patch ist neben anderen Orten erhältlich unter:
www.kernel.org/pub/linux/kernel/people/alan/2.4/patch-2.4.5-ac4.gz.
-
Spezielle
Ausführungsformen
einer Erfindung wurden hier beschrieben. Eine Person mit normalen
Fähigkeiten
im Computerbereich wird schnell erkennen, dass die Erfindung andere
Anwendungen in anderen Umgebungen besitzt. Tatsächlich sind viele Ausführungsformen
und Implementierungen möglich.
Die folgenden Ansprüche
sollen in keiner Weise den Umfang der Erfindung auf spezielle Ausführungsformen,
welche oben beschrieben wurden, begrenzen.
-
-
-
-