DE69419749T2

DE69419749T2 - Speicherverwalter für ein rechnersystem und verfahren hierfür

Info

Publication number: DE69419749T2
Application number: DE69419749T
Authority: DE
Inventors: David Austin; Tantek Celik; Jed Harris; Shui Lo; Steven Szymanski
Original assignee: Apple Computer Inc
Current assignee: Apple Inc
Priority date: 1993-05-12
Filing date: 1994-05-12
Publication date: 1999-12-09
Anticipated expiration: 2014-05-13
Also published as: WO1994027232A1; AU6832994A; DE69419749D1; US5758347A; EP0698243B1; EP0698243A1; JPH08510347A; US5857207A; US5870764A

Description

Ein Teil der Offenbarung dieses Patentdokuments enthält Material, das einem Urheberrechtsschutz unterliegt. Der Eigentümer des Urheberschutzrechts hat keine Einwände gegen die Faksimile-Wiedergabe des Patentdokuments oder der Patentoffenbarung, wie sie in der Patentrolle oder den Aufzeichnungen des "Patent & Trademark Office" (Patent- und Markenamt) erscheint, er behält sich jedoch anderweitig alle Urheberschutzrechte vor.

STAND DER TECHNIK

Anwenderprogramme in einem Computersystem müssen Daten typischerweise so verwalten, daß ein häufiges Aktualisieren ermöglicht ist. Zwei allgemeine Beispiele für solche Anwenderprogramme sind ein Textverarbeitungsprogramm und ein Datenbank-Verwaltungsprogramm. Textverarbeitungsprogramme müssen Textteile und andere verwandte Informationen jedesmal dann manipulieren können, wenn der Benutzer ein Dokument modifiziert, und ein Datenbankprogramm muß entsprechend den Anforderungen eines Benutzers eingaben einfügen, löschen und modifizieren.
Ein Problem, dem Entwickler dieser Typen von Anwenderprogrammen häufig gegenüberstehen, ist das Abwägen zwischen dem Speicherplatz und der Ausführungsgeschwindigkeit. Beispielsweise verwalten Datenbankprogramme Daten typischerweise in Form einer oder mehrerer Tabellen. Jeder Datensatz in einer Tabelle weist die gleiche Anzahl von Feldern auf, die jeweils im gleichen Format gehalten sind und die alle in einer getrennten Datenstruktur beschrieben sind, die das Programm in Zusammenhang mit der Tabelle unterhält. Bei einer solchen Tabelle könnte jede Zeile einen anderen Daten satz darstellen, und jede Spalte könnte ein anderes Feld innerhalb des Datensatzes darstellen. Falls die Tabelle als eine einfache Matrix unterhalten wird, ist jedem Feld eine vorgegebene maximale Länge zugewiesen, und es ist für die maximale Länge jedes Felds in jedem Datensatz Speicher zugeordnet. Dies führt ganz klar dazu, daß viel Speicherplatz verschwendet wird, da die Daten in den meisten Feldern nicht den vollen Umfang des zugeordneten Platzes belegen. Der Entwickler kann Platz sparen, indem er Felder mit veränderlicher Länge als reine Relativzeiger ("offsets") mit einer festgelegten Bytelänge unterhält, die in einen Speicherbereich verweisen, der die tatsächlichen Daten enthält, dies ist jedoch mit einem Maß an Indirektheit verbunden, das jedesmal dann hingenommen werden muß, wenn es erforderlich ist, auf die bestimmten Daten zuzugreifen. Hierdurch kann die Geschwindigkeit beeinträchtigt werden, mit der bestimmte Operationen, wie ein Suchen, ausgeführt werden.
Ein weiteres Problem der Platzausnutzung, dem Entwickler von Datenbankprogrammen häufig gegenüberstehen, wenn Daten gespeichert und als Tabellen unterhalten werden, besteht darin, daß es häufig wünschenswert ist, ein bestimmtes Feld in nur einen oder einige der Datensätze in der Tabelle aufzunehmen, wobei dieses Feld in der großen Mehrzahl der Datensätze unnötig ist. Ein großes Ausmaß an unbenutztem Platz muß zugeordnet werden, um ein solches Feld selbst dann in allen Datensätzen zu erhalten, wenn der Entwickler danach strebt, den verschwendeten Platz durch indirekte Zuweisung zu minimieren. Der Entwickler des Datenbankprogramms kann das Ausmaß an verschwendetem Platz verringern, indem er die Daten als eine Verbundliste und nicht als eine Matrix unterhält, wobei jedoch wiederum der Nachteil eines sehr hohen Zusatzaufwands für Operationen, wie ein Suchen, auftritt. Weiterhin wird durch Verbundlistenausführungen nicht sehr viel Platz eingespart, da weiterhin einiger Speicherplatz zugeordnet werden muß, um anzuzeigen, daß ein bestimmtes Feld in einem bestimmten Datensatz leer ist. Der Entwickler kann den Geschwindigkeitsnachteil möglicherweise durch Hinzufügen von Querzeigern in der Verbundliste verringern, durch diese Technik wird das Ausmaß an verwendetem Speicherplatz jedoch wiederum vergrößert.
Das Abwägen zwischen der Speicherplatzausnutzung und der Zugriffsgeschwindigkeit wird erheblicher, wenn die verwalteten Daten, falls sie als eine Matrix ausgedrückt sind, spärlicher werden. Demgemäß besteht ein Bedarf an einem Verfahren zum Verwalten von Daten, durch das die Platzverwendung und die zum Zugreifen auf die Daten erforderliche Zeit minimiert werden.
Ein weiteres Problem, dem Entwickler von Anwenderprogrammen gegenüberstehen, besteht darin, daß die vom Betriebssystem angebotene Dateistruktur für viele Typen von Anwenderprogrammen nicht für die Aufgabe geeignet ist. Für die von Betriebssystemen angebotenen Daten-Speicherverwaltungseinrichtungen sind diejenigen typisch, die von MS-DOS®, Unix® und von Apple Macintosh® angeboten werden. Bei all diesen Betriebssystemen werden Daten in "Dateien" gespeichert. Eine Datei wird in einem "Verzeichnis" von Dateien gehalten, und Verzeichnisse können als Teile von anderen Verzeichnissen gehalten werden, wodurch eine Baumstruktur für die Dateien erzeugt wird. Falls die vom Betriebssystem verwaltete Speichervorrichtung mehr als ein Speichermedium in der Art verschiedener Festplatten, Disketten, CD-ROMs, über ein Netzwerk zugänglicher ferner Speichermedien oder eines lokalen flüchtigen Speichers enthält, weist gewöhnlich jedes dieser Medien sein eigenes Hauptverzeichnis auf, innerhalb dessen alle auf dem Medium gespeicherten Dateien auftreten. Unix® und Macintosh® unterstützen auch alternative Zuordnungen von Dateien, wobei eine Datei in mehreren verschiedenen Verzeichnissen auftreten kann, wenngleich die Daten der Datei nur an einem Ort vorhanden sind. Alle anderen Orte beziehen sich lediglich auf den einen realen Ort.
Bei diesen Dateisystemen ist die kleinste von dem Betriebssystem unterstützte Informationseinheit für viele der häufig benötigten Operationen eine Datei. Da der Geschwindigkeitsnachteil, der mit Betriebssystemaufrufen zum Öffnen und Schließen von Dateien verbunden ist, erheblich ist, werden Daten von Anwenderprogrammen gewöhnlich in nur einer Datei oder in einigen Dateien gehalten, statt zu versuchen, die vom Betriebssystem unterstützte Dateisystemstruktur auszunutzen. Beispielsweise kann ein Entwickler eines Datenbankprogramms möglicherweise ein großes Ausmaß an Dateibewegungen vermeiden, wenn ein Datensatz eingefügt oder gelöscht wird, indem er jeden Datensatz einfach in einer eigenen Datei hält. Bei einem weiteren Beispiel möchte ein Datenbank-Anwenderprogramm möglicherweise jedes Feld eines Datensatzes in einer eigenen Datei halten, wodurch automatisch Felder mit veränderlicher Länge verwirklicht werden. Keine dieser Techniken ist jedoch praktisch verwendbar, da sie eine enorme Anzahl von Betriebssystemaufrufen zum Öffnen und Schließen von Dateien erfordern würden, wodurch ein erheblicher Geschwindigkeitsnachteil auftreten würde.
Da die Daten bei vielen Anwenderprogrammen in nur einer oder einigen Dateien gehalten werden, ist für jedes solche Programm die Entwicklung und Verwirklichung eines geschützten Datenformats erforderlich, das es der Anwendung ermöglicht, die Daten, die das bestimmte Anwenderprogramm erwartet, schnell zu speichern und abzurufen. Entwickler unterhalten daher häufig große Codebibhiotheken, um auf ihre eigenen geschützten Dateiformate zuzugreifen. Ein Beispiel ist das MacWrite-Programm, das seinen eigenen Mechanismus zum Verschieben von Daten in den Speicher und aus diesem heraus aufweist. Der Mechanismus ist für das bestimmte verwendete Dateiformat optimiert, und er ist nicht direkt von anderen Anwenderprogrammen verwendbar. Andere Anwenderprogramme weisen im wesentlichen ähnliche Mechanismen auf. Das Ergebnis ist eine beträchtliche Erhöhung des Aufwands, der ansonsten für eine verbesserte Funktionalität für den Benutzer verwendet werden könnte.
Es besteht dementsprechend ein erheblicher Bedarf an einer Betriebssystemunterstützung des Speicherns von Daten in einer für einen breiten Bereich von Anwenderprogrammen nützlichen Form.
Ein weiteres Problem, dem Anwendungsentwickler häufig gegenüberstehen, tritt auf, wenn Daten in verschiedenen Teilen einer Datenspeichervorrichtung gespeichert werden, die unterschiedliche Zugriffsprotokolle aufweisen. Beispielsweise kann eine Speichervorrichtung in einem Computersystem nicht nur einen permanenten Speicher in der Art einer Festplatte, sondern auch einen flüchtigen Speicher in der Art des Hauptspeichers des Computersystems aufweisen. Falls ein Anwenderprogramm also die Anzahl der Lese- und Schreibvorgänge einer Festplatte minimieren möchte, kann es einige der Daten so lange wie möglich im Hauptspeicher halten, bevor der Platz, den sie im Hauptspeicher benötigen, für andere Zwecke erforderlich wird. Ein häufiges Beispiel besteht in der Notwendigkeit, daß ein Textverarbeitungsprogramm einen Teil eines gerade bearbeiteten Dokuments im Speicher und andere Teile des Dokuments auf der Platte ausgelagert hält. Es ist für eine solche als Cache-Speichern bekannte Technik häufig erforderlich, daß das Anwenderprogramm verfolgt, welche Daten sich gerade auf welchem Medium befinden, und daß es das geeignete Protokoll zum Zugreifen auf dieses Medium verwendet. Falls sich die Daten beispielsweise auf der Platte befinden, verwendet das Anwenderprogramm typischerweise die Lese- und Schreibaufrufe des Betriebssystems, um auf die Daten zuzugreifen. Falls sich die Daten im Hauptspeicher befinden, kann das Anwenderprogramm jeglichen Zusatzaufwand des Betriebssystems vermeiden, indem es lediglich die bestimmten Speicherstellen adressiert, an denen die Daten angetroffen werden können. Falls sich die Daten im ROM befinden, ist möglicherweise noch ein drittes Datenzugriffsprotokoll erforderlich. Es besteht in der Industrie ein Bedarf, die Verwirklichung von Anwenderprogrammen zu vereinfachen, indem ein gemeinsamer Mechanis mus bereitgestellt wird, durch den der Anwendungsentwickler unabhängig davon auf Daten zugreifen kann, wie oder wo in der Speichervorrichtung des Computersystems sie gespeichert sind.
Viele Entwickler von Anwenderprogrammen stehen noch einem weiteren Problem gegenüber, falls die vom Programm unterhaltenen raten von mehr als einem Benutzer ansteuerbar und modifizierbar sein sollen. Der Begriff "gemeinsam verwendeter strukturierter Speicher" kann als ein Mechanismus definiert werden, der dazu dient, Daten über Sitzungen (Anrufe) eines Anwenderprogramms dauerhaft zu machen, wobei die Daten für ein gemeinsames Aktualisieren verfügbar sind. Es ist beispielsweise bei einem Textverarbeitungsprogramm häufig wünschenswert, die Fähigkeit zu unterstützen, daß zwei oder mehrere verschiedene Benutzer ein einziges Dokument gleichzeitig aktualisieren. Es ist bei einem Datenbanksystem häufig wünschenswert, es verschiedenen Benutzern zu gestatten, die Daten der Datenbank simultan zu aktualisieren. Bei den meisten Anwenderprogrammen ist eine als "pessimistische Simultanität" bekannte Technik verwirklicht, die es nur einem Benutzer gestattet, die Daten zu einem Zeitpunkt zu modifizieren, während sie es zahlreichen Benutzern gestattet, die Daten simultan zu lesen und zu betrachten. Das System "sperrt" den Schreibzugriff für alle anderen Benutzer, wenn ein Benutzer die Daten zum Aktualisieren geöffnet hat. Die pessimistische Simultanität kann auf einer Dateiebene oder, beispielsweise bei hochentwickelten Datenbankprogrammen, auf einer Datensatzebene verwirklicht sein. Das heißt für ein Sperren auf der Dateiebene, daß nur ein Benutzer die Datei zu einem Zeitpunkt zum Schreiben geöffnet haben darf. Dies ist die typische Art, in der Textverarbeitungsprogramme die Simultanität verwirklichen. Ein Datenbankprogramm kann ein Sperren auf der Datensatzebene verwirklichen, falls beispielsweise ein ausgangsseitiger Prozeß der einzige Prozeß ist, bei dem die Datendatei zum Schreiben geöffnet ist, und falls alle anderen Benutzer ihre Befehle und Abfragen über den nachgeschalteten Prozeß ausgeben.
Es wurde bei einigen Anwenderprogrammen versucht, eine "optimistische Simultanität" zu verwirklichen, bei der zwei oder mehrere Benutzer Daten, bei einer nachfolgenden Abstimmung, gleichzeitig modifizieren können. Ein Beispiel ist das von Apple Computer Inc., Cupertino, Kalifornien, erhältliche Programmierarbeitsplatz-Projekthilfsmittel (MPW-Projekthilfsmittel) (englische Originalbezeichnung: Macintosh® Programming Workshop (MPW) Projector). Das MPW-Projekthilfsmittel ist im Referenzhandbuch des MPW 3.1 und in "Projector, An Informal Tutorial" von H. Kanner, das von Apple Computer Inc. (1989) erhältlich ist, beschrieben. Das MPW-Projekthilfsmittel ist ein integrierter Satz von Werkzeugen und Schriftstücken, deren Hauptzweck darin besteht, die Kontrolle über die Entwicklung eines Quellencodes aufrechtzuerhalten. Es bewahrt die verschiedenen Ausgaben einer Datei in geordneter Weise und verhindert durch den Versionsverwaltungsmechanismus auch, das ein Programmierer unbeabsichtigt Änderungen zerstört, die von einem anderen vorgenommen wurden. Falls die zugrundeliegenden Daten Text sind, wird eine Datenkompression erreicht, indem nur eine vollständige Kopie einer Datei gespeichert wird und indem Ausgaben nur als Differenzdateien gespeichert werden. Verschiedene Benutzer desselben Satzes von Dateien können sie in unterschiedlicher Weise betrachten, da jedem Benutzer eine unabhängige Steuerung der Zuordnung zwischen der lokalen Verzeichnishierarchie des Benutzers, in der der Benutzer die Dateien hält, und der zu ihrem Speichern in der Hauptdatenbank des Projekthilfsmittels verwendeten Hierarchie gegeben ist. Das Projekthilfsmittel weist auch eine Einrichtung auf, um einem speziellen Satz von Dateiausgaben einen Namen zuzuordnen, der als ein Bezeichner für eine bestimmte Version oder Freigabe eines Produkts verwendet werden kann. Demgemäß kann der Name allein verwendet werden, um die Auswahl gerade jener Quellendateien auszulösen, die erfor derlich sind, um das gewünschte Beispiel des Produkts herzustellen.
Das MPW-Projekthilfsmittel unterhält Versionen in einer Baumstruktur. Wenn ein Benutzer eine Datei in der Hauptdatenbank des Projekthilfsmittels modifizieren möchte, führt er ein "Auslagern" der Datei durch, wodurch eine Kopie der Datei im eigenen Verzeichnis des Benutzers hergestellt wird. Der Benutzer kann eine Datei entweder als "Nurlesedatei" auslagern, oder er kann sie, falls dies noch kein anderer getan hat, als "Lese-Schreib-Datei" auslagern. Nach dem Modifizieren der Datei kann der Benutzer sie dann entweder als eine neue Version in einem neuen Zweig des Dateiversionsbaums wieder in die Hauptdatenbank des Projekthilfsmittels "einlagern", oder er kann die Datei nur dann, wenn sie als Lese-Schreib-Datei ausgelagert wurde, als eine neue Version im selben Zweig des Versionsbaums einlagern. Wenn es schließlich wünschenswert ist, einen Zweig des Ausgabenbaums wieder in den Hauptstamm zurückzuführen, führt das MPW- Projekthilfsmitael einen strengen auf Text beruhenden Vergleich zwischen den beiden Versionen der Datei aus und zeigt die Unterschiede in einem Paar von Fenstern auf der Anzeige des Computersystems an. Ein Benutzer schneidet dann Teile aus einem Fenster aus und kopiert sie in das andere, um sie zusammenzuführen.
Wenngleich das MPW-Projekthilfsmittel ein guter erster Schritt zu einer optimistischen Simultanität ist, ist eine erhebliche zusätzliche Flexibilität sehr wünschenswert. Beispielsweise ist sein feinstes Unterteilungsniveau weiterhin durch eine "Datei" gegeben. Es wäre wünschenswert, viel höhere Unterteilungsgrade zu unterstützen. Als weiteres Beispiel sei bemerkt, daß die Einrichtungen des MPW-Hilfsmittels, die darauf gerichtet sind, zwei Versionen eines einzigen Dokuments zusammenzuführen, auf eine einzige Prozedur beschränkt sind, bei der der Computer strenge Textunterschiede identifiziert und bei der ein Benutzer angibt, wie jeder Textunterschied aufgelöst werden sollte. Bei der Vergleichsprozedur ist erhebliche zusätzliche Intelligenz ebenso wie eine erheblich erhöhte Flexibilität und Automatisierung bei der Auflösung von Konflikten sowie eine Unterstützung für Vergleiche zwischen Nicht-Text-Dateien wünschenswert.
Einige Entwickler von Anwenderprogrammen haben versucht, das von Apple Computer erhältliche Betriebsmittel-Verwaltungssystem zu verwenden, um ein strukturiertes Speichern von Daten zu verwirklichen. Das Betriebsmittel-Verwaltuwgssystem ist in "Inside Macintosh: Overview", Kapitel 3 (1992) von Apple Computer beschrieben. Das Betriebsmittel-Verwaltungssystem unterstützt jedoch kein simultanes Aktualisieren seiner Daten, und es wurde in jedem Fall nicht für diesen Zweck ausgelegt. Das Betriebsmittel-Verwaltungssystem bietet daher keine angemessene Lösung.
Es besteht dementsprechend ein Bedarf an einer viel höheren Flexibilität bei der Unterstützung der optimistischen Simultanität bei der Unterhaltung von Daten.
In US-A-5 101 493 ist eine Datenstruktur aus dem Stand der Technik beschrieben, die einen Kopfteil und einen Inhaltsteil umfaßt. Der Kopfteil weist einen externen Bezugsvektor auf, der wenigstens ein externes Bezugselement aufweist, welches eine externe Struktur angibt. Der Inhaltsteil weist Daten und einen Zeiger auf, der ein externes Bezugselement im externen Bezugsvektor angibt, wodurch auf die Aufnahme der externen Struktur am Ort des Zeigers im Inhaltsteil hingewiesen wird. Der Oberbegriff des Anspruchs 25 beruht auf diesem Dokument.
In US-A-5 175 810 ist eine weitere Datenstruktur aus dem Stand der Technik für in Zeilen und Spalten angeordnete Tabellendaten beschrieben. Die Datenstruktur weist einen Kopfteil, der eine universelle Spaltenverarbeitungs-Informationstabelle aufweist, sowie einen Datenteil zum Speichern von Daten in Zeilen auf, wobei der Datenteil weiter eine Tabelle angibt, die eine universelle Spaltenverarbeitungsinformation enthält, die bei der Verarbeitung ausgewählter Zellen in der Zeile zu verwenden ist. In WO-A-91/16682 ist ebenso wie in EP-A-523269 eine weitere Datenstruktur aus dem Stand der Technik beschrieben.
Die vorliegende Erfindung beinhaltet grob beschrieben eine Datenstruktur, um Daten in einer Speichervorrichtung derart zu speichern, daß viele oder alle der oben erwähnten Mängel bei bestehenden Speichersystemen verbessert werden. Die Erfindung kann auch als ein Verfahren oder als eine Gruppe von Verfahren zum Unterhalten und/oder Verwirklichen einer Datenstruktur oder als eine Verknüpfung der Datenstruktur mit solchen Verfahren angesehen werden.
Gemäß einer Erscheinungsform der vorliegenden Erfindung ist ein Verfahren zum Aktualisieren von in einer Datenstruktur gespeicherten Daten vorgesehen, das in Anspruch 1 definiert ist.
Gemäß einer weiteren Erscheinungsform der vorliegenden Erfindung ist eine Datenspeichervorrichtung vorgesehen, die in Anspruch 25 definiert ist.
Bei der hier beschriebenen Ausführungsform ist die primäre Speichereinheit in der Datenstruktur eine Grundliste von Merkmalen ("Basic List of Properties") (Blop), in der eine Liste von hier als "Merkmale" ("Properties") bezeichneten Attributen gespeichert ist. Jedes Merkmal enthält keinen oder mehrere Werte ("Values"). Jeder Wert hat einen Typ ("Type") und besteht aus einer Bytesequenz mit veränderlicher Länge. Der Wertetyp ("Valüe Type") kann das Format des Werts einschließlich der Datenstruktur sowie Metainformationen in der Art einer Kompression und einer Verschlüsselung definieren.
Blops sind in Behältern ("Containers") gespeichert. Die Behälter verweisen auf das physikalische Medium, auf dem die Daten gespeichert sind. Die Speicherverwaltungseinrichtung kann über einen Standardsatz von Behälter-Handhabungsmitteln ("Container Handlers") auf jeden Behälter zugreifen, so daß Behälter im Speicher, im ROM, auf der Platte usw. erzeugt werden können.
Verwandte Blops können in hier als Pool bezeichneten Ansammlungen organisiert sein. Jeder Behälter kann einen oder mehrere Pools enthalten, wobei jeder Pool innerhalb des Behälters einen eindeutigen Namen hat. Jede Blop ist in genau einem Pool gespeichert (mit Ausnahme von Delta-Pools und trennbaren Pools ("Separable Pools"), wie weiter unten erörtert wird). Jede Blop kann jedoch mehrere Versionen aufweisen, die in einem Pool gespeichert sind. Versionen einer Blop unterscheiden sich voneinander hinsichtlich ihrer Merkmale, Werte oder Wertetypen.
Versionen verschiedener Blops können in Schichten ("Layers") gruppiert sein, und jede Schicht kann höchstens eine Version einer Blop enthalten. Schichten sind der Mechanismus der Speicherverwaltungseinrichtung, der dazu dient, es zu manipulieren, welche Versionen welcher Blops zu einem gegebenen Zeitpunkt zu verwenden sind. Die Schichten sind als ein azyklischer Digraph aufeinander bezogen, wobei sich jede Schicht über einer oder mehreren Grundschichten ("Base Layers") befindet und wobei sich über ihr eine oder mehrere Schichten befinden. Die einzige Ausnahme ist die Bodenschicht ("Bottom Layer") eines Pools, die keine Grundschicht aufweist. Demgemäß befindet sich jede Schicht in einem Pool transitiv oberhalb der Bodenschicht des Pools.
Jede Schicht bietet einem Benutzer der Blops in einem Pool eine "Ansicht". Es kann in der Hinsicht eine Analogie zwischen den Schichten und einem Stapel von Sichtfolien hergestellt werden, daß man durch eine Schicht direkt in die darunterliegende Schicht (die darunterliegenden Schichten) blicken kann. Der Inhalt jeder Schicht beruht mit anderen Worten auf dem Inhalt der Schichten, von denen sie abgeleitet ist. Um die Ansicht einer Schicht zu ändern, kann ein Benutzer Blops überschreiben, hinzufügen oder entfernen. Diese Änderungen beeinflussen nicht die Ansichten, die die Schichten unterhalb der aktuellen bieten, sie würden jedoch die Ansichten der davon abgeleiteten Schichten beeinflussen. Eine Schicht, die solche Änderungen nicht aufweist, wird als eine leere Schicht ("Empty Layer") bezeichnet, wobei dies nicht in dem Sinne erfolgt, daß bei ihr keine Blops sichtbar sind, sondern vielmehr in dem Sinne, daß sie völlig durchsichtig ist.
In Fig. 1 ist die logische Beziehung symbolisch dargestellt, die zwischen vier Schichten in einem Pool 102 auftreten könnte. Die Bodenschicht 104 des Pools hat zwei Namen, nämlich L1 und Boden, und es befinden sich darin drei Blops, nämlich A, B und C. Von der Schicht L1 ist eine Schicht 106 abgeleitet, nämlich L2. Bei L2 wurde die Blop A in ihre zweite Version geändert, die Versionen von B und C sind jedoch ungeändert, so daß die Version, die sie bei L1 hatten, noch sichtbar ist (in dem Diagramm durch die gestrichelte Begrenzung angegeben). Von der Schicht L2 ist eine Schicht 108 abgeleitet, nämlich L3. L3 ändert wiederum die Blop A, eliminiert (löscht) jedoch auch die Blop C und fügt eine Blop D hinzu. Die Blop B bleibt ungeändert, so daß die Version der Schicht L1 noch sichtbar ist. Die Schicht L4 ist von L3 abgeleitet, es wurden jedoch noch keine Änderungen an L4 vorgenommen, so daß sie als eine leere Schicht bezeichnet werden kann.
Die Pool-/Schicht-/Blop-Datenstruktur ermöglicht ein leichtes Verwirklichen der optimistischen Simultanität mit einer Unterteilung, die so fein wie gewünscht ist. Beispielsweise kann ein Dokument in eine beliebige Anzahl von Blops eingeteilt und in einem einzigen Pool gespeichert werden. Jede Schicht kann dann als ein Entwurf des Dokuments betrachtet werden. Da mehr als eine Schicht von einer Schicht abgeleitet werden kann, können mehrere Schichten auftreten, deren Inhalt auf derselben Grundschicht beruht. Falls ein Dokument beispielsweise in einem Pool in einem Plattendateibehälter gespeichert ist und zwei Personen gleichzeitig daran arbeiten möchten, können sie einfach auf der Grundlage der aktuellen Schicht zwei Schichten erzeugen.
In Fig. 2 ist ein Pool 202 symbolisch dargestellt, bei dem zwei Schichten 206, 208 von einer Grundschicht 204 abgeleitet sind. Die beiden Schichten 206, 208 können getrennt und gleichzeitig betrachtet und bearbeitet werden. Auf diese Weise kann mehr als ein Benutzer ein Dokument modifizieren, ohne daß andere Benutzer daran gehindert werden, auf es zuzugreifen. Weiterhin sind alle von einem Benutzer vorgenommenen Änderungen in einer Datei aufgenommen. Jeder, der Zugriff auf diese Datei hat, kann die verschiedenen Änderungen, die der Benutzer vorgenommen hat, betrachten. Der Benutzer braucht nicht mehrere Dateien für mehrere Entwürfe zu verwalten.
Zusätzlich zur Schichtverzweigung ermöglicht die Datenstruktur auch eine Schichtabstimmung. Wenn eine Schicht von mehr als einer Grundschicht abgeleitet ist, wird sie als eine Abstimmungsschicht ("Reconciliation Layer") bezeichnet, da sie ein Mittel darstellt, um die Ansichten der Schichten, auf denen sie beruht, abzustimmen. Jegliche Blops, bei denen in den verschiedenen Grundschichten verschiedene Versionen sichtbar sind, sind als mehrdeutig ("Ambiguous") definiert und können nicht angesteuert werden, bevor ihre Merkmale, Werte und Wertetypen in der Abstimmungsschicht explizit festgelegt worden sind. In Fig. 3 ist ein Pool 302 dargestellt, der eine Bodenschicht L1, zwei Zwischenschichten L2 und L3, die sich unmittelbar oberhalb der Bodenschicht L1 befinden, und eine Abstimmungsschicht, die sich unmittelbar oberhalb der beiden Schichten L2 und L3 befindet, aufweist. In Fig. 3 ist die Abstimmung der Blop A eindeutig, da sie in den beiden Schichten L2 und L3 nicht geändert wurde. Ebenso ist die Blop D nicht mehrdeutig, da sie nur in L3 auftritt. Die Blops B und C treten jedoch als verschiedene Versionen in L2 und L3 sauf, und sie sind als solche in der Abstimmungsschicht mehrdeutig.
Das Verfahren zum Lösen von Konflikten hängt vom Anwenderprogramm ab, das die Speicherverwaltungseinrichtung verwendet. Die Speicherverwaltungseinrichtung stellt ein Mittel bereit, um Konflikte nach Blop-Versionen zu identifizieren, es schreibt jedoch kein bestimmtes Verfahren zum Lösen von Konflikten vor. Es kann bei einer Anwendung gewählt werden, die Version einer Blop mit der letzten Abänderungszeit zu verwenden, während es bei einer anderen gewünscht sein kann, die Version mit den meisten Daten zu verwenden. Bei einem weiteren Beispiel kann es ein Anwenderprogramm einem Benutzer ermöglichen, eine Änderung gegenüber einer anderen auszuwählen, beide zu ignorieren oder die Blop gegen eine völlig neue Blop zu ersetzen. Das Anwenderprogramm, das eine Routine der Speicherverwaltungseinrichtung aufruft, um Ansichten in zwei Schichten zu vergleichen, stellt vorzugsweise auch einen Bezug zur Prozedur des Anwenderprogramms bereit, um Konflikte beizulegen.
Die Datenstruktur kann auch Pools beinhalten, die hier als Delta-Pools bezeichnet werden, welche es mehreren Pools ermöglichen, sich so zu verhalten, als ob sie ein einziger Pool wären. Bei einem Delta-Pool ist die Bodenschicht tatsächlich von einer Schicht in einem Grund-Pool ("Base Pool") abgeleitet. Demgemäß erscheinen die Schichten im Delta-Pool als eine Fortsetzung der Schichten im Grund-Pool. In Fig. 4 ist ein Beispiel dafür symbolisch dargestellt, wie die Schichten in einem Delta-Pool und seinem Grund-Pool aufeinander bezogen sein könnten.
Insbesondere beinhaltet ein Grund-Pool 402 vier Schichten L1, L2, L3 und L4, und ein Delta-Pool 404 beinhaltet vier Schichten L5, L6, L7 und L8. Wie in Fig. 4 dargestellt ist, liegt die Schicht L5, die die Bodenschicht des Delta- Pools 404 ist, "unmittelbar oberhalb" der Schicht L4 im Grund-Pool 402.
Ein gegebener Grund-Pool kann eine beliebige Anzahl von davon abgeleiteten Pools aufweisen, ein Delta-Pool kann jedoch nur einen Grund-Pool aufweisen. Ein Delta-Pool kann auch zu einem Grund-Pool für andere Delta-Pools werden. Durch einen Versuch, auf einen Delta-Pool zuzugreifen, wird ein Versuch ausgelöst, wieder eine Verbindung zu seinem Grund-Pool (und dem Grund-Pool seines Grund-Pools usw.) herzustellen. Falls der Grund-Pool nicht verfügbar ist, kann nicht auf den Delta-Pool zugegriffen werden. Falls der Grund-Pool verfügbar ist und nicht geändert wurde, seitdem der Delta-Pool zuletzt getrennt wurde, kann der Delta-Pool mit dem Grund-Pool verbunden werden. Falls der Grund-Pool geändert wurde, kann der Delta-Pool nicht automatisch mit dem Grund-Pool verbunden werden, und es muß ein Abstimmungsprozeß ausgelöst werden.
Das Konzept eines Delta-Pools ermöglicht neue Wege, um mit Daten auf Nurlesemedien (beispielsweise einer CD-ROM) zusammenzuwirken. Da ein Delta-Pool von einem Pool abgeheitet werden kann, der auf einem Nurlesemedium gespeichert ist, bietet ein Delta-Pool eine neue Ansicht des Nur-Lese- Pools, und es kann bei dieser Ansicht eine Modifikation vorgenommen werden. Falls beispielsweise ein Film als ein Pool auf einer CD-ROM gespeichert ist, kann der Film gesehen werden, und es kann jeder beliebige Rahmen des Films mit dem Delta-Pool geändert werden. Ein weiteres Beispiel ist ein interner ROM eines Computersystems. Bei Delta-Pools kann ein Computerhersteller den ROM in einen Grund-Pool umwandeln und künftige Ausgaben des Systems als Delta-Pool auf einem entfernbaren Medium in der Art einer Diskette ausliefern.
Die Datenstruktur unterstützt auch hier als trennbare Pools bezeichnete Pools. Trennbare Pools ähneln Delta-Pools in der Hinsicht sehr, daß die Bodenschicht tatsächlich von einer Schicht in einem Grund-Pool abgeleitet ist. Im allgemeinen werden bei einem trennbaren Pool jedoch alle in der Grundschicht sichtbaren Blops in die Bodenschicht des trennbaren Pools heraufkopiert.
Ein gegebener Grund-Pool kann eine beliebige Anzahl von davon abgeleiteten Pools aufweisen, ein trennbarer Pool kann jedoch nur von einem einzigen Grund-Pool abgeleitet sein. Anders als Delta-Pools kann ein trennbarer Pool geöffnet und angesteuert werden, ohne daß der Grund-Pool verfügbar ist.
Wenn ein trennbarer Pool wieder mit seinem Grund-Pool integriert wird, müssen jegliche Konflikte zwischen den beiden beigelegt werden. Ein Weg, die Konflikte zu lösen, besteht darin, im Grund-Pool eine Abstimmungsschicht zu erzeugen, der von der Grundschicht und der gewünschten Schicht im trennbaren Pool abgeleitet ist. Nach der Abstimmung kann der trennbare Pool zerstört werden, da die Änderungen im Grund-Pool aufgenommen sind. In Fig. 5 ist der Prozeß 502 der Reintegration eines trennbaren Pools mit seinem Grund-Pool symbolisch dargestellt. Insbesondere zeigt der Prozeß 502 zuerst die Erzeugung eines trennbaren Pools 504 aus einem Grund-Pool 506. Der Grund-Pool weist eine Schicht L1 auf, die die Grundschicht für die Bodenschicht L2 des trennbaren Pools 504 bildet. Bei der Reintegration erzeugt die Speicherverwaltungseinrichtung eine Abstimmungsschicht L3 im Grund-Pool, um die Unterschiede zwischen den Blops in der L1 zugeordneten Ansicht und den Blops in der L2 zugeordneten Ansicht abzustimmen. Dies ist beim Prozeß 502 dargestellt. Ebenso wie beim oben beschriebenen Abstimmungsprozeß für zwei Schichten im selben Pool ortet die Speicherverwaltungseinrichtung bei der Reintegration eines trennbaren Pools lediglich Konflikte in den Blop-Versionen. Es ist Aufgabe des Anwenderprogramms, auszuwählen, welche Version in der Abstimmungsschicht gespeichert werden soll, oder eine neue Version bereitzustellen.
Trennbare Pools sind für Arbeitsgruppen in einer mobilen Computerumgebung äußerst nützlich. Falls ein Benutzer beispielsweise bestimmte Aufgaben ausführen muß, während er sich außerhalb des Büros befindet, kann er einen im Büro vom Grund-Pool abgeleiteten trennbaren Pool erzeugen und das Dokument aktualisieren, während er unterwegs ist. Wenn der Benutzer zurückkehrt, kann das modifizierte Dokument selbst dann mit dem Originaldokument reintegriert werden, wenn das Originaldokument von anderen Mitarbeitern der Arbeitsgruppe aktualisiert worden ist, während der Benutzer fort war.
Bei einer Erscheinungsform der Erfindung ist ein hier als MoveAllChargesDown bezeichnetes Verfahren vorgesehen, um dabei zu helfen, die Speicheranforderungen für nicht mehr benötigte Blop-Versionen zu verringern. MoveAllChangesDown ist eine Operation, die es ermöglicht, die in einer Schicht auftretenden Änderungen in Schichten herabzuschieben, von denen sie abgeleitet wurde. Insbesondere veranlaßt MoveAll-ChangesDown von der Schicht A zur Schicht B, daß die Schicht B die gleiche Ansicht der Blops wie die Schicht A hat und daß alle Schichten oberhalb von B bis zu A leer sind, so daß sie auch die gleiche Ansicht haben. In Fig. 6 sind die Ergebnisse einer MoveAllChangesDown-Operation symbolisch dargestellt. In Fig. 6 weist ein Pool 602 drei Schichten L1, L2 und L3 auf. Der Schicht L1 ist eine. Ansicht der Version eins von jeder der drei Blops A, B und C zugeordnet. Die Schicht L2, die sich unmittelbar oberhalb der Schicht L1 befindet, hat eine Ansicht der Version zwei der Blop B, sie hat jedoch weiterhin eine Ansicht der Version eins von jeder der Blops A und C. Die unmittelbar oberhalb der Schicht L2 liegende Schicht L3 hat eine Ansicht einer neuer Version drei der Blop B, einer neuer Version zwei der Blop C und der Originalversion eins der Blop A. Nach der MoveAllChangesDown-Operation werden alle Änderungen in den Schichten L2 und L3 nach L1 verschoben, und die Schichten L2 und L3 werden leer gemacht. Demgemäß besteht die der Schicht L1 zugeordnete Ansicht nun aus der Version eins der Blop A, der Version drei der Blop B und der Version zwei der Blop C. Die den Schichten L2 und L3 zugeordneten Ansichten sind mit derjenigen der Schicht L1 identisch.
Die MoveAllChangesDown-Operation entfernt alle Versionen von Blops, die nicht mehr erforderlich sind, wodurch die Größe des die Blops enthaltenden Behälters verringert wird. Dies ist beispielsweise zum Archivieren eines endgültigen oder vorläufigen Entwurfs eines Dokuments besonders nützlich.
Die Speicherverwaltungseinrichtung kann auch ein hier als CollapseLayers bezeichnetes Verfahren beinhalten, durch das unnötige leere Schichten in einem Teil des Schichtbaums eines Pools beseitigt werden. Insbesondere beseitigt eine CollapseLayer-Operation von der Schicht A zur Schicht B alle leeren Schichten, die sich (transitiv) oberhalb der Schicht B und (transitiv) unterhalb der Schicht A unter Einschluß der Schicht A (falls leer) befinden. Jegliche Namen oder nicht leere Schichten, die sich oberhalb beseitigten Schichten befinden, werden zur ersten nicht leeren Schicht herabgeschoben, die sich unterhalb der beseitigten Schicht befindet.
In Fig. 7 ist diese Operation mit einem Pool 702 dargestellt, der eine Bodenschicht L1, zwei Schichten L2 und L3, die sich beide unmittelbar oberhalb der Schicht L1 befinden, zwei Schichten L4 und L5, die sich unmittelbar oberhalb der Schichten L2 bzw. L3 befinden, eine "Version" genannte Abstimmungsschicht L6, die sich unmittelbar oberhalb der beiden Schichten L4 und L5 befindet, und Schichten L7 und L8, die sich beide unmittelbar oberhalb der Schicht L6 befinden, aufweist. In der Darstellung sind die Schichten L2 -L6, möglicherweise infolge einer MoveAllChangesDown-Operation von den Schichten L6 zur Schicht L1, leer. Wie in Fig. 7 dargestellt ist, wurden nach der CollapseLayers- Operation die Schichten L2-L6 beseitigt, wurde die "Version" genannte zur Schicht L1 herabgeschoben, und es befinden sich die Schichten L7 und L8 nun beide unmittelbar oberhalb der Schicht L1. Durch die CollapseLayers-Operation werden unwesentliche Schichten entfernt, und es werden weiterhin die Speicheranforderungen des den Pool 702 enthaltenden Behälters verringert.
Vorzugsweise werden Operationen in der Art von MoveAll- ChangesDown und. CollapseLayers erleichtert, indem jeder Blop ein Blop-Identifizierer zugewiesen wird und sichergestellt wird, daß jede Blop in höchstens einer Schicht in dem Pool "konkret dargestellt" ist. Verschiedene Versionen derselben Blop weisen den gleichen Blop-Identifizierer auf, es tritt jedoch nicht auf, daß zwei Blops in einem Pool, die den gleichen Blop-Identifizierer aufweisen, in derselben Schicht in dem Pool konkret dargestellt sind.
Weiterhin können sich Blops, entweder auf der Blop-Ebene oder der Wertebene, indirekt auf andere Blops beziehen. Indirekt angesprochene Blops können sich in demselben oder verschiedenen Pools befinden, und sie können in demselben oder anderen Behältern angeordnet sein.
Zahlreiche andere Merkmale der Erfindung unter Einschluß verschiedener Merkmale der Datenstruktur und verschiedener. Verfahren zum Unterhalten der Datenstruktur oder der darin gespeicherten Daten werden beim Lesen der weiter unten angeführten detaillierten Beschreibung leicht verständlich werden.

BESCHREIBUNG DER ZEICHNUNG

Die Erfindung wird mit Bezug auf spezielle Ausführungsformen beschrieben, und es wird auf die Zeichnung verwiesen, wobei:
die Fig. 1-4 und 9 logische Beziehungen zwischen Schichten in einem oder mehreren Pools symbolisch darstellen;
die Fig. 5-7, 10 und 11 Operationen symbolisch darstellen, die an Schichten in einem Pool ausgeführt werden können;
Fig. 8 die logische Organisation einer Blop darstellt;
Fig. 12 die Struktur eines Plattenbehälters darstellt;
Fig. 13 dies Strüktür eines Segments darstellt;
Fig. 14 die Struktur eines Pool-Namensindex aus Fig. 12 darstellt;
die Fig. 16a und 16b die Struktur einer Schichtmatrix aus Fig. 15 darstellen;
Fig. 17 die Struktur eines Schichtnamenindex aus Fig. 15 darstellt;
Fig. 18 die Struktur einer Schichtsammlung aus Fig. 15 darstellt;
Fig. 19 die Struktur eines Blop-Kennungs-Zuordnungsmittels aus Fig. 15 darstellt;
Fig. 20 die Struktur eines Schichtsegments aus Fig. 12 darstellt;
Fig. 21 die Struktur einer Blop eines zusammengesetzten Typs darstellt;
in den Fig. 22A, 23A und 24A eine Sichtbarkeitsliste aus Fig. 20 für in den Fig. 22B, 23B bzw. 24B symbolisch dargestellte Schichtbeziehungen dargestellt ist;
die Fig. 25 und 26 die Struktur von Merkmalsdatenblöcken darstellen;
die Fig. 27, 28, 29A, 29B und 29C die Struktur von Datendatenblöcken darstellen und
Fig. 30 die Struktur eines Wegstapels darstellt.

DETAILLIERTE BESCHREIBUNG

Die hier beschriebene Ausführungsform der Erfindung stellt eine Speicherverwaltungseinrichtung und die ihr zugeordneten Datenstrukturen dar. Die Strukturen werden zuerst mit Bezug auf ihre logische Organisation und nachfolgend auf ihre gegenständliche Organisation in der von der Speicherverwaltungseinrichtung verwalteten Speichervorrichtung beschrieben. Das heißt, daß sie zuerst mit Bezug auf die Ansicht, die die Software der Speicherverwaltungseinrichtung einem Anwendungsprogrammierer über eine Anwenderprogammschnittstelle (API) bietet, und nachfolgend mit Bezug auf die Art, in der die logische Organisation bei der vorliegenden Ausführungsform tatsächlich implementiert ist, beschrieben werden. Wenngleich zahlreiche Vorteile der vorliegenden Erfindung von der logischen Organisation herrühren, wird es offensichtlich sein, daß diese logische Organisation bestimmte gegenständliche Strukturen einschließt, die erforderlich sind, um den bildlichen Eindruck, so wie ihn der Anwendungsentwickler sieht, zu erhalten. Die nachfolgend beschriebene gegenständliche Organisation beinhaltet zahlreiche Erscheinungsformen der Erfindung, sie ist jedoch keinesfalls die einzige gegenständliche Struktur, die die dem Anwendungsentwickler dargebotene logische Organisation unterstützen kann.
Es sei einleitend bemerkt, daß die Begriffe "Behälter", "Pool", "Schicht" und "Blop" in der hier verwendeten Bedeutung lediglich Namen für Datenverbände sind. Die Namen sindw zur bequemen Beschreibung der vorliegenden Erfindung gewählt, der Leser sollte jedoch keine Attribute aus ihren Definitionen bei der vorliegenden Ausführungsform in ihre Definitionen für die Zwecke der Gesamterfindung übertragen. In ähnlicher Weise stellen die Begriffe "Merkmal" und "Typ" lediglich Interpretationen von Daten dar. Der Leser sollte keine Attribute aus ihren Interpretationen bei der vorliegenden Ausführungsform in ihre Definitionen für die Zwecke der Gesamterfindung übertragen.

I. LOGISCHE ORGANISATION VON DATEN

Die grundlegende permanente Speichereinheit in der Speicherverwaltungseinrichtung ist eine Blop. Wie in Fig. 8 dargestellt ist, beinhaltet eine Blop einen Satz als Merkmale bezeichneter ungeordneter Attribute. Jedes Merkmal weist eine Sequenz von Werten auf, die von 1 bis n indexiert sind. Jeder Wert ist von einem gegebenen Typ, und mehrere Werte mit dem gleichen Merkmal können den gleichen Typ haben. Der Typ eines Werts ist nicht auf seinen Index bezogen. Jeder Wert besteht aus eines Bytesequenz mit veränderlicher Länge.
Ein Merkmal definiert eine Rolle für einen Wert. Merkmale ähneln Feldnamen in einem Datenbank-Datensatz, wobei sie jedoch einer Blop frei hinzugefügt werden können, und ihre Namen sind innerhalb ihres eigenen Pools eindeutig, so daß Anwendungen sie verstehen können. Die in einer Blop gespeicherten Daten treten in den Werten auf. Werte können eine feste oder eine veränderliche Länge aufweisen. Der Typ eines Werts beschreibt das Format dieses Werts. Typen erfassen die Struktur eines Werts und geben an, ob er komprimiert oder verschlüsselt ist, und dergleichen. Typen verwenden denselben Namensraum wie Merkmale und sind demgemäß auch innerhalb ihres eigenen Pools eindeutig. Typen können Grundtypen, wie "str" oder "long" sein, oder sie können zusammengesetzte Typen sein, wobei sie in diesem Fall weiter in einen Satz von Untermerkmalen und mit einem Typ versehenen Werten eingeteilt sind. Zusammengesetzte Typen können verschachtelt sein.
Wenngleich Blops verwendet werden, um die Informationen innerhalb eines Pools aufzunehmen, ist es häufig nützlich, Informationen über die Informationen zu erhalten, um Anwendungen dabei zu unterstützen, die Daten zu interpretieren. In der Speicherverwaltungseinrichtung werden solche Metainformationen in Metainformations-Blops ("Meta Information Blops") gehalten, die Typen und Merkmalsnamen zugeordnet sind. Jeder Typ und jeder Merkmalsname, der innerhalb eines Pools verwendet wird, weist eine zugeordnete Blop auf, die verwendet werden kann, um zusätzliche Informationen darüber zu speichern, wie der Typ bzw. das Merkmal angesteuert und verwendet werden sollte. Beispielsweise können Typen zugeordnete Metainformations-Blops ein Merkmal enthalten, das die Handhabungsmittel ("Handlers") (also dynamisch geladene Routinen) definiert, um das Lesen und Schreiben von Werten dieses Typs aufzurufen.
Abgesehen davon, daß sie speziellen Bestandteilen der Speicherverwaltungseinrichtung zugeordnet sind, sind Metainformations-Blops normale Blops, und sie werden ebenso angesteuert wie Daten-Blops. Der einzige andere Unterschied besteht darin, daß die Speicherverwaltungseinrichtung die Verwendung einiger Merkmale in Metainformations-Blops definiert, wenngleich sie nicht die Interpretation jeglicher Merkmale in gewöhnlichen Blops definiert. Insbesondere gibt das "Lese-Schreib-Handhabungsmittel ("ReadWrite Handler")"- Merkmal den Namen des Lese-Schreib-Handhabungsmittels an, und das "Überklassen ("Superclass")"-Merkmal gibt an, welcher andere Typ, falls überhaupt, seine Überklasse ist.
Blops können sich auf andere Blops beziehen. Diese Bezüge sind in die Werte einer Blop als Blop-Kennungen ("Blop Ids"), 32-Bit-Zahlen, eingebettet, die innerhalb des sie innehabenden Pools eindeutig sind. Die Blops, auf die verwiesen wurde, können in demselben oder einem anderen Pool und in demselben oder einem anderen Behälter liegen.
Die Speicherverwaltungseinrichtung unterstützt zwei Arten eines indirekten Bezugs. Bei einer Form kann eine Blop automatisch auf eine andere Blop zurückgeführt werden. Es erscheint so, daß die Merkmale und Werte der Blop, auf die verwiesen wurde, innerhalb der lokalen Blop liegen. In der anderen Form kann ein einzelner Wert in einer Blop indirekt auf einen Wert in einer anderen Blop bezogen sein. Wenn auf den lokalen Wert zugegriffen wird, wird tatsächlich der Wert, auf den verwiesen wurde, zurückgegeben. Der indirekte Wert kann einfach ein Teil des Werts, auf den verwiesen wurde, sein, und er kann in der Art eines zeilenweise verschobenen Fensters entlang dem Wert, auf den verwiesen wurde, verschoben werden.
Behälter verweisen auf den physikalischen Ort, an dem Daten gespeichert sind. Dateibehälter ("File Containers") sind normalerweise Macintosh-HFS-Datengabeln ("Macintosh HFS Data Forks") oder Betriebsmittelgabeln ("Resource Forks"). Speicherbehälter ("Memory Containers") sind im Speicher vorhandene Strukturelemente, die Pöools in einer gegebenen Haldenzone halten. ROM-Behälter ("ROM Containers") ermöglichen in den ROM eingebrannte Behälter. Abfallbehälter ("Scrap Containers") werden verwendet, um Strukturen der Speicherverwaltungseinrichtung zum Ablagespeicher von MacIntosh ("MacIntosh Clipboard") weiterzuleiten.
Ein Behälter kann eine beliebige Anzahl von Pools enthalten, und es kann auf jeden Pool innerhalb eines Behälters unabhängig von den anderen zugegriffen werden. Die Speicherverwaltungseinrichtung unterstützt zwei Standardbehälterformate, nämlich das Aktualisieren-am-Ort-Format ("Update- In-Place Format") (UIP-Format) und das Aktualisieren-durch- Anhängen-Format ("Update-By-Append Format") (UBA-Format). UIP-Behälter sind für Direktzugriffs-Dateivorrichtungen optimiert. UBA-Behälter sind für das serielle Schreiben optimiert, wobei die Änderungen an das Ende angehängt werden und direkt gelesen werden. Sie können entweder eine Dateivorrichtung oder einen Speicherbereich verwenden. Dateibehälter können das UIP- oder das UBA-Format verwenden. ROM- und Abfallbehälter verwenden gewöhnlich das UBA-Format. Diese Formate sind durch ein dynamisch verknüpftes und geladenes Behälterhandhabungsmittel, das bei der Erzeugung des Behälters spezifiziert wird, implizit festgelegt. Dieses Handhabungsmittel definiert das verwendete Format sowie die Art der Medien.
Es ist ersichtlich, daß die von der Speicherverwaltungseinrichtung verwaltete Datenspeichervorrichtung kein permanenter Speicher zu sein braucht und daß sie mehrere verschiedene Medien beinhalten kann. Der Begriff "Datenspeichervorrichtung" enthält keine Angabe darüber, wie die von der Speicherverwaltungseinrichtung verwalteten Daten zwischen den verschiedenen Medien aufgeteilt sind. Selbst die "Behälter" der vorliegenden Ausführungsform, die für das Anwenderprogramm so erscheinen, als ob sie vollständig auf einem bestimmten Speichermedium vorhanden wären, können während der Ausführung tatsächlich teilweise auf einem solchen Speichermedium und teilweise im Hauptspeicher existieren. Weiterhin können verschiedene Teile der Datenspeichervorrichtung entnehmbare Datenspeichermedien in der Art von Disketten enthalten.
Pools sind im einfachsten Fall (bei Nichtbeachtung von Schichten, Delta-Pools und trennbaren Pools, die später beschrieben werden) Ansammlungen verwandter Blops. Jede Blop existiert in genau einem "Ausgangs-Pool" (außer bei Delta- Pools). Pools sind in Behältern gespeichert. Jedem Pool muß ein Name gegeben werden, der innerhalb des Behälters, in dem er gespeichert ist, eindeutig ist und der verwendet wird, um diesen Pool innerhalb des Behälters zu identifizieren. Pools im Speicher sind flüchtig, und es wird keine Anstrengung unternommen, um ihren Inhalt über die Lebensdauer der Anwendung hinaus, die sie erzeugt hat, zu bewahren, während Pools in Dateien permanent sind. Pools in Speicherbehältern ist automatisch eine Datei auf der Platte gegeben, die als ein Zusatzspeicher verwendbar ist, der Zweck des Zusatzspeichers besteht jedoch lediglich darin, den Umfang der Blops, die in dem Pool gespeichert werden können, zu vergrößern (da sich nicht alle Blops zu einem Zeitpunkt im physikalischen Speicher befinden müssen). Die Speicherverwaltungseinrichtung ermöglicht unabhängig davon, ob eine Seitenwechsel-Hardware vorhanden ist, eine Virtualisierung von Blops. Falls eine Seitenwechsel-Hardware vorhanden ist wird sie von der Speicherverwaltungseinrichtung in vorteilhaftester Weise verwendet. In jedem Pool kann sich eine beliebige Anzahl hervorgehobener Blops befinden, die als permanent markiert sind. Alle Blops in dem Pool müssen entweder permanent markiert sein, oder es muß durch eine permanente Blop vorübergehend auf sie verwiesen werden. Falls mit anderen Worten alle eingebetteten Blop-Kennungen ("Embedded Blop Ids") in allen permanenten Blop-Werten und dann alle eingebetteten Blop-Kennungen in diesen Blop-Werten usw. verfolgt werden müßten, müßten schließlich alle Blops in dem Pool erreicht werden. Alle Blops, die so nicht erreicht werden können, werden aus dem Pool beseitigt. Dies wird als Blop- Abfallsammlung bezeichnet.
Es ist möglich, daß Pools nicht einfach einen Satz von Blops enthalten, sondern sie können auch mehrere Versionen von jeder dieser Blops enthalten. Verschiedene Versionen einer Blop sind implizit durch den Behälter, den Pool und die Schicht bezeichnet, worin sie konkret dargestellt sind.
Schichten sind der Mechanismus der Speicherverwaltungseinrichtung, der dazu dient, es zu beeinflussen, welche Versionen welcher Blops zu einem gegebenen Zeitpunkt zu verwenden sind. Jede Schicht in einem Pool definiert eine Untergruppe der Blops in dem Pool, die für diese Schicht sichtbar sind, und die Schicht definiert für jede dieser Blops, welche Version der Blop erscheinen soll. Es wird demgemäß gesagt, daß einer Schicht eine "Ansicht" der Blops in dem Pool zugeordnet ist. Jede Anwendung, die auf einen Pool zugreift, muß zuerst angeben, welche Schicht in diesem Pool sie bearbeitet, bevor sie damit beginnen kann, auf irgendwelche der darin liegenden Blops zuzugreifen. Der Parameter, den das Anwenderprogramm verwendet, um eine solche Schicht anzugeben, ist eine hier als CPL-Zugriffsmittel ("CPL-Accessor") bezeichnete vordefinierte Datenstruktur. Er beschreibt vollständig den zum Zugreifen auf eine Gruppe von Blops erforderlichen Zusammenhang. Er definiert einen Behälter, einen Pool- und einen Schichtzusammenhang. Wenn der CPL-Zugriffsmittel-Zusammenhang gegeben ist, kann auf Blops ohne Bezug auf andere Schichten, Pools oder Behälter zugegriffen werden.
Schichten sind nicht völlig formatfrei, sondern sie sind als ein azyklischer Digraph aufgebaut, wobei jede Schicht von einer Anzahl anderer "Grundschichten" "abgeleitet" ist, und wobei eine Anzahl anderer Schichten davon abgeleitet ist. Jeder Pool weist eine einzige "Bodenschicht" auf, von der alle anderen Schichten in dem Pool transitiv abgeleitet sind. Diese "Bodenschicht" wird bei der Erzeugung des Pools erzeugt, und sie kann nicht gelöscht werden. Der Inhalt jeder Schicht beruht auf dem Inhalt der Schichten, von denen sie abgeleitet ist, wobei dies nicht gilt, wenn in dieser Schicht ausdrücklich Änderungen vorgenommen wurden. Solche Änderungen können überschriebene Blops, hinzugefügte Blops, gelöschte Blops und sogar Änderungen an der Permanentheitsmarkierung einer Blop umfassen.
Es wird hier manchmal ausgesagt, daß sich Schichten "oberhalb" oder "unterhalb" anderer Schichten befinden. Dies beinhaltet keine Höhenbeziehung, sondern vielmehr lediglich ein komplementäres Paar von Beziehungen zwischen Schichten. Das heißt, daß sich die Schicht B unterhalb der Schicht A befindet, falls sich die Schicht A oberhalb der Schicht B befindet. Die von den Begriffen "oberhalb" und "unterhalb" eingeschlossene Beziehung ist jedoch physikalisch, da die Beziehung irgendwo gespeichert oder verfügbar sein muß (beispielsweise in einer Topologiematrix), so daß eindeutig festgestellt werden kann, ob sich eine Schicht oberhalb oder unterhalb einer anderen Schicht befindet oder ob beides nicht der Fall ist. Die Begriffe "oberhalb" und "unterhalb" sind auch dafür vorgesehen, transitiv interpretiert zu werden. Falls sich die Schicht A beispielsweise oberhalb der Schicht B befindet, die sich oberhalb der Schicht C befindet, dann befindet sich die Schicht A auch oberhalb der Schicht C. Wenn die Transitivität hier nicht beabsichtigt ist, wird gesagt, daß sich eine Schicht "unmittelbar oberhalb" oder "unmittelbar unterhalb" einer anderen Schicht befindet.
Schichten können durch Schichtnamen ("Layer Names") identifiziert werden. Es gibt keine praktische Grenze für die Anzahl der Schichtnamen, die einer Schicht zugeordnet sein können, ein jeder Name kann jedoch für höchstens eine Schicht in einem gegebenen Pool verwendet werden. Es ist auch möglich, daß einer Schicht keine Namen zugeordnet sind. Schichtnamen werden in der Speicherverwaltungseinrichtung auf zwei Arten verwendet: sie werden erstens verwendet, um bestimmte Schichten in einem Pool zu finden. Wenngleich es beispielsweise in jedem Pool eine eindeutige "Bodenschicht" gibt, kann es viele "obere" Schichten geben, die nicht unterhalb einer anderen Schicht liegen. Falls eine Anwendung eine einzige identifizierbare "obere" Schicht benötigt, kann sie einen Schichtnamen verwenden, um sie anzugeben und zu finden. Die zweite Art, in der Schichtnamen in der Speicherverwaltungseinrichtung verwendet werden, besteht darin, unteilbare Transaktionen zwischen Schichten zu markieren. Diese Anwendung wird durch Aufrufe der Speicherverwaltungseinrichtung aktiviert, bei denen es zum Festlegen des Namens einer Schicht erforderlich ist, daß die aufrufende Stelle auch die Schicht angibt, die diesen Namen zuvor hatte (falls überhaupt). Die Routine der Speicherverwaltungseinrichtung sieht demgemäß ein atomares Prüfen und Festlegen vor. Hierdurch wird garantiert, daß eine andere Anwendung den Ort eines Schichtnamens nicht unerwartet geändert hat.
Fig. 9 ist ein Diagramm, das angibt, wie die Schichten in einem Pool 902 aussehen könnten. Die "Bodenschicht" 904 des Pools hat zwei Namen, nämlich "L1" und "Boden", und es gibt in ihr drei Blops, nämlich A, B und C. Die Blop A ist als eine permanente Blop für den Pool in dieser Schicht markiert (im Diagramm durch fette Buchstaben bezeichnet). Unmittelbar oberhalb der Schicht L1 befindet sich eine Schicht 906, nämlich L2. In L2 wurde die Blop A zu ihrer zweiten Version geändert, die Versionen von B und C sind jedoch ungeändert, so daß die Version, die sie in L1 hatten, noch sichtbar ist (in dem Diagramm durch die gestrichelte Begrenzung angegeben). Unmittelbar oberhalb der Schicht L2 befinden sich zwei Schichten 908 und 910, nämlich L3 und L5. L3 ändert wiederum die Blop A, sie ändert jedoch auch die Blop C und fügt die Blop D hinzu. Die Blop B ist ungeändert, so daß die Version aus der Schicht L1 noch sichtbar ist. In der Schicht L5 sind die Blops A, B und C gelöscht, sind die Blops F und G hinzugefügt und ist F als eine permanente Blop markiert. Demgemäß ist die Ansicht des Pools in L5 von derjenigen in L2, von der sie abgeleitet ist, vollständig getrennt. Die Schicht L6 ist von L5 abgeleitet, es wurden jedoch in L6 noch keine Änderungen vorgenommen, so daß sie als eine leere Schicht bezeichnet werden kann.
Abstimmungsschichten sind oben mit Bezug auf Fig. 3 beschrieben.
Eine von der Speicherverwaltungseinrichtung beim Handhaben von Blops in Schichten beachtete Regel besteht darin, daß es unzulässig ist, eine Blop in einer Schicht so zu ändern, daß das geändert wird, was in einer anderen Schicht gesehen wird, die nicht direkt an der Operation beteiligt ist. Falls sich die aktuelle Schicht beispielsweise unterhalb einer, anderen Schicht befindet, ist es unzulässig, jegliche Blops in der aktuellen Schicht zu erzeugen oder zu ändern, da hierdurch unerlaubt das geändert werden würde, was in der nächsten Schicht gesehen wird. Demgemäß sind die Schichten L1, L2 und L3 in Fig. 3 im wesentlichen Nurleseschichten.
Falls eine direkte Manipulation von Blops in Schichten der einzige Weg zum Ändern von Blops wäre, wären die unteren Schichten in einem Pool als bloße Archive nützlich. Dies ist jedoch nicht der Fall. Die Speicherverwaltungseinrichtung sieht einige Operationen vor, die einige Schichten umfassen, und da diese Operationen mehrere Schichten "direkt betreffen", wird es möglich, in Grundschichten Änderungen vorzunehmen, solange die Anwendung alle Schichten, die von dieser Grundschicht abgeleitet sind, erfolgreich einschließen kann. Eine solche Operation ist SMMoveAllChangesDown, die es ermöglicht, die in einer Schicht auftretenden Änderungen in Schichten herabzuschieben, die sich unterhalb von ihr befinden. Wie oben mit Bezug auf Fig. 6 beschrieben wurde, veranlaßt SMMoveAllChangesDown von der Schicht A zur Schicht B, daß die Schicht B die gleiche Ansicht der Blops hat wie die Schicht A, und sie veranlaßt, daß alle Schichten oberhalb von B bis zu A leer sind, so daß sie alle die gleiche Ansicht haben.
Es sei bemerkt, daß die Ansicht der Blops in L3 in der Darstellung von Fig. 6 durch diese Operation ungeändert ist Dies ist für SMMoveAllChangesDown immer der Fall, und die Ansicht der Schicht, von der kopiert wird, wird nie geändert. Die Ansichten der Schichten unterhalb von ihr bis zu der Schicht herab, zu der kopiert wird, werden geändert, so daß die Regel für das Manipulieren von. Blops in Schichten aufgerufen wird. Bei Anwendung dieser Regel verschiebt die Routine SMMoveAllChangesDown keine Änderungen von der Schicht A zur Schicht B herab, falls es irgendwelche Schichten gibt, die sich transitiv oberhalb von B befinden und die sich nicht transitiv unterhalb von A oder transitiv oberhalb von A befinden.
Die Operation dieser Regel ist in Fig. 10 klarer dargestellt. Wie in Fig. 10 dargestellt ist, ist es bei einem Pool 1002 annehmbar, SMMoveAllChangesDown von L6 nach L1 auszuführen, da sich L2-L5 alle (transitiv) oberhalb von L1 und (transitiv) unterhalb von L6 befinden und da die Operation die Ansicht von L6, L7 und L8 nicht ändert. Es ist bei einem Pool 1004 jedoch nicht annehmbar, da sich L9 oberhalb von L1, jedoch nicht unterhalb von L6 befindet. Bei der Anwendung der oben erwähnten Regel würde die Operation die Ansicht von L9 ändern (durch Ändern von L3 und L1), L9 ist jedoch bei der Operation nicht direkt betroffen. Demgemäß verbietet die SMMoveAllChangesDown-Routine die Operation.
Eine weitere Operation der Speicherverwaltungseinrichtung, die Schichten überspannt, ist die Operation, die durch Aufrufen von SMCleanUp mit einem kSMCCollapseLayers-Parametercode (nachfolgend einfach als CollapseLayers bezeichnet) angerufen wird, welche verwendet wird, um unnötige leere Schichten in einem Teil eines Schichtgraphen zu beseitigen. Die Bodenschichten von Pools werden nicht beseitigt. Wie anhand der vorherigen Beispiele ersichtlich ist, besteht das Ergebnis einer SMMoveAllChangesDown-Routine häufig in einer Gruppe leerer Schichten, die keinen Einfluß darauf haben, was von anderen Schichten gesehen wird. CollapseLayers wird verwendet, um Schichten zu beseitigen. Insbesondere beseitigt CollapseLayers von der Schicht A zur Schicht B alle leeren Schichten, die sich (transitiv) oberhalb von B und (transitiv) unterhalb von A befinden, wobei dies die Schicht A einschließt, falls sie leer ist. Jegliche Namen oder nicht leere Schichten, die sich oberhalb der Schichten befinden, die beseitigt wurden, werden zur obersten nicht leeren Schicht herabgeschoben, die sich unterhalb der beseitigten Schicht befindet. Ein Beispiel einer CollapseLayers-Operation ist in Fig. 7 dargestellt und wurde oben beschrieben.
Der einzige Fall, in dem CollapseLayers keine leere Schicht beseitigt, ist dann gegeben, wenn hierdurch erzwun gen werden würde, einen Namen für mehr als eine Schicht zu verwenden. Beispielsweise befindet sich die leere Schicht L6 in dem Diagramm aus Fig. 11 unmittelbar oberhalb jeweiliger nicht leerer Schichten L2 und L3. Da es mit Ausnahme von L6 keine Schicht gibt, für die der Name "Version" verwendet werden könnte, und die zur gleichen Ansicht von Blöcken führen könnte, kann L6 nicht beseitigt werden. Das Ergebnis von CollapseLayers ist daher so, wie in Fig. 11 dargestellt ist: die leeren Schichten L4 und L5 wurden beseitigt, die leere Schicht L6 bleibt jedoch unmittelbar oberhalb der Schichten L2 und L3.
Delta-Pools werden auch durch die hier beschriebene Speicherverwaltungseinrichtung unterstützt. Im wesentlichen ermöglichen es Delta-Pools mehreren Pools, möglicherweise auf verschiedenen Medien, sich so zu verhalten, als ob sie ein einziger großer Pool wären. Bei einem Delta-Pool ist die Bodenschicht des Pools tatsächlich von Schichten in einem zweiten "Grund-Pool" abgeleitet. Demgemäß wirken die Schichten in dem Delta-Pool als eine Fortsetzung des Schichtgraphen in dem "Grund-Pool". Es sei bemerkt, daß hierdurch die oben gemachte Aussage modifiziert wird, daß Blops in genau einem Pool auftreten. Tatsächlich kann eine Blop in mehreren Pools auftreten, solange sie Teil desselben Delta- Pool-Graphen sind. (Es sei bemerkt, daß die verschiedenen konkreten Darstellungen der Blop weiterhin verschiedene "Versionen" der Blop definieren.) In der oben beschriebenen Fig. 4 ist ein Beispiel davon dargestellt, wie die Schichten in einem Delta-Pool und seine Basis aufeinander bezogen sein könnten. Wie oben beschrieben wurde, kann mit einem gegebenen Grund-Pool eine beliebige Anzahl von Pools verbunden sein. Ein Delta-Pool kann mit nur einem Grund-Pool verbunden sein, und seine Bodenschicht ist von einer Schicht im Grund- Pool abgeleitet. Ein Versuch, auf einen Delta-Pool zuzugreifen, führt zu einem Versuch, ihn wieder mit seiner Basis zu verbinden. Falls die Basis nicht geändert wurde, seit der Delta-Pool zum letzten Mal verbunden wurde, kann der Delta- Pool verwendet werden. Falls sich der Grund-Pool geändert hat, tritt eine Ausnahme auf, und er muß unter Verwendung von SMReconnectPool manuell wiederverbunden werden.
Wenn ein Delta-Pool wiederverbunden wird, ist es möglicherweise erforderlich, daß eine Abstimmung infolge der Änderungen in der Basis auftritt. Eine Abstimmung von Delta- Pools wird von einem Abstimmungs-Handhabungsmittel ("Reconciliation Handler") vorgenommen, das als Teil der Speicherverwaltungseinrichtung bereitgestellt ist, das jedoch durch ein anwendungsspezifisches Handhabungsmittel ersetzt werden kann.
Trennbare Pools werden auch durch die hier beschriebene Speicherverwaltungseinrichtung - unterstützt. Trennbare Pools ähneln sehr Delta-Pools, sie weisen jedoch einige zusätzliche Funktionen auf. Trennbare Pools werden verwendet, um eine Schicht eines Dokuments von einer Arbeitsgruppenumgebung zu trennen. Im allgemeinen werden alle sichtbaren Blops von einer ausgewählten Grundschicht in die Bodenschicht eines neu erzeugten trennbaren Pools heraufkopiert. Dieser Pool tritt gewöhnlich in einem getrennten Behälter auf und kann geöffnet/angesteuert werden, ohne daß der ursprüngliche Pool/Behälter verfügbar ist. Nachdem Änderungen ausgeführt wurden, kann der trennbare Pool reintegriert werden, und die Änderungen des Benutzers können mit dem von anderen Mitarbeitern der Arbeitsgruppe geändertens Grund-Pool abgestimmt werden.
Wenn ein trennbarer Pool reintegriert wird, muß sehr wahrscheinlich eine Abstimmung infolge von Änderungen am Grund-Pool und am trennbaren Pool vorgenommen werden. Eine Abstimmung von trennbaren Pools wird von einem bereitgestellten Abstimmungs-Handhabungsmittel ausgeführt, das durch ein anwendungsspezifisches Handhabungsmittel ersetzt werden kann.
Zusätzlich zu dem oben genannten kann eine Ausführungsform einer Speicherverwaltungseinrichtung auch Merkmalsprototypen ("Property Prototypes") unterstützen, um die Erzeugung von Prototypen von Merkmalen und ihren Werten zu ermöglichen. Nach der konkreten Darstellung eines Merkmals mit einem Merkmalsprototyp würden die Anfangswerte entsprechend dem Prototyp festgelegt werden. Merkmalsprototypen können bei minimaler Redundanz der. Struktur durch mehrere konkrete Darstellungen der Merkmale verwendet werden.
Eine Speicherverwaltungseinrichtung kann auch Transaktionen unterstützen, die dann gestartet, selektiv abgebrochen oder zugewiesen werden können. Diese Aufrufe erweitern die Garantie der Unteilbarkeit von einzelnen Schichtmanipulationsaufrufen auf mehrere Aufrufe, wie beispielsweise SMMoveAllChangesDown bei mehreren getrennten Pools.

II. ROUTINEN der Speicherverwaltungseinrichtung

Die oben beschriebene logische Datenstruktur bietet selbst viele Vorteile gegenüber früheren Strukturen zum Speichern von Daten in einer Datenspeichervorrichtung. Es werden weiter unten einige Routinen dargelegt, die für sich einzigartig sind und die auch die Verwendung der oben beschriebenen Datenstruktur erleichtern. Die Routinen können als Teil eines Speicherverwaltungseinrichtungs-Produkts vorgesehen sein, wobei die Datenstruktur auf einem individuellen Computersystem dadurch erzeugt wird, daß ein Benutzer diese Routinen ausführt.
Es ist vordem Beschreiben der Routinen nützlich, Definitionen der Sprache C für verschiedene Konstanten und Datentypen darzulegen, die in den Routinen verwendet werden: 1992 Apple Computer Konstanten Datentypen
Zusätzlich zu den oben angegebenen Typdefinitionen sind weiter unten die Typdefinitionen der C-Sprache für ein CPL- Zugriffsmittel und ein BPV-Zugriffsmittel dargelegt:
Es wird vor der Beschreibung der einzelnen Routinen auch nützlich sein, bestimmte Ausführungszeitkonzepte zu verstehen, welche die Routinen verwenden. Insbesondere werden zwei Arten von Zugriffsmitteln verwendet, um die Hierarchien zu verschieben, die die Speicherverwaltungseinrichtung verwaltet. BPV-Zugriffsmittel werden verwendet, um den Kontext einer Blop zu kennzeichnen. Ein BPV-Zugriffsmittel definiert eine aktuelle Blop, ein aktuelles Merkmal und einen aktuellen Wert. CPL-Zugriffsmittel kennzeichnen den Zusammenhang eines Behälters. Ein CPL-Zugriffsmittel definiert einen aktuellen Behälter, einen aktuellen Pool und eine aktuelle Schicht. BPV-Zugriffsmittel sind automatisch Eigentum eines CPL-Zugriffsmittels, das die Schicht definiert, die verwendet wird, um auf die gekennzeichnete Blop zuzugreifen. Diese beiden Zugriffsmittel weisen einige gemeinsame Funktionen auf. Sie können verwendet werden, um alle ihre entsprechenden Zusammenhänge zu wiederholen. Beispielsweise kann ein BPV-Zugriffsmittel alle Merkmale innerhalb einer Blop und alle Werte innerhalb eines Merkmals wiederholen. BPV- und CPL-Zugriffsmittel können auch zu anderen Blops und Behältern umgelenkt werden. Hierdurch ist ermöglicht, daß alle Blops innerhalb einer Schicht erreicht werden.
Zugriffsmittel sind nicht permanent gespeichert. Sie werden von einer Anwendung zum dynamischen Zugreifen auf den von der Speicherverwaltungseinrichtung unterhaltenen Speicherplatz verwendet. Wenn beispielsweise versucht wird, auf einen bestimmten Wert einer Blop zuzugreifen, wird ein BPV- Zugriffsmittel als der Parameter gegeben, der den Wert definiert. Das BPV-Zugriffsmittel definiert den Zusammenhang des zu manipulierenden Werts.
CPL-Zugriffsmittel definieren einen im Speicher vorhandenen Arbeitsplatz. Hierdurch sind die Haldengrössen, Cache- Grössen und dergleichen, wo die Speicherverwaltungseinrichtung BPV-Zugriffsmittel und jegliche andere CPL-Zugriffsmittel-Speicherzuordnungen zuordnet, die für ihre Routinen erforderlich sind, definiert. Es gibt einen vorgegebenen Arbeitsplatz, der bei der. Initialisierung festgelegt werden kann und der von einem CPL-Zugriffsmittel verwendet wird, falls für es kein spezieller Arbeitsplatz definiert ist.
Es wird zusätzlich zu dem oben erwähnten hilfreich sein, zu bemerken, daß es innerhalb der Speicherverwaltungseinrichtung einige Routinen gibt, für die das Durchlaufen eines Satzes von Elementen erforderlich ist. Daher sieht die Speicherverwaltungseinrichtung einen robusten Wiederholungsmechanismus vor, der die Definition von Sätzen von Elementen ermöglicht. Der Wiederholungsmechanismus ist generell und ermöglicht es dem Anwenderprogramm, Sätze zu definieren. Von Routinen der Speicherverwaltungseinrichtung zurückgegebene Wiederholungsmittel sind Augenblickaufnahmen des aktuellen Zustands, und sie können nicht zum indirekten Ändern des Zustands verwendet werden. Beispielsweise gibt SMOwnedBPV- Accessors ein Wiederholungsmittel zurück, das alle BPV- Zugriffsmittel enthält, die zu einem gegebenen CPL-Zugriffsmittel gehören. Das Entfernen von Posten aus dem Wiederholungsmittel hat keine Wirkung auf die BPV-Zugriffsmittel, die Eigentum des CPL-Zugriffsmittels sind, wobei lediglich das Wiederholungsmittel geändert wird.
Die Speicherverwaltungseinrichtung beinhaltet die folgenden Anwenderprogrammschnittstellen-Aufrufe.

A. Initialisierung

void SMInit(SMwSReadWriteInfo *rwInfo);

Initialisiert die Umgebung der Speicherverwaltungseinrichtung und legt die Informationen über den vorgegebenen Arbeitsplatz für die CPL-Zugriffsmittel fest.

B. Blop-Identifizierung

void SMBindBlopName(SMBPVAccessor blop, const SMStructuredName theName);

Bindet den gegebenen Namen an die vom gegebenen Zugriffsmittel gekennzeichnete Blop. Es ist nicht erlaubt, einen Namen an eine Blop zu binden, an die bereits ein Name gebunden ist, und es ist auch nicht erlaubt, ihn an eine Metainformations-Blop zu binden.

void SMUnBindBlopName(SMBPVAccessor layer, const SMStructuredName theName);

Entfernt jegliche Namen, die der Blop innerhalb des Zusammenhangs der gegebenen Schicht zugeordnet sind. Diese Routine ist für Metainformations-Blops nicht gültig.

SMSize SMGetBlopName(SMBPVAccessor blop, SMSize maxSize, SMStructuredName theName),

Gibt, falls vorhanden, den Namen zurück, der der vom gegebenen Zugriffsmittel gekennzeichneten Blop zugeordnet ist. Die zurückgegebene Größe ist die Anzahl der in den Namensparameter kopierten Bytes. Eine Größe von Null gibt an, daß kein Name zugeordnet ist. Das Angeben von kSMUndefined für den Namen bewirkt die Rückgabe der tatsächlichen Länge eines zugeordneten Namens.

SMBPVAccessor SMBPVAccessorFromName(SMBPVAccessor layer, const SMStructuredName theName, SMBPVAccessorKind aKind);

Gibt das Zugriffsmittel zurück, das die Blop kennzeichnet, an die der gegebene Name in der durch das gegebene Zugriffsmittel gekennzeichneten Schicht gebunden ist. Es wird ein neues BPV-Zugriffsmittel der gegebenen Art erzeugt, das die Blop kennzeichnet und dann zurückgegeben wird. Die Blop kann entweder eine normale Blop oder eine Metainformations-Blop sein.

SMBlopId SMGetBlopId(SMBPVAccessor layer, SMBPVAcceesor blop);

Bei einer gegebenen Blop innerhalb einer gegebenen Schicht wird die permanente Blop-Kennung (Blop-Id) zurückgegeben. Diese Kennung kann sicher in weitere Wertedaten der Blop eingebettet sein, wodurch eine permanente Verknüpfung erzeugt ist. Es ist für eine Blop-Kennung erforderlich, daß ein Schichtzusammenhang verwendbar ist, bei einem gegebenen Pool behält eine Blop ihre Kennung jedoch unbegrenzt bei, was bedeutet, daß die Blop innerhalb jeder Schicht in dem Pool die gleiche Kennung hat.

C. BPV-Zugriffsmittel

SMBPVAccessor SMNewBPVAccessor(SMBPVAccessorKind aKind, SMCPLAccessor layer, const SMStructuredName blopName, SMBlopId blopId, const SMStructuredName propertyName, SMValueIndex valueIndex, const SMStructuredName typeName);

Weist Blop-Daten einem Zugriffsmittel zu. Ob an den durch diese Art von Zugriffsmitteln gekennzeichneten Daten Änderungen vorgenommen werden dürfen, beruht auf der Art des erzeugten BPV-Zugriffsmittels ("BPV Accessor Kind"). Alle Parameter mit Ausnahme der Art des BPV-Zugriffsmittels sind wahlfrei, und sie werden verwendet, um den anfänglichen Ort des Zugriffsmittels festzulegen. Um die anfängliche Blop zu definieren, die das Zugriffsmittel bezeichnet, müssen die Schicht und der Blop-Name ("blopName") oder die Schicht und die Blop-Kennung ("blopId") angegebene werden: Namen gehen stets vor. Zum Definieren des anfänglichen Merkmals der anfänglichen Blop muß der Merkmalsname ("propertyName") angegeben werden. Der Anfangswert des anfänglichen Merkmals kann entweder durch den Wertindex ("valuelndex") oder durch den Typ des Werts angegeben werden. Falls er durch den Typ angegeben ist, wird der erste Wertindex mit dem gegebenen Typ gekennzeichnet. Falls irgendwelche Parameter ungültig sind, wie beispielsweise ein ungültiger Blop-Name, tritt eine Ausnahme auf.
Jedes BPV-Zugriffsmittel wird innerhalb des Zusammenhangs eines CPh-Zugriffsmittels erzeugt. Mit anderen Worten besitzt ein CPL-Zugriffsmittel alle unter seiner Verwendung erzeugten BPV-Zugriffsmittel. BPV-Zugriffsmittel können selbst von verschiedenen CPL-Zugriffsmitteln desselben Prozesses nicht gemeinsam verwendet werden.

void SMDisposeBPVAccessor(SMBPVAccessor accessor, SMBoolean commit);

Beseitigt das angegebene BPV-Zugriffsmittel. Jegliche mit einem Lese-Schreib-BPV-Zugriffsmittel ("ReadWrite BPV Accessor") an Blop-Daten vorgenommenen Änderungen werden angewiesen, falls die Anweisung kSMBTrue ist. Falls die Anweisung kSMBFalse ist, werden jegliche an den Blop-Daten vorgenommenen Änderungen verworfen. Die Anweisung wird für Nurlese-BPV-Zugriffsmittel ("ReadOnly BPV Accessors") ignoriert.

void SMTransformBpVAccessor(SMBPVAccessor accessor, SMCPLAccessorKind aKind, SMBoolean commit);

Wandelt ein BPV-Zugriffsmittel von einer Art in eine andere um. Falls von Nurlese nach Lese-Schreib umgewandelt wird, muß das BPV-Zugriffsmittel das einzige Zugriffsmittel sein, das die Blop kennzeichnet. Wenn von Lese-Schreib zu Nurlese umgewandelt wird, werden jegliche Änderungen angewiesen, falls die Anweisung kSMBTrue ist. Falls die Anweisung kSMBFalse ist, werden jegliche an den Blop-Daten vorgenommenen Änderungen verworfen. Die Anweisung wird für eine Umwandlung von Nur-Lesen nach Lesen-Schreiben ignoriert.

SMBPVAccessor SMRetatgetBPVAccessor(SMBPVAccessor accessor, SMAccessorKind aKind, SMBoolean commidt, SMPositionCode blopPosition, SMBoolean namePropertyName, SMBoolean nameValueIndex, SMBoolean nameTypeName, SMCycleCode cycleCode);

Weist ein gegebenes BPV-Zugriffsmittel einer möglicherweise verschiedenen Blop auf der Grundlage des gegebenen Blop-Positionscodes zu. Das gegebene Zugriffsmittel wird neu zugewiesen, falls die gegebene Art des Zugriffsmittels SMUndefined ist, oder es wird ein neues BPV-Zugriffsmittel der gegebenen Art erzeugt und so festgelegt, daß es die angewiesene Blop kennzeichnet. Wenn mit einem Lese-Schreib- BPV-Zugriffsmittel eine Neuzuweisung von einer abhängigen Blop zu einer Stamm-Blop vorgenommen wird, werden die ausgeführten Änderungen auf der Grundlage des gegebenen Anweisungsparameters angewiesen oder verworfen: Der Zykluscode ("cyclecode") bestimmt das Ergebnis des Zuweisens einer Blop, die bereits zuvor mit dem gegebenen BPV-Zugriffsmittel erreicht worden ist. Falls samePropertyName, sameValueIndex oder sameTypeName kSMBTrue sind, versucht das zurückgegebene Zugriffsmittel, dem Namen nach das gleiche Markmal wie das Original und dem Index oder dem Namen nach den gleichen Wert wie das Original festzulegen. Falls der Versuch, das gleiche festgelegte Merkmal oder den gleichen festgelegten Typ beizubehalten, fehlschlägt, ist der entsprechende Teil des zurückgegebenen BPV-Zugriffsmittels undefiniert.
Eingebettete Blop-Kennungen innerhalb eines Werts werden als die aktuellen abhängigen Datensätze einer Blop angesehen. Wenn auf kSMPFirstBelow positioniert wird, ist die erste eingebettete Blop-Kennung innerhalb des aktuellen Werts die angesprochene Blop. Die Blop-Kennung wird innerhalb derselben Schicht wie die aktuelle Blop oder innerhalb derselben Schicht wie die ferne Blop ("Remote Blop"), falls sie eine indirekte Blop ("Indirect Blop") ist, zugeordnet. Das Neuzuweisen zu kSMPFirstAbove oder kSMPLastAbove mit einem solchen Zugriffsmittel würde zu dem Wert zurückführen, der verwendet wurde, um den abhängigen Datensatz zu finden. Wenn ein Neuzuweisen zu kSMPNextSib vorgenommen wird, wird die nächste eingebettete Blop-Kennung des Stammdatensatzes verwendet. Falls die Blop keine Stamm-Blop hat, falls also durch einen Namen auf sie positioniert wurde, positioniert kSMPNextSib auf die nächste Blop, die die Schicht besitzt. Die gültigen Positionscodes sind die folgenden:

Parameter: blopPosition

Gültiger Positionscode Bedeutung

kSMPUndefined setze Blop auf undefiniert
kSMPSame bleibe bei derselben Blop
kSMPFirstSib gehe zur ersten Blop auf derselben Ebene
kSMPLastSib gehe zur letzten Blop auf derselben Ebene
kSMPNextSib gehe zur nächsten Blop auf derselben Ebene
kSMPPrevSib gehe zur vorhergehenden Blop auf derselben Ebene
kSMPFirstBelow gehe zum ersten abhängigen Datensatz der Blop
kSMPLastBelow gehe zum letzten abhängigen Datensatz der Blop
kSMPFirstAbove gehe zur Stamm-Blop (ebenso wie kSMPLastAbove)
kSMPLastAbove gehe zur Stamm-Blop (ebenso wie kSMPFirstAbove)
kSMPMWrap lasse Umlaufen zu
kSMPMNoTypes überspringe Typ-Metainformations-Blops
kSMPMNoProperties überspringe Merkmals-Metainformations-Blops
kSMPMNoBlops überspringe normale Blops

SMpositionResult SMPositionBPVAccessor(SMBPVAccessor accessor, const SMStructureName propertyliame, SMPositionCode blopPosition, SMValueIndex targetIndex, SMPositionCode indexPosition, SMBoolean nameTypeName);

Positioniert ein gegebenes BPV-Zugriffsmittel innerhalb einer Blop um und gibt den Staus der Positionierung zurück. Der zurückgegebene Wert gibt, falls er positiv ist, an, wie sich der neue Ort des Zugriffsmittels auf den vorhergehenden Ort bezieht, und er gibt, falls er negativ ist, an, inwieweit SMPositionBPVAccessor in der Lage war, mit diesem Prozeß fortzufahren, bevor ein Fehler erkannt wurde. Bei einem Fehler wird das Zugriffsmittel so belassen, daß es auf das Merkmal und den Wert zeigt, die unter den gefundenen den angeforderten am nächsten kommen und den gegebenen Parameter noch erfüllen. Alle Parameter mit Ausnahme des ersten Zugriffsmittels sind wahlfrei, und sie werden verwendet, um den Ort des Zugriffsmittels zurückzusetzen. Falls ein Merk malsname gegeben ist, wird der entsprechende Positionscode ignoriert. Falls ein Wertindex gegeben ist, wird der entsprechende Positionscode ignoriert.
Die Routine positioniert das Merkmal, entweder über den Namen oder bezüglich des aktuellen Merkmals, zuerst. Der Wert wird als nächstes, entweder über den gegebenen Index oder bezüglich des aktuellen Index, positioniert. Das gegebene sameType-Hinweiszeichen versucht, ein Filter auf die Indizes anzuwenden, die zu kennzeichnen sind. Falls sameType kSMBTrue ist, wird beim Positionieren auf den kSMPNextSib-Index dann beispielsweise versucht, auf den nächsten Wertindex zu positionieren, der den gleichen Typ aufweist wie der aktuelle Index. Falls das Merkmals geändert ist und sich der gegebene Index-Positionscode auf den aktuellen bezieht, ist der Wertindex, auf den positioniert wird, der aktuelle Index zuzüglich des Positionscodes. Es sei beispielsweise auf den Wertindex vier eines Merkmals positioniert. Das Merkmal wird durch kSMPNextSib geändert, und der Wertindex wird durch kSMPNextSib geändert. Das Merkmal wird auf das nächste Merkmal der Blop positioniert. Der Index, auf den positioniert wird, ist der Wertindex fünf, falls ein solcher Index innerhalb des nächsten Merkmals auftritt. Falls dies nicht der Fall ist, ist der Wertindex der höchste verfügbare Index, weil dies der nächste wäre, der gefunden werden könnte. Die gültigen Positionscodes für jedes Positionscodeargument sind die folgenden:

Parameter: propPosition

Gültiger Positionscode, Bedeutung

kSMPUndefined setze Merkmal auf undefiniert
kSMPSame bleibe beim selben Merkmal
kSMPFirstSib gehe zum ersten Merkmal
kSMPLastSib gehe zum letzten Merkmal
kSMPNextSib gehe zum nächsten Merkmal
kSMPPrevSib gehe zum vorhergehenden Merkmal
kSMPMWrap lasse Umlaufen zu

Parameter: indexPosition

Gültiger Positionscode Bedeutung

kSMPUndefined setze Index auf undefiniert
kSMPSame bleibe beim selben Index
kSMPFirstSib gehe zum ersten Index
kSMPLastSib gehe zum letzten Index
kSMPNextSib gehe zum nächsten Index
kSMPPrevSib gehe zum vorhergehenden Index
kSMPMWrap lasse Umlaufen zu

SMCount SMCountBPVAcceseor(SMBPVAccessor accessor, SMPositionCode propertyPosition, SMPositionCode indexPosition, SMBoolean nameType);

Gibt an, wie oft das gegebene Zugriffsmittel entsprechend den Parametern vor der Unterbrechung verschoben werden konnte. Der Umlaufpositionscode-Modifizierer ist für einen gegebenen Positionscode nicht zulässig. Die Parameter werden ebenso interpretiert wie bei der SMPositionBPVAccessor- Routine. Es ist bei dieser Routine einfach, die Anzahl der Merkmale in einer Blop, die Anzahl der Werte in einem Merkmal, die Anzahl der Werte eines gegebenen Typs innerhalb eines Merkmals und dergleichen zu bestimmen.

void SMSetPreferredPosition(SMBPVAccessor accessor)

Legt die bevorzugte Position für die durch das gegebene Zugriffsmittel angegebene gegebene Blop fest. Immer dann, wenn ein SMBPVAccessor für diese Blop mit undefinierten Parametern erzeugt wird, wird er automatisch auf diese Stelle positioniert.

SMBPVAccessor SMCloneBPVAccessor(SMBPVAccessor accessor)

Erzeugt eine Kopie des gegebenen BPV-Zugriffsmittels. Es können ausschließlich Nurlese-Zugriffsmittel geklont werden, da es nicht zulässig ist, daß zwei Lese-Schreib-Zugriffsmittel dieselbe Blop ansteuern.

void SMGetBPVAccessorInfo(SMBPVAccessor accessor, SMBPVReadOnlyInfo *roInfo, SMBPVReadWriteInfo *rwInfo);

Gibt die Einzelheiten von dem wieder, was das gegebene BPV-Zugriffsmittel kennzeichnet. kSMUndefined kann in Form von Argumenten zu Parametern übertragen werden, die nicht erwünscht sind. kSMUndefined wird für undefinierte Elemente zurückgegeben.

void SMSetBPVAccessorInfo(SMBPVAccessor accessor, SMBPVReadWriteInfo *rwInfo);

Legt die Einzelheiten der durch das gegebene BPV-Zugriffsmittel gekennzeichneten Blop fest. Der permanente Sollwert in SMBPVReadWriteInfo ist kSMBTrue.

D. Blop-Erzeugung und -Entfernung

SMBPVAccessor SMCreateBlop(SMCPLAccessor layer, SMACCessorKind aKind),

Erzeugt eine neue Blop. Die Blop ist in dem Behälter, dem Pool und der Schicht konkret dargestellt, die von dem gegebenen CPL-Zugriffsmittel gekennzeichnet sind. Ein die neue Blop kennzeichnendes neues BPV-Zugriffsmittel der gegebenen Art wird erzeugt und dann zurückgegeben.

SMBPVAccessor SMCreateMetaInfoBlop(SMCPLAccessor layer, const SMStructuredName theRame, SMMetaInfoKind mKind SMAccessorKind aKind),

Erzeugt eine neue Metainformations-Blop. Die Metainformations-Blop der gegebenen. Metainformationsart ist mit dem gegebenen Namen in dem Behälter, dem Pool und der Schicht konkret dargestellt, die von dem gegebenen CPL-Zugriffsmittel gekennzeichnet sind. Ein die neue Metainformations-Blop kennzeichnendes neues BPV-Zugriffsmittel der gegebenen Art wird erzeugt und dann zurückgegeben.

void SMIndirectBlop(SMBPVAccessor accessor, SMBPVAccessor remoteBlop, SMCPLaccessor remoteLayer, const SMStructuredName remoteBlopName);

Ändert eine bestehende Blop zu einer indirekten Blop ("Indirect Blop"), die in die von einer remoteBlop oder einer remoteLayer/remoteBlopName-Kombination angegebene Blop aufgelöst werden kann. Falls nur remoteBlop bereitgestellt ist, läßt sich die Indirektheits-Blop ("Indirection Blop") durch ihre Kennung zurückführen. Falls remoteLayer und remoteBlopName bereitgestellt sind, wird die Blop durch den Namen zugeordnet. Diese Routine ist sowohl für Metainformations-Blops als auch für normale Blops gültig. Alle bestehenden Merkmale werden aus der localBlop entfernt. Diese Routine ist nur bei einem Lese-Schreib-BPV-Zugriffsmittel gültig.

SMBPVAccessor SMGetIndirectBlopInfo(SMBPVACCessor localBPVAccessor, SMBPVAccessor remoteValue);

Ruft Informationen darüber ab, welcher Blop eine bestimmte, vermutlich indirekte Blop zugeordnet ist. localBPVAccessor identifiziert die mögliche indirekte Blop. remoteValue wird so umpositioniert, daß er sich auf die angesteuerte Blop bezieht, bevor er zurückgegeben wird. Dies ist ein wahlfreier Parameter, und falls er nicht angegeben ist, wird der localBPVAccessor der angesteuerten Blop neu zugewiesen. Falls sich localBPVAccessor nicht auf eine indirekte Blop bezieht, wird remoteValue auf dieselbe Blop positioniert. Diese Routine ist nur bei einem Nurlese-BPV- Zugriffsmittel gültig.

SMBPVAccessor SMCloneBlop(SMCPLAccessor destCPLAccessor, const SMStructuredName destName, SMBPVAccessor sourceBPVAccessor, SMAccessorKind aKind);

Erzeugt eine Kopie der von sourceBPVAccessor angegebenen Blop in der von destCPLAccessot angegebenen Schicht und gibt ein neues BPV-Zugriffsmittel der gegebenen Art zurück, welches sich auf die Kopie bezieht. Falls an die geklonte Blop gegenwärtig ein Name gebunden ist, weist sie den gleichen Namen in destCPLAccessor auf. Ein neuer Name kann durch Ausgeben von destName festgelegt werden. Die sich ergebende neue Blop ist, abgesehen von jeglichen eingebetteten Blop- Kennungen, die sie in ihren Werten enthalten kann, eine exakte Kopie der ursprünglichen Blop. Es ist möglich, daß eingebettete Blop-Kennungen vom Original geändert werden müssen, falls sich die Ausgangs- und die Zielschicht in verschiedenen Pools befinden, und es ist möglich, daß die Routine in der Bestimmungsschicht indirekte Blops erzeugen muß, die auf die Blops zurückzuführen sind, auf die sich die eingebetteten Blop-Kennungen im Original beziehen. Falls die Bestimmungsschicht der ursprünglichen Blop gleicht, die gekennzeichnet werden kann, indem kSMUndefined für destCPLAccessor angegeben wird und die ursprüngliche Blop benannt ist, weist ihr Klon keinen Namen auf, es sei denn, ihm wurde eine gegeben. Diese Routine gilt sowohl für Metainformations-Blops als auch für normale Blops.

void SMRemoveBlop(SMBPVAccessor blop);

Entfernt eine durch das gegebene Zugriffsmittel gekennzeichnete Blop. Das BPV-Zugriffsmittel wird in einem undefinierten Zustand gelassen. Es können bei der gegebenen Blop keine anderen BPV-Zugriffsmittel angesteuert werden.

E. Wertmanipulation

SMBPVAccessor SMCreateValue(SMBPVAccessor blop, const SMStructuredName propertyName, SMValueIndex valueIndex, const SMStructuredName typeName, SMAccessorKind aKind)

Erzeugt einen neuen Wert für die gekennzeichnete Blop des gegebenen Typs im gegebenen Merkmal beim gegebenen Wertindex, propertyName, valuelndex und typeName sind wahlfrei. Falls einer von ihnen kSMUndefined ist, wird das entsprechende Attribut des Werts von dem entsprechenden Attribut des BPV-Zugriffsmittels abgeleitet. In diesem Fall müssen die geeigneten Elemente beim BPV-Zugriffsmittel definiert sein.
Falls propertyName nicht kSMUndefined ist, wird ein neues Merkmal (falls erforderlich) mit dem gegebenen Namen hinzugefügt, das keine Werte enthält. Der neue Wert ist durch seinen Index spezifiziert und ist von dem gegebenen Typ. Indizes sind nicht knapp, so daß der Wertindex, falls er angegeben ist, zwischen eins und einem Wert, der um eins größer ist als der aktuelle letzte Index, liegen muß. Einträge zu neuen Werten überschreiben niemals bestehende Einträge, sie werden bei dem gegebenen Index vor dem Wert eingefügt, und alle anderen Einträge werden um einen Eintrag nach oben geschoben.
Falls kSMUndefined für die Zugriffsmittelart angegeben ist, wird das gegebene Zugriffsmittel so umpositioniert, daß es den neuen Wert kennzeichnet, und dann zurückgegeben. Ansonsten wird ein neues BPV-Zugriffsmittel der gegebenen Art erzeugt und dann zurückgegeben. Dem Wert sind an diesem Punkt keine Daten zugeordnet. Die Wertedaten werden mit SMWriteValueData, SMInsertValueData oder implizit durch SMIndirectValue oder SMCreateContainer (zum Erzeugen eines eingebetteten Behälters) festgelegt.
Die Typ-Metainformations-Blop, auf die sich typeName bezieht, muß vor dem Aufrufen dieser Routine auftreten. Die Merkmals-Metainformations-Blop, auf die sich propertyName bezieht, braucht nicht vor dem Aufrufen dieser Routine aufzutreten. Falls die Merkmals-Metainformations-Blop nicht auftritt, wird automatisch eine erzeugt. In diesem Fall muß propertyName innerhalb des Pools eindeutig sein.

SMSize SMGetValueSize(SMSPVAccessor value);

Die Größe der von dem gegebenen BPV-Zugriffsmittel gekennzeichneten Wertedaten wird zurückgegeben.

void *SMGetReadOnlyValuePtr(SMBPVAccessor value, SMSize *length);

Es wird ein Zeiger auf die von dem gegebenen BPV- Zugriffsmittel gekennzeichneten Wertedaten zurückgegeben. Falls der Längenparameter nicht kSMUndefined ist, wird die Größe der Wertedaten zurückgegeben. Der von dieser Routine zurückgegebene Zeiger ist gültig, bis entweder das gegebene Zugriffsmittel (oder sein Klon) aus der aktuellen Blop entfernt oder umpositioniert wird. Es wird jeder Versuch unternommen, einen Zeiger auf die aktuelle Daten zurückzuführen, um das Kopieren von Daten zu minimieren. Diese Routine ist nur bei einem Nurlese-BPV-Zugriffsmittel gültig.

SMSize SMReadValueData(SMBPVAccessor value, void *buffer, SMSize offset SMSize maxSize);

Die von dem gegebenen BPV-Zugriffsmittel und dem gegebenen Relativzeiger gekennzeichneten Wertedaten werden bis zu maxSize Bytes in den gegebenen Puffer kopiert. Die Länge der tatsächlich kopierten Wertedaten wird zurückgegeben.

void SMWriteValueData(SMBPVAccessor value, value *buffer, SMSize offset, SMSize length);

Die von dem gegebenen BPV-Zugriffsmittel gekennzeichneten Wertedaten werden beginnend beim Relativzeiger vom Beginn des Werts an zu den Daten des gegebenen Puffers umgewandelt. Die Größe des Puffers wird angegeben. Falls der angegebene Puffer kSMUndefined ist, werden die Wertedaten vom Relativzeiger bis zum Relativzeiger zuzüglich der Länge mit Nullen belegt. Diese Routine ist nur bei einem Lese- Schreib-BPV-Zugriffsmittel gültig.

void SMInsertValueData(SMBPVAccessor value, value *buffer, SMSize offset, SMSize length);

Die Daten von dem gegebenen Puffer werden beim Relativzeiger vom Beginn des Werts an in den vom gegebenen BPV- Zugriffsmittel gekennzeichneten Wert eingefügt. Die Größe des Puffers wird angegeben. Falls der angegebene Puffer kSMUndefined ist, werden die Wertedaten vom Relativzeigerwert an bis zum Relativzeigerwert zuzüglich der Länge mit Nullen belegt. Die sich ergebenden Wertedaten werden um Länge Bytes länger sein. Diese Routine ist nur bei einem Lese-Schreib-BPV-Zugriffsmittel gültig.

void SMRemoveValuelData(SMBPVAccessor value, SMSize offset, SMSize length);

Die von dem gegebenen BPV-Zugriffsmittel bezeichneten Wertedaten werden beginnend mit dem gegebenen Relativzeigerwert für Länge Bytes aus dem Wert entfernt. Die sich ergebenden Wertedaten sind um Länge Bytes kürzer. Diese Routine ist nur bei einem Lese-Schreib-BPV-Zugriffsmittel gültig.

void SMRemoveValue(SMBPVAccessor value);

Der von dem gegebenen Zugriffsmittel gekennzeichnete Wert wird aus dem umgebenden Merkmal entfernt. Das Wertattribut des BPV-Zugriffsmittels wird undefiniert gelassen. Nur der letzte Index kann beseitigt werden, da knappe mehrfache Werte nicht zulässig sind. Falls das BPV-Zugriffsmittel auf den dritten Index eines Merkmals mit fünf definierten Indizes positioniert ist und diese Routine ausgeführt wird, wird eine Ausnahme gemacht. Diese Routine ist nur bei einem Lese-Schreib-BPV-Zugriffsmittel gültig.

void SMRemoveProperty(SMBPVAccessor property);

Das Merkmal und alle seine Werte, die von dem gegebenen Zugriffsmittel gekennzeichnet sind, werden entfernt. Die Merkmals- und Wertattribute des BPV-Zugriffsmittels werden undefiniert gelassen. Diese Routine ist nur bei einem Lese- Schreib-BPV-Zugriffsmittel gültig.

void SMCloneProperty(SMBPVAccessor destBlop, SMBPVAccessor sourceProperty);

Macht eine Kopie des von sourceProperty angegebenen Merkmals (einschließlich aller seiner Werte) bei dem durch destBlop angegebenen Ort. Das sich ergebende neue Merkmal ist, mit Ausnahme jeglicher eingebetteten Blop-Kennungen, die es in seinen Werten enthalten kann, eine exakte Kopie des ursprünglichen Merkmals. Eingebettete Blop-Kennungen von dem Original müssen möglicherweise geändert werden, falls die Ausgangs- und die Bestimmungsschicht in verschiedenen Pools liegen, und die Routinemuß möglicherweise indirekte Blops in der Bestimmungsschicht erzeugen, die den Blops zugeordnet sind, auf die sich die eingebetteten Blop-Kennungen im Original beziehen. Jegliche erforderlichen Metainformations-Blops werden ebenfalls für den Bestimmungsort geklont. Diese Routine ist nur bei einem Lese-Schreib- Bestimmungsort-BPV-Zugriffsmittel gültig.

void SMMarkEmbeddedBlopIds(SMBPVAccessor value, SMSize offset, SMCount count, SMBoolean setMark);

Bei den meisten Werten sind die Orte der eingebetteten Blop-Kennungen in den Daten durch den Typ des Werts defi niert. Es ist jedoch für einige Anwendungen der Speicherverwaltungseinrichtung erforderlich, daß die Struktur eines Werts veränderlich ist, und die Orte der eingebetteten Blop- Kennungen sind daher nicht wohldefiniert. In diesen Fällen muß diese Routine verwendet werden, um die Speicherverwaltungseinrichtung darüber zu informieren, wo eingebettete Blop-Kennungen gespeichert sind und wo sie nicht gespeichert sind. Falls setMark kSMBTrue ist, bemerkt diese Routine, daß der Zählwert longwords in dem Wert, auf den sich das BPV- Zugriffsmittel bezieht, beginnend mit dem Relativzeigerwert eingebettete Blop-Kennungen enthält. Falls setMark kSMBFalse ist, bemerkt sie ebenso, daß die angegebenen longwords keine eingebetteten Blop-Kennungen enthalten. Diese Routine ist nur bei einem Lese-Schreib-BPV-Zugriffsmittel gültig.

F. Indirekte Wertzuweisung

void SMIndirectvalue(SMBPVAccessor localValue, SMBPVAccessor remoteValue, SMSize remoteOffset, SMSize remoteLongth);

Ändert einen durch localValue angegebenen bestehenden Wert in einen indirekten Wert, der dem durch remoteValue angegebenen Wert zugeordnet ist (wenigstens einem Teil von diesem). Falls remoteaffset nicht kSMUndefined ist, wird nur auf den Teil des fernen Werts ("remote Value") verwiesen, der beim angegebenen Relativzeigerwert beginnt. Falls remoteLength nicht kSMUndefined ist, wird nur diese Anzahl von Bytes des fernen Werts verwendet. Es werden jegliche bestehende Wertedaten aus dem lokalen Wert entfernt. remoteOffset und remoteLength werden automatisch an das Ende des fernen Werts angehängt. Diese Routine ist nur bei einem Lese-Schreib-BPV-Zugriffsmittel gültig.

void SMGetIndirectValueInfo(SMBPVAccessor localValue, SMBPVAccessor remoteValue, SMSize *remoteOffset, SMSize *remoteLength);

Ruft Informationen darüber ab, welchem Wert ein bestimmter, vermutlich indirekter Wert zugeordnet ist. localValue gibt den möglicherweise indirekten Wert an. remoteValue (falls er nicht kSMUndefined ist), wird so umpositioniert, daß er sich auf den Wert bezieht, dem localValue zugeordnet ist, und remoteaffset und remoteLength (falls sie nicht kSMUndefined sind) werden mit dem geeigneten Relativzeiger und der geeigneten Länge aufgefüllt. Falls sich localValue nicht auf einen indirekten Wert bezieht, wird remoteValue so umpositioniert, daß er sich auf den gleichen Wert wie localValue bezieht, und *remoteOffset und *remoteLength werden auf kSMUndefined gesetzt.

void SMChangeIndirectValue(SMBPVAccessor localValue, SMSize remoteOffsetChange, SMSize remoteLengthChange);

Ein durch localValue angegebener existierender indirekter Wert wird so geändert, daß er einem anderen Bereich seines fernen Werts ("Remote Value") zugeordnet ist. remoteOffsetChange und remoteLengthChange werden zum aktuellen Relativzeigerwert und zur aktuellen Länge des indirekten Werts addiert. Das Fenster des fernen Werts wird automatisch in den Daten des fernen Werts gehalten, der Relativzeigerwert wird daher oberhalb von Null gehalten, und der Relativzeigerwert zuzüglich der Länge erstreckt sich nicht über das Ende des Werts hinaus. Diese Routine ist nur bei einem Lese- Schreib-BPV-Zugriffsmittel gültig.

6. Wertestrom-Ein-/Ausgabe

SMStream SMStreamOpen(SMBPVAccessor value);

Verwendet SMStreamOpen, um den Wert zu öffnen, dessen Ort vom gegebenen BPV-Zugriffsmittel angegeben ist und ordnet ihm einen Strom zu. Der Strom wird im Nurlese- oder Lese-Schreib-Modus abhängig davon, wie das Zugriffsmittel erfaßt wurde, geöffnet. Falls der Wert erfolgreich geöffnet wird, gibt SMStreamapen einen Zeiger auf eine Stromdatenstruktur zurück, die den Strom steuert.

int SMStreamClose(SMStream stream);

Verwendet SMStreamClose, um den Strom zu schließen, der durch "stream" angegeben ist. Falls der Strom zum Schreiben geöffnet war, wird der Inhalt des dem Strom zugeordneten Puffers in den Wert eingeschrieben ("eingeräumt"), bevor der Wert geschlossen wird. Falls er zum Lesen geöffnet war, werden ungelesene Daten im Puffer verworfen.

SMSize SMStreamRead(void *ptr, SMSize size, SMSize count, SMStream strom);

Verwendet SMStreamRead zum Lesen der durch "count" angegebenen Anzahl der Datenposten, wobei jeder eine durch das Argument "size" angegebene Größe aufweist, an der aktuellen Position im Strom "stream". Die aktuelle Position des Stroms wird nach dem Lesen aktualisiert. Die SMStreamRead- Routine gibt die Anzahl der Posten zurück, die sie erfolgreich gelesen hat.

SMSize SMStreamwrite(const void *ptr, SMSize size, SMSize count, SMStream stream);

Verwendet SMStreamWrite zum Schreiben der Anzahl der durch "count" angegebenen Datenposten, wobei jeder eine durch "size" angegebene Größe aufweist, aus dem Puffer an die aktuelle Position im Strom "stream". Die aktuelle Position des Stroms wird nach dem Schreiben aktualisiert. Die SMStreamWrite-Routine gibt die Anzahl der Posten zurück, die sie tatsächlich geschrieben hat.

int SMStreamSeek(SMStream stream, SMSize offset, SMStreamSeekCode origin);

Verwendet die SMStreamSeek Routine, um "stream" auf den Ort umzupositionieren, der durch einen Relativzeiger ("offset") bezüglich des Argumentsursprungs ("origin") angegeben ist. Die SMStreamSeek-Routine gibt nur dann einen von Null verschiedenen Wert zurück, falls sie den Strom nicht positionieren kann.

int SMStreamGetPos(SMStream stream, SMStreamPos pos);

Verwendet SMStreamGetPos, um die aktuelle Positionsangabe des durch das Argument "stream" an der Datenobjektposition SMStreamPos angegebenen Stroms abzurufen und zu speichern. Dieser Wert wird von der begleitenden Routine SMStreamGetPos verwendet, um den Stroms beim Aufrufen von SMStreamGetPos umzupositionieren. Falls sie erfolgreich ist, gibt SMStreamGetPos null zurück. Bei einem Fehler gibt sie einen von Null verschiedenen Wert zurück.

int SMStreamSetPos(SMStream stream, const SMStreamPoe pos);

Verwendet SMStreamSetPos, um die Position festzulegen, wo ein Lesen oder Schreiben im Strom auftritt. Die neue Position wird an einer Datenobjektposition SMStreamPos angegeben. Zur Wertepositionierung wird der durch einen früheren Aufruf von SMStreamGetPos erhaltene Wert verwendet. Falls sie erfolgreich ist, gibt SMStreamSetPos eine Null zurück. Ansonsten ist der Rückgabewert von Null verschieden.

SMSize SMStreamTell (SMStream stream);

Verwendet SMStreamTell, um die aktuelle Position des Stroms zu erhalten. Die Position wird als eine Byteverschiebung vom Beginn der Datei ausgedrückt. Falls sie erfolgreich ist, gibt SMStreamTell eine SMSize zurück, die die Anzahl der Bytes enthält, um die die aktuelle Position des Stroms gegenüber dem Beginn des Werts verschoben ist. Bei einem Fehler gibt SMStreamTell -1 zurück.

H. CPL-Zugriffsmittel

SMCPLAccessor SMNewCPLAccessor(SMAccessorkind aKind, SMContSpec contSpec, SMPoolName poolName, SMLayerName layerNameh

Erzeugt ein CPL-Zugriffsmittel der gegebenen Art und gibt dieses zurück, wobei dieses den Behälter-, den Pool- und den Schichtzusammenhang definiert. Alle Parameter mit Ausnahme der Art des Zugriffsmittels sind wahlfrei. Der Parameter der Art des CPL-Zugriffsmittels gibt an, ob das Zugriffsmittel ein Lese-Schreib-, ein Lese-Schreib- oder ein transientes Zugriffsmittel bezüglich des Inhalts der Schicht ist oder nicht. Ein transientes Zugriffsmittel kann keine Behälter-, Pool- oder Schichtmanipulation ausführen, er kann jedoch von der aktuell gekennzeichneten Position auf andere Pools und Schichten umpositioniert werden. Der Behälter wird, falls erforderlich, während dieses Aufrufs implizit geöffnet.
Jede Schicht kann viele Leseprozesse aufweisen, sie kann jedoch zu einem Zeitpunkt nur einen Prozeß aufweisen, der eine Schicht modifiziert. Daher kann ein Prozeß keine Erlaubnis zum Schreiben auf die Schicht erhalten, falls es einen anderen Prozeß gibt, der eine Schicht liest oder modifiziert. Jedes CPL-Zugriffsmittel behält seine aktuelle Erlaubnis für die Schicht. Die Erlaubnis wird als Schichtmodus ("Layer Mode") bezeichnet. Es gibt drei Schichtmodi, nämlich einen Lese-Schreib-Modus, einen Nurlesemodus und einen Blindmodus ("None"). Der Lese-Schreib-Modus gibt dem Prozeß, welcher - das CPL-Zugriffsmittel besitzt» ein ausschließliches Recht zum Modifizieren der Schicht. Der Nurlesemodus erlaubt es einem Prozeß, aus der Schicht zu lesen und gleichzeitig jeden Versuch eines anderen Prozesses zu blockieren, einen Lese-Schreib-Modus zu erhalten. Der Blindmodus wird für ein transientes Umpositionieren des Schichtzugriffs verwendet. Möglicherweise möchte der Benutzer beispielsweise ein CPL-Zugriffsmittel innerhalb einer Schichthierarchie verschieben, ohne die Absicht zu haben, irgendwelche Blops zu betrachten, bevor die gewünschte Schicht gefunden wurde.
CPL-Zugriffsmittel desselben Prozesses können denselben Schichtmodus geteilt verwenden. Beispielsweise weist ein Klon eines CPh-Zugriffsmittels denselben Schichtmodus wie das Original auf. Falls das ursprüngliche CPL-Zugriffsmittel einen Lese-Schreib-Modus in einer Schicht aufweist, hat der Klon auch eine Lese- und Schreiberlaubnis für die Schicht.

void SMDisposeCPLAccessor(SMCPLAcceesor accessor);

Beseitigt das angegebene CPL-Zugriffsmittel. Falls irgendwelche BPV-Zugriffsmittel ausstehen, tritt ein Fehler auf. Falls dies das letzte Zugriffsmittel ist, das den Behälter kennzeichnet, wird er implizit geschlossen.

void SMTransformCPLAccessor(SMCPLAccessor accessor, SMAccessorKind aKind);

Wandelt ein CPL-Zugriffsmittel von einer Art zu einer anderen um. Falls von Nur-Lesen zu Lesen-Schreiben übergegangen wird, muß das CPL-Zugriffsmittel das einzige Zugriffsmittel sein, das die Schicht kennzeichnet. Es tritt eine Ausnahme auf, falls versucht wird, ein CPL-Zugriffsmittel umzupositionieren, das ausstehende BPV-Zugriffsmittel aufweist.

void SMRetargetCPLAccessor(SMCPLAccessor accessor, SMContSpec contSpec, SMBoolean samePoolName, SMBoolean sameLayerName);

Weist das gegebene CPL-Zugriffsmittel auf der Grundlage der gegebenen Behälterspezifikation einem möglicherweise anderen Behälter zu. Das gegebene Zugriffsmittel wird neu zugewiesen. Es tritt eine Ausnahme auf, falls versucht wird, ein CPL-Zugriffsmittel umzupositionieren, das ausstehende BPV-Zugriffsmittel aufweist. Da ein CPL-Zugriffsmittel den Zusammenhang für das BPV-Zugriffsmittel liefert, kann ein CPL-Zugriffsmittel nicht umpositioniert werden, falls es ein ausstehendes BPV-Zugriffsmittel gibt. Alle BPV-Zugriffsmittel müssen zuerst "aufgehoben" werden. Falls samePoolName oder sameLayerName kSMBTrue sind, versucht das zurückgegebene Zugriffsmittel, denselben Pool wie das Original und dieselbe Schicht wie das Original dem Namen nach zu kennzeichnen.

SMPositionResult SMPositionCPLAccessor(SMCPAccessor accessor, SMPoolName polName, SMPositionCode poolPosition, SMLayerName layerName, SMPositionCode layerPosition);

Positioniert ein gegebenes CPL-Zugriffsmittel innerhalb eines Behälters um und gibt den Status des Positionierens zurück. Der Rückgabewert gibt, falls er positiv ist, an, wie sich der neue Ort des Zugriffsmittels auf den vorhergehenden Ort bezieht, und er gibt, falls er negativ ist, an, inwieweit SMPositionCPLAccessor in der Lage war, diesen Prozeß fortzusetzen, bevor ein Fehler erkannt wurde. Beim Auftreten eines Fehlers wird das Zugriffsmittel so belassen, daß es auf den Pool und die Schicht zeigt, die von den gefundenen den angeforderten am nächsten kommen und die gegebenen Parameter noch erfüllen. Falls der angegebene Schichtname nicht existiert, wird das CPL-Zugriffsmittel auf den angegebenen Pool positioniert (und nicht auf eine Schicht in dem angegebenen Pool). Eine Ausnahme tritt auf, falls versucht wird, ein CPL-Zugriffsmittel umzupositionieren, das ausstehende BPV-Zugriffsmittel aufweist. Während des Umpositionierens werden Pools, wie es erforderlich ist, implizit geöffnet und geschlossen.
Schichten und Pools werden als umgekehrte Graphen angesehen. Delta-Pools werden als abhängige Datensätze ihres Grund-Pools angesehen. Die Bodenschicht ist der oberste Stammdatensatz in einer Schichthierarchie. Das Positionieren des Pools von einem undefinierten Zustand auf kSMPFirstSib positioniert auf den ersten Pool in dem Behälter. Das Positionieren einer Schicht auf kSMPFirstAbove oder kSMPFirstBelow von einem undefinierten Zustand her positioniert auf die Bodenschicht des Pools.

Parameter: poolPosition

Gültiger Positionscode Bedeutung

kSMPUndefined setze Pool auf undefiniert
kSMPSame bleibe beim selben Pool
kSMPFirstSib gehe zum ersten Pool im selben Behälter
kSMPLastSib gehe zum letzten Pool im selben Behälter
kSMPNextSib gehe zum nächsten Pool im selben Behälter
kSMPPrevSib gehe zum vorhergehenden Pool im selben Behälter
kSMPFirstBelow gehe zum Grund-Pool (ebenso wie kSMPLastBelow)
kSMPLastBelow gehe zum Grund-Pool (ebenso wie kSMPFirstBelow)
KSMPFirstAbove gehe zum ersten verbundenen Delta-Pool
kSMPLastAbove gehe zum letzten verbundenen Delta-Pool
kSMPMWrap lasse Umlaufen innerhalb einer Ebene zu

Parameter: Schichtposition

Gültiger Positionscode Bedeutung

kSMPUndefined setze Schicht auf undefiniert
kSMPSame bleibe in derselben Schicht
kSMPFirstSib gehe zur ersten Schicht auf derselben Ebene
kSMPLastSib gehe zur letzten Schicht auf derselben Ebene
kSMPNextSib gehe zur nächsten Schicht auf derselben Ebene
kSMPPrevSib gehe zur vorhergehenden Schicht auf derselben Ebene
kSMPFirstBelow gehe zur ersten Grundschicht
kSMPLastBelow gehe zur letzten Grundschicht
KSMPFirstAbove gehe zur ersten abgeleiteten Schicht
kSMPLastAbove gehe zur letzten abgeleiteten Schicht
kSMPMWrap lasse Umlaufen innerhalb einer Ebene zu

SMCount SMCountCPLAccessor(SMCPLAccessor accessor, SMPositioncode poolPosition, SMPositionCode layerPosition);

Gibt an, wie oft das gegebene CPL-Zugriffsmittel vor einer Unterbrechung entsprechend den Parametern umpositioniert werden konnte. Der Umlaufpositionscode-Modifizierer ist nicht für jeden gegebenen Positionscode zulässig. Die Parameter werden ebenso interpretiert wie in der SMPositionCPLAccessor-Routine. Es ist bei dieser Routine einfach, die Anzahl der Pools in einem Behälter, die Anzahl der Schichten in einer Hierarchie und dergleichen zu bestimmen.

SMCPLAccessor SMCloneCPLAccessor(SMCPLAccessor orogonal);

Kopiert das angegebene CPL-Zugriffsmittel und gibt die Kopie zurück. Es können ausschließlich Nurlese-Zugriffsmittel und transiente Zugriffsmittel geklont werden, da es nicht zulässig ist, daß zwei Lese-Schreib-Zugriffsmittel dieselbe Schicht ansteuern. Falls die Schicht durch das Zugriffsmittel aktuell undefiniert ist, kann ein Lese- Schreib-Zugriffsmittel geklont werden.

void SMGetCPLAcceesorInfo(SMCPLAccessor accessor, SMCPLReadOnlyInfo *roInfo, SMCOLReadWriteInfo *rwInfo),

Gibt die Einzelheiten darüber zurück, was das gegebene CPL-Zugriffsmittel kennzeichnet. kSMUndefined kann unerwünschten Parametern als Argument gegeben werden. kSMUndefined wird für undefinierte Elemente zurückgegeben. Der Datei-Parameter ist nur dann definiert, wenn der Behälter ein Dateibehälter ist, und für alle anderen Behältern wird immer ksMUndefined zurückgegeben. Durch Angeben von kSMUndefined für poolName, während weiterhin maxPoolNameSize angegeben ist, wird der Parameter auf die Länge des Pool- Namens gelegt. Der basePool-Parameter wird mit einem neu erzeugten Zugriffsmittel basePoolAKind aufgefüllt, falls er nicht kSMUndefined ist, und der gegenwärtig gekennzeichnete Pool ist ein trennbarer Pool oder ein Delta-Pool. Die Parameter der maximalen Informationsgröße geben die aktuelle Größe der Entsprechenden Information zurück, falls kSMUndefined für den Informattonsparameter gegeben ist. Das Schichtnamen-Wiederholungsmittel ist eine Augenblickaufnahme aller Namen, die aktuell für die gekennzeichnete Schicht festgelegt sind. Das Ändern von Posten innerhalb des Wiederholungsmittels hat keine Wirkung auf die Schicht.

void SMSetCPLAccessorInfo(SMCPLhccessor accessor, SMCPLReadWriteInfo *rwInfo);

Legt die Einzelheiten davon fest, was das gegebene CPL- Zugriffsmittel kennzeichnet. kSMUndefined kann für poolName angegeben werden, falls der Name nicht geändert werden soll. In rwInfo gibt. "konsistent" an, ob die von dem gegebenen Zugriffsmittel gekennzeichnete Schicht konsistent ist oder nicht.
Jeder Schicht ist ein Hinweiszeichen zugeordnet, das angibt, ob die Schicht eine konsistente Ansicht der Blops in dem Pool enthält. Da die Speicherverwaltungseinrichtung keine Kenntnisse über die Interpretation von Daten hat, die sie verwaltet, nimmt sie an, daß alle Operationen, die sie ausführen soll, die Schichten in einem konsistenten Zustand belassen. SMSetCPLAccesssorInfo ermöglicht es der Anwendung jedoch, anzugeben, daß eine Schicht in einem konsistenten oder einem inkonsistenten Zustand ist. Da die SMMoveAll-ChangesDown-Routine häufig eine Schicht inkonsistent macht (durch Herunterkopieren einer Untergruppe verwandter Änderungen), weist sie zusätzlich ein Argument auf, das die aufrufende Stelle liefern kann, um anzugeben, ob die sich ergebende Schicht konsistent ist. Der Hauptgebrauch dieses Merkmals besteht darin, die Typen von Operationen zu begrenzen, die bezüglich einer Schicht ausgeführt werden können. Es ist ein Fehler, wenn eine Anwendung eine Schicht erzeugt, die von einer inkonsistenten Schicht abgeleitet ist (wenngleich bestehende Schichten, die über ihr liegen, noch in Ordnung sind), und es ist ein Fehler, wenn eine Anwendung SMMoveAllChangesDown bezüglich einer inkonsistenten Schicht ausführt. Falls eine Anwendung demgemäß eine inkonsistente Schicht in einer geteilt verwendeten Plattendatei ausführt, ist keine andere Anwendung in der Lage, über ihr eine Schicht aufzubauen (und ihren Inhalt zu betrachten), bevor sie als konsistent markiert wurde.

SMIterator SMownedBPVAccessor (SMcpLAccessor accessor);

Gibt ein Wiederholungsmittel zurück, das alle ausstehenden BPV-Zugriffsmittel für das gegebene CPL-Zugriffsmittel enthält. Das Wiederholungsmittel des BPV-Zugriffsmittels ist eine Augenblickaufnahme aller BPV-Zugriffsmittel, die das gegebene CPL-Zugriffsmittel aktuell besitzt. Das Ändern von Posten innerhalb des Wiederholungsmittels hat keine Wirkung auf die eigentlichen Zugriffsmittel.

void SMoleanup (SMCPLAccessor accessor, SMoleanupCode cleanupCode);

Reinigt die Schicht-, die Pool- und die Behälterstrukturen, auf die sich das Zugriffsmittel bezieht, entsprechend "cleanupcode". Das CPL-Zugriffsmittel wird dann entsprechend dem Reinigungsvorgang positioniert.

I. Arbeitsplatz-Instandhaltung

void SMGetWorkspaceInfo(SMCPLAccessor accessor, SMWSReadOnlyInfo *roInfo, SMWSReadWriteInfo *rwInfo);

Gibt die aktuelle Arbeitsplatzinformation für das gegebene CPL-Zugriffsmittel zurück.

void SMSetworkspaceInfo(SMCPhAccessor accessor, SMWSReadWriteInfo *rwInfo);

Legt die Arbeitsplatzinformation für das gegebene CPL- Zugriffsmittel fest.

void SMFlushworkspaceInfo(SMCPLAccessor accessor);

Räumt die Arbeitsplatz-Cache-Speicher für das gegebene CPL-Zugriffsmittel.

J. Erzeugen von Behälterspezifikationen

SMContSpec SMMakeFileContSpec(const SMFileSpec *theFile);

Erzeugt eine Behälterspezifikation für die gegebene Datei.

SMContSpec SMMakeROMContSpec(void);

Erzeugt eine Behälterspezifikation für den ROM. SMCreatecontainer und SMRemoveContainer sind für eine ROM- Behälterspezifikation nicht gültig.

SMContSpec SMMakeScrapContSpec(void);

Erzeugt eine Behälterspezifikation für die Ablagefläche.

SMContSpec SMMakeMemoryContSpec (void);

Erzeugt eine Behälterspezifikation für einen Speicherbereich.

void SMUnMakeContSpec(SMContSpec contspec);

Entfernt die Behälterspezifikation. Es ist nicht erforderlich, eine Behälterspezifikation ("ContSpec") rückgängig zu machen, falls die Spezifikation in den Routinen SMCreate- Container, SMNewCPLAccessor oder SMRetargetCPLAccessor verwendet wird.

K. Behälterinstandhaltung

SMCPLkccessor SMCReateContainer(SMContSpec contSpec, SMContHandler handler, SMAccessorKind aKind);

Erzeugt einen neuen Behälter, der so angeordnet ist, wie durch die Behälterspezifikation ("Container Spec") definiert ist. Das gegebene Handhabungsmittel ist als das Behälterhandhabungsmittel ("Container Handler") für alle Zugriffe auf den gegebenen Behälter festgelegt. Diese Routine erzeugt eine neue Datei oder weist eine neue Haldenzone zu. Falls die Datei oder die Haldenzone bereits bestehen, tritt ein Fehler auf. Nachdem der Behälter als Speicherverwaltungsbehälter initialisiert wurde, kann auf ihn zugegriffen werden. Es wird ein neues CPL-Zugriffsmittel der gegebenen Art erzeugt, das sich auf den Behälter bezieht, und es wird dann zurückgegeben. Das von der Speicherverwaltungseinrichtung bereitgestellte Standard-Behälterhandhabungsmittel wird hier als "SMUIPFileContHandler" bezeichnet.

void SMRemoveContainer(SMCPLAccessor container);

Entfernt den gekennzeichneten Behälter ("Container"). Falls der Behälter eine Datei ist, wird die Datei entfernt. Das gegebene Zugriffsmittel wird an einer undefinierten Position belassen. Es können für das gegebene CPL-Zugriffsmittel keine BPV-Zugriffsmittel ausstehen.

L. Pool-Instandhaltung

SMCPLAccessor SMCmeatePool (SMCPLAccessor container, SMPoolName poolName, SMAccessorKind aKind);

Erzeugt einen neuen Pool in dem durch "Container" angegebenen Behälter. Es wird eine einzige Bodenschicht erzeugt, wenn ein neuer Pool erzeugt wird. Falls kSMUndefined für die Zugriffsmittelart ("Accessor Kind") angegeben wird, wird das gegebene CPL-Zugriffsmittel so positioniert, daß es den neuen Pool kennzeichnet, und dann zurückgegeben. Falls eine gültige Zugriffsmittelart gegeben ist, wird ein neues CPL- Zugriffsmittel der gegebenen Art erzeugt und zurückgegeben.

void SMRemovePool (SMCPLAccessor pool);

Entfernt den Pool, auf den sich "Pool" bezieht. Der durch das gegebene Zugriffsmittel gekennzeichnete Pool ist nach dieser Routine kSMUndefined.

SMCPLAccessor SMCreateDeltaPool(SMCPLAccessor deltaContainer, SMPoolName deltaPoolName, SMCPLAccessor baseLayer, SMAccessorKind aKind);

Erzeugt einen Delta-Pool auf der Grundlage der Schicht, auf die sich "baseLayer" bezieht. Der neue Pool wird in dem durch "deltaContainer" angegebenen Behälter erzeugt und hat den Namen "deltaPoolName". Falls kSMUndefined für die zugriffsmittelart angegeben ist, wird der gegebene Delta- Behälter ("deltaContainer") so positioniert, daß er die neue Bodenschicht des neuen Pools kennzeichnet, und dann zurückgegeben. Falls eine gültige Zugriffsmittelart gegeben ist, wird ein neues CPL-Zugriffsmittel der gegebenen Art erzeugt und zurückgegeben.

SMCPLAccessor SMCreateseparablePool(SMCPLAccessor deltaContainer, SMPoolName sepPoolName, SMCPLAccessor baseLayer, SMAccessorKind aKind),

Erzeugt einen trennbaren Pool auf der Grundlage der Schicht, auf die sich "baseLayer" bezieht. Der trennbare Pool wird in dem durch "sepContainer" angegebenen Behälter erzeugt und hat den Namen "sepPoolName". Falls kSMUndefined für die Zugriffsmittelart angegeben ist, wird der gegebene trennbare Behälter ("sepContainer") so positioniert, daß er die neue Bodenschicht des neuen Pools kennzeichnet, und dann zurückgegeben. Falls eine gültige Zugriffsmittelart gegeben ist, wird ein neues CPL-Zugriffsmittel der gegebenen Art erzeugt und zurückgegeben.

void SMReconnectedPool(SMCPLAccessor deltaPool, SMCPLAccessor basePool, SMReconcileOperator reconcileMask, SMReconcileHandler reconcileHandler);

Verbindet einen Delta-Pool, auf den sich "deltaPool" bezieht, mit dem Grund-Pool, auf den sich "basePool" bezieht. Das gegebene Abstimmungs-Handhabungsmittel ("Reconciliation Handler") wird auf zwei Ebenen (Schichten und Blops) verwendet. "reconcileMask" gibt an, welche Operationen Funktionen des Handhabungsmittels auslösen. Ein Standard-Abstimmungs-Handhabungsmittel wird von der Speicherverwaltungseinrichtung bereitgestellt und hier als "SMDefaultReconcileHandler" bezeichnet.
Ein Abstimmungs-Handhabungsmittel führt eine jedem Abstimmungsoperator ("Reconciliation Operator") gegebene Funktion aus. Dies ist die von der Speicherverwaltungseinrichtung zum Ausführen der Wiederverbindungsroutine verwendete Funktion. Die für jede Schichtabstimmungsoperation abgerufenen Funktionen sind folgendermaßen definiert:
myReconcileLayerFung(SMLayerName layerName, SMReconcileOperator operator, SMCPLAccessor deltaLayer, SMCPLACCessor baseLayer);
Die für jede Blop-Abstimmungsoperation aufgerufenen Funktionen sind folgendermaßen definiert:
myReconcileBlopFung(SMCPLAccessor theBlop, SMReconcileOperator operator, SMCPLAccessor deltaLayer SMCPLAccessor baseLayer);

void SMIntegratePool(SMCPLAccessor sepPool, SMCPLAccessor origPool, SMReconcileOperator reconcileMask, SMReconcileHandler reconcileHandler);

Integriert einen trennbaren Pool, auf den sich "sepPool" bezieht, mit dem Grund-Pool, auf den sich "origPool" bezieht. Das gegebene Abstimmungs-Handhabungsmittel wird auf zwei Ebenen (Schichten und Blops) verwendet. "reconcileMask" gibt an, welche Operationen Handhabungsfunktionen auslösen. Ein Standard-Abstimmungs-Handhabungsmittel wird von der Speicherverwaltungseinrichtung bereitgestellt und hier als "SMDefaultReconcileHandler" bezeichnet.
Ein Abstimmungs-Handhabungsmittel führt eine jedem Abstimmungsoperator gegebene Funktion aus. Dieses ist die von der Speicherverwaltungseinrichtung zum Ausführen der Integrationsroutine verwendete Funktion. Die für jede Schichtabstimmungsoperation aufgerufenen Funktionen sind folgendermaßen definiert:
myIntegrateLayerFung(SMLayerName layerName, SMReconcileOperator operator, SMCPLAccessor sepayer SMCPLAccessor origLayer);.
Die für jede Blop-Abstimmungsoperation aufgerufenen Funktionen sind folgendermaßen definiert:
myIntegrateBlopFung(SMCPLAcceseor theBllop, SMReconcileoperator operator, SMCPLAccessor sepLayer SMCPLAccmssor origLayer);.

SMCPLAccessor SMIntegrateLayer(SMCPLAccessor layer1, SMCPLAccessor layer2, SMReconcileOperator raconcileMask, SMAeconcileHandler reconcileHandler, SMAccessorKind aKind);

Erzeugt eine neue Schicht, die als eine Integrationsschicht zwischen den beiden als "Layer1" und "Layer2" bezeichneten Schichten wirkt. Die neue Schicht wird in demselben Pool erzeugt, der durch Layer1 angegeben ist, wenn Layer1 und Layer2 verschiedene Pools bezeichnen. Layer1 und Layer2 müssen eine gemeinsame Grundschicht aufweisen, um integriert zu werden. "reconcileMask" gibt an, welche Operationen Handhabungsfunktionen auslösen. Das zurückgegebene CPL-Zugriffsmitael ist ein neues Zugriffsmittel der gegebenen Art, das die neue Schicht kennzeichnet. Ein Standard- Abstimmungs-Handhabungsmittel wird von der Speicherverwaltungseinrichtung bereitgestellt und hier als "SMDefault- ReconcileHandler" bezeichnet.
Ein Abstimmungs-Handhabungsmittel führt eine jedem Abstimmungsoperator gegebene Funktion aus. Dieses ist die von der Speicherverwaltungseinrichtung zum Ausführen der Integrationsroutine verwendete Funktion. Die für jede Blop- Abstimmungsoperation aufgerufenen Funktionen sind folgendermaßen definiert:
myIntegrateBlopFunc(SMBPVAccessor theBlop, SMReconcileOperator operator, SMCPLAccessor layer1 SMCPLAccessor layer2);.

SMCPLAccessor SMGetLatestCommonLayer (SMCPLAccessor layer1, SMCPLAccessor layer2, SMAccessorKind aKind);

Findet die letzte gemeinsame Schicht der mit "Layer1" und "Layer2" bezeichneten Schichten und erzeugt ein neues CPL-Zugriffsmittel der gegebenen Art, das sich auf diese gemeinsame Schicht bezieht und dann zurückgegeben wird.

SMCPLAccessor SMGeaBottomLayer(SMCPLAccessor pool, SMAccessorKind aKind);

Gibt die Bodenschicht des mit dem gegebenen CPL- Zugriffsmittel gekennzeichneten Pools zurück. Falls kSMUndefined für die Zugriffsmittelart angegeben ist, wird Pool auf die Bodenschicht umpositioniert. Falls eine gültige Zugriffsmittelart gegeben ist, wird ein neues CPL-Zugriffsmittel der gegebenen Art erzeugt und zurückgegeben.

M. Schichtinstandhaltung

SMCPLAccesaor SMCreateLayer(SMCPLAccessor aboveLayer, SMCPLAccessor belowLayer1, SMCPLAccessor belowLayer2, SMBoolean above, SMAccessorKind axind),

Erzeugt eine Schicht zwischen den mit "aboveLayer" und den beiden unten angegebenen CPL-Zugriffsmitteln ("below- Layer1" und "belowLayer2") spezifizierten Schichten. Falls kSMUndefined für die Zugriffsmittelart angegeben wird, wird belowLayer1 so positioniert, daß sie den neuen Pool kennzeichnet, und dann zurückgegeben. Falls eine gültige Zugriffsmittelart gegeben ist, wird ein neues CPL-Zugriffsmittel der gegebenen Art erzeugt und zurückgegeben. Das oben angegebene Hinweiszeichen bestimmt, ob die neue Schicht in dem durch aboveLayer oder belowLayer1 und belowLayer2 gekennzeichneten Pool erzeugt wird. Wenn versucht wird, eine Schicht in einem Nurlese-Pool zu erzeugen, tritt ein Fehler auf. Neue Schichten werden in einem konsistenten Zustand erzeugt.

void SMRemoveLayer(SMCPLAccessor layer);

Entfernt die mit "Layer" bezeichnete Schicht. Alle innerhalb einer gegebenen Schicht konkret dargestellten Blops werden auch entfernt. Eine Schicht kann nicht entfernt werden, falls von ihr Schichten abgeleitet sind. Das CPL- Zugriffsmittel kennzeichnet weiterhin eine kSMUndefined- Schicht. Die Bodenschicht eines Pools kann nicht entfernt werden.

SMBoolean SMSetLayerName(SMLayerName name, SMCPLAccessor oldLayer, SMCPLAccessor newLayer);

Ändert den Namen, der der mit "oldLayer" bezeichneten Schicht gegeben ist, in unteilbarer Weise zu demjenigen, der "newLayer" gegeben ist. Die mit "oldLayer" und "newLayer" bezeichneten Schichten können in verschiedenen Pools und Behältern liegen. Falls es keine Schicht gibt, die zuvor den gegebenen Namen hatte, sollte kSMUndefined für oldLayer angegeben werden. Falls die Schicht, auf die sich oldLayer bezieht, zu dem Zeitpunkt, zu dem der Aufruf erfolgt, nicht den gegebenen Namen hat, wird kSMBFalse zurückgegeben, und es werden keine Namen geändert. Zum Entfernen des Schichtnamens wird kSMUndefined als newLayer-Parameter angegeben. Diese Routine wird als die Prüf- und Festlege-Operation für alle Schichtverwaltungsprotokolle in der Speicherverwaltungseinrichtung verwendet. Diese Routine gibt kSMBTrue zurück, falls die Schicht, auf die sich oldLayer bezieht, richtig identifiziert wurde, und sie gibt kSMBFalse zurück, falls dies nicht der Fall ist. In diesem Fall tritt kein Fehler auf, so daß der zurückgegebene Wert geprüft werden muß, falls die Routine als eine Prüf-und-Festlege-Routine verwendet wird.

N. Schichtinhaltsmanipulation

void SMMoveAllChangesDown(SMCPLAccessor fromLayer, SMCPLAccessor toLayer);

Verschiebt alle konkreten Darstellungen der Blops, die in den Schichten auftreten, welche zwischen den mit "fromLayer" und "toLayer" bezeichneten Schichten liegen (nicht einschließend), in unteilbarer Weise zu der mit "toLayer" bezeichneten herab, wobei alle dazwischenliegenden Schichten leer bleiben. Demgemäß werden nun alle in den dazwischenliegenden Schichten erzeugten, gelöschten oder geänderten Blops in der mit "toLayer" bezeichneten Schicht erzeugt, gelöscht und geändert. Die mit "fromtayer" bezeich nete Schicht muß sich transitiv über derjenigen befinden, die mit "toLayer" bezeichnet ist, wenngleich sie in verschiedenen Pools liegen können, und alle dazwischenliegenden Schichten müssen sich transitiv oberhalb der mit "toLayer" bezeichneten Schicht und transitiv unterhalb der mit "fromLayer" bezeichneten Schicht befinden. Weiterhin darf die mit "fromLayer" bezeichnete Schicht keine mehrdeutigen Blops aufweisen, und es ist nicht möglich, daß sich CPL- Zugriffsmittel auf die dazwischenliegenden Schichten beziehen.

void SMMoveChangesoDown(SMIterator blope, SMCPLAccessor fromLayer, SMCPLAccessor toLayer; SMBoolean consistent)

Verschiebt die konkreten Darstellungen der spezifizierten Blops, die in den Schichten auftreten, die zwischen fromLayer und toLayer liegen (nicht einschließlich toLayer) in unteilbarer Weise zu toLayer herab und läßt den Zustand dieser Blops in den dazwischenliegenden Schichten ungeändert. Diese Routine ähnelt abgesehen davon, daß nur die spezifizierten Blops betroffen sind, SMMoveAllChangesDown. Das Konsistenzargument ("consistent argument") gibt an, ob die sich ergebende Schicht als eine markiert werden sollte, die eine konsistente Ansicht der Blops in der Schicht bietet.

void SMCopyAllBlopsUp(SMCPLAccessor fromLayer, SMCPLAccessor toLayer);

Kopiert die konkreten Darstellungen aller in fromLayer sichtbaren Blops in unteilbarer Weise zu toLayer, wodurch jegliche Änderungen in allen dazwischenliegenden Schichten gänzlich verborgen werden. Der einzige Unterschied zwischen der Ansicht von toLayer und fromLayer am Ende dieser Operation besteht in den Blops, die in der mit "toLayer" bezeichneten Schicht erzeugt wurden und die durch diese Operation nicht geändert werden. Blops, die in der mit "toLayer" bezeichneten Schicht gelöscht wurden, werden durch die eigentlichen Blops aus der mit "fromLayer" bezeichneten Schicht ersetzt.

void SMCopyBlopsUp (SMIterator blop, SMCPLAccessor fromLayer, SMCPLAccessor toLayer);

Kopiert die konkreten Darstellungen der spezifizierten Blops, die in der mit "fromLayer" bezeichneten Schicht sichtbar sind, zu der mit "toLayer" bezeichneten Schicht, wodurch jegliche Änderungen in allen dazwischenliegenden Schichten gänzlich verborgen werden. Auf diese Weise hängt, die gegebene Schicht nicht mehr davon ab, daß die Schichten unterhalb von ihr die Werte für die Blops bereitstellen. Diese Routine kann verwendet werden, um eine Grundschichtversion mehrdeutiger Blops auszuwählen, die in eine Abstimmungsschicht aufzunehmen ist, oder, um Änderungen an einer Blop "rückgängig zu machen".

void SMEmptyLayer(SMCPLAccessor layer);

Entfernt konkrete Darstellungen aller in der gegebenen Schicht befindlichen Blops. Dies gilt nur für Schichten, von denen keine anderen Schichten abgeleitet sind. Nach dem Abschluß dieser Routine wird die gegebene Schicht als konsistent festgelegt, falls dies erforderlich ist.

O. Wiederholungsmittel

SMIterator SMNewIterator(SMIteratorHandler handler);

Weist ein Wiederholungsmittel unter Verwendung des gegebenen Wiederholungs-Handhabungsmittels ("Iterator Handler") zu. Ein Wiederholungs-Handhabungsmittel führt eine jedem Wiederholungsoperator ("Iterator Operator") gegebene Funktion aus. Dies ist die von der Speicherverwaltungseinrichtung zum Ausführen der Wiederholungsroutinen für das gegebene Wiederholungsmittel verwendete Funktion. Die folgenden Standard-Wiederholungs-Handhabungsmittel werden von der Speicherverwaltungseinrichtung bereitgestellt:
SMBPVAccessorIteratorhandler SMStructureNameIteratorHandler SMBlopIteratorHandler void SMDisposelterator(SMIterator iterator);
Löscht das gegebene Wiederholungsmittel.

SMBoolean SMGetFirstItem(SMIterator iterator, SMIterItemPtr item),

Gibt den ersten verfügbaren Posten vom Wiederholungsmittel zurück. Gibt kSMBTrue zurück, falls sie erfolgreich ist, und kSMBFalse, falls sie dies nicht ist.

SMBoolean SMGetLastItem(SMIterator iterator, SMIterItemPtr item);

Gibt den letzten verfügbaren Posten vom Wiederholungsmittel zurück. Gibt kSMBTrue zurück, falls sie erfolgreich ist, und kSMBFalse, falls sie dies nicht ist.

SMBoolean SMGetNextItem(SMIterator iterator, SMIterItemPtr item),

Gibt den nächsten verfügbaren Posten vom Wiederholungsmittel zurück. Gibt kSMBTrue zurück, falls sie erfolgreich ist, und kSMBFalse, falls sie dies nicht ist.

SMBoolean SMGetPrevItem(SMIterator iterator, SMIterItemPtr item);

Gibt den vorhergehenden verfügbaren Posten vom Wiederholungsmittel zurück. Gibt kSMBTrue zurück, falls sie erfolgreich ist, und kSMBFalse, falls sie dies nicht ist.

SMBoolean SMGetIteratorCount(SMIterator iterator);

Gibt die Anzahl der verfügbaren Posten vom Wiederholungsmittel zurück.

SMBoolean SMGetIndexItem(SMIterator iterator, SMCount index, SMIterItemPtr item);

Setzt den Postenparameter auf den vom gegebenen Index vom Wiederholungsmittel gekennzeichneten Posten. Der Index beruht auf eins Gibt kSMBTrue zurück, falls sie erfolgreich ist, und kSMBFalse, falls sie dies nicht ist.

SMBoolean SMSetIndexItem(SMIterator iterator, SMCount Index, SMIterItemPtr item);

Legt den vom gegebenen Index im Wiederholungsmittel gekennzeichneten Posten fest. Der Index beruht auf eins. Es ist dem Wiederholungs-Handhabungsmittel überlassen, zu entscheiden, ob knappe Postenlisten zulässig sind. Gibt kSMBTrue zurück, falls sie erfolgreich ist, und kSMBFalse, falls sie dies nicht ist.

SMBoolean SMAddItem(SMIterator iterator, const SMIterItemPtr item, SMBoolean unique);

Fügt den gegebenen Posten der Postenliste des Wiederholungsmittels hinzu. Gibt kSMBTrue zurück, falls sie erfolgreich ist, und kSMBFalse, falls sie dies nicht ist. Falls der Einzigartigkeitsparameter ("unique") kSMBTrue ist, ist garantiert, daß der Posten nach dem Hinzufügen einzigartig ist.

SMBoolean SMRemoveltem(SMIterator iterator, const SMIterItemPtr item),

Der gegebene Posten wird aus der Postenliste des Wiederholungsmittels entfernt. Falls es mehr als eine Kopie des gleichen Postens in dar Postenliste gibt, wird nur eine entfernt. Gibt kSMBTrue zurück, falls sie erfolgreich ist, und kSMBFalse, falls sie dies nicht ist.

SMBoolean SMRemoveIndexItem(SMIterator iterator, SMCount index);

Entfernt den gegebenen mit einem Index versehenen Posten aus der Postenliste des Wiederholungsmittels. Gibt kSMBTrue zurück, falls sie erfolgreich ist, und kSMBFalse, falls sie dies nicht ist.

void SMInsertIndexItem(SMIterator iterator, SMCount Index, const SMIterItemPtr item, SMBoolean unique);

Fügt den gegebenen Posten der Postenliste des Wiederholungsmittels beim gegebenen Index hinzu. Es ist dem Wiederholungs-Handhabungsmittel überlassen, zu entscheiden, ob knappe Postenlisten zulässig sind. Alle nachfolgenden Postenindizes werden um eins erhöht. Gibt kSMBTrue zurück, falls sie erfolgreich ist, und kSMBFalse, falls sie dies nicht ist. Falls der Eindeutigartigkeitsparameter ("unique") kSMBTrue ist, ist garantiert, daß der Posten nach dem Hinzufügen eindeutig ist.

SMBoolean SMSetIndexItem(SMIterator iterator, SMCount Index, SMIterItemPtr item),

Gibt die Größe des aktuellen Postens für das gegebene Wiederholungsmittel zurück.

SMBoolean SMSetIndexItemSize(SMIterator iterator);

III. GEGENSTÄNDLICHE VERWIRKLICHUNG DER DATENSTRUKTUR UND IHRE VERWALTUNG

Um die oben beschriebene Datenstruktur zu verwirklichen und die von der Speicherverwaltungseinrichtung bereitgestellten Routinen zu erleichtern, erzeugen und erhalten die Routinen vorzugsweise Blops, Schichten, Pools, Behälter und andere Strukturen gemäß der folgenden Beschreibung.

A. Behälter, Pools und Schichten

Fig. 12 ist ein Blockdiagramm der inneren Struktur eines Behälters. Jeder Behälter ist in einer eigenen Datei in einem einzigen Speichermedium gespeichert. Wie in Fig. 12 dargestellt ist, beinhaltet der Behälter einen Behälter- Kopfteil 1202, der die folgenden Einträge beinhaltet:

Magisches Cookie

Das magische Cookie ("Magic Cookie") ist eine Folge von n Bytes am Anfang der Datei, die diese Datei als eine Datei der Speicherverwaltungseinrichtung gekennzeichnet.

Kettenzeiger auf Liste freie Einermengen (SF)

Eine Liste freier Einermengen ("Singleton Free List") (SF) ist ein Block, der eine geordnete Liste einzelner freier Blöcke in der Datei enthält. Jeder SF-Block enthält einen Zeiger auf den nächsten SF-Block (oder nichts), wodurch eine Kette gebildet wird. Der SF-Kettenzeiger im Kopfteil 1202 enthält entweder nichts, was bedeutet, daß er leer ist, oder er zeigt auf den ersten Block der SF-Liste in der SF-Kette, der in Fig. 12 als 1204 dargestellt ist.

Zeiger auf Liste freier Zuordnungsbereiche

Der Behälter-Kopfteil 1202 enthält einen Zeiger auf eine Liste 1206 freier Zuordnungsbereiche. Eine Liste freier Bereiche (RF-Liste) ist ein sequentieller Satz von Blöcken, der eine geordnete Liste freier Blockbereiche (Blockindex, Blocklänge) enthält. Die Bereiche sind der Länge nach geordnet, wobei der kürzeste der erste ist. Die Segmentverwaltungseinrichtung unterstützt zwei RF-Listen, um eine Simultanität zu unterstützen. Ein den Behälter schließender Prozeß sollte keinen anderen Prozeß blockieren, der fortlau fend Bereiche anfordert. Die Liste freier Zuordnungsbereiche (ARF-Liste) wird von Prozessen zum Zuordnen von zu verwendenden Bereichen von Blöcken verwendet.

Zeiger auf Liste freier Abschlußbereiche

Der Behälter-Kopfteil enthält auch einen Zeiger auf eine Liste 1208 freier Abschlußbereiche. Die Liste freier Abschlußbereiche (CRF-Liste) wird von Prozessen verwendet, die Schließen und eine Abfallsammlung und Integration ihrer freien Einzelblöcke und bereichsfreien Blöcke mit denen auf der Platte vornehmen. Wenn die ARF-Liste 1206 leer ist, werden die ARF-Liste 1206 und die CRF-Liste 1208 ausgetauscht.

Segmenttabellenblock-Zeiger

Der Behälter-Kopfteil 1202 beinhaltet einen Segmenttabellenblock-Zeiger, der auf eine Segmenttabelle (ST) 1210 zeigt. ST ist die Haupttabelle, die Bezüge zu allen Segmenten in einem Behälter enthält. Der nach ST führende Index für ein Segment wird zu seiner Segmentkennung. Jeder Segmenttabelleneintrag enthält:
eine Besitzerkennung ("OwnerID") - Besitzer dieses Segments
einen Besistzertyp ("Owner Type") - Typ des Besitzers (beispielsweise Behälter, Pool, Schicht)
einen Lesezählwert ("ReadCount") - eine Sperre, die die Anzahl der ausstehenden Leser dieses Segments angibt
eine Schreibsperre ("WriteLock") - eine Sperre, die einen ausstehenden Beschreiber dieses Segments angibt
einen Segmentblockindex - zeigt auf den Segmentblock in dieser Datei.
Bei der vorliegenden Ausführungsform belegt jedes Segment nur einen Block. Ein Segment kann jedoch bei einer anderen Ausführungsform einen sequentiellen Satz von Blöcken belegen, und der Segmentblockindex zeigt dann auf den ersten Block des sequentiellen Satzes.
Blockfaktor. Der Kopfteil 1202 beinhaltet auch einen Blockfaktoreintrag, der die Größe des Plattenblocks angibt, der bei der vorliegenden Datei verwendet wird.
Zeichenkette des Namens des Handhabungsmittels von Handhabungsmitteln. Der Kopfteil 1202 beinhaltet auch den Namen eines Handhabungsmittels von Handhabungsmitteln ("handler handler"), welches ein Handhabungsmittel ist, das aufgerufen werden kann, um die Namen der speziellen Handhabungsmittel für diesen Behälter zu erhalten.
Behälter-Informationsblockzeiger und Bytelänge. Der Kopfteil 1202 beinhaltet auch einen Behälter-Informationsblockzeiger und einen Bytelängeneintrag, der null ist (falls es keine Behälterinformation gibt) oder der auf einen Satz sequentieller Blöcke 1212 in der Datei zeigt, wo die Behälterinformation gehalten wird.
Pool-Namensindexblock-Zeig. Dieser Eintrag ist null, falls der Behälter keine Pools hat, oder er zeigt auf sequentielle Blöcke 1214, in denen der Pool-Namensindex (PNI) aufgenommen ist.
Benutzerzählwert. Jedesmal dann, wenn eine Sitzung bzw. ein Benutzer bzw. ein Prozeß einen Dateibehälter öffnet, erhöht die Speicherverwaltungseinrichtung diesen Zählwert um eins. Jedesmal dann, wenn eine Sitzung bzw. ein Benutzer bzw. ein Prozeß einen Dateibehälter schließt, verringert die Speicherverwaltungseinrichtung diesen Zählwert um eins. Jedesmal dann, wenn eine Sitzung bzw. ein Benutzer bzw. ein Prozeß eine geschlossene Datei zuerst öffnet, prüft die Speicherverwaltungseinrichtung diesen Zählwert, und falls der Zählwert größer als 0 ist, wurde die Datei nicht richtig geschlossen (wahrscheinlich infolge eines Systemzusammen bruchs), und es wird automatisch eine Wiederherstellung nach einem Systemzusammenbruch aktiviert.
Jeder Dateibehälter weist eine Segmenttabelle 1210 auf, auf die der Datei-Kopfteil 1202 zeigt. Die Segmenttabelle 1210 ist eine Matrix von Segmenttabelleneinträgen. Jeder Segmenttabelleneintrag enthält eine Besitzerkennung, einen Lesezählwert, eine Schreibsperre und einen Blockzeiger auf die Segmentliste für das Segment, das er repräsentiert.
Segmente mit der gleichen Besitzerkennung sind miteinander verkettet, was bedeutet, daß der Kopfteil des ersten Segments oder des Kopfsegments auf das nächste Segment (nicht auf einen Segmenttabelleneintrag) desselben Besitzers zeigt. Die Besitzerkennung ist die Segmentkennung des Kopfsegments. Diese Aussagen sind in der Speicherverwaltungseinrichtung in der Mitte einiger API-Aufrufe falsch. Es ist jedoch garantiert, daß sie abgesehen von einem Systemzusammenbruch um API-Aufrufe herum wahr sind.
Um eine Segmentliste mit einer Sperre zu versehen, braucht nur der Lesezählwert oder die Schreibsperre im Kopfsegment geändert zu werden.
Fig. 13 zeigt ein Segment 1302. Ein Segment belegt genau einen Block auf dem Speichermedium (bei der vorliegenden Darstellung eine Platte). Das Segment weist drei Abschnitte auf: einen Kopfteil 1304, eine Blockeintragsliste 1306 und eine Posteneintragsliste 1308. Die Einträge im Kopfteil 1302 sind die folgenden:
Blockeintragslisten-Beginn-Beginn-Byte-Relativzeiger - Relativzeiger in das Segment, bei dem die Blockeintragsliste beginnt.
Blockeintragslisten-Ende-Byte-Relativzeiger - Relativzeiger in das Segment, bei dem die Blockeintragsliste endet.
Posteneintragslisten-Ende-Byte-Relativzeiger - Relativzeiger in das Segment, bei dem die Posteneintragsliste endet.
Zählwert freier Blockeinträge - gibt die Anzahl der freien Blockeinträge in dem Segment an.
Zählwert freier Posteneinträge - gibt die Anzahl der freien Posten in dem Segment an.
Größte Lücke - die größte Lücke in allen Blockbereichen, die diesem Segment aktuell zugeordnet sind.
Nächstes Segment - zeigt auf das nächste Segment in dieser Segmentliste oder auf Null, falls dies das Ende der Liste ist.
Jeder der Blockeinträge 1306 enthält einen Blockzeiger und einen Blockzählwert. Der Blockzeiger gibt den Anfangsblock eines Blockbereichs an, der einen Zählwert für die Blocklänge aufweist.
Jeder der Posteneinträgen 1308 enthält einen Blockeintragsindex, einen Byte-Relativzeiger und eine Bytelänge. Der Blockeintragsindex gibt an, in welchem Blockbereich sich der Posten befindet, und der Byte-Relativzeiger und die Bytelänge geben die genauen Bytes an. Posten können mehrere Blöcke umfassen. Mehrere Posten können innerhalb desselben Blockbereichs vorhanden sein.
Die Speicherverwaltungseinrichtung ordnet Blockeinträge und Posten dynamisch zu, indem sie veranlaßt, daß die zwei Listen dynamisch zueinander hinwachsen, wobei das Ende der Blockeintragsliste und auch der Beginn der Posteneintragsliste erhalten bleiben.
Wenn ein Prozeß zuerst ein Behälter-/Pool-/Schicht- Zugriffsmittel (CPL-Zugriffsmittel) auf einen Dateibehälter positioniert, öffnet die Speicherverwaltungseinrichtung die Datei. Falls der Prozeß die Datei zuerst öffnet, prüft die Speicherverwaltungseinrichtung den Benutzerzählwert in dem Kopfteil und führt eine Wiederherstellung nach einem Systemzusammenbruch aus und setzt den Benutzerzählwert auf 1, falls er von Null verschieden ist. Der Kopf der SF-Kette wird entfernt und im Rahmen des Prozesses angeordnet, wodurch die nächste SF zum neuen Kopf der SF-Kette gemacht wird. Jedem Prozeß wird eine SF gegeben, so daß er unabhängig freie Blöcke herausgreifen kann, ohne andere Prozesse oder sich selbst zu blockieren. Falls es am Kopf der Kette keine SF gibt, wird eine neue SF erzeugt und teilweise aufgefüllt, wie weiter unten in der Zuordnung ("Allocation") erklärt wird.
Wenn Einermengenblöcke im Rahmen des Prozesses für neue Posten, Schichten, Pools oder Segmente erforderlich sind, nimmt die Speicherverwaltungseinrichtung sie aus der SF, die zu dem Prozeß gehört. Wenn diese SF leer ist, erzeugt die Speicherverwaltungseinrichtung eine neue SF durch Zuordnen freier Blöcke von der ARF oder vom Ende der Datei und indem sie sie in der neuen SF anordnet (die wahrscheinlich den ersten dieser Blöcke belegt, die zugeordnet wurden), welche dem Prozeß gegeben sind. Wenn ein Blockbereich im Rahmen des Prozesses für neue Posten, anwachsende Posten und dergleichen erforderlich ist, ordnet die Speicherverwaltungseinrichtung den (besten bzw. ersten bzw. intakten) passenden Bereich von der ARF auf der Platte zu. Falls die ARF leer ist, tauscht die Speicherverwaltungseinrichtung die ARF- und die CRF-Liste aus. Falls die ARF noch leer ist, ordnet die Speicherverwaltungseinrichtung den erforderlichen Bereich am Ende der Datei zu.
Wenn die Speicherverwaltungseinrichtung Einermengen- Blöcke freigibt, ordnet sie sie in der SF des Prozesses an. Wenn Bereichsblöcke freigegeben werden, werden sie in der CRF angeordnet.
Wenn ein Prozeß das letzte CPL-Zugriffsmittel auf einen Behälter positioniert, der sich in einer Entfernung von diesem Behälter befindet, durchläuft die Speicherverwaltungseinrichtung den Prozeß des Schließens der Datei. Der Rahmen löst die verbleibenden SFs mit der SF-Kette auf der Platte und die CRF auf. Der Benutzerzählwert wird verrin gert, und dieser Zugriffsweg des Prozesses auf die Datei wird geschlossen.
Die Speicherverwaltungseinrichtung verwendet intern eine Segmentverwaltungseinrichtung zum Verwalten von Segmenten. Die Segmentverwaltungseinrichtung unterstützt die folgenden Aufrufe:
AllocRef OpenSegList(OwnerID,permissions) - die Speicherverwaltungseinrichtung ruft diese Routine zuerst mit der Benutzerkennung ("OwnerID") der Segmentliste, auf die sie zugreifen möchte, und mit Erlaubnissen (R, W, Φ) auf. In der hier verwendeten Bedeutung hinsichtlich Erlaubnissen bezeichnet R eine Leseerlaubnis, W eine Schreiberlaubnis und Φ weder eine Lese- noch eine Schreiberlaubnis. Es wird ein Zuordnungsbezug ("AllocRef") zurückgegeben, den die Speicherverwaltungseinrichtung dann mit allen künftigen Aufrufen dieser Sitzung mit dieser Segmentliste verwendet. Ein Zuordnungsbezug enthält eine Benutzerkennung, einen Segment-Cache- Speicher, die größte Lücke des Segments und eine Angabe des ersten Segments mit freien Posten.
ItemID Newltea(AllocRef,size) - diese Routine wird aufgerufen, um einen neuen Posten in der durch die Zuordnungsreferenz ("AllocRef") bezeichneten Segmentliste zuzuordnen. "NewItem" versucht, einen neuen Posten mit der Länge "size" zu erzeugen, wobei es die Segmentliste durchläuft und nach einem freien Posteneintrag und möglicherweise einem freien Blockeintrag sucht (abhängig von size), um sie dem Posten zuzuordnen.
FreeItem(AllocRef, ItemID) - diese Routine wird aufgerufen, um den Posten "ItemID" freizugeben. Der Posteneintrag wird für eine künftige Verwendung freigemacht, und der Abschnitt des Blockbereichs, welcher verwendet wurde, wird auch implizit zur Wiederverwendung freigemacht. Falls der Posten der letzte Posten war, der in dem Segment zu befreien war, wird das Segment aus der Liste entnommen und befreit. Der sich ergebende befreite Block wird zur SF in dem Rahmen hinzugefügt.
ResizeItem(AllocRef, ItemID, size, relocateitem) - diese Routine wird aufgerufen, um einen Posten zu vergrößern oder zu verkleinern. Beim Verkleinern eines Postens wird einfach die im Posteneintrag festgelegte Länge geändert. Beim Vergrößern versucht die Segmentverwaltungseinrichtung zuerst, den Posten am Ort zu vergrößern. Falls die Größe des Postens nicht am Ort geändert werden kann, und das Hinweiszeichen zum Ändern des Orts des Postens ("relocateitem flag") wahr ist, und es ausreichend Platz auf der Platte gibt, um den größeren Posten zu speichern, durchläuft die Segmentverwaltungseinrichtung die folgenden Schritte, bis es ihr gelingt, die Größe des Postens zu ändern, falls dies möglich ist.
1. es wird versucht, den Posten ans Ende seines Blockbereichs zu verschieben
2. falls es einen weiteren Blockeintrag im Segment des Postens gibt, wird dem Posten in dem Blockeintrag ausreichend Platz zugeordnet und der Posten dorthin verschoben
3. allen Posten im Blockbereich der Posten wird ausreichend Platz zugeordnet, alle im Blockbereich der Posten enthaltenen. Posten werden komprimiert bzw. zum neuen Blockbereich verschoben, der Blockbereich wird am Blockeintrag der Posten angeordnet und der alte Blockbereich wird freigegeben
CloseSegList(AllocRef) - diese Routine wird aufgerufen, um einen Zuordnungsbezug ("AllocRef") zu schließen, wenn die zugeordnete Segmentliste beendet wurde, so daß andere Benutzer auf sie zugreifen können.
GetItem (AllocRef, ItemID, offset, &length, &void*) - ruft den Abschnitt des Postens ab, der durch den Relativzeiger ("offset") und den Längenwert ("length") angegeben ist und ordnet ihn in dem Puffer an, auf den der Pufferzeiger ("bufferptr") zeigt. Falls der Pufferzeiger null ist, wird ein Puffer zugeordnet und zurückgeführt. Falls der Relativzeiger ("offset") und der Längenwert ("length") irgendwelche vordefinierten Werte sind, wird der ganze Posten von der Platte geladen. Die tatsächliche Anzahl der ausgelesenen Bytes wird in der Variablen "length" zurückgegeben.
PutItem (AllocRef,Item ID, offset, &length, void*) - schreibt in den Abschnitt des Postens "ItemID", der durch "offset" und "length" des Pufferzeigers angegeben ist. Die tatsächliche Anzahl der nach außen geschriebenen Bytes wird in "length" zurückgegeben.
boolean ChangePerm(AllocRef, permissions) - versucht, den Zugriff auf den Zuordnungsbezug ("AllocRef") in denjenigen zu ändern, der im Erlaubnisargument spezifiziert ist. Die Änderungen x → x, W → R, W → Φ, R → Φ sollen stets gelingen. Die anderen möglichen Änderungen können gelingen oder nicht, falls andere Leser/Schreiber vorhanden sind.
Compact (AllocRef) - komprimiert die durch AllocRef angegebene Segmentliste und sammelt darin enthaltenen Abfall.
MergeItems (*ItemID ) - führt die gegebenen Posten im ersten Posten in der Matrix zusammen.
Jeder Pool in einem Behälter ist mit einem Namen versehen, und sein Name ist innerhalb des Behälters eindeutig. Der Pool-Name ist daher ein garantierter Weg zum Identifizieren eines dem Behälter gegebenen Pools. Der in jedem Behälter vorhandene Pool-Namensindex 1214 wird von der Speicherverwaltungseinrichtung verwendet, um die Pool-Namen und die entsprechenden Pools zu erhalten. Der PNI wird nicht in einem Segment gespeichert. Er wird abhängig von seiner. Größe direkt in einem Einermengen-Block oder einem Bereichsblock gespeichert. Die Blocknummer und die Länge des PNI werden in dem Behälter-Kopfteil gespeichert.
Der PNI 1214 ist in Fig. 14 dargestellt und enthält drei Abschnitte: einen Kopfteil 1402, eine Pool-Namens-/Pool- Segment-Liste (SL) 1404 und einen sortierten Index 1406. Der Kopfteil enthält die Relativzeiger vom Beginn des Blocks zu jedem der anderen beiden Segmente, und er enthält die Längen der anderen beiden Abschnitte. Die Pool-Namens/Pool-SL ist eine nicht sortierte Liste von Pool-Namen in dem Behälter zusammen mit den Pool-Kennungen ("PoolIDs") der entsprechen den Pools. Die Pool-Kennung wird verwendet, um den Ort der Segmentliste (SL) für einen Pool zu bestimmen, und sie wird weiter unten in näheren Einzelheiten beschrieben. Der sortierte Index ist eine Liste von Einträgen, die Relativzeiger vom Beginn der Pool-Namens-/Pool-Kennungs-Liste enthält. Jeder dieser Einträge entspricht einem Pool. Die Reihenfolge der Liste ist die sortierte Reihenfolge der Pool-Namen.
Bei der Darstellung aus Fig. 14 ist die Pool-Namens- /Pool-Kennungs-Liste 1404 vergrößert, um ihren Inhalt zu zeigen. Sie enthält insbesondere vier Einträge, wobei jeder von ihnen den Namen eines Pools und seine Kennung (die die Besitzerkennung des ersten Segments des Pools ist) enthält. Bei der Darstellung enthält der erste Eintrag den Namen "erster Pool" und die Kennung 1, der zweite Eintrag den Namen "zweiter Pool" und die Kennung 4, der dritte Eintrag den Namen "dritter Pool" und die Kennung 6 und der vierte Eintrag den Namen "vierter Pool" und die Kennung 8. Weiterhin geht jedem Eintrag eine Angabe bezüglich der Länge des Pool-Namens voraus. In Fig. 14 ist dargestellt, wie der PNI 1402 erscheinen würde, falls die vier Pools in der Reihenfolge ihrer Namen erzeugt würden. Es sei darauf hingewiesen, daß der sortierte Index 1406 in alphanumerischer Reihenfolge und nicht in der Reihenfolge ihrer Erzeugung auf die vier Pool-Namens-/Kennungs-Listeneinträge zeigt.
Wenn die Speicherverwaltungseinrichtung einen Pool erzeugt, prüft sie den zugeführten Pool-Namen bezüglich des PNI unter Verwendung einer binären Suche bezüglich des sortierten Index und der Pool-Namen, auf die er sich bezieht. Falls der Pool-Name nicht existiert, fügt die Speicherverwaltungseinrichtung den Pool-Namen und seine entsprechende Pool-Kennung dem unteren Teil der Pool-Namens- /Pool-Kennungs-Liste hinzu. Der sortierte Index wird auch aktualisiert, so daß er den neuen Pool beinhaltet. Falls ein Pool zerstört werden soll, sucht die Speicherverwaltungseinrichtung seinen Namen unter Verwendung der binären Suche bezüglich des sortierten Index und der Pool-Namen, auf die er sich bezieht. Falls der Pool-Name existiert, kann die Zerstörung fortgesetzt werden.
API-Aufrufe, die die folgenden Funktionen ausführen, können Simultanitätsimplikationen aufweisen: SMNewPool (füge einen Pool-Namen hinzu), SMDestroyPool (lösche einen Pool- Namen), SMPositionCPLAccessor (Pool-Namens-Suche) und SMNewCPLAccessor (Pool-Namens-Suche). Zum Lesen oder Schreiben des PNI muß im Block ein Semaphor eingerichtet werden. Dies bedeutet auch daß während des Zugriffs jeder andere Prozeß gesperrt wird. Daher sollte der Prozeß den Semaphor freigeben, sobald seine Operation beendet ist. Da alle Operationen bezüglich des PNI dynamisch selten sind, wird durch die Notwendigkeit, andere Prozesse zu blockieren, kein erheblicher Simultanitätsengpaß erzeugt. Es sei bemerkt, daß Semaphoren derart verwirklicht werden sollten, daß es der Speicherverwaltungseinrichtung ermöglicht ist, viele Semaphoren lokal und im ganzen Netzwerk gleichzeitig und schnell zu manipulieren. Weiterhin sollten Semaphoren auf einer Blockebene statt auf einer Dateiebene verwirklicht werden.
Segmente sind in Segmentlisten (SLs) organisiert, die tatsächlich Ketten von Segmenten sind. Es gibt zwei Arten von SLs - Pool-SLs, wie 1216, und Schicht-SLs, wie 1218 und 1220 (Fig. 12). Um eine SL zu finden, wird die Benutzerkennung (die Segmentkennung des Kopfsegments) verwendet.
Für einen Anwendungsprozeß gibt es zwei Arten von Sperren für SLs, nämlich eine Schreibsperre ("Write-Lock") und eine Lesesperre ("Read-Lock"). Um eine dieser Sperren festzulegen, muß zuerst ein Semaphor bei der ST erhalten werden. Jeder andere Prozeß, der eine Sperre für irgendeine SL sucht, wird dann bezüglich der ST blockiert. Der Semaphor sollte freigegeben werden, sobald die Operation bezüglich der ST abgeschlossen wurde, so daß andere anhängige Anforderungen von Sperren verarbeitet werden können.
Da die meisten SLs von Prozessen für einen Nurlesezugriff geteilt verwendet werden können, erhält die Speicherverwaltungseinrichtung im entsprechenden ST-Eintrag (also im ersten Segment der SL) einen Lesezählwert, um die Anzahl der Leser zu verfolgen. Wenn ein Prozeß eine Schreibsperre bezüglich einer SL anfordert, erhöht die Speicherverwaltungseinrichtung den Lesezählwert. Sobald der Prozeß das Lesen bezüglich der SL beendet hat, sollte er die Lesesperre aufheben, so daß die Speicherverwaltungseinrichtung den Lesezählwert verringern kann.
Eine Schreibsperre bezüglich einer SL garantiert ein exklusives Lesen bzw. Schreiben hinsichtlich der SL. Daher kann eine Schreibsperre nur dann erfolgreich erhalten werden, wenn der Lesezählwert null ist und die SL noch keine Schreibsperre ausgegeben hat. Sobald die Schreibsperre durch Setzen des Schreibsperrenfelds im ST-Eintrag auf wahr ("true") gewährt wurde, kann kein anderer Prozeß zum Lesen oder zum Schreiben auf die SL zugreifen. Ähnlich wie beim Lesen sollte der Prozeß die Schreibsperre aufheben, sobald das Schreiben abgeschlossen ist, so daß andere Prozesse auf die SL zugreifen können.
In Fig. 15 ist die Struktur eines Pool-Segments 1216 dargestellt (Fig. 12). Jeder Pool in einem Behälter weist eine Pool-SL auf, die alle Informationen über den Pool einschließlich der Schichttopologie, der Schichtinformation, des Blop-Kennungs-Zuordnungsmittels und der Benutzer-Pool- Information enthält. Es gibt mehrere Pool-SLs in einem Behälter (der Anzahl der, Pools gleichend). Die Besitzerkennung (also die Segmentkennung des ersten Segments) der Pool- SL wird zur Pool-Kennung.
Jede Pool-SL enthält nur ein Segment, und das Segment hat nur fünf Posten. Wie in Fig. 15 dargestellt ist, entsprechen die fünf Posten zusätzlich zu einem Kopfteil 1502, der auf den Beginn von jedem der fünf Posten zeigt, einer Schichtmatrix 1504, einem Schichtnamensindex 1506, einem Blop-Kennungs-Zuordnungsmittel ("BlopID Allocator") 1508, einer Sammlung von Schicht-SLs 1510 für alle Schichten in dem Pool und einer Benutzer-Pool-Information 1512. Ihre Reihenfolge in dem Segment ist vorgegeben.
Die Schichtmatrix 1504 gibt die aktuelle Topologie der Schichten in dem Pool an. Ihre veränderliche Größe hängt von der Anzahl der Schichten in dem Pool ab. Die Matrix ist tatsächlich eine zweidimensionale Matrix, die die topologische Beziehung zwischen Schichten darstellt. Die Achsen der zweidimensionalen Matrix sind die Schichten, und jedes Matrixelement zeigt, ob eine Schicht unmittelbar oberhalb, oberhalb, unmittelbar unterhalb oder unterhalb der anderen Schicht oder in einem anderen Zweig als diese liegt.
Die Diagonalelemente der Schichtmatrix brauchen keine topologische Beziehung zwischen der Schicht, die auf der horizontalen Achse angegeben ist, und der Schicht, die auf der vertikalen Achse angegeben ist, angeben, da beide Achsen dieselbe Schicht angeben. Diese Elemente enthalten statt dessen drei Hinweiszeichen. Eines der Hinweiszeichen gibt an, ob die Schicht eine Bodenschicht ist, und ein zweites Hinweiszeichen gibt an, ob die Schicht von einem fernen Pool ("Remote Pool") abgeleitet ist. Das dritte Hinweiszeichen wird zum Sperren einer Schicht verwendet, wie weiter unten erörtert wird.
In Fig. 15A ist der Inhalt einer Schichtmatrix 1504 für die in Fig. 16B dargestellte Schichttopologie dargestellt. Wie in Fig. 16B dargestellt ist, enthält der Pool insbesondere vier Schichten L1, L2, L3 und L4. Die Schicht L1 ist die Bodenschicht, und die Schicht L2 liegt unmittelbar oberhalb der Schicht L1. Die Schichten L3 und L4 liegen beide unmittelbar oberhalb der Schicht L2. Jedes Element der Schichtmatrix 1504 (mit Ausnahme der Diagonalelemente) gibt die topologische Beziehung der auf der horizontalen Achse angegebenen Schicht zur auf der vertikalen Achse angegebenen Schicht an. Der folgende Code wird verwendet:
A Die Schicht auf der horizontalen Achse liegt unmittelbar oberhalb der Schicht auf der vertikalen Achse
a Die Schicht auf der horizontalen Achse liegt oberhalb der Schicht auf der vertikalen Achse
B Die Schicht auf der horizontalen Achse liegt unmittelbar unterhalb der Schicht auf der vertikalen Achse
b Die Schicht auf der horizontalen Achse liegt unmittelbar unterhalb der Schicht auf der vertikalen Achse
X Die Schicht auf der horizontalen Achse liegt nicht im selben Zweig wie die Schicht auf der vertikalen Achse
* Das Element enthält Hinweiszeichen für die auf der horizontalen und der vertikalen Achse angegebene Schicht, (welche gleich sind).
Wie ersichtlich ist, ist die Schicht L1 so angegeben, daß sie sich unmittelbar unterhalb der Schicht L2 und transitiv unterhalb der Schichten L3 und L4 befindet. Die Schicht L2 ist so angegeben, daß sie sich unmittelbar oberhalb der Schicht L1 und unmittelbar unterhalb der beiden Schichten L3 und L4 befindet. Die Schicht L3 ist so angegeben, daß sie sich transitiv oberhalb der Schicht L1 und unmittelbar oberhalb der Schicht L2 befindet und daß sie sich in einem anderen Zweig als die Schicht L4 befindet. Die Schicht L4 ist so angegeben, daß sie sich transitiv oberhalb der Schicht L1, unmittelbar oberhalb der Schicht L2 und in einem anderen Zweig als die Schicht L3 befindet.
Normalerweise kann die Schichtmatrix nicht sicher in einem Cache-Speicher gespeichert werden. Der Kopfteil 1502 des Pool-Segments 1216 enthält jedoch eine Schichtmatrix- Erzeugungsnummer für die Schichtmatrix 1504. Wenn ein Prozeß die Matrix ausliest, kann er die Matrix und die zugeordnete Erzeugungsnummer in einem Cache-Speicher speichern. Wenn der Prozeß die Schichttopologie beim nächsten Mal herausfinden muß, braucht er nur die Erzeugungsnummer zu prüfen, ohne erneut in der Matrix zu lesen. Falls die in einem Cache- Speicher gespeicherte Erzeugungsnummer und die auf der Platte vorhandene übereinstimmen, ist die in einem Cache- Speicher gespeicherte Matrix noch gültig. Ansonsten muß die Matrix erneut geladen werden. Hierdurch kann ein Lesevorgang eingespart werden und daher die zum Sperren der Pool-SL erforderliche Zeit verringert werden.
Im folgenden ist die Struktur der Schichtmatrix 1504 in der Sprache C beschrieben: 1992 Apple Computer
Es sei bemerkt, daß das Speichern der Schichtmatrix optimiert werden kann, indem sie als eine dreieckige Matrix und nicht als eine rechteckige Matrix gespeichert wird, weil die obere Hälfte die gleichen Informationen wie die untere Hälfte enthält.
Einer Schicht kann ein Name (oder Namen) zugeordnet sein oder nicht. Falls dies der Fall ist, wird der Schichtname (die Schichtnamen) in einer als Schichtnamensindex (LNI) bezeichneten Struktur gespeichert. Ihre Struktur und Verwendung ähneln denjenigen von PNI. Wie in Fig. 17 dargestellt ist, enthält der LNI 1506 einen Kopfabschnitt 1702, in dem die Relativzeiger vom Beginn des Blocks und die Längen der beiden anderen Abschnitte gespeichert sind. Er enthält auch eine Schichtnamens-/Schichtkennungs-Liste 1704, die eine nicht sortierte Liste von Schichtnamen und den Schichtkennungen der entsprechenden Schichten ist. Der LNI 1506 enthält auch einen sortierten Index 1706, der eine Liste von Einträgen ist, die Relativzeiger vom Beginn der Schichtnamens-/Schichtkennungs-Liste enthält, welche in der alphanumerischen Reihenfolge der Schichtnamen sortiert ist. In Fig. 17 ist der Inhalt der LNI 1506 für die Schichttopologie von Fig. 16B und für die Situation, bei der die Schicht L1 als "Original" bezeichnet ist, bei der die Schicht L2 als "aktuell" bezeichnet ist, bei der die Schicht L3 als "von Dave" bezeichnet ist und bei der die Schicht L4 als "von Tantek" bezeichnet ist, dargestellt.
Es gibt Gelegenheiten, bei denen ein Schichtname bei einer gegebenen Schichtkennung gefunden werden muß. Der Aufbau des LNI bei der vorliegenden Ausführungsform erzwingt ein sequentielles Durchsuchen der Schichtnamens- /Schichtkennungs-Liste. Eine Möglichkeit, dies zu verbessern, besteht darin, die Schichtnamens-/Schichtkennungs- Liste unter Verwendung der Schichtkennungen zu sortieren. Es kann eine binäre Suche vorgenommen werden, um den Schichtnamen sehr schnell zu finden.
Wie zuvor erwähnt wurde, weist jede Schicht eine SL auf, um ihre Informationen und Daten zu speichern. Der Schichtsammlungsabschnitt 1510 der Pool-SL 1216 ist eine lineare Matrix von Bezügen zu den Schicht-SLs. Der in die Schichtsammlung weisende Index der Schicht wird zur Schichtkennung.
Schichtkennungen müssen permanent sein, weil sie verwendet werden, um sich sowohl innerhalb eines Prozesses als auch über Prozesse hinweg auf Schichten zu beziehen. Es gibt jedoch Probleme mit permanenten Schichtkennungen, da durch ihre Permanenz die Wiederverwendbarkeit begrenzt ist und dadurch unnötig Platz im Speichermedium belegt werden kann. Falls ein Prozeß beispielsweise eine Folge von Neu, Sichern und Schließen ("New, Save and Close") ausführt, wird eine Reihe leerer Schichten erzeugt und zerstört. Diesen zerstörten Schichten werden jedoch Schichtkennungen und Speicherplatz in der Schichtsammlung zugewiesen. Zum Wiederverwenden dieser Schichtsammlungseinträge wzrd jeder Schichtkennung eine Erzeugungsnummer zugeordnet. Jedesmal dann, wenn eine Schicht zerstört wird, wird am Ort der Schicht-SL ein Beseitigungshinweis gespeichert, und die Erzeugungsnummer wird um 1 erhöht. Wenn der Prozeß durch eine Schichtkennung auf eine Schicht zugreifen möchte, muß er die Erzeugungsnummer prüfen. Falls die Erzeugungsnummer, die der Prozeß aufweist, derjenigen auf der Platte gleicht, kann die Operation fortgesetzt werden. Eine andere Erzeugungsnummer bedeutet, daß eine neue Schicht unter Verwendung derselben Schichtkennung und von Speicher in der Schichtsammlung erzeugt worden ist.
In Fig. 18 ist die Struktur der Schichtsammlung 1510 dargestellt. Jeder Eintrag enthält eine Schichtdaten-SL- Nummer, die die Segmentkennung des ersten Segments der durch den Eintrag repräsentierten Schicht ist, und eine Erzeugungsnummer. Falls eine Schicht zerstört worden ist, ist ihre Schichtdaten-SL-Nummer 0, und ihre Erzeugungsnummer ist größer als 0. Falls eine Schicht zerstört worden ist und gegenwärtig wiederverwendet wird, ist ihre Schichtdaten-SL- Nummer von Null verschieden, und ihre Erzeugungsnummer ist größer als 0. Da bei der vorliegenden Ausführungsform ein Postenblock 2³² Bytes an Informationen enthalten kann und jeder Eintrag 8 Bytes (2³ Bytes) benötigt, kann die Schichtsammlung 1510 bis zu 2²&sup9; Schichten enthalten. Dies bedeutet auch, daß ein Pool auf 2²&sup9; Schichten begrenzt ist.
Im folgenden wird eine Definition der Schichtsammlung 1510 in der Sprache C gegeben: 1992 Apple Computer
Jede Blop hat eine als Blop-Kennung bezeichnete permanente Kennung. Blop-Kennungen sind innerhalb eines Pools eindeutig. Der Pool ist daher dafür verantwortlich, sich über die verwendeten Blop-Kennungen auf dem laufenden zu halten und nicht verwendete Blop-Kennungen für neue Blops auszugeben. Jeder Pool-SL ist ein Posten zum Verwalten eines Blop-Kennungs-Zuordnungsmittels (BID) zugewiesen.
Ein Blop-Kennungs-Zuordnungsmittel 1508 ist in Fig. 19 dargestellt. Es besteht aus einem Kopfteil 1902 und einer Matrix 1904 von Datensätzen. Der Kopfteil 1902 enthält eine Haupt-Hochwassermarkierung ("Master High Water Mark") 1906, die Anzahl 1908 der Bereiche, die sich aktuell im Zuordnungsmittel ("Allocator") befinden und eine Bitzuordnung 1910, die anzeigt, welche Bereiche aktuell verwendet werden. Jeder Datensatz 1904 unterhält einen Bereich von Blop-Kennungen, indem er das Ende des Bereichs 1912 und die Hochwassermarkierung 1914 (also die höchste Blop-Kennung, die von dem Prozeß, dem der Bereich aktuell zugewiesen ist, verwendet worden ist) in dem Bereich speichert. Wenn ein Prozeß einen Schreibzugriff auf eine Schicht erhält, wird einer dieser Datensätze dem Prozeß zugewiesen. Daher können mehrere simultane Prozesse Blops unter Verwendung verschiedener Bereiche des Blop-Kennungs-Platzes erzeugen.
Falls ein Prozeß alle Blop-Kennungen in dem zugewiesenen Bereich aufbraucht, kann er vom Blop-Kennungs-Zuordnungsmittel einen anderen Bereich anfordern. Der Datensatz, der diesen vollen Bereich enthält, wird dann vom Blop-Kennungs- Zuordnungsmittel entfernt. Das Blop-Kennungs-Zuordnungsmittel enthält daher nur Bereiche mit nicht verwendeten Blop- Kennungen. Falls alle Bereiche aufgebraucht sind, erzeugt das Blop-Kennungs-Zuordnungsmittel neue Bereiche für weitere nicht verwendete Blop-Kennungen. Es sei bemerkt, daß die im Blop-Kennungs-Zuordnungsmittel gespeicherten Bereiche nicht die gleiche Große aufweisen müssen.
Der Benutzer-Pool-Informationsabschnitt 1512 des Pool- Segments 1216 ist für Benutzer verfügbar, um Informationen zu speichern, die sich auf den Pool beziehen. Die Benutzer- Pool-Information ist in einem Posten im Pool-SL gespeichert und wird als ein Strom von Bits behandelt. Die Größenbegrenzung des Postens der Segmentverwaltungseinrichtung (2³² Bytes) ist die maximale Größe der Benutzer-Pool-Information für einen Pool.
Hinsichtlich der Simultanität sei bemerkt, daß viele Prozesse eine Pool-Liste gleichzeitig lesen können, daß es jedoch zu einem Zeitpunkt nur einen Leser geben kann. Immer dann, wenn ein Prozeß einen Lesezugriff auf eine Pool-SL hat, werden daher alle Prozesse, die einen Schreibzugriff auf dieselbe Pool-Pool-SL anstreben, blockiert. Andererseits blockiert ein Prozeß mit einem Schreibzugriff alle Prozesse, die versuchen, auf dieselbe Pool-SL zuzugreifen. Da die meisten Operationen bezüglich einer Pool-SL dynamisch selten sind, kann ein Prozeß einen exklusiven Lese- und Schreibzugriff auf eine Pool-SL erhalten, wobei eine sehr geringe Wahrscheinlichkeit des Blockierens anderer Prozesse besteht. Das gleiche gilt für mäßig häufige Operationen, für deren Ausführung eine kurze Zeit erforderlich ist. Die Schreibsperre und der Lesezählwert für die Pool-SL werden in dem entsprechenden ST-Eintrag gehalten. Die detaillierten Operationen des Festlegens und Aufhebens der Sperre werden nach folgend umrissen. Der folgende Pseudocode ist ein Beispiel für ein bevorzugtes Szenario zum Aktualisieren einer Pool- SL:
Es gibt einige mäßig häufige Operationen, zu deren Abschluß eine lange Zeit erforderlich ist (beispielsweise MoveAllChangesDown). Diese Aufrufe werden hauptsächlich für Mehrschichtoperationen verwendet. Um andere Prozesse zuzulassen, bei deren Ablauf diese Schichten nicht betroffen sind, sieht die Schichtmatrix einen anderen Satz von Sperren für die Mehrschichtoperationen vor. Die Idee besteht darin, daß der Prozeß, der eine Mehrschichtoperation ausführt, die Pool-SL nur gerade lange genug blockieren würde, um diese Schichtmatrixsperren festzulegen. Nachdem die Pool-SL aufgehoben wurde, finden jegliche anderen Prozesse, die eine Operation bezüglich irgendwelchen dieser Schichten ausführen möchten, sie blockiert. Die Schichten werden für andere Prozesse verfügbar, wenn der ursprüngliche Prozeß die Schichtmatrixsperren aufhebt. Der folgende Pseudocode zeigt, wie MoveAllChangesDown verwirklicht werden kann:
Fig. 20 zeigt die Struktur eines Schichtsegments 2002, das beispielsweise eines der Segmente der Schichtsegmentliste 1218 ist (Fig. 12). Eine Schicht-SL wird verwendet, um Typen und Blops zu speichern und zu organisieren, die in der Schicht erzeugt oder konkret dargestellt sind. Blops weisen Merkmale und Daten auf, und Typen (mit Ausnahme von Grundtypen ("Basic Types")) weisen Merkmale auf. Merkmalew und Daten sind in Posten einer Schicht-SL gespeichert. Die entsprechenden Postenkennungen werden die Merkmalskennungen (PID) und Datenkennungen (DID). Es gibt hinsichtlich der Struktur keinen Unterschied darin, wie Merkmale und Daten gespeichert und manipuliert werden, weil beide Posten eines Segments sind. Sie sind lediglich in unterschiedlicher Weise benannt, um zu zeigen, daß sie verschiedene Arten von Informationen enthalten. Zusammengesetzten Typen und Blops eines zusammengesetzten Typs kann eine Hierarchie von PIDs und DIDs zugeordnet sein. PIDs und DIDs werden weiter unten in näheren Einzelheiten beschrieben. Fig. 21 ist ein Beispiel einer Blop eines zusammengesetzten Typs.
Jedes Segment kann bis zu (Blockgröße - Kopfteilgröße - Anzahl der Blockeinträge)/9 Posten enthalten. Daher kann jedes von diesen bis zur selben Anzahl Merkmals- und Datenblöcke aufweisen. Dies steht jedoch nicht direkt damit in Zusammenhang, wieviele Blops gespeichert werden können, weil eine Blop mehr als einen PDB (Merkmalsdatenblock) und mehr als einen DDB (Datendatenblock) verwenden kann.
Wiederum mit Bezug auf Fig. 20 sei bemerkt, daß ein Schichtsegment 2002 einen Kopfabschnitt 2004, eine Sichtbarkeitsliste 2006, einen Blop-Namensindex (BNI) 2008 sowie einen Typ-Namensindex (TNI) 2010 zusätzlich zu den Datensätzen 2012 aufweist. Der Kopfabschnitt 2004 beinhaltet u. a. einen Zeiger auf das nächste Schichtsegment in der Schicht- SL 1218, einen Zählwert der Anzahl freier Posten, die größte Lücke, einen freien Blockeintrag und Erlaubnisse. Er beinhaltet auch Zeiger auf die anderen Abschnitte des Schicht segments 2002 unter Einschluß von Zeigern auf die einzelnen Posten in dem Datensatzabschnitt 2012.
Die Sichtbarkeitsliste 2006 betrifft in der Schicht erzeugte und konkret dargestellte Blops. Es ist möglich, durch Durchlaufen von Sichtbarkeitslisten einer Schicht und aller unter ihr liegenden Schichten die "Ansicht" der Schicht zu bestimmen und alle Blops in der Ansicht zu erreichen.
Es gibt zwei Arten von Sichtbarkeitslisten. Die erste Art ist die vollständige Sichtbarkeitsliste ("Complete Visibility List") (CVL). Die CVL ist eine Matrix, die alle von dieser Schicht sichtbaren Blops angibt. Sie beinhaltet demgemäß in dieser Schicht erzeugte und konkret dargestellte Blops sowie nicht geänderte Blops aus den darunterliegenden Schichten. Die Blop-Kennung ist in der Reihenfolge der CVL implizit gegeben.
Fig. 22A ist ein Beispiel einer CVL für eine Schicht, wie diejenige, die in Fig. 22B symbolisch dargestellt ist. In Fig. 22A weist die erste Blop 2202 implizit die Blop- Kennung 0 auf, weist die zweite Blop 2204 implizit eine Blop-Kennung 1 auf und so weiter. Jeder Matrixdatensatz enthält die Haupt-DID der Blop, auf die er sich bezieht. Von der Haupt-DID kann auf den restlichen Teil der DID-Hierarchie zugegriffen werden. Die PID der Blop ist auch in der DID gespeichert, so daß die Merkmale auch abgerufen werden können. Bei einer anderen Ausführungsform könnte ein CVL- Eintrag sowohl die DID als auch die PID der Blop enthalten. Auf die Blop 0 kann nicht direkt durch einen Prozeß zugegriffen werden. Sie ist für Schichtmerkmale reserviert. Falls es kein Merkmal für eine Schicht gibt, enthält der Datensatz eine vordefinierte DID (0), um zu zeigen, daß der Schicht kein Merkmal zugeordnet ist. Schichtmerkmale sind ein Ort, wo die Speicherverwaltungseinrichtung Buchhaltungsinformationen über eine Schicht speichern kann. Verschiedene Ausführungsformen könnten dort verschiedene Informationen speichern oder sie gänzlich fortlassen oder sie aufnehmen und zulassen, daß ein Prozeß in der normalen Weise direkt auf sie zugreift.
Die zweite Art einer Sichtbarkeitsliste ist eine Delta- Sichtbarkeitsliste (DVL). Anders als eine CVL speichert eine DVL nur die Biops, die seit der letzten CVL erzeugt, zerstört oder geändert wurden. Daher enthält jeder DVL- Matrixdatensatz sowohl die Blop-Kennung als auch ihre Haupt- DID. Da eine Schicht keine Merkmale von ihrem Stammdatensatz (ihren Stammdatensätzen) übernimmt, wird der erste DVL- Datensatz stets initialisiert, um darzustellen, daß eine neue Schicht keine Merkmale hat. Falls die Schicht L2 beispielsweise in dem Beispiel aus den Fig. 22A und 22B oberhalb der Schicht L1 erzeugt wird, wie in Fig. 23B symbolisch dargestellt ist und die Blop A geändert worden ist, sind die Sichtbarkeitslisten für die Schichten L1 und L2 jene, die in Fig. 23A dargestellt sind. Es ist ersichtlich, daß ein Datensatz 2302 in der DVL für L2 der Blop-Kennung 0 entspricht und daß der Datensatz 2304 in der DVL für L2 der Blop-Kennung 1 entspricht. Wenn in der DVL für L2 ein Matrixdatensatz 2304 für die Blop-Kennung 1 vorhanden ist, weist dies darauf hin, daß die entsprechende Blop in irgendeiner Weise gegenüber der vorhergehenden Schicht L1 geändert wurde und daß die DID 0x284 im Datensatz 2304 die Haupt-DID der neuen Version der Blop ist. Falls die DID im Datensatz 2304 0 wäre, würde dies angeben, daß die Blop bezüglich der Schicht L1 vollständig gelöscht wurde. Wenn in der DVL für die Schicht L2 für die Blop-Kennungen 2 und 3 kein Datensatz vorhanden ist, weist dies darauf hin, daß die durch die Datensätze 2206 und 2208 in der Schicht L1 angegebenen Blops in der Schicht L2 unverändert sind.
DVLs haben gegenüber CVLs den Vorteil, daß sie weniger Platz belegen. Bei Verwendung einer DVL ist jedoch die mittlere zum Finden einer DID eines Blops erforderliche Zeit erhöht. Um die Verarbeitungszeit zu verringern, werden DVLs für die meisten abgeleiteten Schichten erzeugt, CVLs werden jedoch erzeugt, um alle Änderungen der darunterliegenden Schichten zu prüfen. Ein Beispiel hierfür ist in den Fig. 24A und 24B dargestellt. Es sind mehrere Regeln zum Bestimmen, wann eine CVL erzeugt werden soll, möglich. Eine Regel besteht beispielsweise darin, DVLs für eine bestimmte Anzahl von Schichten zu erzeugen und dann eine CVL zu erzeugen, nachdem diese Anzahl von Schichten (nämlich DVLs) erzeugt worden ist. Eine bevorzugte Regel besteht darin, einen Schwellenwert für die DVL festzulegen (einen Prozentsatz der Blops, die geändert worden sind). Falls der Schwellenwert erreicht wurde, wird eine CVL statt einer DVL erzeugt, wenn eine Schicht beim nächsten Mal erzeugt wird.
Sichtbarkeitslisten stellen nicht nur ein Mittel zum Lokalisieren der Haupt-DID für eine Blop, sondern auch die Struktur für eine Versionsverwaltung bereit. Routinen in der Art von MoveAllChangesDown, MoveChangesDown, CopyAllBlopsUp und CopyBlopsUp hängen stark von den Sichtbarkeitslisten ab. Die Sichtbarkeitslisten bilden bei der vorliegenden Ausführungsform einen Teil der gegenständlichen Strukturen, welche die Ansicht erhalten, die eine Schicht hinsichtlich der Blops in einem Pool hat.
Im folgenden wird eine Definition der Sichtbarkeitsliste in der Sprache C gegeben: 1992 Apple Computer
Wiederum mit Bezug auf Fig. 20 sei bemerkt, daß der Blop-Namensindex (BNI) 2008 und der Typ-Namensindex (TNI) 2010 ähnlich wie der Schicht-Namensindex (LNI) aus Fig. 17 aufgebaut sind. Typen sind benannt, und ihre Namen sind in dem TNI gespeichert. Blops können benannt sein, und Blop- Namen sind im BNI gespeichert.
Es sei bemerkt, daß die in Fig. 17 dargestellte Struktur für Namensindizes nicht in der Lage ist, eine große Anzahl von Namen wirksam zu behandeln. Das Problem kann durch eine Erweiterung des Schemas gelöst werden. Wenn die Größe der Namen einen bestimmten Schwellenwert erreicht, wird eine dynamische Hash-Tabelle erzeugt, und die Namen werden dann in die Speicherbereiche der Hash-Tabelle verteilt. Es kann bei einer anderen Ausführungsform weiterhin nützlich sein, die Typnamen auf eine feste Länge zu begrenzen und dadurch die Struktur des TNI so zu verändern, daß viel Platz auf der Platte eingespart wird.
Anders als Sichtbarkeitslisten weisen TNIs und BNIs keine Delta-Versionen auf. Sie enthalten stets einen vollständigen Satz von Namen für die Schicht. Hierdurch wird die Namensuche unter Verwendung einer Kennung vereinfacht, und umgekehrt.
Hinsichtlich der Simultanität ein bemerkt, daß mehr als ein Prozeß eine Schicht-SL gleichzeitig lesen kann. Der Lesezählwert des entsprechenden ST-Eintrags wird erhöht, wenn ein Prozeß ein CPL-Zugriffsmittel auf die Schicht mit einer "Leseerlaubnis" positioniert. Es kann jedoch zu einem Zeitpunkt nur ein Prozeß auf eine Schicht-SL schreiben. Eine Schreibsperre wird erhalten, wenn ein Prozeß ein CPL- Zugriffsmittel auf die Schicht mit einer "Schreiberlaubnis" positioniert. Der exklusive Lese-und-Schreib-Zugriff wird durch Setzen der Schreibsperre des entsprechenden ST-Eintrags erhalten. Wenn der Zugriff vorgenommen wird, kann der Prozeß dann die Sperre aufheben, so daß ein anderer Prozeß auf ihn zugreifen kann.
Für einen Lesezugriff auf eine Schicht-SL kann ein Prozeß jede Struktur der SL und die SLs der darunterliegenden Schichten in einem Cache-Speicher speichern. Dies liegt daran, daß niemand eine dieser SLs ändern kann, wenn der Prozeß einen Lesezugriff auf die Schicht hat. Falls der Prozeß die Lesesperre jedoch aufhebt (beispielsweise durch Umpositionieren eines CPL-Zugriffsmittels), müssen möglicherweise alle in einem Cache-Speicher gespeicherten Daten der Schicht-SL geräumt werden. Für einen Schreibzugriff auf eine Schicht-SL kann ein Prozeß auch alle Strukturen der SL in einem Cache-Speicher speichern, da der Prozeß das einzige Zugriffsrecht auf die SL besitzt. Dies bedeutet auch, daß alle Manipulationen der Sichtbarkeitsliste, des Namensindex und der Daten im Speicher vorgenommen werden können. Wenn der Prozeß die Schreibsperre aufhebt, müssen alle Änderungen ausgeräumt und auf die Platte verlegt werden. Eine minimale Wechselwirkung mit der Platte ermöglicht eine gute Funktionsfähigkeit für die Speicherverwaltungseinrichtung.
Abgesehen von einer Lesesperre und einer Schreibsperre stellen Schichten auch zwei zusätzliche Erlaubnisarten für einen Zugriff bereit. Die erste Art wird als Null-Sperre bezeichnet. Dies bedeutet, daß der Prozeß ein CPL-Zugriffsmittel auf die Schicht positioniert hat, ohne ein Lesen oder Beschreiben der Schicht zu beabsichtigen. Den größten Teil der Zeit durchläuft der Prozeß die Schichten, wenn dies geschieht.
Die andere Erlaubnisart wird als transiente Leseerlaubnis bezeichnet. Diese Erlaubnis wird gewährt, wenn eine Schicht in einem anderen Pool von der Schicht abgeleitet ist. Es gibt keine Garantie, daß sich der oben erwähnte Pool richtig ablöst. Wenn sich der oben erwähnte Pool nicht richtig ablöst (wenn der den oben erwähnten Pool behandelnde Prozeß beispielsweise abstürzt), wird der untere Pool in einen schlechten Zustand versetzt, da kein anderer Prozeß einen Schreibzugriff auf ihn erhalten kann. Falls die Speicherverwaltungseinrichtung jedoch herausfindet, daß der untere Pool eine "transiente Leseerlaubnis" gewährt hat, kann die Speicherverwaltungseinrichtung dann alle Prozesse durchlaufen, die Schichten aufweisen, welche von der Schicht abgeleitet sind, um herauszufinden, ob sie noch ablaufen. Falls keiner der Prozesse abläuft, führt die Speicherverwaltungseinrichtung den Zustand des. Pools wieder zum Normalzustand zurück und gibt anderen Prozessen weiterhin die Erlaubnis zu einem Lese- oder Schreibzugriff.
Abfallsammlung. In der Speicherverwaltungseinrichtung sind viele Ebenen der Abfallsammlung (GC) verwirklicht. Die unterste Ebene liegt auf der Ebene der Segmentverwaltungseinrichtung, wobei ein Wiederherstellen nach einem Systemzusammenbruch und eine Plattenkomprimierung betont sind. Sie ist für die Speicherverwaltungseinrichtung jedoch nicht ausreichend. Es gibt mehrere andere Strukturen, bei denen mehr erforderlich ist als ein Hin- und Herschieben von Blöcken.
Beispielsweise sind ST-Einträge Pool-SLs und Schicht-SLs zugewiesen. Wenn ein Pool oder eine Schicht gelöscht wird, kann der entsprechende ST-Eintrag wiederverwendet werden. Ein Weg, um sie wiederzuverwenden besteht darin, die neuen Pools und die neuen Schichten unter Verwendung dieser "freigesetzten" Einträge zu erzeugen. Ein anderer Weg zum Manipulieren bestehender Einträge besteht darin, diese "freigesetzten" Einträge aufzufüllen und die ST danach während der GC-Zeit zu verkleinern. Es kann für das zweite Verfahren erforderlich sein, zahlreiche auf der Platte vorhandene Strukturen (beispielsweise PNIs, Pool-SLs und ihre Schichtsammlungen) zu durchlaufen, um die geeigneten Bezüge zu aktualisieren.
Ein weiteres Beispiel besteht in einer Schichtsammlung. Wie erwähnt wurde, können Schichtsammlungseinträge in der Pool-Liste wiederverwendet werden, falls eine Erzeugungsnummer jedem Eintrag zugeordnet ist. Das Zuordnen einer Erzeu gungsnummer zu einer Schichtkennung bedeutet jedoch, daß mehr Bits erforderlich sind, um eine Schicht eindeutig zu identifizieren. Falls nur 32 Bits zu verwenden sind, kann die Erzeugungsnummer nur von 0 bis 63 verlaufen (da 26 der 32 Bits für die Schichtkennung verwendet werden). Falls mehr als 32 Bits verwendet werden, kann das Angeben der Schichtkennungen mühsam werden.
Wenngleich die Segmentverwaltungseinrichtung weiterhin Hilfsmittel bereitstellt, um nicht verwendete Posten in einer Schicht-SL als Abfall zu sammeln, ist dies möglicherweise nicht ausreichend. Während der GC-Zeit sollte jeder Posten geprüft werden, um sicherzustellen, daß seine PID- oder DID-Bezüge noch gültig sind. Falls dies nicht der Fall ist, müssen sie aktualisiert werden. Dies ist ein sehr zeitaufwendiger Vorgang. Er kann jedoch etwas beschleunigt werden, indem für jeden Posten im Schichtsegment ein Bit "hat einen Bezug" gehalten wird. Während der GC-Zeit brauchen nur diejenigen untersucht zu werden, bei denen das Bit "hat einen Bezug" gesetzt ist.

B. Blops, Werte und Typen

Es wird nun beschrieben werden, wie Merkmale, Typen und Werte einer Blop tatsächlich im Speicher und in der Speichervorrichtung dargestellt sind. Wie zuvor erwähnt wurde, besteht eine Blop aus einer Liste von Merkmalen, denen jeweils eine Anzahl von, Elementen zugeordnet sein kann. Ein Element kann eine Kombination eines Werts und eines Typs sein, wobei der Typ in diesem Fall ein Grundtyp ist (in der Art von "Zeichenkette" ("string"), "lang" ("long") und dergleichen) und wobei der Wert die Dateneinheit für das Element ist. Ein Element kann statt dessen ein zusammengesetzter Typ sein, wobei es sich in diesem Fall lediglich in verschachtelter Weise auf eine andere Liste von Merkmalen bezieht.
Die Merkmalsinformation in einer Blop ist im Speicher und in der Speichervorrichtung als eine Hierarchie von einem oder mehreren Merkmalsdatenblöcken ("Property Data Blocks") (PDBs) dargestellt. Die Merkmalsdatenblöcke zeigen auf einen oder mehrere Datendatenblöcke ("Data Data Blocks") (DDBs), in denen die Werte tatsächlich gespeichert sind. Falls eine Blop keine zusammengesetzten Typen aufweist, weist die Blop nur einen PDB auf. Falls die Blop jedoch zusammengesetzte Typen aufweist, zeigt die PDB für jeden dieser zusammengesetzten Typen auf einen anderen PDB, der die Merkmalsinformation für die Merkmale enthält, welche im zusammengesetzten Typ enthalten sind. Wie beim ersten PDB einer Blop-Hierarchie gilt, daß, falls eines der Merkmale in einem PDB von einem zusammengesetzten Typ selbst von einem zusammengesetzten Typ ist, cer PDB-Eintrag für dieses Merkmal auf einen wiederum anderen PDB zeigt, der die Merkmalsinformation für die in diesem zusammengesetzten Typ enthaltenen Merkmale enthält, und so weiter. Wegen der Gleichwertigkeit des ersten PDB einer Blop und in der Blop enthaltenen PDBs von zusammengesetzten Typen wird selbst der erste PDB einer Blop hier manchmal so bezeichnet, daß er einen zusammengesetzten Typ repräsentiert.
Die Speicherverwaltungseinrichtung verwendet eine PID (kurz für Merkmalsdatenblock-Kennung ("Property Data Block ID")), um einen PDB innerhalb eines Pools zu identifizieren. Jedem zusammengesetzten Typ ist wenigstens ein PDB zugeordnet. Falls ein Merkmal wiederum von einem zusammengesetzten Typ ist, speichert der PDB die PID des PDB, der die Merkmalsinformation des zusammengesetzten Typs enthält.
In Fig. 25 ist die Struktur eines PDB 2502 dargestellt. Er besteht, wie dargestellt, aus einem PDB-Kopfteil 2504, einer Merkmalsnamensliste 2506, einem Merkmalsabschnitt 2508, einer sortierten Namenliste 2510 und einem Abschnitt 2512 mit Relativzeigern bevorzugter Wege. Der PDB-Kopfteil 2504 enthält Relativzeiger für andere Abschnitte des PDB. Die Merkmalsnamensliste 2506 enthält eine nicht sortierte Liste von Namen aller Merkmale in dem zusammengesetzten Typ. Der Merkmalsabschnitt 2508 enthält eine Matrix von Merkmalsinformationen. Abgesehen von einem in die Merkmalsnamens liste verweisenden Relativzeiger 2514 enthält jedes Element des Merkmalsabschnitts auch einen Wertetyp 2515, einen Merkmalsrelativzeiger 2516 und einen Index 2518 veränderlicher Merkmale.
Der Wertetyp 2515 gibt an, wie die Wertedaten des Merkmals zu interpretieren sind. Sie können entweder von einem Grundtyp oder einem zusammengesetzten Typ sein, und falls sie von einem zusammengesetzten Typ sind, enthalten sie die PID des PDB, worin weiter aufgeschlüsselt ist, wie die Wertedaten zu interpretieren sind. Falls die Wertedäten eines gegebenen Merkmals mehrere Werte eines einzigen Typs enthalten, spezifiziert der Wertetyp 2515 in dem diesem Merkmal entsprechenden Merkmalsinformationselement die Interpretation jedes solchen Werts. Falls die Wertedaten für ein gegebenes Merkmal mehrere Werte verschiedener Typen enthalten, wird der Wertetyp 2515 im Merkmalsinformationselement, das diesem Merkmal entspricht, gewöhnlich übergangen und ignoriert. Es wird verständlich werden, daß bestimmte Typen von DDBs ihre eigene Spezifikation für Wertetypen enthalten können und daß diese Spezifikationen den Wertetypeintrag 2515 in der PDB übergehen.
Der Merkmalsrelativzeiger 2516 ist der Relativzeiger (in Bytes), der dorthin in der Datenstruktur weist, wo der Wert (die Werte) des Merkmals beginnt (beginnen). Falls ein Typ beispielsweise aus zwei Merkmalern besteht und jedes Merkmal einen Wert des Grundtyps "long" (32-Bit-Wert) aufweist, ist der Relativzeigerwert für das erste Merkmal 0 und derjenige für das zweite 4. Um Strukturen mit veränderlicher Größe zu behandeln, werden 4 Bytes für jedes Merkmal mit veränderlicher Größe verwendet. Falls ein Typ beispielsweise aus zwei Merkmalen besteht, wobei das erste einen Wert eines Typs "str" mit veränderlicher Größe und das zweite einen Wert eines Typs "long" aufweist, ist der Merkmals-Relativzeigerwert für "str" 0 und derjenige für "long" 4. Es sei bemerkt, daß der Merkmals-Relativzeigerwert auch dann, wenn ein Merkmal von einem zusammengesetzten Typ ist, noch auf den Ort in der Datenstruktur zeigt, wo die Werte der mehreren Merkmale des zusammengesetzten Typs beginnen. Der Merkmals- Relativzeigerwert für das nächste Merkmal des Typs kann dann um erheblich mehr als 4 Bytes oberhalb des Merkmals-Relativzeigerwerts für das Merkmal liegen, das von einem zusammengesetzten Typ ist.
Der Index 2518 veränderlicher Merkmale ist die laufende Nummer von Merkmalen mit veränderlicher Größe in dem Typ, wobei jene eingeschlossen sind, auf die indirekt über eine Kette zusammengesetzter Typen Bezug genommen ist. Der Index beinhaltet nicht die Anzahl der Merkmale mit veränderlicher Größe in dem aktuellen Merkmal selbst, und er ist -1, falls der Typ eine feste Größe hat:
Die sortierte Namensliste in Merkmalsdatenblock 2502 ist eine Liste von Indizes, die in die Merkmalsnamensliste verweisen, und von Relativzeigern, die in den Merkmalsabschnitt verweisen, wo die Merkmalsinformation liegt. Die Reihenfolge der Indizes ist die sortierte Reihenfolge der Merkmalsnamen. Die Relativzeiger 2512 bevorzugter Wege sind eine Liste von Relativzeigern, die in die Typ-PDBs verweisen. Diese Relativzeiger betreffen Merkmale des bevorzugten Wegs. Der bevorzugte Weg einer Blop (oder eines zusammengesetzten Typs) ist eine vorgegebene Position für ein in die Blops positioniertes BPV-Zugriffsmittel. Falls eine Blop beispielsweise einen Textabsatz repräsentiert, wobei nur einer von deren. Werten der Text selbst ist, kann das Anwenderprogramm den bevorzugten Weg der Blop so festlegen, daß er auf diesen Wert zeigt, weil dies das ist, was der Benutzer meistens wünscht.
Es sei bemerkt, daß eine PDB vom zusammengesetzten Typ mehr als einmal in einer PDB-Hierarchie aufgerufen werden kann. Fig. 26 ist ein Beispiel der Struktur eines zusammengesetzten Typs, Welcher zwei als PDB1 und PDB2 angegebene PDBs belegt. PDB1 enthält die Merkmalsinformation für einen zusammengesetzten Typ, die zum Speichern der Adresse einer Person nützlich ist, und PDB2 enthält die Merkmalsinforma tion für einen zusammengesetzten Typ, die zum Speichern persönlicher Informationen einer Person nützlich ist. Insbesondere weist der PDB1 drei Merkmale auf, die mit "Straße", "Staat" und "Postleitzahl" bezeichnet sind. Alle enthalten einzelne Werte der Grundtypen "str", "long" bzw. "long". Falls PDB1 dementsprechend der erste PDB in einer Blop wäre, wäre die Merkmalsinformation für die ganze Blop in diesem einen PDB gespeichert.
Der Merkmals-Relativzeigerwert für das erste Merkmal· in PDB1 ist 0, und da der Typ des Werts für das erste Merkmal ein Typ mit veränderlicher Länge ("str") ist, ist der Merkmals-Relativzeigerwert für das zweite Merkmal in PDB1 4. Da der Typ des Werts für das zweite Merkmal auch eine veränderliche Länge aufweist, ist der Merkmals-Relativzeigerwert für das dritte Merkmal in PDB1 8. Der Index veränderlicher Merkmale ("Variable Property Index") (VPI) für das erste Merkmal in PDE1 ist 0, wodurch angegeben wird, daß keine Werte mit veränderlicher Länge dem Wert für das erste Merkmal vorhergehen. Da das erste Merkmal in PDB1 einen Typ mit veränderlicher Länge aufweist, ist der VPI für das zweite Merkmal 1. Der VPI für das dritte Merkmal ist -1, wodurch angegeben wird, daß der Typ des dritten Merkmals ("long") keine veränderliche Länge aufweist.
PDB2 weist drei Merkmale auf, die mit "Name", "Heimatanschrift" bzw. "Arbeitanschrift" bezeichnet sind. Der Typ des Werts für das erste Merkmal ist der Grundtyp "str". Der Typ des zweiten Merkmals in PDB2 ist ein zusammengesetzter Typ, so daß der Merkmalsabschnitt von PDB2 den Wert PID1 als den Typ für das zweite Merkmal enthält. PID1 gibt den zusammengesetzten Typ an, der mit PDB1 beginnt (und in diesem Fall damit endet). Der Typ des dritten Merkmals in PDB2 enthält auch PID1, da es nützlich ist, dasselbe Format zu verwenden, um Wertedaten für eine Arbeitsanschrift als eine Heimatanschrift zu verwenden. Der Merkmals-Relativzeigerwert in PDB2 ist 0, und da der Typ des dem ersten Merkmal zugeordneten Werts ein Typ mit veränderlicher Länge ("str") ist, ist der Merkmals-Relativzeigerwert für das zweite Merkmal in PDB2 4. Da der zusammengesetzte Typ des zweiten Merkmals einen Relativzeiger von 12 Bytes enthält, beträgt der Merkmals-Relativzeigerwert für das dritte Merkmal in PDB2 4 + 12 = 16. Der Index veränderlicher Merkmale (VPI) für das erste Merkmal in PDB2 ist 0, wodurch angegeben wird, daß keine Werte mit veränderlicher Länge dem Wert für das erste Merkmal vorhergehen. Da das erste Merkmal in PDB2 keinen Wert mit einem Typ veränderlicher Länge aufweist, ist der VPI für das zweite Merkmal 1. Der VPI für das dritte Merkmal ist 3, weil der Typ des zweiten Merkmals (PDB1) zwei Werte mit veränderlicher Länge enthält.
Wenngleich der Typ und seine Merkmale in PDBs gespeichert sind, sind Werte in Datendatenblöcken (DDBs) gespeichert. DDBs sind durch ihre DDB-Kennungen (DIDs) identifiziert, und es könnten, abhängig davon, wieviel Informationen mit Ausnahme der Wertinformation die Wertdaten selbst begleiten müssen, verschiedene Arten von DDBs verwendet werden. In Fig. 27 ist die Struktur einer Art von DDB 2702 dargestellt. Es wird nützlich sein, diese Art zuerst zu beschreiben, da sie die Art ist, welche die vorliegende Ausführungsform für den ersten DDB in einer DDB-Hierarchie (mit einer oder mehreren DDBs) verwendet. Der DDB 2702 enthält einen DDB-Kopfteil 2704, der in andere Abschnitte verweisende Relativzeiger enthaht, sowie eine Liste mit Bezügen veränderlicher Größe ("Variable-size Reference List") (VRL) 2706. Die VRL 2706 ist eine Liste von Einträgen, von denen jeder einem Wert mit veränderlicher Größe entspricht. In der VRL 2706 haben nur Werte mit veränderlicher-Größe entsprechende Einträge. Da ein Wert mit veränderlicher Größe an einem von zwei Orten in demselben DDB oder in einem getrennten Block in einem lokalen oder einem fernen Pool liegen kann, weist jeder Eintrag ein Hinweiszeichen auf, um den Ort des Werts zu zeigen. Jeder Eintrag in der VRL 2706 enthält auch ein 4-Byte-Feld, das abhängig davon, wo sich die Wertedaten befinden, verschiedenen Zwecken dient. In der folgenden Tabelle sind die Bedeutung jeder Hinweiszeichen-Einstellung und der entsprechende Zweck des 4-Byte-Felds dargelegt.
Der DDB 2732 beinhaltet auch einen Abschnitt 2708 mit Einträgen fester Größe (FSE-Abschnitt), der einen Eintrag aufweist, der jedem Wert in dem Typ entspricht (unabhängig davon, ob der Wert eine feste oder eine veränderliche Länge aufweist), wobei Werte eingeschlossen sind, die sich in einem anderen DDB befinden. Für Werte mit einer festen Größe speichert der entsprechende Eintrag im Abschnitt 2708 mit Einträgen fester Größe den Wert selbst. Für Werte mit einer veränderlichen Größe enthält der entsprechende Eintrag im Abschnitt 2708 mit Einträgen festen Größe die eigentliche Adresse im Speicher, wo die Wertedaten selbst beginnen. Dies bedeutet, daß der Eintrag im FSE-Abschnitt 270 dann, wenn sich die Wertedaten mit veränderlicher Größe in dem 4-Byte- Feld hinter den Hinweiszeichen in der VRL 2706 befinden, die Adresse dieses 4-Byte-Felds enthält. Falls sich die Wertedaten mit veränderlicher Größe im Datenabschnitt des DDB 2702 befinden, enthält der Eintrag im FSE-Abschnitt 270 die Adresse der Wertedaten in diesem Datenabschnitt. Falls sich die Wertedaten mit veränderlicher Größe in einem getrennten DDB befinden, enthält der Eintrag im FSE-Abschnitt 270 die Adresse in diesem DDB, wo die Wertedaten beginnen.
Der DDB 2702 enthält auch eine Bitzuordnung 2710, die verwendet wird, um externe Bezüge in dem Wert zuzuordnen, sowie einen Abschnitt 2712 bevorzugter Wege, der Informationen zum Zuordnen des Werts für den bevorzugten Weg enthält. Ein Eintrag hinsichtlich eines bevorzugten Wegs kann einen direkten Relativzeiger enthalten, der auf einen Wert oder einen Wegnamen verweist, der unter Verwendung der Typen aufgelöst werden muß. Das zuvor erwähnte Verfahren ist nützlich, wenn die Typinformation nicht verfügbar ist. Falls der Typ auch einen bevorzugten Weg aufweist, ist er durch den im DDB 2702 angegebenen vorbelegt.
In Fig. 28 ist ein Beispiel eines DDB dargestellt, der für den oben mit Bezug auf Fig. 26 beschriebenen zusammengesetzten Typ erzeugt werden könnte. Die Bitzuordnung und der Abschnitt bevorzugter Wege sind aus Deutlichkeitsgründen fortgelassen. Weiterhin sind alle Werte bei diesem Beispiel in dem Datenabschnitt desselben DDB gespeichert, wobei keiner in einem getrennten DDB und keiner in der VRL 2706 gespeichert ist. Es sei bemerkt, daß zum Berechnen der Relativzeiger in den 4-Byte-Feldern nach den Hinweiszeichen in der VRL 2706 jeder der Werte mit veränderlicher Größe im Datenabschnitt 2714 mit einem Null-Byte endet.
Wie oben erwähnt wurde, unterstützt die gegenwärtig beschriebene Ausführungsform der Speicherverwaltungseinrichtung mehrere verschsiedene DDB-Artens Falls ein VRL-Eintrag in einem DDB des in Fig. 28 angegebenen Typs angibt, daß Wertedaten in einem getrennten DDB gespeichert sind, kann der getrennte DDB irgendeiner der Arten angehören, die in den Fig. 29A, 29B und 29C dargestellt sind. Diese DDB- Arten werden hier als sekundäre Arten bezeichnet, wobei die in Fig. 28 dargestellte Art eine primäre Art ist. Die Speicherverwaltungseinrichtung bestimmt automatisch, abhängig von der Größe der Wertedaten, abhängig davon, ob die Wertedaten für das bestimmte Merkmal mehrere Werte enthalten, und davon, ob die mehreren Werte alle dem gleichen Typ angehören oder ob sie mehreren Typen angehören, die beste zu verwen dende DDB-Art. Alle in den Fig. 29A, 29B und 29C dargestellten DDB-Arten können als entartete oder erweiterte Versionen des DDB aus Fig. 28 angesehen werden, und eine andere Ausführungsform der Speicherverwaltungseinrichtung könnte eine allgemeinere DDB-Art verwenden, wenn die vorliegende Speicherverwaltungseinrichtung eine weniger allgemeine Art verwendet. Eine andere Ausführungsform der Speicherverwaltungseinrichtung könnte beispielsweise die in Fig. 29C dargestellte allgemeinste DDB-Art für alle DDBs in der Datenstruktur verwenden.
Es ist in Fig. 29A ersichtlich, daß die erste alternative DDB-Art 2902 aus dem Datenabschnitt 2714 besteht, der nur das allgemeine DDB-Format 2702 aufweist (Fig. 27). Die in Fig. 29A dargestellte DDB-Art ist zum Speichern von Wertedaten für ein Merkmal nützlich, dem genau ein Wert mit veränderlicher Größe zugeordnet ist. In dieser Situation braucht mit den Wertedaten keine Typinformation gespeichert sein, weil der Typ im Wertetypfeld 2515 des Merkmalselements 2508 im Merkmalsabschnitt des entsprechenden PDB angegeben ist (s. Fig. 25). Eine andere Ausführungsform könnte eine etwas allgemeinere DDB-Art unterstützen, die zusätzlich zum Datenabschnitt 2714 einen Wertezählwert-Kopfteil aufweist. Ein solcher DDB könnte verwendet werden, um die Wertedaten für ein Merkmal zu speichern, dem mehrere Werte eines einzigen Typs mit relativ hoher fester Länge oder eine große Anzahl von Werten eines einzigen Typs mit relativ geringer fester Länge zugeordnet sind.
Der in Fig. 29B dargestellte DDB 2904 ist nützlich, wenn einem Merkmal mehrere Werte eines einzigen Typs mit veränderlicher Größe zugeordnet sind. Wie in Fig. 29B dargestellt ist, enthält der DDB 2904 den Kopfabschnitt 2704, den VRL- Abschnitt 2706 und den FSE-Abschnitt 2708 aus Fig. 27, er beinhaltet jedoch nicht den Bitzuordnungsabschnitt 2710, den Abschnitt 2710 bevorzugter Wege oder den Datenabschnitt 2714 aus Fig. 27. Der Kopfabschnitt 2704 im DDB 2904 enthält einen Zählwert der Anzahl der dem entsprechenden Merkmal zugeordneten Werte, und jeder Wert ist in einem eigenen DDB, wie 2906 oder 2908, gespeichert. Die DDBs 2906 und 2908 sind von der gleichen Art wie derjenige aus Fig. 29A, der nur den Datenabschnitt 2714 enthält. Die VRL 2706 des DDB 2904 beinhaltet nur die Bezüge auf die Orte der DDBs 2906 und 2908 im permanenten Speicher (also die DIDs für die Datenabschnitte 2906 und 2908), und der FSE-Abschnitt 2708 beinhaltet nur die Zeiger auf die Orte, wo die DDBs 2906 und 2908 im Speicher beginnen.
In Fig. 29D ist die allgemeinste Art eines sekundären DDB dargestellt, die von der Speicherverwaltungseinrichtung gemäß der vorliegenden Ausführungsform unterstützt wird. Sie enthält den Kopfabschnitt 2704, die Liste 2706 mit Bezügen veränderlicher Länge, den Abschnitt 2708 mit Einträgen fester Größe und den Datenabschnitt 2714 aus Fig. 27. Der DDB 2910 könnte auch eine Bitzuordnung 2710 und einen Abschnitt 2712 bevorzugter Wege (in Fig. 29C nicht dargestellt) beinhalten. Der Kopfabschnitt 2704 des DDB 2910 enthält einen Zählwert bezüglich der Anzahl der dem entsprechenden Merkmal zugeordneten Werte. Der VRL-Abschnitt 2706 enthält ein Element für jeden der dem Merkmal zugeordneten Werte, die jeweils, ähnlich wie bei der Struktur eines VRL- Eintrags in dem DDB aus Fig. 28, ein Hinweiszeichenfeld 2912 und ein 4-Byte-Mehrzweckfeld 2914 enthalten. In dem DDB 2910 beinhaltet jedes VRL-Element jedoch auch ein Typfeld 2916, in dem der Typ des Werts, dem das VRL-Element entspricht, angegeben ist. Der in diesem Feld angegebene Typ kann entweder ein zusammengesetzter Typ, wobei das Feld 2916 in diesem Fall die PID des PDB enthält, welche den Typ weiter beschreibt, oder ein Grundtyp sein. Diese Typen können auch eine feste oder eine veränderliche Größe aufweisen.
Der FSE-Abschnitt 2708 des DDB 2910 enthält die Speicheradresse, bei der jeder dem Merkmal zugeordnete Wert beginnt, welche im Datenabschnitt 2714 oder in einem getrennten DDB, wie einem der in Fig. 29A dargestellten Art, liegen kann. DIDBs der in Fig. 29C dargestellten Art sind nützlich, wenn einem Merkmal mehrere Werte mehrerer Typen zugeordnet sind.
Wenn einer der primären DDBs, wie der in Fig. 28 dargestellte, verschiedene DDBs für verschiedene Merkmale aufruft, könnte er DDBs mehrerer der in den Fig. 29A, 29B und 29C dargestellten Arten für verschiedene der Merkmale aufrufen. Die Speicherverwaltungseinrichtung gemäß der vorliegenden Ausführungsform versucht, eine intelligente Auswahl hinsichtlich des Orts, wo die Wertedaten für jedes Merkmal gespeichert sind, und hinsichtlich der zu verwendenden DDB-Art, falls sie in einem getrennten DDB liegen, vorzunehmen. Falls das Datenspeichermedium aus Blöcken mit fester Größe, wie der 512-Bytes betragenden Blockgröße einer Platte, besteht, von denen alle Bytes bei einem einzigen Zugriff geschrieben oder gelesen werden müssen, versucht die Speicherverwaltungseinrichtung, die Ausnutzung jedes Blocks zu maximieren, um dadurch die Anzahl der erforderlichen Zugriffe auf das Datenspeichermedium zu minimieren. Falls es wahrscheinlich ist, daß die Wertedaten über das Ende eines Blocks hinauslaufen, wenn sie im Datenabschnitt 2714 eines gegebenen DDB gespeichert werden, ist es demgemäß wahrscheinlich, daß die Speicherverwaltungseinrichtung diese Wertedaten statt dessen in einem getrennten DDB anordnet. Falls die einem bestimmten PDB zugeordneten Werte eine solche Größe und einen solchen Umfang aufweisen, daß sie wahrscheinlich in denselben Block wie der primäre DDB passen, ist es andererseits wahrscheinlich, daß die Speicherverwaltungseinrichtung die Wertedaten im Datenabschnitt des DDB anordnet. Die Speicherverwaltungseinrichtung verwendet die folgenden Kriterien, um zu bestimmen, wo jeder Wert eines gegebenen Merkmals gespeichert werden sollte, nämlich die Anzahl der einem gegebenen Merkmal zugeordneten Werte, die Anzahl der einem Merkmal zugeordneten Wertetypen, ob die Werte eine feste oder eine veränderliche Größe aufweisen, sowie die Größe von jedem Wert.
Die folgende Tabelle zeigt die verschiedenen Kombinationen der Kriterien und die sich ergebende Wahl für den Ort des Werts. Ein Stern gibt an, daß die gegebene Situation so selten ist, daß die Speicherverwaltungseinrichtung hinsichtlich der Gesamtausführungszeit, der Komplexität des Codes und des Speicherplatzes spart, indem sie die Wertedaten in der angegebenen, ansonsten weniger wirksamen Weise speichert, wenngleich diese Wertedaten in der gegebenen Situation wirksamer als in der beschriebenen Weise gespeichert werden könnten.
Jedem Wert mit veränderlicher Größe muß auch ein Bytezählwert oder ein Trennzeichen zugeordnet sein. Dieses sollte in der Typbeschreibung beschrieben sein.
Es sei bemerkt, daß PDBs und DDBs im Bereich eines Pools liegen. Daher kann bei Verwendung lediglich von PIDs und DIDs kein Bezug auf einen Datenblock in einem anderen Pool genommen werden. Um einen Zusammenhang für eine ferne PID oder DID herzustellen, unterhält jeder Pool eine Liste von Informationen hinsichtlich ferner Pools, auf die seine PDBs und DDBs verweisen. Jeder Eintrag in der Liste enthält den Behälternamen, den Pool-Namen und sogar einen Schichtnamen. Indizes von fernen Pools ("Remote Pool Indexes") (RPIs), die als Teil des Pools unterhalten werden, werden verwendet, um sich auf die Einträge zu beziehen. Der genaue Datenblock kann unter Verwendung einer PID oder einer DID zusammen mit seinem entsprechenden RPI selbst dann zugeordnet werden, wenn sich der Block in einem fernen Pool befindet.
Während der Ausführungszeit wird diese Information hinsichtlich ferner Pools von einer als Tabelle ferner Pools des Arbeitsplatzes ("Workspace Remote Pool Table") genannten Arbeitsplatzstruktur unterhalten. Jedesmal dann, wenn auf einen fernen Datenblock Bezug genommen wird, wird seine Information hinsichtlich ferner Pools in die WRP-Tabelle eingegeben. Jede Arbeitsplatzstruktur wird dann einen der fernen PID oder DID zugeordneten Index ferner Pools des Arbeitsplatzes ("Workspace Remote Pool Index") (WRPI) aufweisen. Um das Einfügen in die WRP-Tabelle und das Aufsuchen eines WRPI zu beschleunigen, kann auch eine Nachschlagetabelle, bei der ein Pool und der RP-Index verwendet werden, unterhalten werden.
Sowohl BPV-Zugriffsmittel als auch CPL-Zugriffsmittel weisen einen PDB-Cache-Speicher und einen DDB-Cache-Speicher auf. Durch diese Cache-Speicher werden die Ein-/Ausgabevorgänge bezüglich der Platte stark verringert, und sie gewährleisten auch ein für den Benutzer vorhersehbares Verhalten. Alle geladenen Datenblöcke werden im BPV- Zugriffsmittel gespeichert. Wenn das BPV-Zugriffsmittel aufgehoben wird, werden diese Datenblöcke in die Cache- Speicher des CPL-Zugriffsmittels verschoben. Diese Daten blöcke brauchen nur dann ausgeräumt zu werden, wenn wenig Speicher vorhanden ist oder wenn das CPL-Zugriffsmittel auf eine andere Schicht positioniert wird.
Jedem BPV-Zugriffsmittel ist auch ein Wegstapel ("Path Stack") zugeordnet. Der Wegstapel zeigt den aktuellen Weg des Merkmals bzw. des Werts, worauf sich das BPV-Zugriffsmittel bezieht. Ein Wegstapel enthält viele miteinander verkettete Wegstapelelemente. Jedes Element repräsentiert eine Verfeinerung des Wegs oder einen indirekten Typ bzw. einen indirekten Wert. Durch Verfolgen der Kette kann daher leicht der aktuelle Weg gefunden werden, und es kann wirksam navigiert werden.
Jedes Element des Wegstapels enthält Informationen bezüglich des dem Teilweg zugeordneten Typs und des diesem zugeordneten Werts. (Bei einer anderen Ausführungsform kann ein Wegstapelelement statt dessen nur die Typinformation enthalten, da die Wertinformation anderswo erhalten werden kann, sobald die Typinformation bekannt ist.) Die Information wird hinsichtlich PID, DID und geeigneter, darin verweisender Relativzeiger gespeichert. Wiederum sei unter Verwendung des Beispiels aus den Fig. 26 und 28 bemerkt, daß ein auf die Blop bzw. die Heimatanschrift bzw. den Staat zeigendes BPV-Zugriffsmittel den in Fig. 30 dargestellten Wegstapel aufweist.

IV. ROUTINEN der Speicherverwaltungseinrichtung

Bei den oben beschriebenen Datenstrukturen können nun bestimmte der Routinen, die ein Anwenderprogramm aufrufen kann, in erster Linie im Pseudocode dargelegt werden.
Eine wertvolle Anwendung von Schichtnamen besteht darin, den Namen "aktuell" einer Schicht in einem Pool zuzuordnen. Falls der Pool beispielsweise ein Dokument enthält, das durch eine Gruppe von Mitarbeitern aktualisiert und modifiziert wird, kann ein Bearbeiter die Kontrolle darüber behalten, welche Versionen welcher Blops des Dokuments beispielsweise als die letzte überarbeitete Ausgabe genehmigt wurden. Nach dem Erzeugen einer Abstimmungsschicht, deren Ansicht die gewünschte Version jeder Blop in dem Dokument enthält, kann der Bearbeiter dann dieser Schicht den Namen "aktuell" zuordnen. Falls ein anderer an dem Dokument arbeitender Mitarbeiter weiß, daß alle Modifikationen immer mit der "aktuell" genannten Schicht beginnen müssen, kann der Herausgeber eine Situation verhindern, in der verschiedene Mitarbeiter verschiedene Versionen eines Dokuments überarbeiten. Falls ein Mitarbeiter (beispielsweise ein Illustrator für das Dolcument) einen trennbaren Pool der "aktuellen" Schicht erzeugt, wird der Illustrator wissen, ob eine neue überarbeitete Ausgabe des Dokuments seitdem genehmigt worden ist, wenn eine Reintegration versucht wird. Dies wird offensichtlich sein, weil der Name "aktuell" dann einer anderen Schicht zugeordnet sein wird als derjenigen, die den trennbaren Pool herbeigeführt hat. Weiterhin kann allen an einem Dokument arbeitenden Mitarbeitern, die Modifikationen in das Dokument integrieren möchten, die Anweisung gegeben werden, die Modifikationsschicht stets mit irgendeiner Schicht, die dann mit "aktuell" benannt ist, abzustimmen. Auf diese Weise kann es die Arbeitsgruppe mehreren Bearbeitern ermöglichen, Modifikationen einzufügen, ohne daß das Risiko besteht, daß verschiedene Bearbeiter Modifikationen in verschiedene Versionen des Gesamtdokuments einfügen. Die unteilbare "Prüfen-und-Festlegen-Funktion" der SMSetLayerName-Routine gewährleistet, daß ein gegebener Name (wie beispielsweise "aktuell") nur einer Schicht in einem Pool zugeordnet werden kann.
Aufheben eines BPV-Zugriffrmittels. Wie oben beschrieben wurde, müssen IDDBs und PDBs in den Cache-Speicher des CPL- Zugriffsmittels verschoben werden, wenn das BPV-Zugriffsmittel aufgehoben wird. Möglicherweise sind jedoch nicht alle DIDs real. Wenn ein neuer DDB erforderlich ist (beispielsweise wenn ein neuer "großer" ("big") Wert eingefügt wird), ordnet die Speicherverwaltungseinrichtung den Datenblock dann nicht wirklich auf der Platte zu. Sie verwendet statt dessen einen Puffer im Speicher, um den Wert zu halten und eine "temporäre" DID zu verwenden. Beim API-Aufruf SMReleaseBPVAccessor durchläuft die Speicherverwaltungseinrichtung daher alle DDBs, um den neu erzeugten Werten reale DDBs zuzuordnen, und sie ersetzt alle "temporären" DIDs durch reale DIDs.
Der folgende Pseudocode verwirklicht eine ReleaseBPV- Accessor-Routine:
Ändern der Bestimmung für eine Blop. Eine indirekte Blop weist eine spezielle vordefinierte PID auf, und der DDB enthält die Informationen der Ziel-Blop. Wenn die Speicherverwaltungseinrichtung daher versucht, die Blop abzurufen (durch einen GetRootID-Vektor-Aufruf), wird die spezielle PID zurückgegeben.
Es wird ein fernes CPL-Zugriffsmittel erzeugt, das sich auf die Schicht bezieht, wo die Ziel-Blop liegt. Dieses ferne CPL-Zugriffsmittel sollte ein Hinweiszeichen aufweisen, um seinen speziellen Status zu zeigen, weil es sich nach dem Aufheben seines letzten BPV-Zugriffsmittels beseitigen muß.
Nachdem dass CPL-Zugriffsmittel erzeugt wurde, sollte ein Schein-BPV-Zugriffsmittei erzeugt werden, das sich auf die Ziel-Blop bezieht. Hierdurch wird im wesentlichen eine Schreibsperre an der Blop erzeugt. Dieses BPV-Zugriffsmittel ist tatsächlich lediglich ein Platzhalter, und es kann daher ein geringeres Gewicht als ein normales BPV-Zugriffsmittel aufweisen.
In der oben angegebenen SMReadValueData-Routine können Grundtypen Handhabungsmittel zugeordnet sein. Diese Handhabungsmittel können als eine Blackbox mit einem Eingangsstrom und einem Ausgangsstrom angesehen werden. Die Handhabungsmittel sind in etwas, was hier als ein komplexer Typ bezeichnet wird, in der Reihenfolge der Grundtypen miteinander verkettet. Auf diese Weise ist eine Pipeline hergestellt, die einen Eingangsstrom und einen Ausgangsstrom aufweist. Die vom Eingangsstrom eingeführten Daten werden von jedem Handhabungsmittel gehandhabt, und die Ausgabe wird ein zusammengestelltes Ergebnis von allen Handhabungsmitteln. Es können daher komplexe Typen konstruiert werden, die die Daten in geeigneter Weise manipulieren, wenn sie aus einem Behälter abgerufen oder in einen Behälter eingeschrieben werden.
Die Fähigkeit, Handhabungsmitteln einen Grundtyp zuzuordnen, ist beispielsweise dann nützlich, wenn eine Kompression oder Verschlüsselung der Daten erforderlich ist. Ein Anwenderprogramm kann einen "Kompressionstyp" an einen Grundtyp anhängen. Zum Lesen von Daten aus der Speichervorrichtung weiß das Grundtyp-Handhabungsmittel, wie der spezielle Datentyp abzurufen ist. Es übergibt die Rohdaten dann an das "Kompressionshandhabungsmittel", das die erforderliche Kompression. (oder Dekompression) ausführt.
Eine komplementäre SMWriteValueData-Routine wird weiter unten detailliert angegeben:

V. ANWENDUNGSBEISPIELE

Im folgenden werden mehrere Beispiele dazu angegeben, wie die API der Speicherverwaltungseinrichtung zu verwenden ist. Diese Beispiele sind nicht unbedingt die optimale Verwendung der API der Speicherverwaltungseinrichtung, sondern sie sind vielmehr gewählt, um am besten zu zeigen, wie die API arbeitet. Bei all diesen Beispielen sind in Fettdruck geschriebene Funktionen Aufrufe der Speicherverwaltungseinrichtung, und in Kursivschrift geschriebene Funktionen sind Benutzerfunktionen (die gewöhnlich verwendet werden, um Code zu verbergen, der sich nicht direkt auf das dargestellte Beispiel bezieht). Bei den meisten dieser Beispiele wurde der Klarheit wegen eine Ausnahmebehandlung fortgelassen.

A. Modell mit einem einzigen Benutzer

Der erste Satz von Beispielen behandelt die Verwendung von Behältern, Pools und Schichten in einem einfachen Modell mit einem einzigen Benutzer. Bei vielen Anwendungen wird ein einfaches Modell der Dokumentmanipulation verwendet: der Neu-Befehl ("New command") erzeugt ein leeres "unbetiteltes" Dokument, dem keine Datei zugeordnet ist. Wenn der Benutzer zum ersten Mal speichert, erzeugt er die Datei und kopiert die Informationen in diese und so weiter. Es gibt zwei Verfahren, die hinsichtlich der Erzeugung eines neuen Dokuments verwendet werden können. Ein Weg besteht darin, einen Speicherbehälter ("Memory Container") zu erzeugen und die Pools in dem Behälter nach dem Speichern-Befehl ("Save command") in einen Dateibehälter ("File Container") zu kopieren. Eine weitere Lösung würde darin bestehen, nach einem Neu-Befehl einen Dateibehälter mit einem vorläufigen Namen zu erzeugen und ihn dann umzubenennen und beim Speichern zu verschieben. Die folgenden Codesegmente zeigen, wie diese Funktionen mit der Speicherverwaltungseinrichtung verwirklicht werden können.
Neues Dokument. Wenn ein neues Dokument erzeugt wird, ist ein vorläufiger Behälter mit einem einzigen Pool erforderlich.
Erstes Speichern. Wenn Sie das Dokument zum ersten. Mal speichern, müssen Sie die Behälterdatei umbenennen.
Speichern. Bei diesem Satz von Beispielen wird die einfachste Verwendung von Schichten in der Speicherverwaltungseinrichtung angenommen. Es gibt in dem Pool zwei Schichten, wobei die eine der gespeicherte Zustand ist (die Bodenschicht) und die andere die Aktualisierungsschicht ist (der vorhergehende Code richtet genau diese Situation ein). Alle von der Anwendung hervorgebrachten Änderungen sollten in der Aktualisierungsschicht ausgeführt werden. In diesem Fall ist ein Speichern einfach ein Verschieben der Änderungen von der Aktualisierungsschicht zur Bodenschicht herab.
Schließen. Zum Schließen des Dokuments braucht lediglich das CPL-Zugriffsmittel beseitigt zu werden, das sich auf das Dokument bezieht. Hierdurch wird die Dokumentdatei implizit geschlossen.
Schließen ohne Speichern. Zum Schließen des Dokuments, ohne Änderungen zu speichern, braucht lediglich die Aktualisierungsschicht geleert zu werden und das CPL-Zugriffsmittel beseitigt zu werden, das sich auf das Dokument bezieht. Hierdurch wird die Dokumentdatei implizit geschlossen.
Öffnen. Zum Öffnen eines bestehenden Dokuments wird einfach ein CPL-Zugriffsnittel auf die Aktualisierungsschicht des Dokuments positioniert.

B. Versionsverwaltung bei einem einzigen Benutzer

Der nächste Satz von Beispielen beruht auf dem gleichen Dokumentschema wie der vorhergehende Satz, und es werden bei ihm fast alle Funktionen verwendet, es ist bei ihm jedoch die Fähigkeit hinzugefügt, mehrere Versionen eines Dokuments zu speichern. Dieser Satz von Beispielen zeigt kein Verzweigen von Versionen oder einen simultanen Zugriff. Das Grundmodell besteht hier darin, daß der Pool einen einfachen Stapel von Schichten enthält, die die verschiedenen Versionen des Dokuments repräsentieren. Die oberste Schicht ist, wie beim vorhergehenden Beispiel, eine Aktualisierungsschicht, die es der Anwendung ermöglicht, Änderungen auf die Platte herauszuschreiben, ohne sie als Versionen anzuweisen. Dieser Schicht ist der Namensidentifizierer gUpdateLayerName gegeben, und den Versionsschichten sind Namensidentifizier gegeben, die ihren Versionsnummern entsprechen.
Neues Dokument. Verwendet die vorhergehende Neues-Dokument-Routine ("NewDocumentRoutine") unverändert.
Erstes Speichern. Wenn ein Dokument mit Versionen zum ersten Mal gespeichert wird, geschieht dies genau so, wie beim vorhergehenden Beispiel, wobei jedoch das Benennen der Bodenschicht als die erste Version hinzugefügt ist.
Speichern. Bei diesem Beispiel wird die aktuelle Aktualisierungsschicht mit dem gegebenen Versionsnamen versehen, und eine neue Aktualisierungsschicht wird für künftige Aktualisierungen auf ihr erzeugt.
Schließen. Verwendet die vorhergehende Schließ-Routine unverändert.
Schließen, ohne Versionen zu speichern. Verwendet die vorhergehende Schließen-ohne-Speichern-Routine unverändert.
Öffnen. Verwendet die vorhergehende Öffnen-Routine unverändert.
Öffnen der vorigen Version. Der Zweck des Beibehaltens der alten Versionen eines Dokuments besteht darin, daß die Anwendung zurückgehen und sie lesen kann. Der folgende Aufruf kann verwendet werden, um eine der alten Versionen "zu öffnen". Dies gleicht tatsächlich einem normalen Öffnen, wobei die Schicht, auf die zugegriffen wird, jedoch eine mit einer Version versehene Schicht ist und wobei das Zugriffsmittel ein Nurlese-Zugriffsmittel ist. Weil von allen mit einer Version versehenen Schichten bereits andere Schichten abgeleitet sind (entweder eine Version höherer Ordnung oder die Aktualisietungsschicht), können die zusätzlichen abgeleiteten Schichten nicht geändert werden, was bedeutet, daß die mit einer Version versehene Schicht als Nurleseschicht geöffnet wird und daß jegliche Speichervorgänge, die die Anwendung versuchen könnte, fehlschlagen. Vor dem Aufruf wird die Anwendung dem Benutzer eine Liste aller benannten Versionen des geöffneten Dokuments dargeboten haben, so daß er wählen könnte, welche Version geöffnet werden soll. Der Name wird dann zusammen mit dem Nurlese-Zugriffsmittel, das den richtigen Behälter und den richtigen Pool angibt, an die Öffne-die-vorige-Version-Funktion ("OpenPastVersion function") übergeben.

C. Divergierender simultaner Zugrriff

Der nächste Satz von Beispielen ist etwas komplexer. Sie zeigen, wie die Speicherverwaltungseinrichtung verwendet werden könnte, um ein System zu erzeugen, bei dem es im allgemeinen einen Schreiber oder viele Leser der aktuellen Version geben kann, wobei jedoch jeder eine Gabel bzw. einen Zweig in der Versionstruktur hervorrufen kann, um mehr als eine "aktuelle Version" zu erzeugen. Da solche Systeme es im allgemeinen nicht erzwingen, daß die Zweige schließlich wieder zur Hauptlinie zusammengeführt werden, kann die Struktur als divergent angesehen werden. Die meisten Codesteuersysteme einschließlich des MPW-Projekthilfsmittels verwenden ähnliche Schemata. Bei diesem Beispiel wird zur Vereinfachung angenommen, daß der Benutzer in Form einer Version speichern muß, um Änderungen zu speichern. Ein Weg, um dies mit der Speicherverwaltungseinrichtung zu verwirklichen, besteht darin, in gleicher Weise vorzugehen wie im letzten Beispielsatz. Die Versionsscichten werden in einem Graphen angeordnet, und jedem Schreiber wird eine Aktualisierungsschicht zugeordnet. Die Leser benötigen, wie zuvor erwähnt wurde, keine Aktualisierungsschichten, sondern sie können direkt auf die Versionsschichten zugreifen. Es treten Schwierigkeiten auf, wenn bestimmt werden soll, welche Schichten welche sind, was insbesondere dann der Fall ist, wenn mit einer Sitzung begonnen wird. Die Lösung besteht darin, ein Schichtbenennungsschema einzuführen, das sowohl die Struktur des Graphens der Versionen als auch die Benutzer der Aktualisierungen identifiziert. Neues Dokument Erstes Speichern
Speichern. Sobald an der Aktualisierungsschicht Änderungen vorgenommen wurden, besteht die nächste Aufgabe darin, sie durch Ändern des Namens in eine neue Version zu ändern. Der Name dieser neuen Version kann vom Namen der erzeugten Aktualisierungsschicht abgeleitet werden.
Schließen. Verwendet die vorhergehende Schließen-Routine unverändert.
Schließen, ohne Versionen zu speichern. Verwendet die vorhergehende Schließen-Routine unverändert. Die künftige Öffnen-Routine entfernt die inkonsistente Schicht.
Öffnen. Das Öffnen einer Version zum Schreiben ist etwas komplexer. Die Anwendung muß die Aktualisierungsschicht erzeugen und sie auf der Grundlage der geöffneten Version, des Namens des Benutzers sowie auf der Grundlage davon, wie viele andere Leute diese Version zum Schreiben geöffnet haben (also davon, welcher Zweig erzeugt wird), benennen. Ein den richtigen Pool kennzeichnendes Nurlese-Zugriffsmittel wird ebenso wie der Name der zu aktualisierenden Version und der Name des das Aktualisieren vornehmenden Benutzers an die Öffnen-Funktion übergeben.
Öffne die vorige Version. Verwendet die vorhergehende Öffne-vorige-Version-Routine unverändert.

D. Konvergerender simultaner Zugriff

Der letzte Satz von CPL-Beispielen betrifft den Systemtyp, der stets versucht, eine einzige "aktuelle" Version des Dokuments zu erhalten. Er kann es mehreren Anwendungen ermöglichen, ein Dokument zum Schreiben zu öffnen, wobei jede jedoch dafür verantwortlich ist, ihre Änderungen mit jeglichen von anderen Anwendungen veröffentlichten Änderungen abzustimmen, wodurch das Dokument stets bei einer einzigen Version konvergiert. Wenn die letzte Anwendung das Dokument schließt, sollte in dem auf der Platte befindlichen Pool tatsächlich nur eine Schicht übrig sein.
Neues Dokument. Diese gleicht der ersten Neues-Dokument- Routine ("NewDocument routine"), wobei die Bodenschicht jedoch mit "aktuell" benannt wird. Erstes Speichern
Speichern. Die ganze harte Arbeit für diese Art von System tritt beim Speichern-Aufruf auf. Viele Systeme teilen diese Aufgabe in mehrere Arbeitsgänge ein, bei diesem Beispiel wurde jedoch alles zu einem Teil eines Aufrufs gemacht. Die Grundfolge von Ereignissen ist die folgende:
1) Versuche, die Aktualisierungsschicht auf der Grundlage dessen, was die Anwendung gewöhnlich für die "aktuelle" Schicht gehalten hat, mit "aktuell" zu benennen.
2) Falls das Benennen gelingt, gehe zum Schritt S.
3) finde die neue "aktuelle" Schicht und bilde eine Abstimmungsschicht zwischen der neuen "aktuellen" Schicht und der Aktualisierungsschicht und mache die Abstimmungsschicht zur Aktualisierungsschicht.
4) Sobald die Schichten abgestimmt wurden, springe zum Schritt 1 zurück.
5) Falls daß Umbenennen im Schritt 2 gelingt, versuche, die Struktur zu komprimieren, indem die Änderungen zuerst zur Bodenschicht herunterkopiert werden, falls dies möglich ist, und indem die Schichten dann komprimiert werden.
Schließen. Verwendet die vorhergehende Schließen = Routine unverändert.
Schließen, ohne Versionen zu speichern. Verwendet die vorhergehende Schließen-Routine unverändert. Die künftige Öffnen-Routine entfernt die inkonsistente Schicht.
Öffnen. Der übergebene aktuelle Parameter kennzeichnet lediglich den Pool. Er wird durch die Routine auf die "aktuelle" Schicht umpositioniert, und es wird eine Aktualisierungsschicht zurückgegeben.

VI. SCHLUSSFOLGERUNG

Es ist demgemäß ersichtlich, daß die Speicherverwaltungseinrichtung gemäß der vorliegenden Erfindung u. a. die folgenden Vorteile bietet:
Allgemeines bzw. auswählbares Datenmodell. Während bestimmte Systeme Benutzer auf ein bestimmtes Medium (oder nur einige Medien) beschränken, abstrahiert das Datenmodell der Speicherverwaltungseinrichtung gemäß der vorliegenden Erfindung den eigentlichen gegenständlichen Speicher. Benutzer können daher die APIs der Speicherverwaltungseinrichtung verwenden, um auf jegliche Speicherarten (einschließlich Dateien, Speicherplatz, ROM, Ablageflächen, Datenbanken usw.) zuzugreifen.
Flexibler strukturierter Speicher. Bei bestehenden Datenbanksystemen ist zum Zugreifen auf Daten ein Schema erforderlich, während bei objektorientierten Systemen eine Klassenhierarchie verwendet wird, um das Datenformat zu definieren. Die Speicherverwaltungseinrichtung gemäß der vorliegenden Erfindung verwendet statt dessen ein einer "Universalbeziehung" ähnelndes, Datenmodell. Jede Blop kann eine beliebige Anzahl von Merkmalen ("Properties") und Werten ("Values") enthalten. Hierdurch wird die Anforderung eines starren Schemas oder einer Klassenhierarchie aufgehoben. Die Speicherverwaltungseinrichtung unterstützt zusätzlich zusammengesetzte Typen ("Compound Types"), bei denen das Format von Daten in einer Blop entsprechend einer verschachtelten Hierarchie von durch die Anwendung definierten Typen beschrieben werden kann, welche nur am Ende der Hierarchie durch die Speicherverwaltungseinrichtung definierte gewöhnliche Grundtypen ("Basic Types") aufrufen.
Ein anderes Simultanitätsmodell. Viele Datenbankmodelle sehen ein Sperren für einen simultanen Zugriff vor. Wenn ein Benutzer auf die Daten zugreift, kann kein anderer Benutzer auf dieselben Daten zugreifen. Dies wird als pessimistische Simultanität bezeichnet. Wenn bei bestehenden Verwirklichungen einer optimistischen Simultanität ein Zugriffsweg seine Änderungen an den Daten übergibt, müssen alle anderen Zugriffswege ihre Änderungen verwerfen. Die Speicherverwaltungseinrichtung gemäß der vorliegenden Erfindung sieht ein Simultanitätsschema vor, das sich von den oben beschriebenen recht deutlich unterscheidet. Es kann eine Simultanität durch Ändern der mit dem Schichtnamen.("Layer Name") gekennzeichneten aktuellen Schicht ("Current Layer") behandeln. Es kann auch eine Abstimmung mit der aktuellen Schicht vorgenommen werden, und die Abstimmungsschicht ("Reconciliation Layer") kann zur aktuellen Schicht gemacht werden. Dieser Prozeß ermöglicht es mehreren Benutzern, miteinander in Konflikt stehende Änderungen an einer Grundschicht ("Base Layer") vorzunehmen und die Abstimmung auf einen späteren Zeitpunkt zu verschieben.

Integration der Versionsverwaltung und der Simultanität.

Einige bestehende Systeme können Versionen unterhalten und auch die Simultanität steuern. Keines der Systeme integriert die beiden jedoch in einen Mechanismus. Bei der Speicherverwaltungseinrichtung gemäß der vorliegenden Erfindung werden Schichten nicht nur zur Versionsverwaltung sondern auch zur Steuerung der Simultanität verwendet. Benutzer können divergierende Versionen besitzen, indem sie Zweige von Schichten erzeugen, die Versionen gleichzeitig bearbeiten und jegliche miteinander in Konflikt stehende Änderungen unter Verwendung einer Abstimmungsschicht abstimmen.
Schichtverwaltungsmechanismus. Bestehende Systeme haben eine Versionsverwaltungsfähigkeit. Nur wenige haben jedoch einen wohldefinierten Mechanismus zum Verwalten der Versionen. Ein Benutzer kann eine Version nur hinzufügen, löschen oder betrachten. Die Speicherverwaltungseinrichtung gemäß der vorliegenden Erfindung definiert einen Satz von Operationen bezüglich Schichten. Ein Verschiebe-alle-Änderungennach-unten ("MoveAllChangesDown") stellt ein Archivierungsschema bereit, das vorhersehbar und wirksam ist. Vernichte- Schichten ("CollapseLayers") ermöglicht es Benutzern, unerwünschte Schichten zu entfernen. Diese Operationen vereinfachen die Versionsstruktur und verringern die Behältergröße. Das Abfallsammlungsschema beseitigt jegliche Blops, die im Behälter nicht mehr verwendet werden, und es hilft dabei, wertvollen Speicherplatz wiederzugewinnen.
Das Simultanitätsmodell paßt zu einer mobilen Verwendung. Wenige oder keine der bestehenden Systeme sind dafür ausgelegt, eine mobile Computerumgebung gut zu behandeln. Bei der Speicherverwaltungseinrichtung gemäß der vorliegenden Erfindung ermöglichen es trennbare Pools ("Separable Pools") Benutzern, eine Schicht von einem Grundpool ("Base Pool") abzuleiten und sie zu bearbeiten, während sie vom Grundpool getrennt ist. Die Änderungen können zu einem späteren Zeitpunkt unter Verwendung einer Abstimmungsschicht abgestimmt werden. Der Abstimmungsprozeß gleicht demjenigen beim Abstimmen von Änderungen von zwei Schichten in demselben Pool.
Zugriffsmittel. Die Speicherverwaltungseinrichtung gemäß der vorliegenden Erfindung sieht Zugriffsmittel ("Accessors") zum Zugreifen auf Daten in einer Blop vor. Es werden zwei Arten von Zugriffsmitteln unterstützt: CPL-Zugriffsmittel ("CPL Accessors") und BPV-Zugriffsmittel ("BPV Accessors"). CPL-Zugriffsmittel ermöglichen es einem Anwenderprogramm, den Ort eines Behälters, eines Pools oder einer Schicht zu bestimmen. BPV-Zugriffsmittel ermöglichen es dem Anwenderprogramm, den Ort eines Merkmals oder eines Werts innerhalb einer Blop zu bestimmen.
Verbergen von Behältergrenzen. Herkömmliche Speichermodelle unterstützen selten Bezüge auf ein Objekt in einer anderen Datei. Die Speicherverwaltungseinrichtung gemäß der vorliegenden Erfindung unterstützt jedoch indirekte Blops, um es zu ermöglichen, daß sich Blops in einem Behälter auf andere Blops in einem anderen Behälter beziehen. Zugriffsmittel machen das Zugreifen auf ferne Blops für das Anwenderprogramm völlig transparent.
Intelligente Typverwaltung. In vielen Programmierumgebungen werden Typen ausschließlich verwendet, um das Format von Daten zu definieren. Die Speicherverwaltungseinrichtung gemäß der vorliegenden Erfindung unterstützt jedoch komplexe Typen ("Complex Types"), die mit einem oder mehreren Grundtypen ("Basic Types") gebildet sind, wobei jedem von ihnen ein Handhabungsmittel ("Handler") zugeordnet sein kann. Die Handhabungsmittel sind in der Reihenfolge der Grundtypen in einem komplexen Typ miteinander verkettet. Ein Anwenderprogramm kann daher komplexe Typen bilden, die die Daten in der geeigneten Weise manipulieren, wenn sie aus einem Behälter abgerufen oder in einen Behälter geschrieben werden.

Claims

1. Verfahren zum Aktualisieren von in einer Datenstruktur gespeicherten Daten, wobei die Datenstruktur mehrere Datenteile (beispielsweise A.v1, B.v1, A.v2) beinhaltet, jeder Teil einen Teilabschnitt der Daten enthält und jedem Teil ein Datenteilbezeichner bzw. -identifizierer (beispielsweise A, B) zugeordnet ist, wobei die Datenstruktur weiterhin mehrere Schichtstrukturen (beispielsweise L1, L2, 206, 208, 108, "Abstimmung") aufweist, jeder der Schichtstrukturen wenigstens einer der Datenteile zugeordnet ist, die Datenteilbezeichner aller der Datenteile, die jeder gegebenen der Schichtstrukturen zugeordnet sind, zueinander eindeutig sind und einer der Schichtstrukturen (beispielsweise L3) ein Datenteil (beispielsweise B.v3) zugeordnet ist, welcher einen Datenteilbezeichner (B) aufweist, der mit demjenigen eines Datenteils (beispielsweise B.v1) identisch ist, der einer anderen (beispielsweise L1) der Schichtstrukturen zugeordnet ist, jedoch verschiedene Teilabschnitte der Daten aufweist, mit den Schritten:

- Erzeugen eines Versionsbaums (L1, L2, L3) in der Datenstruktur, der unter den Schichtstrukturen mehrere Zwischenschichtstrukturen (L2, L3) aufweist, die von einer Anfangsschichtstruktur (L1) unter den Schichtstrukturen verschieden sind, und

- Erzeugen einer Abstimmungsschichtstruktur unter den Schichtstrukturen ("Abstimmung") in der Datenstruktur auf der Grundlage von wenigstens zwei der Zwischenschichtstrukturen, wobei der Abstimmungsschichtstruktur mehrere Teile (A.v1, B.v?, C.v?, D.v1) zugeordnet sind, die jeweils einen Datenteilbezeichner (A, B, C, D) aufweisen, der dem Datenteilbezeichner eines Teils gleicht, welcher wenigstens einer der wenigstens zwei Zwischenschichtstrukturen zugeordnet ist.

2. Verfahren nach Anspruch 1, wobei der Versionsbaum wenigstens einen Zweig aufweist und sich alle Zwischenschichtstrukturen an Einem einzigen der Zweige befinden.

3. Verfahren nach Anspruch 1, wobei der Versionsbaum wenigstens zwei Zweige aufweist und sich wenigstens zwei der Zwischenschichtstrukturen (L2, L3) an verschiedenen der Zweige befinden.

4. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Erzeugens einer Abstimmungsschichtstruktur den Schritt des unveränderten Aufnehmens jedes Teils (A.v1), der sich in allen Zwischenschichtstrukturen befindet und der in allen Zwischenschichtstrukturen gleich ist, in die Abstimmungsschichtstruktur beinhaltet.

5. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Erzeugens einer Abstimmungsschichtstruktur den Schritt des unveränderten Aufnehmens jedes Teils (D.v1), der sich in genau einer der Zwischenschichtstrukturen befindet, in die Abstimmungsschichtstruktur beinhaltet.

6. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Erzeugens einer Abstimmungsschichtstruktur die folgenden Schritte beinhaltet:

- Kennzeichnen bzw. Identifizieren eines gegebenen Teils (B) , der sich in wenigstens zwei der Zwischenschichtstrukturen (L2, L3) befindet, der jedoch in den beiden Zwischenschichtstrukturen nicht gleich ist,

- Aufrufen einer Teilabstimmungsprozedur, die einen abgestimmten Teil (B.v?) zurückgibt, der die Identität (B) des gegebenen Teils aufweist, und

- Aufnehmen des abgestimmten Teils in die Abstimmungs schichtstruktur.

7. Verfahren nach einem der vorhergehenden Ansprüche, welches weiter den Schritt des Markierens der Anfangsschichtstruktur mit einer vorgegebenen Markierung ("Version" in Fig. 7) beinhaltet und welches weiter die folgenden nach dem Schritt des Erzeugens einer Abstimmungsschichtstruktur ausgeführten unteilbaren Schritte beinhaltet:

- Bestimmen, ob die Anfangsschichtstruktur noch mit der vorgegebenen Markierung markiert ist, und

- Verschieben der vorgegebenen Markierung von der Anfangsschichtstruktur zur Abstimmungsschichtstruktur, genau dann, wenn die Anfangsschichtstruktur noch mit der vorgegebenen Markierung markiert ist.

8. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Erzeugens eines Versionsbaums die folgenden Schritte beinhaltet:

- Zuordnen eines vorgegebenen Namens zu der ersten der Zwischenschichtstrukturen,

- Herstellen einer zweiten der Zwischenschichtstrukturen als eine überarbeitete Ausgabe der ersten Zwischenschichtstruktur und

- Aufrufen einer Prozedur zum Festlegen eines Schichtnamens für die zweite Zwischenschichtstruktur mit dem vordefinierten Namen und einer Kennzeichnung der ersten Zwischenschichtstruktur, wobei die Prozedur zum Festlegen eines Schichtnamens den vordefinierten Namen genau dann von der ersten Zwischenschichtstruktur zur zweiten Zwischenschichtstruktur verschiebt, wenn der vordefinierte Name zu dem Zeitpunkt, zu dem in die Prozedur zum Festlegen eines Schichtnamens eingetreten wird, der ersten Zwischenschichtstruktur noch zugewiesen ist.

9. Verfahren nach Anspruch 8, wobei sich wenigstens einer der Teile in der zweiten Zwischenschichtstruktur auch in der ersten Zwischenschichtstruktur befindet und wobei sich wenigstens einer der Teile in der zweiten Zwischenschichtstruktur nicht in der ersten Zwischenschichtstruktur befindet.

10. Verfahren nach einem der Ansprüche 8-9, wobei wenigstens einer der Teile in der zweiten Zwischenschichtstruktur eine modifizierte Version eines Teils in der ersten Zwischenschichtstruktur ist.

11. Verfahren nach einem der Ansprüche 8-10, wobei die Prozedur zum Festlegen eines Schichtnamens die folgenden Schritte beinhaltet:

- Bestimmen, ob der vordefinierte Name noch der ersten Zwischenschichtstruktur zugewiesen ist,

- und, falls dies der Fall ist, Verschieben des vordefinierten Namens von der ersten Zwischenschichtstruktur zu der zweiten Zwischenschichtstruktur,

- wobei die Prozedur zum Festlegen eines Schichtnamens Unterbrechungen zwischen dem Schritt des Bestimmens und dem Schritt des Verschiebens durch irgendeine Prozedur, die die Zuordnung der Namen zu der ersten oder der zweiten Zwischenschichtstruktur modifiziert, verhindert.

12. Verfahren nach einem der Ansprüche 8-11, das weiter beim Verwalten paralleler, duch mehrere Arbeiter überarbeiteter Ausgaben der Datenstruktur verwendbar ist, welches weiter den Schritt des Sicherstellens, daß jede neue Ausgabe der durch irgendwelche der Arbeiter überarbeiteten Datenstruktur mit den Teilen in einer beliebigen der Schichtstrukturen in der Datenstruktur beginnt, denen dann der vordefinierte Name zugeordnet wird, beinhaltet.

13. Verfahren nach einem der Ansprüche 8-12, welches, falls die Prozedur zum Festlegen eines Schichtnamens den vordefinierten Namen nicht von der ersten Zwischenschichtstruktur zu der zweiten Zwischenschichtstruktur verschoben hat, weiter die folgenden Schritte beinhaltet:

- Kennzeichnen einer dritten der Zwischenschichtstrukturen, wobei die dritte Zwischenschichtstruktur diejenige der Zwischenschichtstrukturen ist, welche dann dem vordefinierten Namen zugeordnet ist, und

- Integrieren der zweiten Zwischenschichtstruktur mit der dritten Zwischenschichtstruktur, um die Abstimmungsschichtstruktur zu erzeugen.

14. Verfahren nach Anspruch 13, wobei der Schritt des Integrierens der zweiten Zwischenschichtstruktur mit der dritten Zwischenschichtstruktur zum Erzeugen der Abstimmungsschichtstruktur den Schritt des Aufrufens einer Schichtintegrationsprozedur mit einem Bezug zu einer Rückrufprozedur beinhaltet, wobei die Schichtintegrationsprozedur die folgenden Schritte ausführt:

- Bestimmen, ob ein gegebener Teil in der zweiten Zwischenschichtstruktur einem entsprechenden Teil in der dritten Zwischenschichtstruktur gleicht bzw. entspricht, jedoch eine andere Version des entsprechenden Teils ist,

- und, falls dies der Fall ist, Aufrufen der Rückrufprozedur mit einer Kennzeichnung bzw. Identifizierung des gegebenen Teils in der zweiten Zwischenschichtstruktur und einer Kennzeichnung des entsprechenden Teils in der dritten Zwischenschichtstruktur, wobei die Rückrufprozedur die Kennzeichnung eines zur Abstimmungsschichtstruktur hinzuzufügenden Teils zurückgibt, und

- Hinzufügen des von der Rückrufprozedur gekennzeichneten Teils zur Abstimmungsschichtstruktur.

15. Verfahren nach einem der vorhergehenden Ansprüche, welches weiter den Schritt des Bereitstellens aller Teile, die sich in der Anfangsschichtstruktur (L4 in Fig. 4) befinden, auf einem ersten Datenspeichermedium beinhaltet,

wobei der Schritt des Erzeugens eines Versionsbaums in der Datenstruktur die folgenden Schritte beinhaltet:

- Herstellen eines Delta-Pools (404) aus Teilen der Arbeit aus der Anfangsschichtstruktur, wobei der Delta-Pool eine erste neue Schichtstruktur (L5) enthält, die anfänglich alle Teile der Arbeit aufweist, die sich in der Anfangsschichtstruktur befinden, und

- Ausführen von wenigstens einem der Schritte (1) Hinzufügen eines zusätzlichen Teils zu der ersten neuen Schichtstruktur, (2) Löschen eines Teils der ersten neuen Schichtstruktur und (3) Erzeugen einer Kopie eines bestimmten der Teile, die sich in der Anfangsschichtstruktur befinden, um eine erste neue Version des bestimmten Teils in der ersten neuen Schichtstruktur zu erzeugen, wobei diese erste neue Version des bestimmten Teils jede vorhergehende Version des bestimmten Teils in der ersten neuen Schichtstruktur ersetzt,

- wobei das Verfahren weiter den Schritt des Bereitstellens aller Teile, die sich in der ersten neuen Schichtstruktur und nicht in der Anfangsschichtstruktur befinden, und einer Kennzeichnung von jedem der Teile in der Anfangsschichtstruktur, die in der ersten neuen Schichtstruktur gelöscht wurden, auf einem zweiten Medium beinhaltet.

16. Verfahren nach Anspruch 15, welches weiter die folgenden Schritte beinhaltet:

- wirkungsmäßiges Koppeln des ersten Mediums mit einem Computer, so daß alle Teile in der Anfangsschichtstruktur lesbar sind, und nachfolgend

- wirkungsmäßiges Koppeln des zweiten Mediums mit dem Computer und

- Lesen von Teilen in der ersten neuen Schichtstruktur, wobei alle Teile in der ersten neuen Schichtstruktur, die sich nicht in der Anfangsschichtstruktur befinden, aus dem zweiten Medium ausgelesen werden, alle Teile in der ersten neuen Schichtstruktur, die Teile in der Anfangsschichtstruktur ersetzt haben, aus dem zweiten Medium ausgelesen werden, und alle Teile, die sich sowohl in der Anfangsschichtstruktur als auch in der ersten neuen Schichtstruktur befinden, aus dem ersten Medium ausgelesen werden.

17. Verfahren nach einem der Ansprüche 8-16, das weiter die folgenden Verschieben-aller-Änderungen-nach-unten-Schritte (im englischen Originaltext: Move-All-Changes-Down steps) beinhaltet:

- Löschen aller Teile aus der ersten Zwischenschichtstruktur, die sich in der ersten Zwischenschichtstruktur und nicht in der zweiten Zwischenschichtstruktur befinden,

- Hinzufügen aller Teile in der zweiten Zwischenschichtstruktur, die sich nicht bereits in der ersten Zwischenschichtstruktur befinden, zur ersten Zwischenschichtstruktur und

- in der ersten Zwischenschichtstruktur erfolgendes Ersetzen jedes bestimmten Teils in der ersten Zwischenschichtstruktur, der einen entsprechenden Teil in der zweiten Zwischenschichtstruktur aufweist, welcher eine überarbeitete Ausgabe des bestimmten Teils in der ersten Zwischenschichtstruktur ist, durch den entsprechenden Teil aus der zweiten Zwischenschichtstruktur.

18. Verfahren nach einem der Ansprüche 8-17, wobei der Schritt des Herstellens einer zweiten Zwischenschichtstruktur als eine überarbeitete Ausgabe der ersten Zwischenschichtstruktur die folgenden Schritte beinhaltet:

- seriell durch wenigstens ein in dem gegebenen Teil spezifiziertes Handhabungsmittel erfolgendes Verarbeiten wenigstens eines Teilabschnitts eines gegebenen der Teile in der ersten Zwischenschichtstruktur und

Überarbeiten des gegebenen Teils in der verarbeiteten Form.

19. Verfahren nach Anspruch 18, wobei der Schritt des Verarbeitens den Schritt des seriell durch wenigstens zwei in dem gegebenen Teil in der ersten Zwischenschichtstruktur spezifizierte Handhabungsmittel erfolgenden Verarbeitens des Teilabschnitts des gegebenen Teils beinhaltet, wobei die Folge der Handhabungsmittel auch in dem gegebenen Teil spezifiziert ist.

20. Verfahren nach einem der Ansprüche 1-7 (Fig. 5), wobei die Teile in der Anfangsschichtstruktur (L1 in Fig. 5) in einem Grund-Pool (506) von Teilen enthalten sind und· der Grund-Pool wirkungsmäßig mit einem Computer gekoppelt ist, wobei der Schritt des Erzeugens eines Versionsbaums die folgenden Schritte beinhaltet:

- Kopieren aller Teile, die sich in der Anfangsschichtstruktur befinden, in einen trennbaren Pool (504) von Teilen, wobei der trennbare Pool wirkungsmäßig mit dem Computer gekoppelt ist,

- Trennen des trennbaren Pools von dem Computer und

- Überarbeiten der Daten in der Datenstruktur von den Kopien der Teile in dem trennbaren Pool, während der trennbare Pool von dem Computer getrennt ist, um eine getrennte Schichtstruktur (L2 in 508) in der Datenstruktur zu erzeugen, wobei die getrennte Schichtstruktur eine der Zwischenschichtstrukturen ist,

- und wobei der Schritt des Erzeugens einer Abstimmungsschichtstruktur den Schritt des Aufrufens einer Pool- Integrationsprozedur für die getrennte Schichtstruktur (L2) und eine Grundschichtstruktur (L1) mit Bezug auf eine Rückrufprozedur beinhaltet, wobei die Pool- Integrationsprozedur die folgenden Schritte ausführt:

- Bestimmen, ob ein gegebener Teil in der getrennten Schichtstruktur eine Kopie eines entsprechenden Teils in der Grundschichtstruktur, jedoch eine andere Version des entsprechenden Teils in der Grundschichtstruktur, ist,

- und, falls dies der Fall ist, Aufrufen der Rückrufprozedur mit einer Kennzeichnung des gegebenen Teils in der getrennten Schichtstruktur und einer Kennzeichnung des entsprechenden Teils in der Grundschichtstruktur, wobei diese Rückrufprozedur die Kenn Zeichnung eines zur Abstimmungsschichtstruktur (L3 in 508) hinzuzufügenden Teils zurückgibt, und

- Hinzufügen des von der Rückrufprozedur gekennzeichneten Teils zur Abstimmungsschichtstruktur (L3 in 508).

21. Verfahren nach Anspruch 20, wobei die Grundschichtstruktur (L1) die Anfangsschichtstruktur ist.

22. Verfahren nach Anspruch 20, wobei sich die Grundschichtstruktur transitiv oberhalb der Anfangsschichtstruktur befindet.

23. Verfahren nach einem der Ansprüche 20-22, wobei die Pool-Integrationsprozedur weiter den Schritt des Bestimmens, ob ein Teil in der trennbaren Schichtstruktur eine Kopie eines kopierten Teils in der Grundschichtstruktur ist, und des, falls dies der Fall ist, Aufnehmens des kopierten Teils in die Abstimmungsschichtstruktur beinhaltet.

24. Verfahren nach einem der Ansprüche 20-23, wobei die Pool-Integrationsprozedur weiter die folgenden Schritte beinhaltet:

- Bestimmen, ob eine Kopie eines bestimmten Teils in der Grundschichtstruktur aus der getrennten Schichtstruktur gelöscht wurde,

- und, falls dies der Fall ist, Aufrufen der Rückrufprozedur mit einer Kennzeichnung des bestimmten Teils in der Grundschichtstruktur, wobei die Rückrufprozedur die Kennzeichnung eines zur Abstimmungsschichtstruktur hinzuzufügenden Teils zurückgibt, und

25. Datenspeichervorrichtung, in der Daten in einer Daten struktur gespeichert sind, die mehrere Teile (beispielsweise A.v1, B.v1, A.v2) der Daten beinhaltet, wobei jeder Teil einen Teilabschnitt der Daten enthält und jedem Teil ein Datenteilbezeichner (beispielsweise A, B) zugeordnet ist, dadurch gekennzeichnet, daß die Datenstruktur weiter mehrere Schichtstrukturen (beispielsweise L1, L2, 206, 208, 108, "Abstimmung") aufweist, jeder der Schichtstrukturen wenigstens einer cer Datenteile zugeordnet ist, die Datenteilbezeichner aller der Datenteile, die jeder gegebenen der Schichtstrukturen zugeordnet sind, zueinander eindeutig sind und eine der Schichtstrukturen (beispielsweise L3) einen Teil (beispielsweise B.v3) beinhaltet, der einen Datenteilbezeichner (B) aufweist, der mit demjenigen eines Datenteils (beispielsweise B.v1) in einer anderen (beispielsweise L1) der Schichtstrukturen identisch ist, jedoch verschiedene Teilabschnitte der Daten aufweist.

26. Vorrichtung nach Anspruch 25, wobei die mehreren Schichtstrukturen (L1, L2, L3, "Abstimmung") eine Bodenschichtstruktur (L1) und wenigstens eine obere Schichtstruktur ("Abstimmung"), die von der Bodenschichtstruktur verschieden ist, aufweisen, wobei jede Schichtstruktur mit Ausnahme der Bodenschichtstruktur unmittelbar oberhalb wenigstens einer anderen der mehreren Schichtstrukturen liegt und jede der mehreren Schichtstrukturen mit Ausnahme der oberen Schichtstrukturen unmittelbar unterhalb wenigstens einer anderen der mehreren Schichtstrukturen liegt, wobei alle Teile der Daten, die jeder der gegebenen Schichtstrukturen mit Ausnahme der unteren Schichtstruktur zugeordnet sind, der Gruppe angehören, die aus (a) einem Datenteil (beispielsweise D in der Schicht L3), der einen Datenteilbezeichner aufweist, der von den Datenteilbezeichnern in allen Datenteilen verschieden ist, die jeglichen der Schichtstrukturen unterhalb der gegebenen Schichtstruktur zugeordnet sind, und (b) einem Datenteil (beispielsweise B in der Schicht L3), der einen Datenteilbezeichner aufweist, der demjenigen von einem der Datenteile (B in L2), die einer der Schichtstrukturen (L1) zugeordnet sind, welche sich unmittelbar unterhalb der gegebenen Schichtstruktur befinden, gleicht, der jedoch einen Teilabschnitt der Daten aufweist, der von dem Teilabschnitt verschieden ist, der in dem einen der Datenteile enthalten ist, die einer der Schichtstrukturen zugeordnet sind, die sich unmittelbar unterhalb der gegebenen Schichtstruktur befinden, besteht.

27. Vorrichtung nach Anspruch 26, wobei sich eine Verzweigung bzw. eine eine Verzweigung aufweisende der Schichtstrukturen (L1) unmittelbar unterhalb zwei anderen der Schichtstrukturen (L2, L3) befindet.

28. Vorrichtung nach Anspruch 27, wobei einer ersten (L3) der zwei anderen Schichtstrukturen ein erster Datenteil (A.v1), der auch der Zweigschichtstruktur (L1) zugeordnet ist, und ein zweiter Datenteil (B.v3), der einen Datenteilbezeichner bzw. -identifizierer (B) aufweist, der demjenigen eines dritten der Datenteile (B.v1), die der Zweigschichtstruktur (L1) zugeordnet sind, gleicht, der jedoch einen Teilabschnitt der Daten aufweist, der von demjenigen des dritten Datenteils verschieden ist, zugeordnet sind, und wobei der zweiten (L2) der zwei anderen Schichtstrukturen der erste Datenteil (A.v1) und ein vierter Datenteil (B.v2) zugeordnet sind, wobei der vierte Datenteil einen Datenteilbezeichner (B) aufweist, der demjenigen des zweiten und des dritten Datenteils (B.v1, B.v3) gleicht, der jedoch einen Teilabschnitt der Daten aufweist, der von demjenigen des dritten Datenteils verschieden ist.

29. Vorrichtung nach Anspruch 26, wobei sich eine Abstimmungsschichtstruktur unter den Schichtstrukturen ("Abstimmung") unmittelbar oberhalb von zwei anderen (L2, L3) der Schichtstrukturen befindet.

30. Vorrichtung nach Anspruch 29, wobei alle der Abstimmungsschichtstruktur zugeordneten Datenteile auch wenigstens einer der Schichtstrukturen zugeordnet sind, die sich unmittelbar unterhalb der Abstimmungsschichtstruktur befinden.

31. Vorrichtung nach Anspruch 30, wobei ein erster der Datenteile (B.v?), der der Abstimmungsschichtstruktur zugeordnet ist, auch einer ersten der Schichtstrukturen (B.v2 in L2) zugeordnet ist, die sich unmittelbar unterhalb der Abstimmungsschichtstruktur befinden,

wobei der Datenteilbezeichner (B) des ersten Datenteils (B.v?) demjenigen eines zweiten Datenteils (B.v3) gleicht, der einer zweiten der Schichtstrukturen (L3) zugeordnet ist, die sich unmittelbar unterhalb der Abstimmungsschichtstruktur befinden,

wobei jedoch der Teilabschnitt der Daten, die in dem ersten Datenteil (B.v?) enthalten sind, von demjenigen des zweiten Datenteils (B.v3) verschieden ist.

32. Vorrichtung nach Anspruch 25, wobei die Datenstruktur mehrere Pools (402, 404, 504, 506, 508) der Schichtstrukturen und der Datenteile unter Einschluß eines ersten Pools (402, 506) und eines zweiten Pools (404, 504) beinhaltet, wobei die mehreren Schichtstrukturen eine erste Bodenschichtstruktur (L1) in dem ersten Pool und eine zweite Bodenschichtstruktur (L5 im Pool 404; L2 im Pool 504) in dem zweiten Pool beinhalten, wobei sich alle weiteren Schichtstrukturen (L2, L3, L4) in dem ersten Pool (402) oberhalb der ersten Bodenschichtstruktur (L1) befinden und sich alle weiteren Schichtstrukturen (L6, L7, L8) in dem zweiten Pool (404) oberhalb der zweiten Bodenschichtstruktur (L5) befinden, wobei alle jeder gegebenen Schichtstruktur im ersten und im zweiten Pool zugeordneten Datenteile, wobei sich die Schichtstruktur unmittelbar oberhalb einer anderen Schichtstruktur befindet, der Gruppe angehören, die aus (a) einem Datenteil, der keiner Schichtstruktur unterhalb der gegebenen Schichtstruktur zugeordnet ist, und (b) einem Datenteil, der wenigstens einer Schichtstruktur unmittelbar unterhalb der gegebenen Schichtstruktur zugeordnet ist, besteht.

33. Vorrichtung nach Anspruch 32, wobei keine zwei der Datenteile, die jeglichen der Schichtstrukturen in jeglichen gegebenen der Pools zugeordnet sind, den gleichen Datenteilbezeichner und den gleichen Teilabschnitt der Daten aufweisen.

34. Vorrichtung nach Anspruch 32, wobei sich die zweite Bodenschichtstruktur (L5) oberhalb einer Schichtstruktur (L1, L3, L4) in dem ersten Pool befindet.

35. Vorrichtung nach Anspruch 34, wobei einer der Datenteile, die einer der Schichtstrukturen (L1) in dem ersten Pool (506) zugeordnet sind, in einem ersten Datenspeichermedium gespeichert ist und wobei einer der Datenteile, die einer der Schichtstrukturen (L2) in dem zweiten Pool (504) zugeordnet sind, (a) keiner der Schichtstrukturen in dem ersten Pool zugeordnet ist und (b) in einem zweiten Datenspeichermedium gespeichert ist, das von dem ersten Datenspeichermedium verschieden ist.

36. Vorrichtung nach Anspruch 35, wobei das zweite Datenspeichermedium bezüglich des ersten Datenspeichermediums entfernbar ist.

37. Vorrichtung nach Anspruch 32, wobei alle Datenteile, die der zweiten Bodenschichtstruktur (L5 oder L2) zugeordnet sind, Kopien jeweiliger Datenteile sind, die einer Grundschichtstruktur der Schichtstrukturen (L4 oder L1) in dem ersten Pool zugeordnet sind.

38. Vorrichtung nach Anspruch 37, wobei einer der der Grundschichtstruktur in dem ersten Pool zugeordneten Datenteile in einem ersten Datenspeichermedium gespeichert ist und wobei alle der zweiten Bodenschichtstruktur zugeordneten Datenteile in einem zweiten Datenspeichermedium gespeichert sind, das von dem ersten Datenspeichermedium verschieden ist.

39. Vorrichtung nach Anspruch 37, wobei einer der der Grundschichtstruktur in dem ersten Pool zugeordneten Datenteile in einem ersten Datenspeichermedium gespeichert ist und wobei alle der zweiten Bodenschichtstruktur zugeordneten Datenteile in Datenspeichermedien gespeichert sind, die bezüglich des ersten Datenspeichermediums entfernbar sind.

40. Vorrichtung nach Anspruch 37, wobei sich eine Abstimmungsschichtstruktur unter den Schichtstrukturen (L3 in 508) in dem ersten Pool unmittelbar oberhalb einer anderen Schichtstruktur (L1 in 508) in dem ersten Pool und auch unmittelbar oberhalb einer Schichtstruktur (L2 in 508) in dem zweiten Pool befindet.

41. Vorrichtung nach einem der Ansprüche 25-40, wobei die Datenstruktur weiter einen ersten und einen zweiten Behälter (1202) aufweist, wobei jeder Behälter wenigstens einen der Datenteile und wenigstens eine der Schichtstrukturen beinhaltet, wobei alle Datenteile in dem ersten Behälter in einem ersten Datenspeichermedium gespeichert sind und alle Datenteile in dem zweiten Behälter in einem zweiten Datenspeichermedium, das von dem ersten Datenspeichermedium verschieden ist, gespeichert sind.

42. Vorrichtung nach Anspruch 41, wobei dem ersten Behälter ein erstes Handhabungsmittel zum Handhaben von Datenzugriffen auf das erste Medium zugeordnet ist und wobei dem Behälter ein zweites Handhabungsmittel zum Handhaben von Datenzugriffen auf das zweite Medium zugeordnet ist, wobei das zweite Handhabungsmittel von dem ersten Handhabungsmittel verschieden ist.

43. Vorrichtung nach einem der Ansprüche 25-40, wobei der Teilabschnitt der in jedem der Datenteile enthaltenen Daten in wenigstens einen Wert (2714) eingeteilt ist, wobei jeder der Werte in jedem der Datenteile einen zugeordneten Wertetyp (2515) aufweist, der das Format des Werts angibt.

44. Vorrichtung nach Anspruch 43, wobei ein einziger der Wertetypen in einem gegebenen der Datenteile mehreren Werten in dem gegebenen Datenteil zugeordnet ist.

45. Vorrichtung nach Anspruch 43, wobei jeder der Werte in einem gegebenen der Datenteile auch ein zugeordnetes Merkmal bzw. eine zugeordnete Eigenschaft in dem Datenteil aufweist, wobei alle Merkmale in dem gegebenen Datenteil darin eindeutig benannt sind und alle Werte in dem gegebenen Datenteil eindeutig innerhalb eines gegebenen Merkmals in dem gegebenen Datenteil benannt sind.

46. Vorrichtung nach Anspruch 43, wobei ein gegebener der Werte in einem gegebenen der Datenteile weiter in mehrere Unterwerte eingeteilt ist, wobei jeder der Unterwerte in dem Datenteil einen zugeordneten Untertyp aufweist, der das Format des Unterwerts angibt, und wobei die Unterteilung des gegebenen Werts in Unterwerte und die Kennzeichnung des jedem der Unterwerte zugeordneten Werte-Untertyps beide durch den dem gegebenen Wert zugeordneten Wertetyp definiert sind.

47. Vorrichtung nach einem der Ansprüche 43-46, wobei der einem gegebenen der Werte zugeordnete Wertetyp einen Bezug zu einer Entschlüsselungsprozedur zum Lesen des Teilabschnitts der in dem gegebenen Wert gespeicherten Daten aufweist.

48. Vorrichtung nach einem der Ansprüche 43-47, wobei der einem gegebenen der Werte zugeordnete Wertetyp einen Bezug zu mehreren Handhabungsmitteln und einer Folge der Handhabungs mittel zum Lesen des Teilabschnitts der in dem gegebenen Wert gespeicherten Daten aufweist.