DE69936257T2

DE69936257T2 - Erzeugen und uberprüfen von referenz-adresszeigern

Info

Publication number: DE69936257T2
Application number: DE69936257T
Authority: DE
Inventors: John R. Bellevue DOUCEUR; Yoram Seattle BERNET; Ofer Bar
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1998-06-23
Filing date: 1999-06-23
Publication date: 2008-02-07
Anticipated expiration: 2019-06-24
Also published as: AU4581699A; ATE364207T1; EP1088268A1; WO1999067710A1; JP4290335B2; JP4290337B2; EP1088278B1; US6105039A; DE69936257D1; US6636874B1; EP1090347A1; JP2002519764A; WO1999067723A2; JP4290336B2; JP2002519758A; WO1999067709A1; AU4705699A; EP1088278A2; WO1999067723A3; AU4581599A

Description

Die vorliegende Erfindung betrifft Computersysteme zum Erzeugen, Verwalten und Validieren von Bezugs-Handles von Verbrauchern, die Zugriff auf Ressourcen anfordern.
Es ist nichts Ungewöhnliches, dass Softwaremodule, die in Computersystemen betrieben werden, Zugriff auf gemeinsam genutzte Ressourcen anfordern. So kann beispielsweise ein jeweiliges Computerprogramm Zugriff auf Dateien anfordern, die durch ein Dateiensystem unterhalten werden, oder es kann Zugriff auf Netzwerkverbindungen, die durch einen Netzwerk-Treiber unterhalten werden, anfordern. Netzwerk-Treiber fordern möglicherweise Zugriff auf Informationsstrukturen, die durch eine Netzwerkpaket-Klassifizierungseinrichtung unterhalten werden, an. Hierbei handelt es sich um eine komplizierte Anordnungsstruktur, die eine Vielzahl von Softwaremodulen, wie beispielsweise Software-Treibern, die Zugriff auf viele gemeinsam genutzte Ressourcen anfordern, und eine Zugriffs-Überwachungseinrichtung, die entweder die Ressourcen unterhält oder wenigstens bei dem Zugriff durch die Softwaremodule auf die Ressource als Vermittler agiert, umfasst.
Solche eine Vermittlung wird aus verschiedenen Gründen durchgeführt, wobei ein besonders wichtiger Grund aus dem Fall herrührt, in dem ein Softwaremodul eine Ressource entfernt. Wenn ein erstes Softwaremodul eine erste Ressource entfernen sollte, währenddessen andere Softwaremodule direkte Zeiger zu der ersten Ressource unterhalten, wären sich die Zeiger der anderen Softwaremodule des Entfernens der Ressource nicht bewusst, und sie würden nicht länger zu einer gültigen Ressource zeigen. Es wurden Versuche unternommen, um dieses Problem zu lösen, bei denen Softwaremodule benachrichtigt werden, wenn ein Entfernen einer Ressource auftritt. Dies erfordert jedoch ein ausführliches Accounting und Tracking (Nachverfolgen) von Softwaremodulen und ihren jeweiligen Zeigern zu den Ressourcen. Als Ergebnis ist dieser Prozess äußerst kostenintensiv und sehr komplex.
Ein weiterer Versuch, dieses Problem zu lösen, beinhaltet das Veranlassen einer Zugriffs-Überwachungseinrichtung zum Vermitteln, wenn eine Softwaremodul Zugriff auf eine bestimmte Ressource anfordert. Durch das Vermitteln wird gewährleistet, dass die bestimmte Ressource noch existiert, bevor dem Softwaremodul Zugriff auf die bestimmte Ressource gewährt wird. Typischweise wird dies dadurch erzielt, dass die Zugriffs-Überwachungseinrichtung veranlasst wird, jedem Softwarenmodul ein Handle zu einer bestimmten Ressource auszugeben, anstatt jedem Softwaremodul einen direkten Zeiger zu dieser bestimmten Ressource zu gestatten. Das Softwaremodul verwendet das Handle nicht, um direkt auf die Ressource zuzugreifen. Stattdessen präsentiert das Softwaremodul das Handle der Zugriffs-Überwachungseinrichtung, die das Handle dereferenzieren kann, um für dieses Softwaremodul einen Zeiger zu der Ressource zu erhalten. Obgleich diese Herangehensweise der Zugriffs-Überwachungseinrichtung ermöglicht, eine Kontrolle über die Verwaltung der gemeinsam genutzten Ressourcen zu haben, liefern bisher vorhandene Verfahren, die diese Herangehensweise verfolgen, lediglich eine rudimentäre Kontrolle und weisem dementsprechend mehrere Einschränkungen auf.
Erstens, sind bisherig angewendete Verfahren uneffizient, kostenintensiv und weisen hinsichtlich ihren Verwendungsmöglichkeiten Einschränkungen auf, da sie über keine Operationen in konstanter Zeit verfügen, was sich dann als Problem erweist, wenn die Anzahl von gleichzeitig aktiven Handles groß ist. Darüber hinaus weisen die Handle-Datenbanken der bisherig angewendeten Verfahren eine begrenzte Flexibilität auf, da sie nicht auf effiziente Weise beliebig vergrößert oder verkleinert werden können. Zusätzlich dazu fehlt es den bisherig angewendeten Verfahren an einem schnellen und effizienten Dereferenzieren, und sie sind in einer Multi-Thread-Umgebung ineffektiv. Darüber hinaus fehlt es den bisherig angewendeten Verfahren an effizienten Prozessen zum Wiederverwenden (Recycling) von Handles zum Vergrößern des Handle-Platzes und zum Optimieren der Handle-Datenbank. In Anbetracht dessen wird ein computerimplementiertes System zum effektiven und effizienten Erzeugen und Validieren von Bezugs-Handles, welches diese Einschränkungen überwindet, benötigt.
Wie auch immer die Vorzüge der bisherig angewendeten Systeme und Verfahren sein mögen, erzielen sie nicht Vorteile der vorliegenden Erfindung.
ANDREAS J R ET AL offenbart in dem Dokument: „MANAGING AND SHARING DISPLAY OBJECTS IN THE STARBASE/X11 MERGE SYSTEM", im Hewlett-Packard Journal, Bnd. 40, Nr. 6, 1. Dezember 1989, Seiten 12 bis 19, eine objektorientierte Herangehensweise zum Einbinden von gemeinsam genutzten Grafikressourcen, und sie offenbart insbesondere eine Vorrichtung zum Allozieren einer Systemanzeige-Ressource unter verschiedenen konkurrierenden Clients.
Das Dokument EP 0 405 724 A offenbart Datenverarbeitungssysteme für dynamisches Ressourcen-Pooling, wobei das Vergrößern und das Verkleinern eines Ressourcen-Pools auf dynamische Art und Weise in Reaktion auf eine Anforderung für die Ressourcen offenbart wird.
Das Dokument „RESOURCE MANAGEMENT SYSTEM FOR MULTIMEDIA DEVICES" im IBM Technical Disclosure Bulletin, Bnd. 36, Nr. 9B, vom 1. September 1993, offenbart eine Softwareimplementierung zum Bereitstellen eines normalisierten Mechanismus zum dynamischen Verwalten von Multimedia-Ressourcen in einer Vielzahl von Anwendungsumgebungen.
Das Dokument EP 0 424 758 offenbart ein Verfahren zum seriellen gemeinsamen Nutzen von erneut nutzbaren Ressourcen von N Prozessen, wobei jeder Bezug durch lediglich einen Prozess benutzt und unabhängig von den anderen Bezügen betrieben wird.
Es ist die Aufgabe der vorliegenden Erfindung, verbesserte Verfahren zum Bereitstellen von Kommunikation zwischen einem Zugriffs-Vermittler und einer Vielzahl von Ressourcen in einem System bereitzustellen, das Verbraucher aufweist, die Zugriff auf diese Ressourcen anfordern.
Diese Aufgabe wird durch den Gegenstand der unabhängigen Ansprüche 1 und 4 erfüllt.
Bevorzugte Ausführungsformen werden durch den Gegenstand der abhängigen Ansprüche definiert.
Um die voranstehend beschriebenen Einschränkungen des Standes der Technik zu überwinden, und um weitere Einschränkungen zu überwinden, die beim Lesen und Verstehen der vorliegenden Erfindung offensichtlich werden, ist die vorliegende Erfindung in einem Verfahren zum Erzeugen und Validieren von Bezugs-Handles für Verbraucher, die in einem Computersystem Zugriff auf Ressourcen anfordern, ausgeführt. Durch das Erzeugen und Validieren von Bezugs-Handles entsprechend der vorliegenden Erfindung wird ein effizientes Verwalten und Administrieren des Zugriffes durch Verbraucher auf Ressourcen in einer Vielzahl von Computerumgebungen bereitgestellt, so wie beispielsweise in vernetzten Personalcomputern und nicht-vernetzten Personalcomputern.
Ein Aspekt, der für das Verständnis der vorliegenden Erfindung von Nutzen ist, umfasst einen Ressourcen-Verwalter, der einen Handle-Administrator aufweist, eine Vielzahl von Verbrauchern und eine Vielzahl von Ressourcen. In der folgenden Beschreibung bezieht sich der Begriff „Verbraucher" auf ein Softwaremodul, das, unter anderem, Zugriff auf eine Ressource anfordert (beispielsweise einen Druckertreiber, der Zugriff auf eine dynamische Link-Bibliothekendatei (DLL) anfordert). Der Begriff „Ressourcen-Verwalter" bezieht sich auf ein Softwaremodul, das entweder die Ressourcen unterhält oder wenigstens bei dem Zugriff durch die Verbraucher auf die Ressource als Vermittler agiert. Der Ressourcen-Verwalter verwaltet die Handles, die er an die Verbraucher ausgibt.
Der Handle-Administrator umfasst eine Zuweisungs-Routine, eine Freigabe-Routine und eine Dereferenzierungs-Routine. Mit der Zuweisungs-Routine werden neue Handles ausgegeben, mit der Freigabe-Routine werden Handles, die nicht weiter angefordert werden, freigegeben (dementsprechend wird das Handle als ungültig eingeschätzt), und mit der Dereferenzierungs-Routine werden Handles zu einem Zeiger zu einer Ressource dereferenziert, was das Bestätigen, dass das Handle ungültig ist, umfasst. Zusätzlich dazu umfasst der Aspekt eine Hilfs-Subroutine zum Verwalten von genutzten und ungenutzten Einträgen, eine Vergrößerungs-Subroutine zum effizienten Vergrößern der Handle-Datenbank, eine Handle-Wiederverwendungs-Subroutine zum Wiederverwenden (Recyclen) von Handles, eine Verkleinerungs-Subroutine zum effizienten Verkleinern der Handle-Datenbank, eine Hysterese-Subroutine zum auf Wahrscheinlichkeitsrechnung basierenden Verkleinern der Handle-Datenbank sowie eine Subroutine für fehlgeschlagene Speicherallozierung.
Ein Leistungsmerkmal des Aspektes besteht darin, dass die Zuweisung und die Freigabe von Handles Vorgänge sind, die mit konstanter Zeit durchgeführt werden, was vor allem dann wichtig ist, wenn die Anzahl von gleichzeitig aktiven Handles groß ist. Ein weiteres Leistungsmerkmal besteht darin, dass der Handle-Administrator der vorliegenden Erfindung effiziente Zuweisungs-, Freigabe- und Dereferenzierungs-Routinen aufweist, die in einer Multi-Thread-Umgebung auf effiziente Weise funktionieren. Ein weiterer Aspekt der für das Verständnis der vorliegenden Erfindung von Nutzen ist, besteht darin, dass die Größe der Datenbank beliebig vergrößert werden kann, was sich dann als wichtig erweist, wenn die Anzahl an Handles vorab nicht bekannt ist; und darin, dass die Größe der Datenbank gegebenenfalls verkleinert werden kann, was sich dann als besonders wichtig erweist, wenn die Anzahl von Handles dramatisch variiert. Ein weiteres Leistungsmerkmal der vorliegenden Erfindung besteht darin, dass, wenn die Anzahl von Handles, die über eine Lebenszeit ausgegeben werden, die Größe des Handle-Platzes übersteigt, die Handles wiederverwendet werden können.
Dementsprechend ist der Handle-Administrator so eingerichtet, dass er effizient und effektiv arbeitet, wenn die Anzahl von gleichzeitig aktiven Handles groß ist, wenn die Anzahl von gleichzeitig aktiven Handles vorab unbekannt ist, wenn die Anzahl von gleichzeitig aktiven Handles im Verlauf der Zeit dramatisch variiert, wenn das Dereferenzieren der Handles sehr schnell durchgeführt werden muss, wenn der Betrieb in Multi-Thread-Umgebungen erfolgt, und wenn die Anzahl von Handles, die über eine Lebenszeit ausgegeben werden, in Anbetracht des Handle-Platzes sehr groß ist.
Die voranstehend genannten sowie weitere Leistungsmerkmale und Vorteile der vorliegenden Erfindung ebenso wie ein vollständigeres Verständnis davon werden anhand der Betrachtung der folgenden ausführlichen Beschreibung der Erfindung in Zusammenhang mit den beigefügten Zeichnungen und der angehängten Ansprüche offensichtlich.
In Bezug auf die Zeichnungen, in denen gleiche Referenznummern die entsprechenden Teile in der gesamten Beschreibung darstellen, ist
1 ein Blockdiagramm, das eine Vorrichtung zum Umsetzen der Erfindung illustriert;
2 ist ein Blockdiagramm, das die Interaktion zwischen den wichtigsten Komponenten der vorliegenden Erfindung illustriert;
3 ist ein Ablaufdiagramm, das die grundlegende Funktionsweise des Handle-Administrators der vorliegenden Erfindung illustriert;
4 ist ein Blockdiagramm einer Architektur, das die wichtigsten Komponenten und die Sub-Komponenten eines Funktionsbeispiels der vorliegenden Erfindung illustriert;
Die 5 bis 7 sind Diagramme, die die Handle-Wiederverwendungs-Subroutine der vorliegenden Erfindung visuell illustrieren;
8 ist ein Ablaufdiagramm, das die Zuweisungs-Routine der vorliegenden Erfindung illustriert;
9 ist ein Ablaufdiagramm, das die Freigabe-Routine der vorliegenden Erfindung illustriert;
10 ist ein Ablaufdiagramm, das die Dereferenzierungs-Routine der vorliegenden Erfindung illustriert;
Die 11A und 11B sind Ablaufdiagramme, die die Vergrößerungs-Subroutine der Zuweisungs-Routine der vorliegenden Erfindung illustriert;
Die 12A und 12B sind Ablaufdiagramme, die die Verkleinerungs-Subroutine der Freigabe-Routine der vorliegenden Erfindung illustrieren;
13 ist ein Ablaufdiagramm, das die Subroutine zum Aktualisieren der Einträge der Verkleinerungs-Subroutine der vorliegenden Erfindung illustriert;
14 ist ein Ablaufdiagramm, das die Subroutine zum Erklären von alten Handles als ungültig der Vergrößerungs-Subroutine der vorliegenden Erfindung illustriert; und
15 ist ein Ablaufdiagramm, das die Subroutine zum Verarbeiten von Einträgen der Subroutine zum Erklären von alten Handles als ungültig der vorliegenden Erfindung illustriert.
In der folgenden Beschreibung der Erfindung wird Bezug auf die beigefügten Zeichnungen genommen, die einen Bestandteil davon bilden, und in denen im illustrativen Sinne ein spezifisches Beispiel dargestellt ist, in dem die Erfindung umgesetzt werden kann. Hierbei ist zu beachten, dass auch andere Ausführungsformen verwendet werden können und strukturelle Änderungen vorgenommen werden können, ohne von dem Umfang der vorliegenden Erfindung abzuweichen.
ÜBERBLICK
Exemplarische Betriebsumgebung
1 und die folgende Diskussion stellen beabsichtigterweise eine kurze, allgemeine Beschreibung einer geeigneten Rechenumgebung, in der die Erfindung implementiert werden kann, bereit. Obwohl dies nicht unbedingt erforderlich ist, wird die Erfindung in dem allgemeinen Kontext von durch Computer ausführbaren Befehlen wie beispielsweise Programmmodulen, welche durch einen Personalcomputer ausgeführt werden, beschrieben. Im Allgemeinen umfassen Programmmodule Routinen, Programme, Objekte, Komponenten, Datenstrukturen und so weiter, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Darüber hinaus wird es den Personen mit der gewöhnlichen Erfahrung auf dem Gebiet der Technik offensichtlich sein, dass sie Erfindung auch mit anderen Computersystem-Konfigurationen, einschließlich Handgeräten, Multiprozessorsystemen, auf Mikroprozessoren basierenden oder programmierbaren Konsumelektronikgeräten, Netzwerk-PCs, Minicomputern, Großrechnern und Ähnlichen umgesetzt werden kann. Darüber hinaus kann die Erfindung auch in verteilten Rechenumgebungen umgesetzt werden, in denen Aufgaben durch dezentrale Verarbeitungsvorrichtungen ausgeführt werden, die über ein Kommunikationsnetzwerk angeschlossen sind. In einer verteilten Rechenumgebung können die Programmmodule sowohl in lokalen als auch in dezentralen Speichereinrichtungen vorhanden sein.
In Bezug auf 1 umfasst ein exemplarisches System zum Implementieren der Erfindung eine Universal-Rechenvorrichtung in Form eines herkömmlichen Personalcomputers 100, der eine Verarbeitungseinheit 102, einen Systemspeicher 104 und einen Systembus 106, der verschiedene Systemkomponenten, einschließlich des Systemspeichers 104 mit der Verarbeitungseinheit 102 koppelt, umfasst. Der Systembus 106 kann ein beliebiger von mehreren Typen von Busstrukturen einschließlich eines Speicherbuses oder einer Speichersteuereinheit, eines Peripheriebuses und eines lokalen Buses, der eine beliebige Architektur von einer Reihe verschiedener Busarchitekturen verwendet, sein. Der Systemspeicher enthält einen Festwertspeicher (ROM) 110 und einen Direktzugriffsspeicher (RAM) 112. Ein Basis-Eingabe-/Ausgabesystem 114 (BIOS), das die allgemeinen Routinen enthält, welche das Übertragen von Informationen zwischen den Elementen innerhalb des Computers 100 wie beispielsweise während des Hochfahrens unterstützt, ist in dem ROM 110 gespeichert. Der Personalcomputer 100 enthält darüber hinaus ein Festplattenlaufwerk 116 zum Lesen von und Schreiben auf eine Magnetfestplatte, nicht dargestellt, ein Magnetplattenlaufwerk 118 zum Lesen von oder Schreiben auf eine entnehmbare Magnetplatte 120 und ein optisches Plattenlaufwerk 122 zum Lesen von oder Schreiben auf eine entnehmbare optische Platte 124, wie beispielsweise eine CD-ROM oder andere optische Medien. Das Festplattenlaufwerk 116, das Magnetplattenlaufwerk 118 und das optische Plattenlaufwerk 122 sind jeweils über eine Festplattenlaufwerkschnittstelle 126, eine Magnetplattenlaufwerkschnittstelle 128 und eine Schnittstelle eines optischen Plattenlaufwerkes 130 mit dem Systembus 106 verbunden. Die Laufwerke und ihre verbundenen computerlesbaren Medien stellen eine nicht-flüchtige Speicherung von durch Computer ausführbaren Befehlen, Datenstrukturen, Programmmodulen und anderen Daten für den Personalcomputer 100 bereit. Obgleich die hierin beschriebene exemplarische Umgebung eine Festplatte, ein entnehmbare Magnetplatte 120 und eine entnehmbare optische Platte 130 verwendet, sollte es den Personen mit der gewöhnlichen Erfahrung auf dem Gebiet der Technik offensichtlich sein, dass andere Typen von computerlesbaren Medien, die Daten, auf die durch einen Computer zugegriffen werden kann, speichern können, wie beispielsweise Magnetkassetten, Flash-Speicherkarten, DVDs (Digital Versatile Disks), Bernoulli-Kartuschen, Direktzugriffsspeicher (RAMs), Festwertspeicher (ROMS) und Ähnliches ebenfalls in der exemplarischen Betriebsumgebung verwendet werden können.
Es kann eine Anzahl von Programmmodulen auf der Festplatte, der Magnetfestplatte 120, der optischen Platte 124, dem Festwertspeicher ROM 110 oder dem Direktzugriffsspeicher RAM 112 gespeichert werden, und sie enthalten ein Betriebssystem 132, ein oder mehrere Anwendungsprogramme 134, weitere Programmmodule 136 sowie Programmdaten 138. Ein Benutzer kann Befehle und Informationen über Eingabegeräte wie beispielsweise eine Tastatur 140 und eine Zeigevorrichtung 142 in den Personalcompu ter 100 eingeben. Andere Eingabegeräte (nicht dargestellt) können ein Mikrophon, ein Joystick, ein Gamepad, eine Satellitenschüssel, einen Scanner oder Ähnliches umfassen. Diese und andere Eingabegeräte sind oftmals über eine serielle Anschlussschnittstelle 144, die an den Systembus 106 angeschlossen ist, mit der Verarbeitungseinheit 102 verbunden, wobei die Eingabegeräte auch durch andere Schnittstellen, wie beispielsweise einen Parallelanschluss, einen Gameanschluss oder einen Universal Serial Bus (USB) verbunden sein können. Ein Monitor 146 oder ein anderer Typ von Anzeigegerät ist ebenfalls über eine Schnittstelle, wie beispielsweise einen Videoadapter 148 mit dem Systembus 106 verbunden. Zusätzlich zu dem Monitor 146 umfassen Personalcomputer typischerweise andere Peripherieausgabegeräte (nicht dargestellt), wie beispielsweise Lautsprecher und Drucker.
Der Personalcomputer 100 kann in einer Netzwerkumgebung unter Verwendung von logischen Verbindungen zu einem oder mehreren dezentralen Computern, wie beispielsweise einem dezentralen Computer 150 betrieben werden. Der dezentrale Computer 150 kann ein Personalcomputer, ein Server, ein Router, ein Netzwerk-PC, ein Partnergerät oder ein anderer allgemein verwendeter Netzwerkknoten sein und enthält typischerweise eine Vielzahl von oder sämtliche der hinsichtlich des Personalcomputers 100 voranstehend beschriebenen Elemente, obgleich lediglich eine Speichervorrichtungen 152 in 1 dargestellt wurde. Die in 1 dargestellten logischen Verbindungen umfassen ein Local Area Network (LAN) 154 und ein Wide Area Network (WAN) 156. Solche Netzwerkumgebungen sind in Büros, unternehmensweiten Computernetzwerken, Intranets und dem Internet weit verbreitet.
Wenn der Personalcomputer 100 in einer LAN-Netzwerkumgebung verwendet wird, ist er über eine Netzwerkschnittstelle oder einen Adapter 158 an das lokale Netz LAN 154 angeschlossen. Wenn der Personalcomputer 100 in einer WAN-Netzwerkumgebung verwendet wird, umfasst er typischerweise ein Modem 160 oder eine andere Vorrichtung zum Herstellen von Verbindungen über das Wide Area Network (WAN) 156, wie beispielsweise dem Internet. Das Modem 160, das ein internes oder ein externes Modem sein kann, ist über die serielle Anschlussschnittstelle 144 an den Systembus 106 angeschlossen. In einer Netzwerkumgebung können die im Zusammenhang mit dem Personalcomputer 100 dargestellten Programmmodule oder Abschnitte davon in der dezentralen Speichervorrichtung gespeichert sein. Es wird offensichtlich sein, dass die darge stellten Netzwerkverbindungen exemplarischen Charakter besitzen und dass andere Vorrichtungen zum Herstellen einer Kommunikationsverbindung zwischen den Computern verwendet werden können.
Grundlegendes System
2 ist ein allgemeines Blockdiagramm, dass die Interaktion zwischen den wichtigsten Komponenten der vorliegenden Erfindung illustriert. Die vorliegende Erfindung umfasst einen Ressourcen-Verwalter 200, eine Vielzahl von Verbrauchern 212, 214, 216 und eine Vielzahl von Ressourcen 218, 220 und 222. Der Ressourcen-Verwalter 200 weist darüber hinaus einen Handle-Administrator 230 auf. Die Verbraucher 212, 214, 216 sind Softwaremodule. Bei den Ressourcen 218, 220, 22 handelt es sich um Computersoftware-Ressourcen, wie beispielsweise dynamische Link-Bibliothekendateien (DLL-Datei). Die Softwaremodule 212, 214, 216 fordern möglicherweise zu einem gewissen Zeitpunkt Zugriff (entweder alleiniger oder gemeinsam genutzter) auf eine oder sämtliche Ressourcen 216, 220, 222 an. So fordert beispielsweise ein Druckertreiber-Softwaremodul für gewöhnlich Zugriff auf eine Ressource einer dynamischen Link-Bibliothekendatei an.
Der Handle-Administrator 230 erzeugt und validiert Bezugsmarkierungen oder Handles, um dem Ressourcen-Verwalter 200 Einrichtungen zum Verwalten der Verbraucher und der Ressourcen bereitzustellen. Der Handle-Administrator 230 verwaltet unter Verwendung von Bezugs-Handles auf effiziente Weise den Zugriff auf die Ressourcen 218, 220, 222. Der Handle-Administrator 230 vermittelt mit den Bezugs-Handles, wenn ein Verbraucher Zugriff auf eine bestimmte Ressource anfordert. Das Vermitteln umfasst das Ausgeben eines Handles zu einer bestimmten Ressource an den Verbraucher, anstatt dem Verbraucher einen direkten Zeiger zu dieser bestimmten Ressource zu gestatten. Der Verbraucher kann das Handle nicht zum direkten Zugreifen auf die Ressource verwenden. Stattdessen präsentiert der Verbraucher das Handle dem Handle-Administrator 230, der zuerst verifiziert, dass das Handle gültig ist, der anschließend das Handle dereferenziert, um für diesen Verbraucher einen Zeiger zu der Ressource zu erhalten. Auf diese Weise wird durch Vermitteln gewährleistet, dass die bestimmte Ressource noch existiert, bevor dem Verbraucher Zugriff auf die bestimmte Ressource gewährt wird.
Im Allgemeinen führt der Handle-Administrator Zuweisung, Freigabe und Dereferenzierung von Handles, die zu den Ressourcen 218, 220, 222 zeigen, an die Verbraucher 212, 214, 216 durch. Bei dem Ressourcen-Verwalter 200 handelt es sich um ein Softwaremodul, das entweder die Ressourcen 218, 220, 222 unterhält oder wenigstens bei dem Zugriff durch die Verbraucher 212, 214, 216 auf die Ressourcen 218, 220, 222 als Vermittler agiert. Der Ressourcen-Verwalter 200 verwaltet die Handles, die er an die Verbraucher 212, 214, 216 ausgibt.
3 ist ein Ablaufdiagramm, das die allgemeinen Funktionsweise des Handle-Administrators der vorliegenden Erfindung darstellt. In Bezug auf 2 zusammen mit 3 implementiert der Handle-Administrator 230 die voranstehend beschriebenen Operationen mit einer Zuweisungs-Routine 310 zum Ausgeben von neuen Handles, einer Freigabe-Routine 312 zum Freigeben von Handles, die nicht länger gebraucht werden und einer Dereferenzierungs-Routine 314 zum Umwandeln eines Handles in einen Zeiger zu einer Ressource, einschließlich des Verifizierens, dass das Handle gültig ist. Die vorliegende Erfindung stellt jede dieser Operationen in Form einer Funktion dar, die durch einen Code in dem Ressourcen-Verwalter 200 aufgerufen werden kann. Dies bedeutet, dass diese Funktionen als eine Funktion assign_handle() (Handle zuweisen), eine Funktion release_handle() (Handle freigeben) und eine Funktion dereference_handle() (Handle dereferenzieren) definiert werden können.
Die Funktion assign_handle() nimmt einen Zeiger zu einer Ressource an und führt ein Handle zurück, das sich von diesem Zeitpunkt an auf den Zeiger beziehen wird. Die Funktion release_handle() nimmt ein Handle an und markiert es als ungültig, so dass es sich nicht länger auf einen Ressourcen-Zeiger beziehen sollte, und führt einen Statuscode, der anzeigt, ob das Handle, das weitergeleitet wurde, ein gültiges Handle ist, zurück. Die Funktion dereference_handle() nimmt ein Handle an, überprüft seine Gültigkeit, und wenn das Handle gültig ist, führt sie einen Zeiger zu der geeigneten Ressource zurück, wenn das Handle jedoch ungültig ist, führt sie einen Null-Zeiger zurück. Die Implementierung dieser Funktionen ist ziemlich komplex, dementsprechend präsentiert der folgende Abschnitt eine aufeinanderbauende Beschreibung des Handle-Administrators, wobei mit dem grundlegendsten System begonnen wird und im weiteren Verlauf progressiv wichtige Leistungsmerkmale solange hinzugefügt werden, bis die Darstellung des abschließenden Systems erreicht ist.
Theoretisch könnte ein Handle ein beliebiger Typ von Handle sein, da es dem Ressourcen-Verwalter 200 und den Verbrauchern 212, 214, 216 gegenüber nicht transparent ist. In der vorliegenden Erfindung ist das Handle eine vorzeichenlose ganze Zahl. In ihrer grundlegendsten Form umfasst die Datenstruktur der vorliegenden Erfindung eine Anordnung von Einträgen, von denen jeder die Felder enthält, die in Tabelle 1 beschrieben sind.

Typ Feld Beschreibung

Handle handle Handle-Wert

Ressource* resource Zeiger zu Ressource

Tabelle 1: Felder in jedem Eintrag des grundlegenden Systems
Die in Tabelle 1 dargestellte Nomenklatur „Ressource" wird als ein „Zeiger zu einer Ressource" definiert. Bei dieser Nomenklatur handelt es sich um Standard in der C-Programmiersprache und wird im gesamten Verlauf der Beschreibung verwendet.
Zu Beginn wird der handle_value (Handle-Wert) für jeden Eintrag auf den Wert eingestellt, der dem Index dieses Eintrages entspricht, wie dies in dem Beispiel, das in Tabelle 2 dargestellt ist, demonstriert wird. Jedes aktuell gültige Handle entspricht einem Eintrag in der Anordnung.

Index Handle Ressource

0 0 Null

1 1 Null

2 2 Null

3 3 Null

Tabelle 2: Anfangszustand des grundlegenden Systems der Größe 4
Wenn der Handle-Administrator 230 über einen Aufruf der Funktion assign_handle() (Handle zuweisen), dazu angefordert wird, ein neues Handle auszugeben, wählt er einen ungenutzten Eintrag (Kästchen 320), stellt das Ressourcen-Feld des Eintrages auf den Ressourcen-Zeiger, der als ein Argument weitergeleitet wird (Kästchen 322) und führt den Handle-Wert in dem Handle-Feld des Eintrages zurück (Kästchen 324).
Wenn beispielsweise der Ressourcen-Verwalter 200 die Funktion assign_handle() (Handle zuweisen) mit einem Zeiger zu einer Ressource A aufruft, kann der Handle-Administrator den Eintrag an dem Index 0 auswählen, in wessen Fall der Handle-Administrator das Ressourcen-Feld so einstellen wird, dass zu der Ressource A gezeigt wird, und er führt einen Handle-Wert von 0 zu dem Ressourcen-Verwalter zurück. Die Anordnung von Einträgen wird dementsprechend so modifiziert, wie dies in Tabelle 3 dargestellt ist.

Index Handle Ressource

0 0 A

1 1 Null

2 2 Null

3 3 Null

Tabelle 3: Zustand des exemplarischen grundlegenden Systems nach einer Zuweisung
Wenn der Handle-Administrator 230 über einen Aufruf der Funktion dereference_Handle() (Handle dereferenzieren) nach dem Zeiger befragt wird, der einem gegebenen Handle entspricht, berechnet er einen Index, indem er den Wert des Handles Modulo der Größe der Anordnung (Kästchen 326) nimmt, den Wert in dem Handle-Feld des indexierten Eintrages mit dem Handle-Wert, der als ein Argument weitergeleitet wird (Kästchen 328), vergleicht und bestimmt, ob die Werte miteinander übereinstimmen. Wenn die zwei Werte miteinander übereinstimmen, wird von dem weitergeleiteten Handle bestimmt, dass es gültig ist (Kästchen 332), und der Zeiger in dem Ressourcen-Feld des indexierten Eintrages wird zurückgeführt (Kästchen 334). Wenn die zwei Werte nicht übereinstimmen, wird von dem weitergeleiteten Handle bestimmt, dass es ungültig ist (Kästchen 336), und es wird ein Null-Zeiger zurückgeführt (Kästchen 338).
Wenn beispielsweise der Ressourcen-Verwalter 200 die Funktion dereference_handle() (Handle dereferenzieren) mit einem Handle des Wertes 0 aufruft, berechnet der Handle-Administrator 230 einen Index, indem er diesen Wert Modulo 4 nimmt, wobei ein Index des Wertes 0 als Ergebnis vorliegt. Anschließend vergleicht er das Handle mit dem Wert in dem Handle-Feld des Eintrages des Wertes 0. Da die zwei Werte miteinander übereinstimmen, wird der Zeiger zu der Ressource A zurückgeführt.
Wenn der Handle-Administrator 230 über einen Aufruf der Funktion release_handle() (Handle freigeben) aufgefordert wird, ein Handle freizugeben, berechnet er einen Index, indem er den Wert des Handles Modulo der Größe der Anordnung nimmt (Kästchen 340), den Wert in dem Handle-Feld des indexierten Eintrages mit dem Handle-Wert, der als ein Argument weitergeleitet worden ist (Kästchen 342), vergleicht, und bestimmt, ob die Werte miteinander übereinstimmen (Kästchen 344). Dieser Vergleich ist nicht zwingend erforderlich, es handelt sich dabei jedoch um ein einfaches Überprüfen hinsichtlich eines fehlerhaften Argumentes. Wenn die zwei Werte nicht miteinander übereinstimmen, wird von dem weitergeleiteten Handle bestimmt, dass es ungültig ist (Kästchen 346), und es wird ein Fehler-Statuscode zurückgeführt (Kästchen 348). Anderenfalls erhöht er den Wert in dem Handle-Feld um die Größe der Anordnung (Kästchen 350), stellt das Ressourcen-Feld auf einen Null-Zeiger-Wert (Kästchen 352) ein und führt einen Erfolg-Statuscode zurück (Kästchen 354). Der Grund dafür, dass der Handle-Wert um die Größe der Anordnung erhöht wird, liegt darin, dass der neue Wert des Handle-Feldes auf diese Weise denselben Index ergeben wird, der entsteht, wenn die Größe der Anordnung im Modulo-Verfahren berechnet wird. Der Grund dafür, dass das Ressourcen-Feld auf den Wert Null eingestellt wird, liegt darin, dass der Handle-Administrator auf diese Weise bestimmen kann, dass der Eintrag ungenutzt ist und dass er dementsprechend erneut zugewiesen werden kann.
Wenn beispielsweise der Ressourcen-Verwalter die Funktion release_handle() (Handle freigeben) mit einem Handle des Wertes 0 aufruft, berechnet der Handle-Administrator einen Index, in dem er diesen Wert Modulo 4 nimmt, was einen Index von 0 ergibt. Anschließend vergleicht der Handle-Administrator das Handle mit dem Wert in dem Handle-Feld des Eintrages mit dem Wert 0. Da die beiden Werte miteinander übereinstimmen, wird der Wert in dem Handle-Feld auf den Wert 4 eingestellt, und der Wert in dem Ressourcen-Feld wird auf den Wert Null eingestellt. Die Anordnung von Einträgen wird dementsprechend so modifiziert, wie dies in Tabelle 4 angezeigt ist.

Index Handle Ressource

0 4 Null

1 1 Null

2 2 Null

3 3 Null

Tabelle 4: Zustand des exemplarischen grundlegenden Systems nach einer Freigabe
Wenn nun der Ressourcen-Verwalter die Funktion dereference_handle() (Handle dereferenzieren) mit einem Handle des Wertes 0 aufruft, berechnet der Handle-Administrator einen Wert, indem er diesen Wert Modulo 4 nimmt, was einen Index des Wertes 0 ergibt. Anschließend vergleicht er das Handle mit dem Wert in dem Handle-Feld des Eintrages des Wertes 0. Da die beiden Werte nicht miteinander übereinstimmen, wird ein Null-Zeiger zurückgeführt.
Als Nächstes sei angenommen, dass der Ressourcen-Verwalter erneut die Funktion assign_handle() (Handle zuweisen) aufruft, dieses Mal mit einem Zeiger zu der Ressource B. Darüber hinaus sei angenommen, dass der Handle-Administrator den Eintrag des Wertes 0 auswählt, dass er das Ressourcen-Feld so einstellt, dass zu der Ressource B gezeigt wird, und dass ein Handle-Wert 4 zu dem Ressourcen-Verwalter zurückgeführt wird. Die Anordnung der Einträge wird so modifiziert, wie dies in Tabelle 5 dargestellt ist.

Index Handle Ressource

0 4 B

1 1 Null

2 2 Null

3 3 Null

Tabelle 5: Zustand des exemplarischen grundlegenden Systems nach einer weiteren Zuweisung
Wenn der Ressourcen-Verwalter die Funktion dereference_handle() (Handle dereferenzieren) mit einem Handle des Wertes 4 aufruft, berechnet der Handle-Administrator einen Index, indem er diesen Wert Modulo 4 nimmt, was einen Index des Wertes 0 ergibt. Anschließend vergleicht der Handle-Administrator das Handle mit dem Wert in dem Handle-Feld des Eintrages des Wertes 0. Da die zwei Werte miteinander übereinstimmen, wird der Zeiger zu der Ressource B zurückgeführt. Wenn im Gegensatz dazu der Ressourcen-Verwalter die Funktion dereference_handle() (Handle dereferenzieren) mit einem Handle des Wertes 0 aufruft, berechnet der Handle-Administrator einen Index, indem er diese Wert Modulo 4 nimmt, was einen Index des Wertes 0 ergibt, wobei es sich um denselben Wert handelt, der für ein Handle des Wertes 4 berechnet wird. Wenn der Handle-Administrator den Wert jedoch mit dem Wert in dem Handle-Feld des Eintrag es des Wertes 0 vergleicht, stimmen die zwei Werte nicht miteinander überein, und dementsprechend wird ein Null-Zeiger zurückgeführt.
FUNKTIONSBEISPIEL
4 ist ein Blockdiagramm einer Architektur, die die wichtigsten Komponenten und die Sub-Komponenten eines Funktionsbeispiels der vorliegenden Erfindung illustriert. Nun, da das grundlegende System voranstehend beschrieben worden ist, präsentieren die folgenden Abschnitte untenstehend eine auf sich aufbauende Beschreibung eines Funktionsbeispiels des Handle-Administrators der vorliegenden Erfindung, wobei mit der Hilfsstruktur begonnen wird und im weiteren Verlauf progressiv wichtige Leistungsmerkmale so lange hinzugefügt werden, bis das abschließende Funktionsbeispiel beschrieben wird.
In Bezug auf 4 umfasst die Zuweisungs-Routine 310 des Handle-Administrators 230 eine Hilfs-Subroutine 402 zum Verwalten von genutzten und ungenutzten Einträgen, eine Vergrößerungs-Subroutine 404 zum effizienten Vergrößern der Handle-Datenbank, eine Handle-Wiederverwendung-Subroutine 406, eine Subroutine für fehlgeschlagene Speicher-Allozierung 412, und eine Subroutine zum Erklären von Ungültigkeit 414 zum automatischen Erklären alter Handles als ungültig.
Die Hilfs-Subroutine kann eine verbundene Liste 420, einen binären Baum 422 oder eine beliebige andere 424 Suchbaum-Subroutine umfassen, die für das Umsetzen der Erfindung geeignet ist. Die Vergrößerungs-Subroutine 404 weist eine Multi-Thread-Subroutine 426 auf. Die Subroutine zum Erklären von Ungültigkeit weist eine Subroutine 432 zum Verarbeiten von Einträgen zum Verarbeiten von hohen und niedrigen Einträgen auf.
Die Freigabe-Routine weist eine Verkleinerungs-Subroutine 434 und eine Hysterese-Subroutine 436 auf. Die Verkleinerungs-Subroutine 434 weist eine Multi-Thread-Subroutine 437 auf. Die Dereferenzierungs-Routine 312 weist eine Multi-Thread-Subroutine 438 auf.
Hilfsstruktur
Der folgende Abschnitt beschreibt die Hilfs-Subroutine 402 der vorliegenden Erfindung. Wie dies voranstehend beschrieben worden ist, durchsucht der Handle-Administrator 230 in Reaktion auf einen Aufruf der Funktion assign_handle() (Handle zuweisen) die Anordnung, um einen ungenutzten Eintrag zu finden. Wenn die Größe der Anordnung sehr klein ist, wie dies in dem oben beschriebenen Beispiel der Fall ist, ist dies kein sehr kostspieliger Vorgang. Die Kosten ändern sich jedoch linear mit der Größe der Anordnung, so können die Kosten ziemlich hoch sein, wenn die Größe der Anordnung groß ist. Eine einfache Optimierung wie beispielsweise das Unterhalten einer verbundenen Lise mit ungenutzten Einträgen kann diese Kosten auf eine Konstante reduzieren. Wenn ein neues Handle ausgegeben werden soll, wird ein Eintrag aus dieser Liste ausgewählt; und wenn ein Handle freigegeben wird, wird der verbundene Eintrag zu der Liste hinzugefügt. Dadurch wird das Hinzufügen eines neuen Feldes zu jedem Eintrag erforderlich, wie dies in Tabelle 6 dargestellt ist.

Typ Feld Beschreibung

Handle handle Handle-Wert

Ressource* Ressource Zeiger zur Ressource

Eintrag* nächster Eintrag Zeiger zu nächstem Eintrag in der Liste

Tabelle 6: Felder in jedem Eintrag des grundlegenden Systems mit Liste
Das neue Feld, next_record (nächster Eintrag) ist ein Zeiger zu einem Eintrag. Ein Zeiger zu dem Kopf der Liste wird unterhalten, und jeder ungenutzte Eintrag enthält einen Zeiger zu einem anderen Eintrag auf der Liste, mit Ausnahme des letzten Eintrages, der einen Null-Zeiger enthält. (Hierbei ist zu beachten, dass die Indexe von Anordnungen anstelle der Zeiger hätten verwendet werden können, um die Einträge der Listen zu verbinden.)
Es können weiter Optimierungen mit verbundenen Listen 420 und Suchbäumen 422, 424 je nach der gewünschten Effizienz des Systems vorgenommen werden. Wenn beispielsweise ein neues Handle ausgegeben werden soll, kann ein Optimierungsverfahren so implementiert werden, dass der geeignete Eintrag von den ungenutzten Einträgen in der Anordnung mit Überlegungen hinsichtlich der Effizienz ausgewählt wird. Wenn beispielsweise der Eintrag mit dem niedrigsten Index ausgewählt würde, würde der Handle-Wert in den unteren Einträgen tendenziell (wenn Handles zugewiesen und freigegeben werden) schneller ansteigen als jene in den oberen Einträgen. Da der Handle-Platz durch die Anzahl von Bits in dem Handle eingeschränkt ist, verbrauchen die unteren Einträge möglicherweise schließlich alle ihrer möglichen Handle-Werte reichlich bevor die oberen Einträge einen signifikanten Teil ihrer möglichen Werte verbrauchen, wodurch auf diese Weise der Handle-Platz nicht effizient genutzt wird. Dieses Problem kann beseitigt werden, indem Handles aus allen Einträgen mit einer relativen gleichmäßigen Frequenz ausgegeben werden, was durch Ausgeben des niedrigsten Handle-Wertes von sämtlichen ungenutzten Einträgen erzielt werden kann. Um diese Herangehensweise zu erleichtern, sollten die ungenutzten Einträge in einer Struktur gespeichert werden, die sich selbst an einer schnellen Auswahl des Eintrages mit dem niedrigsten Handle-Wert, wie beispielsweise der Suchbaum 422 orientiert. Das Suchen nach dem niedrigsten Handle-Wert in einem Satz (oder diesem entsprechend, Einfügen eines neuen Wertes in eine sortierte Position in einen Satz) ist jedoch ein Vorgang mit inherent logarithmischer Zeit anstelle eines Vorgangs mit konstanter Zeit. Es ist eher wünschenswert, dass die Funktion assign_handle() (Handle zuweisen) und die Funktion release_handle() (Handle freigeben) Vorgänge mit konstanter Zeit sind, ungeachtet der Anzahl von aktiven Handles.
Die bevorzugte Herangehensweise bewahrt den Vorgang mit konstanter Zeit der Zuweisungs- und Freigabefunktionen (und behindert nicht die in den darauffolgenden Abschnitten beschriebenen Verbesserungen), und gibt Handles aus den Einträgen mit einer ungefähr gleichmäßigen Frequenz aus. Die Herangehensweise ist so eingerichtet, dass sie eine verbundene Liste 420 wie voranstehend beschrieben, verwendet, wobei die Einträge für die Zuweisung aus dem Kopf der Liste entfernt werden und bei Freigabe an das Ende der Liste platziert werden. Dies erfordert das Unterhalten eines Zeigers zu dem Ende der Liste zusätzlich zu dem Zeiger zu dem Kopf der Liste. In Anbetracht eines relativ zufälligen Freigabemusters, wird diese Herangehensweise dazu tendieren, die Zuweisung der Handles relativ gleichmäßig unter den Einträgen aufzuteilen. Hierbei sollte beachtet werden, dass in Anbetracht einer beliebigen Hilfsstruktur es nicht länger erforderlich ist, dass der Handle-Administrator 230 den Wert des Ressourcen-Feldes auf Null einstellt, da das Vorhandensein des Eintrages in der Struktur anzeigt, dass es nicht genutzt wird.
Vergrößerung der Datenbank
Der folgende Abschnitt beschreibt die Vergrößerungs-Subroutine 404, die angewendet wird, wenn die Funktion assign_handle() (Handle zuweisen) aufgerufen wird, jedoch sämtliche Einträge in Verwendung sind. Ohne einen Mechanismus zum Erhöhen der Größe der Handle-Datenbank gibt es keine wünschenswerte Art und Weise, auf eine Anforderung einer Handle-Zuweisung zu reagieren, wenn die Datenbank voll ist: Entweder wird die Anforderung abgelehnt, oder es wird ein Handle-Eintrag von denjenigen entnommen, die bereits genutzt werden. Allgemein ausgedrückt, wird die Vergrößerungs-Subroutine 404 durchgeführt, um die Größe der Anordnung zu erhöhen, so dass mehr Einträge für die Zuweisung verfügbar sind. Es ist im Allgemeinen jedoch nicht möglich, zusätzlichen Speicherplatz unmittelbar auf einen gegebenen Bereich von verbrauchtem Speicherplatz folgend zu allozieren, da dieser folgende Speicherplatz möglicherweise zum Speichern von anderen Daten genutzt wird. Dementsprechend erfordert das Erhöhen der Größe der Anordnung das Allozieren eines separaten, großen Speicherbereiches, wobei die Informationen von der kleineren Anordnung in die größere Anordnung kopiert werden, und der Speicherplatz für die kleinere Anordnung dealloziert wird. Die neue erhöhte Größe wird auf eine Weise ausgewählt, dass das Abbilden von jeweils unterschiedlichen Handles zu jeweils unterschiedlichen Einträgen bewahrt wird.
So ist beispielsweise in Tabelle 7 eine volle Anordnung der Größe 4 illustriert.

Index Handle Ressource

0 4 B

1 1 A

2 10 D

3 7 C

Tabelle 7: Zustand des exemplarischen grundlegenden Systems vor der Vergrößerung
Wenn die Anordnungsgröße auf 6 erhöht werden würde, würde in diesem Fall ein Versuch, das Handle 7 zu dereferenzieren, einen Index von 1 (= 7 mod 6) ergeben. Ein Versuch, das Handle 1 zu dereferenzieren, würde jedoch ebenfalls einen Index von 1 ergeben, was in einem Konflikt resultiert. Im Allgemeinen sollte die Vergrößerung so durchgeführt werden, dass, wenn zwei Handles denselben Index in der größeren Anordnung ergeben, diese auch denselben Index in der kleineren Anordnung ergeben sollten (obgleich das Umgekehrte weder erforderlich noch wünschenswert ist). Dies kann dadurch erzielt werden, dass die Anordnungsgröße durch eine integrale multiplikative Konstante erhöht wird. Durch das Auswählen der Konstante und der anfänglichen Größe als Zweierpotenz wird der Versuch in gewisser Weise vereinfacht, da dadurch einfache Operationen der Bitmanipulation möglich sind, die anstelle der eher involvierten mathematischen Operationen angewendet werden. Für den restlichen Verlauf der Beschreibung wird angenommen, dass die multiplikative Konstante 2 ist, so dass die Größe der Anordnung mit jeder Vergrößerung verdoppelt wird. Dementsprechend wird die Anordnungsgröße auf den Wert 8 erhöht, wie dies in Tabelle 8 dargestellt wird.

Index Handle Ressource Nächster Eintrag

0 8 Null 3

1 1 A Null

2 10 D Null

3 11 Null 6

4 4 R Null

5 5 Null 0

6 14 Null Null

7 7 C Null

Tabelle 8: Zustand des exemplarischen Systems nach der Vergrößerung
Hierbei ist zu beachten, dass keine Konflikte unter den zugewiesenen Handles vorzufinden sind. Die Handles 1 und 10, die vorher die jeweiligen Indexe von 1 und 2 ergeben haben (1 mod 4 = 1; 10 mod 4 = 2), ergeben immer noch diese jeweiligen Indexe (1 mod 8 = 1; 10 mod 8 = 2); die Handles 4 und 7, die vorher jeweils die Indexe von 0 und 3 ergeben haben (4 mod 4 = 0; 7 mod 4 = 3), ergeben nun die jeweiligen Indexe von 4 und 7 (4 mod 8 = 4; 7 mod 8 = 7). Nachdem der Speicherplatz für die größere Anordnung alloziert worden ist, werden die Einträge in Übereinstimmung mit den Indexen, die in Bezug auf die größere Anordnung berechnet worden sind, aus der kleineren Anordnung in die größere Anordnung kopiert. Die Ressourcen-Zeiger von sämtlichen anderen Einträgen in der größeren Anordnung werden auf Null-Werte eingestellt (obgleich, wie dies voranstehend erwähnt wurde, dies dann nicht zwingend erforderlich ist, wenn eine Hilfsstruktur vorhanden ist, die nachverfolgt, welche Einträge nicht genutzt werden). Die Werte für die Handle-Felder dieser anderen Einträge werden so berechnet, wie dies im Folgenden beschrieben wird.
Eingangs sollte beachtet werden, dass zwei Indexe in der größeren Anordnung vorhanden sind, die einem jeden Index in der kleineren Anordnung entsprechen. So entsprechen beispielsweise die Indexe 0 und 4 in dem obigen Beispiel der größeren Anordnung dem Index 0 in dem Beispiel der kleineren Anordnung, was bedeutet, dass jeder beliebige Handle-Wert, der einen Index von 0 oder 4 in der größeren Anordnung ergibt, einen Index von 0 in der kleineren Anordnung ergeben wird. Wenn dementsprechend die kleinere Anordnung zu der größeren Anordnung vergrößert wird, gehört der Eintrag auf dem Index 0 in der kleineren Anordnung auf entweder den Index 0 oder den Index 4 in der größeren Anordnung. Diese zwei Indexe sind als gegenseitige „Dualwerte" bekannt. Wenn ein Eintrag aus der kleineren Anordnung in die größere Anordnung kopiert wird, ergibt der Handle-Wert Modulo der neuen Anordnungsgröße den Index von einem der Dualwerte, in die der Eintrag kopiert wird. Der Wert für das Handle-Feld in dem anderen Dualwert wird auf den Wert eingestellt, der dem Handle-Wert des kopierten Eintrages plus der Größe der kleineren Anordnung entspricht.
So weist beispielsweise der Eintrag in dem Index 0 der kleineren Anordnung, die in Tabelle 7 dargestellt ist, einen Handle-Wert von 4 auf. Wenn dieser Wert Modulo der größeren Anordnungsgröße (8) genommen wird, ergibt dies den Wert 4, dementsprechend wird dieser Eintrag in den Eintrag mit dem Index 4 in der größeren Anordnung kopiert, wie dies in Tabelle 8 dargestellt ist. Der Dualwert dieses Eintrages ist der Eintrag 0, dementsprechend wird sein Ressourcen-Zeiger auf den Wert Null eingestellt, und sein Handle-Wert wird auf den Wert 8 (4 + 4) eingestellt.
Für ein zweites Beispiel hat der Eintrag in dem Index 1 der kleineren Anordnung, die in 7 dargestellt ist, einen Handle-Wert von 1. Wenn dieser Wert Modulo der größeren Anordnungsgröße (8) genommen wird, ergibt dies den Wert Index 1, dementsprechend wird dieser Eintrag in den Eintrag mit dem Index 1 in der größeren Anordnung kopiert, wie dies in Tabelle 8 dargestellt wird. Der Dualwert dieses Eintrages ist der Eintrag 5, dementsprechend wird sein Ressourcen-Zeiger auf den Wert Null eingestellt, und sein Handle-Wert wird auf den Wert 5 (1 + 4) eingestellt.
Wenn die ungenutzten Einträge in der Hilfsstruktur behalten werden, wie dies in der vorangehenden Abschnitt beschrieben wurde, werden die neuen ungenutzten Einträge in diese Struktur eingefügt.
Wenn, wie dies voranstehend beschrieben wurde, die Größe der Anordnung um eine multiplikative Konstante erhöht wird, wird die Anordnung geometrisch größer, woraus sich die äußerst wünschenswerte Eigenschaft ergibt, dass die durchschnittliche Zeit zum Ausgeben eines Handles asymptotisch durch eine Konstante gebunden ist. Genauer gesagt, sei zu berücksichtigen, dass in dem voranstehend beschriebenen Beispiel die Anordnungsgröße von 4 auf 8 in Reaktion auf eine einzelne Anforderung zum Ausgeben eines Handles angestiegen ist. Diese angeforderten 4 Einträge, die kopiert werden sollen und die 4 neuen Einträge, die initialisiert werden sollen. Die nächsten 3 Handle-Zuweisungen werden eine Vergrößerung der Anordnung nicht erfordern, dementsprechend beläuft sich der durchschnittliche Aufwand des Ausgebens eines jeden dieser 4 Handles auf eine Kopie und eine Initialisierung. Wenn in einem ähnlichen Fall keine Handles freigegeben werden, wird in diesem Fall durch die nächste Zuweisung die Anordnungsgröße von 8 auf 16 ansteigen, wodurch 8 Kopien und 8 Initialisierungen erforderlich werden. Die nächsten 7 Handle-Zuweisungen werden kein Vergrößern der Anordnung erfordern, dementsprechend beläuft sich der durchschnittliche Aufwand für das Ausgeben eines jeden dieser 8 Handles auf eine Kopie und eine Initialisierung. Wenn irgendwelche Handles während einer solchen Abfolge von Vorgängen freigegeben werden, wird in diesem Fall der durchschnittliche Aufwand pro Zuweisung geringer sein.
Dementsprechend wird die Anordnung geometrisch größer, und dementsprechend ist die durchschnittliche Zeit zum Ausgeben eines Handles asymptotisch durch eine Konstante gebunden.
Tabelle 8 illustriert darüber hinaus auch das nächste Eintrags-Feld der voranstehend beschriebenen Subroutine 402. Obgleich das Feld next_record (nächster Eintrag) in Tabelle 6 als ein Zeiger zu einem Eintrag definiert ist, ist es in Tabelle 8 im Sinne einer einfacheren Erklärung als der Index eines Eintrages dargestellt. Das Ziel der Hilfs-Subroutine 402 besteht darin, die ungenutzten Einträge in einer Liste zu unterhalten, die ungefähr nach Handle-Wert sortiert wird. In Tabelle 6 wird die Liste mit ungenutzten Einträgen als vollständig sortiert dargestellt, wobei es sich um ideales jedoch nicht um gewährleistetes Verhalten handelt. Der Kopf der Liste ist der Eintrag mit dem Index 5, wobei die Informationen durch die Subroutine 402 an einem Ort gespeichert werden, der von der Tabelle selbst separat vorhanden ist. Wie dies aus Tabelle 8 entnommen werden kann, weist der Eintrag mit dem Index 5 einen Handle-Wert auf, wobei es sich um den kleinsten ungenutzten Handle-Wert in der Datenbank handelt. Dieser Eintrag hat einen Wert next_record (Wert des nächsten Eintrages) von 0. wodurch angezeigt wird, dass der nächste Eintrag in der Liste von ungenutzten Eintrag ein Eintrag mit dem Index 0 ist, der einen Handle-Wert von 8 hat. Dieser Eintrag hat einen Wert next_record (Wert des nächsten Eintrages) von 3, wodurch angezeigt wird, dass der nächste Eintrag in der Liste von ungenutzten Einträgen der Eintrag mit dem Index 3 ist, der einen Handle-Wert von 11 aufweist. Dieser Eintrag hat einen Wert next_record (Wert des nächsten Eintrages) von 6, wodurch angezeigt wird, dass der nächste Eintrag in der Liste von ungenutzten Einträgen der Eintrag mit dem Index 6 ist, der einen Handle-Wert von 14 aufweist. Dieser Eintrag hat einen Wert next_record (Wert des nächsten Eintrages) von Null, wodurch angezeigt wird, dass es sich dabei um den letzten Eintrag in der Liste handelt. Demzufolge wird die Liste mit nicht zugewiesenen Handle-Werten als sich in der Reihenfolge von {5, 8, 11, 14} befindlich erachtet, was korrekt sortiert ist. Sämtliche Einträge mit zugewiesenen Handles haben Werte next_record (Werte des nächsten Eintrages) von Null.
Verkleinerung der Datenbank
Der folgende Abschnitt beschreibt die Verkleinerungs-Subroutine 434. Obgleich die Verkleinerung der Handle-Datenbank nicht erforderlich ist, kann sie vor allem dann wünschenswert sein, wenn der Speicherplatzbedarf des Handle-Administrators kritisch ist.
Die Verkleinerungs-Subroutine 434 setzt Systemspeicherplatz frei. Wenn mehr Handles erforderlich sind als Einträge verfügbar sind, in denen sie gespeichert werden können, sollte in diesem Fall die Datenbank mit der Vergrößerungs-Subroutine 404 vergrößert werden. Wenn jedoch Handles freigegeben werden, könnte eine Situation entstehen, in der weitaus weniger Handles erforderlich sind, als Einträge vorhanden sind. Obgleich dies nicht direkt Probleme hinsichtlich der Funktionen bereitet, kann dies indirekte Probleme hervorrufen, beispielsweise das Nutzen von mehr Systemressourcen (insbesondere von Speicherplatz) als erforderlich ist.
Als ein Beispiel sei ein Szenario betrachtet, in dem herkömmlicherweise ungefähr 10 aktive Handles zu einem gegebenen Zeitpunkt vorhanden sind, was zu einer Anordnungsgröße von 16 in Anbetracht der voranstehend beschriebenen binären Vergrößerung führt. Wenn, über einen kurzen Zeitraum hinweg, die Anzahl von aktiven Handles auf 1000 ansteigt, erhöht sich die Anordnungsgröße auf 1024. Wenn dieser kurze Burst vorüber ist, sinkt die Anzahl von aktiven Handles auf 10, wenn jedoch die Anordnungsgröße bei dem Wert 1024 verbleibt, werden 99 % des Speicherplatzes, der durch den Handle-Administrator verbraucht wird, verschwendet.
Die vorliegende Erfindung umfasst dementsprechend eine Verkleinerungs-Subroutine 434 zum Verkleinern der Handle-Datenbank. Obgleich ähnliche Effekte zu der Umkehrung der Vergrößerungs-Subroutine vorliegen, sind in der Verkleinerungs-Subroutine komplexe Hinzufügungen enthalten. Erstens ist es, obgleich es normalerweise möglich ist, die Datenbank zu vergrößern (angenommen, dass mehr Speicherplatz alloziert werden kann), in einigen Situationen nicht möglich, die Datenbank zu verkleinern, selbst wenn die Anzahl von aktiven Handles nicht größer als die Hälfte der Anordnungsgröße ist. Es sei die Anordnung von Handle-Einträgen betrachtet, die in Tabelle 9 illustriert ist.

Index Handle Ressource

0 16 Null

1 1 A

2 10 D

3 11 Null

4 12 Null

5 5 E

6 22 Null

7 7 C

Tabelle 9: Exemplarisches grundlegendes System in einem nicht verkleinerbaren Zustand
Obgleich die Anordnungsgröße 8 lediglich 4 aktive Handles enthält, würde die Verkleinerung der Anordnung auf eine Größe von 4 einen Konflikt verursachen. Genauer gesagt, würden Handle 1 und Handle 5 jeweils denselben Anordnungsindex für ihre Einträge ergeben (1 mod 4 = 5 mod 4 = 1). Mit anderen Worten bedeutet dies, dass sie gegenseitige Dualwerte sind, und da sie beide zugewiesen werden, würde zwischen ihnen ein Konflikt entstehen, wenn ihre Anordnungsgröße auf 4 reduziert werden würde. Zwei Einträge, die gegenseitige Dualwerte sind und die beide zugewiesen werden, werden im Folgenden als ein „zugewiesenes Paar" bezeichnet. Im Allgemeinen kann eine Handle-Anordnung nur dann verkleinert werden, wenn es keine zugewiesenen Paare enthält, so wie beispielsweise die Anordnung, die in Tabelle 8 illustriert ist.
Die Zählung der zugewiesenen Paare in der Datenbank kann mit Hilfe des folgenden Prozesses nachverfolgt werden. Wenn die Datenbank initialisiert wird, oder wenn sie vergrößert wird, wird die Zählung von zugewiesenen Paaren auf den Wert Null eingestellt. Wann immer ein Handle von einem Eintrag ausgegeben wird, dessen Dualwert bereits ein zugewiesenes Handle hält, wird die Zählung der zugewiesenen Paare um eine Einheit erhöht. Wann immer ein Handle von einem Eintrag, dessen Dualwert ein zugewiesenes Handles hält, freigegeben wird, wird die Zählung der zugewiesenen Paare um eine Einheit verringert. Die erneute Berechnung der Zählung von zugewiesenen Paaren nach einer Verkleinerung wird im folgenden Verlauf ausführlich beschrieben.
Zusätzlich dazu besteht eine Beschränkung hinsichtlich einer Mindest-Anordnungsgröße für die Verkleinerungs-Subroutine. Es ist eindeutig, dass die Anordnung nicht verkleinert werden kann, wenn ihre Größe bei Eins liegt, es ist jedoch wünschenswert, einen größeren Wert für die Mindest-Anordnungsgröße einzustellen. Und zwar erfordert das bevor zugte Verfahren der vorliegenden Erfindung eine Mindest-Anordnungsgröße von Zwei, und dementsprechend sollte die Anordnung wenigstens eine Größe von Vier haben, bevor die Verkleinerungs-Subroutine angewendet wird. Andere Einschränkungen der Verkleinerungs-Subroutine sind ebenfalls wünschenswert und werden ausführlich in einem folgenden Abschnitt beschrieben.
Hierbei sollte beachtet werden, dass die Verkleinerungs-Subroutine das Hinzufügen eines neuen Feldes zu einem jeden Eintrag erfordert, wie dies in Tabelle 10 dargestellt ist.

Typ Feld Beschreibung

Handle Handle Handle-Wert

Handle nächstes Handle nächster Handle-Wert

Ressource* Ressource Zeiger zu Ressource

Tabelle 10 : Felder in jedem Eintrag des verkleinerbaren Systems
Das neue Feld next_handle (nächstes Handle), hält den nächsten Handle-Wert, der von dem Eintrag ausgegeben werden wird. Wenn der Eintrag ungenutzt ist, dann entspricht dieser Wert dem Handle-Wert. Wenn der Eintrag genutzt wird, dann ist dieser Wert um einige Vielfache der Größe der Anordnung größer als der Handle-Wert. Eine Anordnung von Einträgen, die das Feld des nächsten Handles enthält, ist in Tabelle 11 dargestellt. Diese exemplarische Anordnung wird für die Diskussion der Verkleinerung verwendet.

Index Handle Nächstes Handle Ressource

0 0 0 Null

1 17 17 Null

2 10 18 D

3 11 11 Null

4 4 4 Null

5 5 13 E

6 30 30 Null

7 7 15 C

Tabelle 11: Zustand des exemplarischen grundlegenden Systems vor der Verkleinerung
Hierbei ist zu beachten, dass fünf Einträge, die keine zugewiesenen Handles enthalten, Handle-Felder und Felder nächster Handles aufweisen, die einander entsprechen, wohingegen die drei Einträge, die zugewiesene Handles enthalten, Werte des next_handle (Werte des nächsten Eintrages) aufweisen, die voneinander abweichen. Als Standard entspricht die Differenz zwischen einem Handle-Wert eines Eintrages und seinem Wert des next_handle (Wert des nächsten Eintrages) der aktuellen Größe der Anordnung.
Im Folgenden wird die Handle-Zuweisung und die Handle-Freigabe unter Einbeziehung dieses neuen Feldes beschrieben. Wenn beispielsweise der Eintrag 0 dafür ausgewählt wird, ein Handle auszugeben, würde in diesem Fall das ausgegebene Handle den Wert 8 aufweisen, und das Feld next_handle (nächstes Handle) würde um die Größe der Anordnung erhöht werden, was in einem Wert von 16 resultiert. Wenn darüber hinaus der Handle-Wert 8 freigegeben wird, wird in diesem Fall das Handle-Feld des Eintrages 0 mit dem Feld next_handle (nächstes Handle) des Eintrages 0 aktualisiert, wodurch sich der Wert 16 ergibt. Auf diese Weise dient die Verwendung des Feldes next_handle (nächstes Handle) dem Unterteilen des Erhöhens eines Handle-Wertes in zwei Schritte durch die Größe der Anordnung, die in einem vorangehenden Abschnitt beschrieben worden ist.
Der Bedarf an dem Feld next_handle (nächstes Handle) und seine Verwendung bei der Verkleinerung wird im Folgenden beschrieben. Zunächst wird allerdings Tabelle 12 dargestellt, um den Zustand der Anordnung zu illustrieren, nachdem die Verkleinerung abgeschlossen ist.

Index Handle Nächstes Handle Ressource

0 4 4 Null

1 5 13 E

2 10 26 D

3 7 11 C

Tabelle 12: Zustand des exemplarischen grundlegenden Systems nach der Verkleinerung
Die Verkleinerungs-Subroutine stellt alle drei Felder eines jeden Eintrages ein. Genauer gesagt, wird für das Ressourcen-Feld, wenn keiner der entsprechenden Dualwerte in Verwendung ist, in diesem Fall der Ressourcen-Zeiger auf den Wert Null eingestellt. Anderenfalls wird der Ressourcen-Zeiger auf den Ressourcen-Zeiger des Eintrages eingestellt, der sich in Verwendung befindet. So werden beispielsweise zum Einstellen des Ressourcen-Zeigers auf den Eintrag 0 in der kleineren Anordnung die zwei entsprechenden Dualwert-Einträge in der größeren Anordnung (0 und 4) überprüft. Da sich keiner von beiden in Verwendung befindet, ist der geeignete Wert ein Null-Zeiger. Im Sinne eines weiteren Beispiels werden, um den Ressourcen-Zeiger des Eintrages 1 in der kleineren Anordnung einzustellen, die zwei entsprechenden Dualwert-Einträge in der größeren Anordnung (1 und 5) überprüft. Da sich der Eintrag 5 in Verwendung befindet, wird der geeignete Wert aus dem Eintrag 5 in der größeren Anordnung kopiert, und zwar zu einem Zeiger zu der Ressource E.
Für das Feld next_handle (nächstes Handle) wird das größere der Felder next_handle von einem jeden entsprechenden Dualwert ausgewählt, und die Größe der kleineren Anordnung wird von diesem Wert subtrahiert. So werden beispielsweise, um das Feld next_handle (nächstes Handle) des Eintrages 0 in der kleineren Anordnung einzustellen, die zwei entsprechenden Dualwert-Einträge in der größeren Anordnung (0 und 4) überprüft. Da es sich bei den Feldern next_handle jeweils um 8 und 4 handelt, und da das größere von den beiden der Wert 8 ist, wird der Wert 8 ausgewählt und anschließend die Größe der kleineren Anordnung (4) von dem Wert 8 subtrahiert, um den Wert 4 zu erhalten.
Diese Vorgehensweise gewährleistet, dass der Wert des nächsten Handles, der von dem neuen Eintrag ausgegeben worden ist, nicht identisch mit einem Handle-Wert ist, der bereits ausgegeben und freigegeben worden ist. So weist beispielsweise der Eintrag an dem Index 1 der größeren Anordnung einen Handle-Wert von 17 auf, was impliziert, dass dieser Eintrag vorhergehend einen Handle-Wert von 9 (= 17 – 8) ausgegeben hat. Wenn dementsprechend die Anordnung verkleinert wird und das Feld next_handle (nächstes Handle) des neuen Eintrages auf den Wert 13 eingestellt wird, wird der Handle-Wert 9 nicht erneut ausgegeben werden. Wenn im Gegensatz dazu das Feld next_handle (nächstes Handle) nicht zu den Eintragen hinzugefügt worden ist, dnn wäre in diesem Fall, nachdem das Handle 5 freigegeben worden wäre, der Wert des nächsten Handle, der von diesem Eintrag ausgegeben worden wäre, als 9 berechnet (= 5 + 4) worden.
Hierbei sollte beachtet werden, dass die Handle-Werte, die niemals ausgegeben worden sind, möglicherweise entfernt worden sind. So weist beispielsweise der Eintrag an dem Index 6 der größeren Anordnung einen Handle-Wert von 30 auf, was impliziert, dass dieser Eintrag vorhergehend einen Handle-Wert von 22 (= 30 – 8) ausgegeben hat. Wenn also die Anordnung zusammengebrochen ist, wird das Feld next_handle (nächstes Handle) des Eintrages 2 der kleineren Anordnung auf den Wert 26 eingestellt, wodurch verhindert wird, dass der Handle-Wert 22 erneut ausgegeben wird. So verhindert dieser Wert des next_handle (Wert des nächsten Handle) jedoch auch, dass ein Handle-Wert 18 ausgegeben wird, obgleich dieser vorhergehend nicht ausgegeben worden ist. Das Verkleinern der Anordnung wird jedoch durchgeführt, um die Platzanforderung der Datenbank zu reduzieren, wodurch der Platz, der zum Speichern solcher Informationen verfügbar ist, ebenfalls reduziert wird. Experimente haben gezeigt, dass, selbst bei großen Schwankungen von Anordnungsgrößen, wenn die Handles zufällig freigegeben werden, in diesem Fall die Handle-Werte lediglich um 12 % bis 16 % schneller verbraucht werden, als sie verbraucht worden wären, wenn keine Verkleinerung stattgefunden hätte.
Das Handle-Feld eines jeden Eintrages wird mit der folgenden Vorgehensweise eingestellt. Wenn sich keiner der entsprechenden Dualwerte in Verwendung befindet, wird in diesem Fall der Handle-Wert entsprechend dem Feld next_handle (nächstes Handle) des Eintrages eingestellt. Anderenfalls wird der Handle-Wert auf das Handle-Feld des Eintrages, der sich in Verwendung befindet, eingestellt. So werden beispielsweise, um den Handle-Wert des Eintrages 0 in der kleineren Anordnung einzustellen, die zwei entsprechenden Dualwert-Einträge in der größeren Anordnung (0 und 4) überprüft. Da sich keiner von beiden in Verwendung befindet, wird der Handle-Wert auf den Wert des next_handle (Wert des nächsten Handle) eingestellt, der 4 ist. Als ein weiteres Beispiel werden, um den Handle-Wert des Eintrages 1 in der kleineren Anordnung einzustellen, die zwei entsprechenden Dualwert-Einträge in der größeren Anordnung (1 und 5) überprüft. Da sich der Eintrag 5 in Verwendung befindet, wird der Handle-Wert von dem Eintrag 5 in der größeren Anordnung, genauer gesagt ein Wert von 5 kopiert.
Das Abschließen des Verkleinerungsprozesses erfordert einen zusätzlichen Schritt, nämlich die erneute Berechnung der Zählung zugewiesener Paare. Der Prozess ist unkompliziert und wird wie folgt durchgeführt. Die Subroutine iteriert durch die Hälfte der Anordnung, und bei jedem Schritt, wenn der Eintrag und sein Dualwert jeweils beide zugewiesen sind, erhöht die Subroutine die Zählung der zugewiesenen Paare um eine Einheit. Hierbei ist zu beachten, dass es nicht erforderlich ist, die Zählung des zugewiesenen Paares vor dieser Vorgehensweise auf den Wert Null zu setzen. Dies rührt daher, dass die Zählung bereits den Wert Null betragen muss, damit eine Verkleinerung auftreten kann. Es ist geringfügig leichter, diese Vorgehensweise zu implementieren, wenn die Anordnung niemals kleiner als zwei Einträge groß ist, so dass jeder Eintrag in der Anordnung einen Dualwert aufweist.
Hierbei ist zu beachten, dass die in diesem Abschnitt beschriebenen Vorgehensweisen das Bestimmen dahingehend erfordern, ob ein beliebiger Eintrag zugewiesen ist. Wenn die einzige Anzeige eines Zuweisungsstatus eines Eintrages die Liste ist, auf der der Eintrag gehalten wird, kann die Bestimmung dieses Status mit relativ hohen Kosten verbunden sein. Dies rührt daher, dass die Vorgehensweise das Durchsuchen der gesamten Liste umfassen kann. Wie dies jedoch in den vorangehenden Abschnitten angedeutet worden ist, kann ein Eintrag auch als nicht zugewiesen betrachtet werden, indem sein Ressourcen-Zeiger auf den Wert Null eingestellt wird, wodurch eine schnelle, mit konstanter Zeit durchgeführte Bestimmung des Zuweisungsstatus des Eintrages ermöglicht wird. Ein mögliches Problem, das mit dieser Technik auftritt, besteht darin, dass ein Verbraucher verständlicherweise den Wunsch hat, ein Handle einem Null-Zeiger zuzuweisen, und wenn dies durchgeführt würde, würde der Handle-Administrator veranlasst werden, unkorrekterweise zu bestimmen, ob ein Eintrag nicht zugewiesen ist. Wie dies voranstehend erwähnt worden ist, entspricht, wenn ein Eintrag nicht zugewiesen ist, der Wert des next_handle (Wert des nächsten Handle) seinem Handle-Wert. Wenn im Gegensatz dazu ein Eintrag zugewiesen ist, entspricht in diesem Fall sein Wert des next_handle (Wert des nächsten Handle) nicht seinem Handle-Wert. Diese Bedingung wird durch die vorliegende Erfindung geprüft, um zu bestimmen, ob ein Eintrag zugewiesen ist.
Verbessern der Verkleinerungsmöglichkeiten
Wie dies in dem vorangehenden Abschnitt erwähnt worden ist, erfordert das Verkleinern einer Handle-Anordnung nicht lediglich, dass keine weiteren aktiven Handles vorhanden sind, die in die verkleinerte Anordnung hineinpassen, sondern es erfordert darüber hinaus, dass die Anordnung keine zugewiesenen Paare enthält. Wenn die Größe der Anordnung zunimmt, nimmt die Wahrscheinlichkeit dafür progressiv immer mehr ab. Die Wahrscheinlichkeit, dass eine zufällige Konfiguration von n Handles keine zugewiesenen Paare in einer Anordnung der Größe m ergibt, wird durch die folgende Gleichung ausgedrückt: P(m,n) = 1 – (U(m,n)/C(m,n)C ist der binominale Koeffizient von m und n, und U wird durch die folgende Wiederholung ausgedrückt: U(m,n) = C(m – 2, n – 2) + 2 U(m – 2, n – 1) + U(m – 2, n) U(2,0) = 0; U(2,1) = 0, U(2,2) = 1
Das Bewerten dieses Ausdruckes führt zu einem hohen Rechenaufwand, wenn die Werte von m und n steigen. Für einige kleine Werte zeigt jedoch Tabelle 13 die Wahrscheinlichkeit, dass keine zugewiesenen Paare in Anbetracht von verschiedenen Anordnungsgrößen und verschiedenen Anzahlen von zugewiesenen Handles vorhanden sind.

n = 2 n = 4 n = 8 n = 16

m = 2 0 – – –

m = 4 0,67 0 – –

m = 8 0,86 0,23 0 –

m = 16 0,93 0,62 0,02 0

m = 32 0,97 0,81 0,31 1,1e-4

Tabelle 13: Wahrscheinlichkeit der Verkleinerbarkeit für m Einträge und n zugewiesene Handles
Wie anhand von Tabelle 13 ersichtlich ist, besteht bei einer Anordnungsgröße von 32 lediglich eine Eins-zu-Tausend-Wahrscheinlichkeit dafür, dass ein zufälliger Satz von 16 nicht zugewiesenen Handles zufällig keine ausgewiesenen Paare aufweist. Dementsprechend ist es, obgleich es möglicherweise wünschenswert ist, eine solche Anordnung von 32 Einträgen bis 16 Einträgen zu verkleinern, nicht wahrscheinlich, dass dies erreicht werden kann. Wenn die Anzahl von zugewiesenen Handles auf den Wert 8 fällt, steigt in diesem Fall die Wahrscheinlichkeit, dass die Anordnung auf eine Größe von 16 verkleinert werden kann, auf 31 %, jedoch besteht dann eine bloße 2 %-ige Wahrscheinlichkeit dafür, dass sie auf einen Wert weiter als 8 verkleinert werden kann.
Da es relativ unwahrscheinlich ist, dass die Bedingung, die Verkleinerung ermöglicht, eigenständig auftritt, ist es wünschenswert, diese Bedingung aktiv aufrechtzuerhalten. Der Handle-Administrator hat keine Steuerung darüber, von welchen Einträgen Handles freigegeben wurden, und dies präsentiert einen Weg, mit dem die erwartete Anzahl von zugewiesene Paaren reduziert werden kann.
So sei beispielsweise die in Tabelle 9 illustrierte Handle-Anordnung betrachtet. Es ist lediglich ein Paar an zugewiesenen Einträgen vorhanden, und zwar jene mit den Indexen 1 und 5. Hierbei sei angenommen, dass vor der Freigabe von entweder dem einen oder dem anderen dieser Handles, der Ressourcen-Verwalter das Ausgaben eines neuen Handles anfordert. In Übereinstimmung mit der Hilfs-Subroutine sollte, wie dies voranstehend beschrieben wurde, der ausgewählte Eintrag derjenige mit dem geringsten Handle-Wert sein, welcher Eintrag 3 ist. Wenn jedoch der Eintrag 3 ausgewählt wird, und anschließend Handle 1 freigegeben wird, kann die Anordnung nicht verkleinert werden. Dies rührt daher, dass immer noch ein zugewiesenes Paar an Einträgen vorhanden ist, und zwar jene mit den Indexen 3 und 7. Auf diese Weise behinderte die Erzeugung des zugewiesenen Paares die Fähigkeit, die Datenbank zu verkleinern. Wenn alternativ dazu das Handle von entweder dem Eintrag mit dem Index 0 oder dem Eintrag mit dem Index 4 ausgegeben wurde, wäre in diesem Fall das zugewiesene Paar nicht erzeugt worden, und wenn dementsprechend das Handle 1 freigegeben werden würde, könnte die Anordnung verkleinert werden. Der Index 4 sollte bevorzugt gegenüber dem Index 0 ausgewählt werden, da er einen geringeren Handle-Wert aufweist.
Als Ergebnis sollte ein Handle von einem Eintrag ausgegeben werden, der, wenn möglich, kein zugewiesenes Paar erzeugt. Eine Art und Weise, diese Anforderung zu erfüllen, ist es, zwei Listen an ungenutzten Einträgen zu unterhalten, von denen eine jene Einträge enthält, von denen Handles ausgegeben werden können, ohne dass dabei ein zugewiesenes Paar erzeugt wird, und von denen eine jene Einträge enthält, von denen die Ausgabe von Handles ein zugewiesenes Paar erzeugt. Wenn die erste Liste leer ist, wird in diesem Fall lediglich ein Handle von der zweiten Liste ausgegeben.
Als ein Beispiel für die Handle-Anordnung, die in Tabelle 9 dargestellt ist, enthält die erste Liste lediglich den Eintrag 4, wohingegen die zweite Liste die Einträge 0, 3 und 6 enthält. Der Grund dafür, dass der Eintrag 0 auf der zweiten Liste und nicht in der ersten Liste enthalten ist, liegt darin, dass, wenn ein Handle von dem Eintrag 4 ausgegeben worden ist, das Ausgeben eines Handles von dem Eintrag ein zugewiesenes Paar erzeugen wird. Der Eintrag 4 und nicht der Eintrag 0 ist auf der ersten Liste vorhanden, da er einen geringeren Handle-Wert aufweist.

Wenn Handle 1 freigegeben wird, wird in diesem Fall der Eintrag 1 auf der zweiten Liste platziert, da der Dualwert von Eintrag 1 (Eintrag 5) ein Handle aufweist, das zugewiesen ist. Wenn Handle 10 freigegeben wird, wird der Handle-Wert des Eintrages 2 um die Größe der Anordnung erhöht, um den Wert 18 zu erreichen, wobei dieser Wert kleiner als der Handle-Wert (22) seines Dualwertes (Eintrag 6) ist, dementsprechend wird der Eintrag 2 auf der ersten Liste platziert. Wenn das Handle 7 freigegeben wird, wird der Handle-Wert des Eintrages 7 um die Größe der Anordnung erhöht, um den Wert 15 zu erreichen, wobei dieser Wert größer als der Handle-Wert (11) seines Dualwertes (Eintrag 3) ist, und dementsprechend sollte der Eintrag 7 auf die zweite Liste platziert werden, und der Eintrag 3 sollte von der zweiten Liste auf die erste Liste umplatziert werden. Da der Eintrag 3 an einem beliebigen Ort auf der zweiten Liste vorhanden sein könnte, kann er auf effektive Weise nur dann entfernt werden, wenn diese Liste zweifach verbunden ist. Auf diese Weise wird zu einem jeden Eintrag ein neues Feld hinzugefügt, wie dies in Tabelle 14 illustriert ist.

Typ	Feld	Beschreibung
Handle	Handle	Handle-Wert
Handle	nächstes Handle	nächster Handle-Wert
Ressource*	Ressource	Zeiger zu Ressource
Eintrag*	nächster Eintrag	Zeiger zu nächstem Eintrag auf der Liste
Eintrag*	vorhergehender Eintrag	Zeiger zu vorhergehendem Eintrag in der Liste

Tabelle 14: Felder in jedem Eintrag des verkleinerbaren Systems mit einer zweifach verbundenen Liste

Das neue Feld, prev_record (vorhergehender Eintrag) ist ein Zeiger zu einem Eintrag, und jeder ungenutzte Eintrag verwendet dieses Feld, um zu dem vorhergehenden Eintrag zu zeigen, auf welcher Liste er auch immer vorhanden ist.
Nachdem die Verkleinerung durchgeführt worden ist, weist jeder Eintrag einen anderen Dualwert als zuvor auf. So ist beispielsweise in Tabelle 12 der Dualwert des Eintrages 0 der Eintrag 2, wohingegen vor der Verkleinerung sein Dualwert der Eintrag 4 war. Auf ähnliche Weise ist der Dualwert des Eintrages 1 der Eintrag 3, wohingegen sein Dualwert vor der Verkleinerung der Eintrag 5 war. Auf diese Weise wird in Übereinstimmung mit der neuen Paarbildungsanordnung bestimmt, auf welche Liste jeder ungenutzte Eintrag gehört.
Unter erneuter Bezugnahme auf das Beispiel, in dem die in Tabelle 11 illustrierte Anordnung verkleinert wird, enthält die erste Liste vor der Verkleinerung den Eintrag 4. Darüber hinaus enthält die zweite Liste die Einträge 0, 1 und 6 in dieser Reihenfolge (wobei angenommen wird, dass sie auf korrekte Weise sortiert sind, was wahrscheinlich ist, jedoch nicht gewährleistet wird). Nach der Verkleinerung sind die einzigen ungenutzten Einträge jene, die einem Eintrag auf der ersten Liste vor der Verkleinerung entsprechen. In dem Beispiel ist der Eintrag 4 vor der Verkleinerung der einzige ungenutzte Eintrag auf der ersten Liste, und der entsprechende Eintrag nach der Verkleinerung ist der Eintrag 0, welcher, wie dies in der Tabelle 12 ersichtlich ist, der einzige ungenutzte Eintrag nach der Verkleinerung ist.
Aufgrund der Tatsache, dass es wünschenswert ist, die Reihenfolge der Listen beizubehalten, erzeugt diese Subroutine der vorliegenden Erfindung die neuen ersten und zweiten Listen in zwei Schritten. Erstens werden einhergehend mit dem Berechnen der Zählung von neu zugewiesenen Paaren jeder Eintrag und sein Dualwert mit einem Tag versehen, auf dem angezeigt wird, auf welche Liste sie gehören. Zweitens werden Iteratio nen durch die alte erste Liste durchgeführt, und jeder Eintrag wird auf die angezeigte Liste platziert.
Verkleinerungs-Hysterese
In dem vorangehenden Abschnitt wurde ein Mechanismus zum Erhöhen der Wahrscheinlichkeit, dass eine Anordnung verkleinert werden kann, präsentiert. Der folgende Abschnitt beschreibt eine Verkleinerungs-Hysterese-Subroutine 436, die das Verkleinern einer Anordnung bis über den Zeitpunkt hinaus verzögert, zu dem es möglich wird, die (die Verkleinerung) durchzuführen.
Voranstehend wurde erwähnt, dass, wenn die Anordnung geometrisch vergrößert wird, in diesem Fall die Durchschnittszeit zum Ausgeben eines Handles asymptotisch durch eine Konstante gebunden ist. Es wird jedoch nicht gewährleistet, dass dies auch dann der Fall ist, wenn die Anordnung verkleinert ebenso wie vergrößert wird. So sei beispielsweise ein Beispiel betrachtet, in dem die Anzahl von aktiven Handles 4 ist, und in dem die Anordnungsgröße ebenfalls 4 ist. Wenn ein weiteres Handle ausgegeben wird, wird die Anordnung auf die Größe von 8 vergrößert, was erfordert, dass 4 Einträge kopiert und 4 Einträge initialisiert werden müssen. Wenn dieses neue Handle anschließend freigegeben wird, kann die Anordnung zurück auf eine Größe von 4 verkleinert werden, was das Zusammenlegen von 4 Paaren an Einträgen erforderlich mach. Diese Abfolge kann auf unbegrenzte Zeit wiederholt werden, so dass jede Zuweisung auf diese Weise 4 Kopiervorgänge und 4 Initialisierungen erfordert, da die Anzahl von aktiven Handles zwischen 4 und 5 schwankt. Wenn alternativ dazu die Anordnungsgröße zwischen 8 und 9 schwanken sollte, würde in diesem Fall jede Zuweisung 8 Kopiervorgänge und 8 Initialisierungen erfordern. Wenn, im Allgemeinen, die Verkleinerungen so bald wie möglich durchgeführt werden, ist der durchschnittliche Rechenaufwand einer Zuweisung durch eine lineare Funktion der Anzahl von aktiven Handles und nicht durch eine Konstante gebunden.
Der durchschnittliche Rechenaufwand von Zuweisungen und Freigaben kann zu einem konstanten Wert durch Hinzufügen einer geeigneten Hysterese zu dem Verkleinerungsvorgang zurückgeführt werden. Es wird ein Rechenlast-Wert aufrechterhalten. Anfangs wird dieser Wert bei Null eingestellt, und jedes Mal, wenn ein Vergrößerungsvorgang durchgeführt wird, wird der Wert um die Anzahl von Aufteilungsvorgängen für Einträge erhöht, wobei eine Eintragsaufteilung ein Kopieren eines Eintrages und eine Initialisierung eines Eintrages umfasst. Auf ähnliche Weise wird jedes Mal, wenn ein Verkleinerungsvorgang durchgeführt wird, der Wert um die Anzahl von zusammengelegten Eintragspaaren erhöht. Jedes Mal, wenn ein Vorgang einer Zuweisung oder ein Vorgang einer Freigabe durchgeführt wird, wird die Rechenlast um eine Einheit verringert, mit einer unteren Grenze von Null für den Wert der Rechenlast. Die Anordnung wird nur dann verkleinert, wenn die Rechenlast dem Wert Null entspricht.
Es sei erneut das voranstehend beschriebene Beispiel betrachtet, in dem die Größe der Anordnung von dem Wert 4 auf den Wert 8 vergrößert wird, wenn ein fünftes Handle zugewiesen wird. Angenommen, dass die Rechenlast vorher den Wert Null betrug, wird durch die Vergrößerung veranlasst, die Rechenlast auf den Wert 4 einzustellen, und durch die einhergehende Zuweisung wird die Rechenlast sofort auf den Wert 3 reduziert. Wenn das Handle anschließend freigegeben wird, wird durch diesen Vorgang die Rechenlast auf den Wert 2 reduziert, und da dieser Wert größer als Null ist, wird die Anordnung nicht verkleinert. Wenn das nächste Handle zugewiesen wird, wodurch die Anzahl von aktiven Handles wieder auf 5 gebracht wird, muss die Anordnung nicht vergrößert werden, da sie bereits die Größe von 8 aufweist, und durch diese Zuweisung die Rechenlast auf den Wert 1 reduziert wird. Durch die nächste Freigabe wird die Rechenlast auf den Wert von Null reduziert, und dementsprechend wird anschließend die Anordnung verkleinert, wenn dies möglich ist; zu diesem Zeitpunkt hat sich der Rechenaufwand der vorherigen Vergrößerung über die vorhergehenden zwei Vergrößerungen und zwei Verkleinerungen bereits amortisiert und dementsprechend ist der durchschnittliche Rechenaufwand pro Vorgang eine Konstante. Auf ähnliche Weise wird durch die aktuelle Verkleinerung die Rechenlast auf den Wert 4 erhöht, so dass der Aufwand der Zusammenlegungen über zukünftige Zuweisungs- und Freigabevorgänge amortisiert werden wird.
Für große Anordnungsgrößen ist das Nachverfolgen der Rechenlast auf die soeben beschriebene Art und Weise sehr effektiv. Für kleine Anordnungsgrößen ist der Aufwand für Kopieren, Initialisieren und das Zusammenlegen von Einträgen jedoch relativ klein im Verhältnis zu dem Aufwand für das Allozieren und Deallozieren von Speicherplatz für Vergrößerungen und Verkleinerungen. Dementsprechend kann, selbst wenn der durch schnittliche Rechenaufwand pro Vorgang durch dieses System konstant gehalten wird, dieser konstante Wert aufgrund von Störgeräusch beim Allozieren/Deallozieren unakzeptabel hoch sein. Eine einfache Lösung für dieses Problem besteht darin, den Aufwand des Allozierens und des Deallozierens zu der Rechenlast, die durch die Vergrößerung und die Verkleinerung verursacht wurde, hinzuzufügen. Der Aufwand für das Allozieren und Deallozieren von Speicherplatz wurde empirisch für eine spezifische Implementierung des Funktionsbeispiels als 12 Mal der Aufwand für einen einzelnen Vorgang einer Eintragsmodifizierung bestimmt. Dementsprechend wird für diese bestimmte Implementierung jedes Mal, wenn ein Vorgang einer Vergrößerung oder einer Verkleinerung durchgeführt wird, die Rechenlast um einen Wert von 12 plus die Anzahl von Einträgen, die modifiziert werden, erhöht.
Fehler bei der Allozierung von Speicherplatz
Es ist möglich, dass ein Versuch, Speicherplatz zu allozieren, fehlschlägt und jedes beliebige System, das Speicherplatz alloziert (wie beispielsweise die vorliegende Erfindung) sollte vorbereitet sein, um mit Fehlern bei der Allozierung von Speicherplatz umzugehen. Die vorliegende Erfindung alloziert Speicherplatz zu drei Anlässen: bei der Initialisierung, bei jeder Vergrößerung und bei jeder Verkleinerung. Wenn Speicherplatz bei der Initialisierung nicht alloziert werden kann, schlägt die Erzeugung des Handle-Administrators fehl.
Wenn Speicherplatz für eine Vergrößerung nicht alloziert werden kann, besteht die offensichtliche Herangehensweise darin, den Versuch zum Zuweisen eines neuen Handles, für das in der Anordnung kein Platz ist, nicht durchzuführen. Es gibt jedoch eine alternative Herangehensweise, obgleich sie sich auf das Modifizieren der Semantik des Handle-Administrators stützt. Bis zu diesem Zeitpunkt hat das System auf eine Weise funktioniert, dass ein Handle dann gültig ist, sobald es zugewiesen ist, und es so lange gültig bleibt, bis es freigegeben wird. Da jedoch durch einen Aufruf der Dereferenzierungs-Routine ein Null-Zeiger zurückgeführt werden kann, sollte ein jeder Verbraucher darauf eingestellt sein, das ein Handle ungültig wird, lediglich aus der Begründung heraus, dass ein anderer Verbraucher das Handle freigegeben hat. Dementsprechend befähigt die neue Semantik den Handle-Administrator zum Erklären der Handles als ungül tig, wodurch ein Handle veranlasst wird, ungültig zu werden, gerade so, als ob es durch einen Verbraucher freigegeben werden würde.
Mit dieser Befugnis, kann der Handle-Administrator mit einer fehlgeschlagenen Allozierung von Speicherplatz umgehen, in dem er die Handles, die aktuell zugewiesen werden, als ungültig erklärt, und anschließend ein neues Handle von dem Eintrag zugewiesen wird. Diese Herangehensweise kann wünschenswert sein, da eine größere Wahrscheinlichkeit dahingehend besteht, dass das neue Handle eher genutzt wird als ein Handle, das vor einer langen Zeit zugewiesen wurde. Diese Überlegung suggeriert, dass das Handle, dass für ungültig erklärt wird, unter diesen Umständen das Handle sein sollte, das am weitesten zurückliegend zugewiesen wurde, was das Nachverfolgen der Reihenfolge, in der Handles zugewiesen werden, erfordert. Jeder Eintrag enthält ein Paar an Zeigern zu anderen Einträgen, und jeder zugewiesene Eintrag befindet sich auf einer von zwei Listen. Bis zu diesem Zeitpunkt waren die zugewiesenen Einträge noch auf gar keiner Liste, es ist jedoch ein Leichtes, diese auf eine solche Liste so zu platzieren, dass sie sich in der Reihenfolge ihrer Zuweisung befinden. Jedes Mal wenn ein Eintrag zugewiesen wird, wird er an das Ende der Liste platziert; wenn ein Eintrag freigegeben wird, wird er von der Liste entfernt, und wenn ein Eintrag aufgrund einer fehlgeschlagenen Allozierung von Speicherplatz als ungültig erklärt werden soll, wird er aus dem Kopf der Liste entfernt. Wenn Speicherplatz für eine Verkleinerung nicht alloziert werden kann, wird die Verkleinerung einfach nicht durchgeführt. Da das Verkleinern der Anordnung niemals erforderlich ist und aus anderen Gründen als die, die in dem vorhergehenden Abschnitt erklärt worden sind, verzögert werden kann, ist diese Reaktion auf eine fehlgeschlagene Allozierung akzeptabel.
Wiederverwenden von Handles
Wie dies in dem Abschnitt zum Überblick erwähnt wurde, handelt es sich bei einem Handle um eine vorzeichenlose ganze Zahl. Wenn die Größe der ganzen Zahl beispielsweise 32 Bits beträgt, sind lediglich ungefähr vier Milliarden einzigartige Handles vorhanden, die ausgegeben werden können. In einigen Szenarien ist dies möglicherweise ausreichend. In anderen Szenarien ist es möglicherweise nicht ausreichend. So kann es beispielsweise sein, dass Systeme mit langer Lebenszeit, die Handles sehr oft zuweisen und freigeben, den Handle-Platz aufbrauchen. Eine Alternative zu diesem Problem besteht darin, die Handles größer zu gestalten, es kann jedoch Fälle geben, in denen dies entweder nicht praktisch oder nicht ausreichend ist. Eine weitere Alternative ist es, eine Handle-Wiederverwendungs-Subroutine 406 zum Wiederverwenden (Recyclen) von Handles, die für eine lange Zeit ungültig gewesen sind, in Anbetracht der Theorie zu verwenden, dass Befugte ausreichend Möglichkeiten hatten, zu erkennen, dass die Handles ungültig geworden sind und dementsprechend keinen weiteren Versuch unternehmen werden, diese erneut zu dereferenzieren. Hierbei sollte beachtet werden, dass die Handle-Wiederverwendungs-Subroutine 406 eine optionale Funktion ist.
Die Handle-Wiederverwendungs-Subroutine 406 stellt ein effizientes Wiederverwenden von Handles bereit. Wenn der Handle-Wert in einem Eintrag auf einen Wert erhöht wird, der über den repräsentierbaren Bereich hinausgeht, „umschließt" [„wrap around"] der Wert einen Wert, der dem Wert Modulo der Anzahl von Werten in dem repräsentierbaren Bereich entspricht oder größer als dieser ist. Wenn beispielsweise der Handle-Wert (hexadezimal) FFFFFFFA ist, und dieser Wert um 8 erhöht wird (wobei angenommen wird, dass dies die Größe der Anordnung ist), wird das Ergebnis den Wert 2 betragen, wobei es sich um einen Handle-Wert handelt, der wahrschiendlich vor ungefähr vier Milliarden Handle-Ausgaben ausgegeben wurde. Es besteht jedoch die Gefahr dahingehend, dass, obgleich dieser Handle-Wert vor einer langen Zeit ausgegeben worden ist, er möglicherweise erst vor Kurzem freigegeben worden ist. Dementsprechend hatte der Verbraucher, der dieses Handle hält, möglicherweise noch nicht die Möglichkeit, zu bemerken, dass dieses Handle ungültig geworden ist. Eine Lösung für dieses potentielle Problem besteht darin, jegliche Handles, die älter werden als eine eingestellte Ablauffrist, für ungültig zu erklären, so dass die Verbraucher ausreichend Möglichkeit haben, zu bemerken, dass die Handles ungültig geworden sind.
Als solche erklärt die Handle-Wiederverwendungs-Subroutine 406 periodisch sehr alte Handles für ungültig. Die 5 bis 7 sind Diagramme, die visuell die Handle-Wiederverwendungs-Subroutine 406 der vorliegenden Erfindung illustrieren. Eine Handle-Datenbank 500 umfasst einen maximalen Handle-Bereich 510, eine Handle-Basis 520, einen Schwellenwert 525, der auf einen Basis-Wert 520 plus den maximalen Handle-Bereich eingestellt ist, und einen Handle-Bereichs-Schritt 528. Für die folgenden Beispiele wird angenommen, dass Handles ganze Zahlen von 16 Bits sind, dass der maximale Handle-Bereich 510 9000 (hexadezimal) ist und dass der Handle-Bereichs-Schritt 528 2000 (hexadezimal) ist. Zu Beginn wird der Handle-Basis-Wert 520 auf den Wert 0 eingestellt, und es wird ein Schwellenwert 525 auf den Basis-Wert 520 plus den maximalen Handle-Bereich 510, der in diesem Fall 0000 ist, eingestellt. Der schattierte Bereich 530 in den 5 bis 7 illustriert den gültigen Bereich der zugewiesenen Handles, der in 5 als 0 bis ungefähr 2400 dargestellt ist, was bedeutet, dass der größte Handle-Wert ungefähr 2400 mal ausgegeben wurde.
Wenn mehr Handles ausgegeben werden, wird der Bereich zugewiesener Handles als Handles 630 und 730 in den 6 und 7 größer. Und zwar führt in Bezug auf 5 zusammen mit den 6 und 7, wenn ein Handle-Wert, der größer ist als ein Schwellenwert 525, ausgegeben wird, das System ein Scannen durch sämtliche Einträge in der Anordnung durch und erklärt jegliches Handle innerhalb des Bereiches von der Handle-Basis 520 (in diesem Fall 0) zu der Handle-Basis 520 plus dem Handle-Bereichs-Schritt 528 (in diesem Fall 2000) für ungültig. Anschließend werden die Handle-Basis 520 und der Schwellenwert 525 durch den Handle-Bereichs-Schritt 528 zu einer neuen Handle-Basis 620 und dem Schwellenwert 625, wie dies in 6 dargestellt ist, vergrößert.
Mit der größten Wahrscheinlichkeit sind nur sehr wenige (vielleicht gar keine) Handles in diesem Bereich vorhanden, so dass der tatsächliche Effekt dieser Herangehensweise oftmals außerhalb des Handle-Administrators nicht gesehen wird. Wenn diese Prozedur abgeschlossen ist, könnten die Handles weiterhin so lange ausgegeben werden, bis der nächste Schwellenwert 625 erreicht ist, anschließend wird ein weiterer Schritt des Erklärens als ungültig durchgeführt. Schließlich führt das Erhöhen der Handle-Basis 720 dazu, dass der Schwellenwert 725 den maximalen Wert 550 umschließt, wie dies in 7 dargestellt ist.
Zusätzlich dazu wird eine Vergleichsmodifizierung verwendet, damit der Vergleich der Handle-Werte selbst dann korrekt durchgeführt werden kann, nachdem sich die Werte um die Handle-Werte herum angeordnet haben. An verschiedenen Stellen der voranstehend beschriebenen Verfahren werden zwei Handle-Werte miteinander verglichen, um zu bestimmen, welcher Wert größer ist. Wenn es den Handle-Werten gestattet wird, sich drumherum anzuordnen, wird in diesem Fall der Vergleich in Bezug auf den Handle-Basis-Wert anstelle eines absoluten Vergleiches angestellt. So seien beispielsweise die zwei Handles E320 und 1162 in dem in 7 dargestellten Szenario betrachtet. Ein Standardvergleich würde zu dem Schluss kommen, dass E320 der größere Wert ist. Wie jedoch in 7 dargestellt ist, ist dieser Wert tatsächlich kleiner als der andere in Bezug auf den Handle-Basis-Wert. Mit anderen Worten bedeutet dies, dass, wenn der Bereich so lange verschoben werden würde, bis sich die Handle-Basis bei Null befindet, dieses Handle kleiner sein würde.
Dieser Vergleich kann korrekt durchgeführt werden, indem zuerst der Handle-Basis-Wert von einem jeden Handle-Wert subtrahiert wird, bevor das Ergebnis verglichen wird: E320 – C000 = 2320 und 1162 – C000 = 5162, und 2320 ist kleiner als 5162. Hierbei ist zu beachten, dass sich die Subtraktionen implizit aus demselben Grund drumherum anordnen wie die Addition. Es handelt sich nämlich um ein Nebenprodukt aus Mathematik mit ganzen Zahlen auf einem digitalen Computer.
Multithreading
Der Handle-Administrator kann in einer Multi-Thread-Umgebung mit Multi-Thread-Subroutinen 426, 437 und 438 für jeweils die Zuweisung-, die Freigabe- und die Dereferenzierungs-Routinen 310, 314 und 312 verwendet werden. Aufgrund des Potentials für Konflikte in Multi-Thread-Umgebungen, ist es üblich, Sperren zu verwenden, um zu verhindern, dass verschiedene Threads miteinander interferieren, wenn sie eine gemeinsame Datenstruktur verwenden. Es gibt zwei Sperrmechanismen, die üblich sind, die Sperre mit Single Access (mit einfachem Zugriff) und die Sperre mit Single Writer – Multi Reader. Beim Sperren mit Single Access hat möglicherweise nur ein Thread Zugriff auf die Datenbank zu einem gegebenen Zeitpunkt, ungeachtet dessen, was der Thread mit der Datenbank durchführt. Beim Konzept des Single Writer – Multi Reader (SWMR) kann entweder ein Thread mit Lese-/Schreibprivilegien auf die Datenbank zugreifen, oder es kann eine beliebige Anzahl von Threads mit lediglich Leseprivilegien auf die Datenbank zugreifen. Der zweite Typ von Sperre weist eindeutig weniger Einschränkungen auf und ist demzufolge zu bevorzugen, wenn sie unterstützt werden kann. Die vorliegende Erfindung umfasst einen Mechanismus, der eine noch weniger restriktive Form von Sperre zulässt. In diesem Fall kann nur ein Thread mit Lese-/Schreibprivilegien auf die Datenbank zugreifen, jedoch kann eine beliebige Anzahl anderer Threads mit Leseprivilegien auf die Datenbank selbst während des Schreibzugriffs zugreifen.
Genauer gesagt, umfasst das System eine Sperre. Um die Routine assign_handle() (Handle zuweisen) aufzurufen, wird diese Sperre zuerst genommen. Um die Routine release_handle() (Handle freigeben) aufzurufen, wird diese Sperre zuerst genommen. Es muss jedoch keine Sperre genommen werden, um die Routine dereference_handle() (Handle dereferenzieren) aufzurufen. Dies wird durch zwei verschiedene Verfahren erzielt, wie dies in diesem Abschnitt beschrieben wird.
Zunächst seien die Situationen betrachtet, in denen Multithreading Probleme verursachen kann. Eine solche Situation tritt dann auf, wenn die Routine dereference_handle() (Handle Dereferenzieren) einen Versuch unternimmt, ein Handle, das sich in dem Prozess des Aufrufens der Funktion release_handle() (Handle freigeben) befindet, zu validieren, was in einem anderen Thread auftritt. Für ein korrektes Verhalten verhält sich das System so, als ob diese zwei Operationen nacheinander auftreten würden, obwohl sie sich in der Praxis möglicherweise überschneiden. Wenn das Dereferenzieren vor dem Freigeben auftritt, wird in diesem Fall ein gültiger Zeiger zurückgeführt, wenn das Dereferenzieren nach dem Freigeben auftritt, wird in diesem Fall ein Null-Zeiger zurückgeführt, was anzeigt, dass das Handle nicht gültig ist. Die Gefahr des Multithreading besteht darin, dass ein ungültiger Zeiger zurückgeführt wird. Dies kann vermieden werden, ohne Sperren zu verwenden, indem die Reihenfolge von Lese- und Schreibvorgängen sorgfältig bestimmt wird. Die Routine dereference_handle() (Handle dereferenzieren) führt Schritte in der folgenden Reihenfolge durch:

– Wert des Zeigers aus dem Eintrag lesen und lokal speichern
– Wert des Handles aus dem Eintrag lesen und unter Berücksichtigung des weitergegebenen Handle validieren.
– Wenn das Handle gültig ist, den lokal gespeicherten Zeiger zurückführen; ansonsten den Null-Zeiger zurückführen

Die alternative und die natürlichere Reihenfolge für die Routine besteht darin, dass zuerst das Handle validiert wird und anschließend der Zeiger aus dem Eintrag gelesen wird. Es ist jedoch möglich, dass zwischen diesen zwei Vorgängen der Eintrag als ungültig erklärt wird und anschließend zu einem neuen Zeiger erneut zugewiesen wird, und dass dementsprechend der falsche Zeiger durch die Dereferenzierungs-Routine zurückgeführt wird.
Die voranstehend beschriebene Situation betraf das Problem des sicheren Erklärens von Handles als ungültig. Ein weiteres potentielles Problem tritt mit dem Ändern der Größe der Anordnung auf. Wenn die Größe einer Anordnung geändert wird, wird eine neue Anordnung alloziert, und die Informationen von der alten Anordnung werden mit Modifizierung in die neue Anordnung kopiert. Während dieses Kopierens wird die alte Anordnung nicht modifiziert, dementsprechend können Handles immer noch unter Verwendung der alten Anordnung dereferenziert werden. Wenn das Kopieren abgeschlossen ist, können Handles unter Verwendung der einen oder der anderen Anordnung dereferenziert werden, dementsprechend kann zu diesem Zeitpunkt des System auf sichere Weise den Anordnungszeiger von der alten Anordnung zu der neuen Anordnung umschalten, nachdem es auf sichere Weise die alte Anordnung deallozieren kann. Es ist wichtig, dass der Zeiger zu der Anordnung und die Anordnungsgröße gleichzeitig umgeschalten werden können. Wenn die Dereferenzierungs-Routine einen inkonsistenten Satz dieser Werte beim Suchen nach einem Eintrag des Handles verwenden würde, würde sie den falschen Anordnungsindex aus dem Handle-Wert berechnen.
Das System stellt sicher, dass die zwei Werte konsistent betrachtet werden, indem zwei Hilfsvariablen, genannt „Verifizierer" verwendet werden. Herkömmlicherweise weisen diese zwei Verifizierer denselben Wert auf, jedoch werden sie auf unterschiedliche Werte eingestellt (durch die Vergrößerungs- und Verkleinerungsroutinen), wenn der Anordnungs-Zeiger und die Anordnungs-Größe möglicherweise inkonsistent sind. Die Verifizierer werden gelesen und durch die Dereferenzierungs-Routine überprüft, um die Konsistenz des Anordnungs-Zeigers und der Anordnungs-Variablen zu bestimmen. Zwischen dem Kopieren der Einträge zu der neuen Anordnung und dem Deallozieren der alten Anordnung werden mit der Vergrößerungsvorgehensweise und der Verkleinerungsvorgehensweise die folgenden Schritte der Reihe nach durchgeführt:

– Erhöhen des Verifizierers 0 um eine Einheit
– Aktualisieren des Anordnungs-Zeigers und der Anordnungsgröße
– Einstellen des Verifizierers 1 so, dass er dem Verifizierer 0 entspricht

Mit der Dereferenzierungs-Routine werden die folgenden Schritte der Reihe nach durchgeführt:

– Lesen und lokales Speichern des Wertes des Verifizierers 1
– Lesen des Anordnungs-Zeigers und der Anordnungsgröße
– Index des Eintrages berechnen
– Die Werte des Zeigers und des Handles aus dem indexierten Eintrag lesen
– Den Wert des Verifizierers 0 lesen und mit dem lokal gespeicherten Wert des Verifizierers 1 vergleichen
– Wenn die Verifizierer nicht übereinstimmen, werden in diesem Fall sämtliche voranstehenden Schritte wiederholt.

Die Wiederholungsklausel in der voranstehend beschriebenen Vorgehensweise besagt, dass die Dereferenzierungs-Routine möglicherweise für eine Weile durchlaufen wird, währenddessen sie abwartet, bis der andere Thread die Änderung der Anordnungsgröße abgeschlossen hat. Dies ist jedoch sehr unwahrscheinlich, da die Zeit während der die Verifizierer nicht miteinander übereinstimmen, extrem kurz ist.
Integrierte Komponenten
Im folgenden Abschnitt wird ein Beispiel der vorliegenden Erfindung mit den voranstehend beschriebenen Komponenten in einem integrierten System ausführlich beschrieben. Die 8 bis 15 illustrieren ein integriertes System, das die Zuweisungs-Routine, die Freigabe-Routine, die Dereferenzierungs-Routine, die Vergrößerungs-Subroutine, die Verkleinerungs-Subroutine, die Eintrags-Aktualisierungs-Subroutine, die Subroutine zum Erklären von Ungültigkeit und die Eintrags-Verarbeitungs-Subroutine, wie diese in dem voranstehenden Funktionsbeispiel beschrieben worden sind, umfasst. Hierbei sollte beachtet werden, dass sämtliche Additions- und Subtraktionsvorgänge implizit Modulo der Größe des Wertes des Handle-Platzes durchgeführt werden, wie dies in dem Abschnitt zum Wiederverwenden von Handles beschrieben wird.
8 ist ein Ablaufdiagramm, das die Zuweisungs-Routine der vorliegenden Erfindung darstellt. Die Routine wird gestartet (Kästchen 800), und anschließend wird bestimmt, ob die Population kleiner als die Anordnungsgröße ist (ist irgendein Eintrag in der Anordnung aktuell nicht zugewiesen?) (Kästchen 802). Wenn die Population nicht kleiner als die Anordnungsgröße ist, wird in diesem Fall ein Versuch zum Vergrößern der Anordnung mit der Vergrößerungs-Subroutine (siehe 11A und 11B) durchgeführt (Kästchen 804). Anschließend wird bestimmt, ob die Vergrößerung erfolgreich war (Kästchen 806). Wenn die Vergrößerung nicht erfolgreich war, hängt das Ausführen der Routine davon ab, wie das System konfiguriert worden ist. Wenn nämlich das System so konfiguriert worden ist, dass es dem Handle-Administrator nicht gestattet ist, ausgegebene Handles für ungültig zu erklären, wird die Routine in diesem Fall mit einem Fehlercode (Strichlinie zu Kästchen 810) zurückgeführt. Wenn der Handle-Administrator jedoch so konfiguriert ist, dass er die Befugnis besitzt, ausgegebene Handles für ungültig zu erklären, führt er in diesem Fall eine Subroutine für fehlgeschlagene Speicherplatzallozierung durch (Kästchen 808). Mit der Subroutine für fehlgeschlagene Speicherplatzallozierung wird das Handle, das am kürzesten zurückliegend zugewiesen worden ist, für ungültig erklärt, um einen Eintrag in der Handle-Datenbank für eine neue Handle-Zuweisung freizumachen. Die Subroutine führt das Erklären der Ungültigkeit durch Bewegen des am kürzesten zurückliegend zugewiesenen Eintrags von der zugewiesenen Liste zu der zweiten Liste, durch Einstellen des Handles des Eintrages auf eine Weise, dass es dem nächsten Handle entspricht, des Verringerns der Zählung zugewiesener Paare um eine Einheit und des Verringerns der Population um eine Einheit (Kästchen 808) durch.
Nachdem die Population um eine Einheit verringert worden ist, oder wenn die Datenbank-Vergrößerung erfolgreich ist (Kästchen 806), oder wenn die Population kleiner als die Anordnungsgröße ist (Kästchen 802), werden Schritte zum Verbessern der Verkleinerungsmöglichkeiten durchgeführt. Dies umfasst zuerst das Bestimmen, ob die erste Liste leer ist (Kästchen 812). Wenn die erste List nicht leer ist, wird in diesem Fall die erste Liste angezeigt (Kästchen 814). Wenn die erste Liste leer ist, wird in diesem Fall die zweite Liste angezeigt, und die Zählung der zugewiesenen Paare wird um eine Einheit erhöht (Kästchen 816). In beiden Fällen wird der Eintrag von dem Kopf des Satzes der angezeigten Liste zu dem Ende der zugewiesenen Liste bewegt, der Ressourcen-Zeiger des Eintrages wird eingestellt, das nächste Handle des Eintrages wird um die Anordnungsgröße erhöht, die Population wird um eine Einheit erhöht, und die Rechenlast wird für die Verkleinerungs-Hysterese beschränkend auf Null um eine Einheit verringert (Kästchen 818). Anschließend wird bestimmt, ob der Handle-Wert größer als ein Schwellenwert ist (Kästchen 820). Wenn der Handle-Wert größer als der Schwellenwert ist, wird in diesem Fall die Subroutine zum Erklären von alten Handles als ungültig durchgeführt (siehe 14) (Kästchen 822), und das Handle des Eintrages wird zu rückgeführt (Kästchern 824). Wenn jedoch der Handle-Wert nicht größer als der Schwellenwert ist, wird in diesem Fall das Handle des Eintrages zurückgeführt (Kästchen 824), ohne dass zuerst die Subroutine zum Erklären von alten Handles als ungültig durchgeführt wird.
9 ist ein Ablaufdiagramm, das die Freigabe-Routine der vorliegenden Erfindung darstellt. Die Funktion startet (Kästchen 900), und anschließend berechnet die Funktion den Index des Eintrages (Kästchen 902). Als Nächstes wird bestimmt, ob der Eintrag mit dem Handle übereinstimmt (Kästchen 904). Wenn der Eintrag nicht mit dem Handle übereinstimmt, wird ein Fehlercode zurückgeführt (Kästchen 906), wodurch angezeigt wird, dass das Handle ungültig ist. Wenn der Eintrag mit dem Handle übereinstimmt, wird bestimmt, ob der Dualwert des Eintrags zugewiesen worden ist (Kästchen 908).
Wenn der Dualwert des Eintrages nicht zugewiesen worden ist, wird bestimmt, ob das nächste Handle des Dualwerts kleiner als das nächste Handle des Eintrages ist (Kästchen 910). Wenn das nächste Handle des Dualwerts kleiner als das nächste Handle des Eintrages ist, wird die erste Liste angezeigt (Kästchen 912). Wenn das nächste Handle des Dualwerts kleiner als das nächste Handle des Eintrages ist, wird der Dualwert aus der zweiten Liste zu dem Ende der ersten Liste bewegt, und es wird die zweite Liste angezeigt (Kästchen 914). Wenn jedoch der Dualwert des Eintrages zugewiesen worden ist, (wie dies in Kästchen 908 bestimmt wird), wird die zweite Liste angezeigt, und die Zählung der zugewiesenen Paare wird um eine Einheit verringert (Kästchen 916).
Nachdem entweder die erste Liste angezeigt wird (Kästchen 912), die zweite Liste angezeigt wird (Kästchen 914) oder die Zählung der zugewiesenen Paare um eine Einheit verringert wird (Kästchen 916), wird der Eintrag von der zugewiesenen Liste zu dem Ende der angezeigten Liste bewegt, das Handle des Eintrages wird so eingestellt, dass es dem nächsten Handle entspricht, die Population wird um eine Einheit verringert, und die Rechenlast wird beschränkend auf Null um eine Einheit verringert. Als Nächstes wird bestimmt, ob die Anordnungsgröße größer als Zwei ist, ob die Zählung der zugewiesenen Paare dem Wert Null entspricht, und ob die Rechenlast dem Wert Null entspricht (Kästchen 920). Wenn sämtliche der voranstehenden Bedingungen erfüllt sind, wird die Verkleinerungs-Subroutine aufgerufen (siehe 12A und 12B) (Kästchen 922). Wenn die Verkleinerung erfolgreich war, wird ein gültiger Erfolgscode zurückgeführt (Kästchen 924). Wenn die Schritte von Kästchen 918 nicht zutreffen, kehrt in diesem Fall die Subroutine mit einem Erfolgscode zurück (Kästchen 924).
10 ist ein Ablaufplan, der die Dereferenzierungs-Routine der vorliegenden Erfindung darstellt. Die Funktion kann in einer Multi-Thread-Umgebung betrieben werden, sie wird gestartet (Kästchen 1000), und anschließend wird eine lokale Kopie des Verifizierers 1 angefertigt (Kästchen 1002). Anschließend wird der Index des Eintrages anhand einer Anordnungsgröße berechnet (Kästchen 1004). Eine lokale Kopie des Ressourcen-Zeigers des Eintrages wird anschließend angefertigt (Kästchen 1006). Als Nächstes wird eine lokale Kopie des Handle-Wertes des Eintrages angefertigt (Kästchen 1008). Anschließend wird bestimmt, ob der lokale Verifizierer mit dem Verifizierer 0 übereinstimmt (Kästchen 1010). Wenn der lokale Verifizierer mit dem Verifizierer 0 übereinstimmt, wird in diesem Fall bestimmt, ob die lokale Kopie des Handles des Eintrages mit dem Handle übereinstimmt, und anschließend wird die lokale Kopie des Zeigers des Eintrages zurückgeführt (Kästchen 1014). Wenn jedoch die lokale Kopie des Handles des Eintrages nicht mit dem Handle übereinstimmt, wird in diesem Fall ein Null-Zeiger zurückgeführt (Kästchen 1016).
Die 11A und 11B sind Ablaufdiagramme, die die Vergrößerungs-Subroutine der vorliegenden Erfindung illustrieren. Die Funktion startet (Kästchen 1100), und anschließend wird eine neue Anordnung mit dem Zweifachen der Größe alloziert (Kästchen 1102). Als Nächstes wird bestimmt, ob die Allozierung erfolgreich war (Kästchen 1104). Wenn die Allozierung nicht erfolgreich war, wird in diesem Fall ein Vergrößerungs-Fehlercode zurückgeführt (Kästchen 1106). Wenn die Allozierung erfolgreich war, wird in diesem Fall eine Variable eines alten Eintrages auf den ersten Eintrag in der alten Anordnung eingestellt (Kästchen 1108). Als Nächstes wird der Index des neuen Eintrages für das nächste Handle des alten Eintrages berechnet, das nächste Handle des neuen Eintrages wird auf das nächste Handle des alten Eintrages eingestellt, und das nächste Handle des Dualwerts des neuen Eintrages wird auf das nächste Handle des alten Eintrages plus der Größe der alten Anordnung eingestellt (Kästchen 1110). Der Index des neuen Eintrages für das Handle des alten Eintrages wird berechnet, und das Handle des neuen Eintrages wird auf das Handle des alten Eintrages eingestellt, der Ressourcen-Zeiger des neuen Eintrages wird auf den Ressourcen-Zeiger des alten Eintrages eingestellt, der alte Eintrag auf der zugewiesenen Liste wird durch einen neuen Eintrag ersetzt, und das Handle des Dualwerts des neuen Eintrages wird auf das nächste Handle des Dualwerts des neuen Eintrages eingestellt (Kästchen 1112). Als Nächstes wird die Variable des alten Eintrages auf den nächsten Eintrag in der alten Anordnung eingestellt (Kästchen. Anschließend wird bestimmt, ob die Einträge aufgebraucht sind (Kästchen 1116). Wenn die Einträge nicht aufgebraucht sind, werden die Schritte der Kästchen 1110 bis 1114 wiederholt. Diese Schritte werden solange durchlaufen, bis sämtliche Einträge aufgebraucht sind (Kästchen 1116).
Wenn die Einträge aufgebraucht sind, werden die nicht zugewiesenen Einträge auf der zweiten Liste in der Reihenfolge der Dualwerte auf der zugewiesenen Liste platziert, und die Rechenlast wird um den Aufwand bei der Speicherplatzallozierung plus der Größe der alten Anordnung erhöht (Kästchen 1118). Der Verifizierer 0 wird um eine Einheit erhöht, die Anordnungsgröße und der Anordnungs-Zeiger werden aktualisiert, und der Verifizierer 1 wird so eingestellt, dass er dem Verifizierer 0 entspricht (Kästchen 1120). Die alte Anordnung wird dealloziert, und die Zählung der zugewiesenen Paare wird auf den Wert Null eingestellt (Kästchen 1122). Anschließend wird ein Vergrößerungs-Erfolgscode zurückgeführt (Kästchen 1124).
Die 12A und 12B sind Ablaufdiagramme, die die Verkleinerungs-Subroutine der Zuweisungs-Routine und der Freigabe-Routine vorliegenden Erfindung illustrieren. Die Funktion startet (Kästchen 1200), und anschließend wird eine neue Anordnung der Hälfte der Größe der vorhergehenden Anordnung alloziert, und es wird eine Tag-Anordnung derselben Größe alloziert (Kästchen 1202) Anschließend wird bestimmt, ob die Allozierungen erfolgreich waren (Kästchen 1204). Wenn eine von beiden Allozierungen nicht erfolgreich war, wird die Verkleinerungs-Subroutine beendet, und es wird keine Verkleinerung durchgeführt (Kästchen 1206). Wenn die Allozierungen erfolgreich waren, wird eine niedrige Variable des Eintrages 1 auf den Eintrag in der alten Anordnung 1/4 oberhalb der ersten Anordnung eingestellt, eine hohe Variable des Eintrages 0 wird auf den Eintrag in der alten Anordnung 1/2 oberhalb von dem ersten Eintrag eingestellt, eine hohe Variable des Eintrages 1 wird auf den Eintrag in der alten Anordnung 3/4 oberhalb des ersten Eintrages eingestellt, eine Variable des neuen Eintrages 0 wird auf den ersten Eintrag in der neuen Anordnung eingestellt, und eine Variable des neuen Eintrages 1 wird auf den Eintrag in der neuen Anordnung 1/2 oberhalb des ersten Eintrages eingestellt (Kästchen 1208). Das Handle, das nächste Handle und der Ressourcen-Zeiger werden anschließend für den neuen Eintrag 0 eingestellt, und der geeignete Eintrag auf der Liste wird durch den neuen Eintrag 0 (Kästchen 1210), ersetzt, wie dies ausführlich in 13 dargestellt ist. Als Nächstes werden das Handle, das nächste Handle und der Ressourcen-Zeiger für einen neuen Eintrag 1 eingestellt, und der geeignete Eintrag auf der Liste wird durch den neuen Eintrag 1 ersetzt (Kästchen 1212), wie dies ausführlich in 13 dargestellt ist. Anschließend wird bestimmt, ob beide neuen Einträge nicht zugewiesen sind (Kästchen 1214). Wenn beide neuen Einträge nicht zugewiesen sind, wird der Eintrag mit dem kleineren Handle-Wert mit einem Tag für die erste Liste gekennzeichnet, und der Eintrag mit dem größeren Handle-Wert wird mit einem Tag für die zweite Liste gekennzeichnet (Kästchen 1216). Wenn wenigstens ein neuer Eintrag zugewiesen ist, werden in diesem Fall beide Einträge mit einem Tag für die zweite Liste versehen (Kästchen 1218), obgleich lediglich der nicht zugewiesene Eintrag mit den darauffolgenden Schritte der Routine tatsächlich auf die zweite Liste platziert wird. Anschließend wird bestimmt, ob beide neuen Einträge zugewiesen sind (Kästchen 1220). Wenn beide neuen Einträge zugewiesen sind, wird in diesem Fall die Zählung der zugewiesenen Paare um eine Einheit erhöht (Kästchen 1222). Wenn entweder beide neuen Einträge nicht zugewiesen sind (Kästchen 1220), oder nachdem der Eintrag mit dem größeren Handle-Wert mit einem Tag für die zweite Liste versehen wurde (Kästchen 1216), oder nachdem die Zählung der zugewiesenen Paare um eine Einheit erhöht ist (Kästchen 1222), wird jeder Eintrags-Zeiger auf den nächsten Eintrag in der Anordnung eingestellt (Kästchen 1224). Als Nächstes wird bestimmt, ob alle Einträge aufgebraucht worden sind (Kästchen 1226). Wenn die Einträge nicht aufgebraucht worden sind, durchläuft die Routine die Schritte in den Kästchen 1210 bis 1224. Wenn jedoch die Einträge aufgebraucht sind, wird jeder nicht zugewiesene Eintrag auf die erste Liste platziert, für die er mit einem Tag versehen worden ist, und zwar in derselben Reihenfolge wie die aktuelle nicht zugewiesene Liste. Die Rechenlast wird um den Aufwand bei der Speicherplatzallozierung plus der Größe der alten Anordnung erhöht (Kästchen 1228). Als Nächstes wird der Verifizierer 0 um eine Einheit erhöht, die Anordnungsgröße und der Anordnungszeiger werden aktualisiert, und der Verifizierer 1 wird so eingestellt, dass er dem Verifizierer 0 entspricht (Kästchen 1230). Die alte Anordnung und die Tag-Anordnung werden anschließend dealloziert, und die Zählung der zugewiesenen Paare wird auf den Wert Null eingestellt (Kästchen 1232). Anschließend kehrt die Subroutine zurück (Kästchen 1234).
13 ist ein Ablaufplan, der die Eintrags-Aktualisierungs-Subroutine der Vergrößerungs-Subroutine, die in den 12A und 12B dargestellt ist, illustriert. Die Funktion startet (Kästchen 1300), und anschließend wird das nächste Handle des neuen Eintrages auf das größere der nächsten Handles aus den hohen und niedrigen Einträgen minus der neuen Anordnungsgröße eingestellt (Kästchen 1302). Als Nächstes wird bestimmt, ob der hohe oder der niedrige Eintrag zugewiesen worden ist (Kästchen 1304). Wenn der hohe oder der niedrige Eintrag zugewiesen worden ist, werden in diesem Fall das Handle und der Ressourcen-Zeiger des zugewiesenen Eintrages in den neuen Eintrag kopiert, und der zugewiesene Eintrag auf der zugewiesenen Liste wird durch den neuen Eintrag ersetzt (Kästchen 1306). Wenn jedoch der hohe oder der niedrige Eintrag nicht zugewiesen worden ist, wird das Handle des neuen Eintrages so eingestellt, dass es dem nächsten Handle des neuen Eintrages entspricht, und der alte Eintrag mit dem kleineren Handle-Wert auf der ersten Liste wird durch den neuen Eintrag ersetzt (Kästchen 1308). Nachdem entweder der zugewiesene Eintrag auf der zugewiesenen Liste durch den neuen Eintrag (Kästchen 1306) ersetzt ist, oder der alte Eintrag mit dem kleineren Handle-Wert auf der ersten Liste durch den neuen Eintrag ersetzt ist (Kästchen 1308), kehrt die Subroutine zurück (Kästchen 1310).
14 ist ein Ablaufdiagramm, das die Subroutine zum Erklären von alten Handles als ungültig der Zuweisungs-Subroutine der vorliegenden Erfindung illustriert. Die Funktion startet (Kästchen 1400), und anschließend wird eine Variable eines niedrigen Eintrages auf den ersten Eintrag in der Anordnung eingestellt, und eine Variable eines hohen Eintrages wird auf den Eintrag in der Anordnung 1/2 oberhalb des ersten Eintrages eingestellt (Kästchen 1402). Als Nächstes wird bestimmt, ob wenigstens ein Handle in dem Ungültigkeitserklärungs-Bereich vorhanden ist (Kästchen 1404). Der Ungültigkeitserklärungs-Bereich beginnt an der Handle-Basis, und die Größe des Ungültigkeitserklärungs-Bereiches entspricht dem Handle-Bereichs-Schritt. Wenn wenigstens ein Handle in dem Ungültigkeitserklärungs-Bereich vorhanden ist, wird in diesem Fall bestimmt, ob beide Einträge zugewiesen sind. Wenn beide Einträge zugewiesen sind, wird in diesem Fall die Zählung der zugewiesenen Paare um eine Einheit erhöht (Kästchen 1408). Wenn beide Einträge nicht zugewiesen sind, oder nachdem die Zählung der zugewiesenen Paare um eine Einheit erhöht wird (Kästchen 1408), werden der niedrige Eintrag (Kästchen 1410) und der hohe Eintrag (Kästchen 1412) jeweils in Übereinstimmung mit den Schritten, die in 15 dargestellt sind, verarbeitet. Als Nächstes wird bestimmt, ob entweder der eine oder der andere Eintrag zugewiesen ist (Kästchen 1414). Wenn entweder der eine oder der andere Eintrag zugewiesen worden ist (Kästchen 1414), wird der andere Eintrag auf die zweite Liste platziert (Kästchen 1416). Wenn der eine oder der andere Eintrag nicht zugewiesen ist, wird der Eintrag mit dem kleinerer Wert auf die erste Liste platziert, und der Eintrag mit dem kleineren Handle-Wert auf die erste Liste platziert, und der Eintrag mit dem größeren Wert wird auf die zweite Liste platziert (Kästchen 1416). Nachdem entweder der eine oder der andere Eintrag auf die zweite Liste platziert wurde (Kästchen 1416), wird der Eintrag mit dem größeren Handle auf die zweite Liste platziert (Kästchen 1418), oder wenn sich wenigstens ein Handle nicht in dem Ungültigkeits-Erklärungsbereich befindet (Kästchen 1404), wird jeder Zeiger auf den nächsten Eintrag in der Anordnung eingestellt (Kästchen 1420). Als Nächstes wird bestimmt, ob sämtliche Einträge aufgebraucht worden sind (Kästchen 1422). Wenn die Einträge nicht aufgebraucht worden sind, wird die Verarbeitung für die voranstehend beschrieben Routine erneut durchgeführt (Kästchen 1404 bis 1420). Wenn die Einträge aufgebraucht worden sind, werden die Handle-Datenbank und der Handle-Schwellenwert um den Handle-Bereich vergrößert (Kästchen 1414), und anschließend kehrt die Subroutine zurück (Kästchen 1426).
15 ist ein Ablaufdiagramm, das die Eintrags-Verarbeitungs-Subroutine der Subroutine zum Erklären von alten Handles als ungültig, die in 14 dargestellt ist, illustriert. Die Funktion startet (Kästchen 1500), und anschließend wird bestimmt, ob der Eintrag nicht zugewiesen ist oder sich in dem Ungültigkeitserklärungs-Bereich befindet (Kästchen 1502). Wenn der Eintrag nicht zugewiesen ist oder sich in dem Ungültigkeitserklärungs-Bereich befindet, wird der Eintrag aus der Liste entfernt (Kästchen 1504). Wenn der Eintrag zugewiesen ist, oder wenn er sich nicht in dem Ungültigkeitserklärungs-Bereich befindet (Kästchen 1502), oder nachdem der Eintrag aus der Liste entfernt wird (Kästchen 1504), wird bestimmt, ob sich das Eintrags-Handle in dem Ungültigkeitserklärungs-Bereich befindet (Kästchen 1506). Wenn sich der Eintrag nicht in dem Ungültigkeitserklärungs-Bereich befindet, wird die Routine beendet (Kästchen 1508). Wenn sich der Eintrag in dem Ungültigkeitserklärungs-Bereich befindet, wird bestimmt, ob der Eintrag zugewiesen worden ist (Kästchen 1510). Wenn der Eintrag zugewiesen worden ist, wird die Population um eine Einheit verringert (Kästchen 1512). Wenn der Eintrag nicht zugewiesen wurde (Kästchen 1510), oder wenn die Population um eine Einheit verringert wird, wird der nächste Handle-Wert des Eintrages auf den Basiswert plus den Handle-Bereichs-Schritt plus den Index des Handle-Bereichs-Schritt plus den Index des Eintrages vergrößert, es sei denn, dieser Wert ist bereits größer, und der Handle-Wert wird so eingestellt, dass er dem nächsten Handle-Wert entspricht (Kästchen 1514). Anschließend kehrt die Subroutine zurück (Kästchen 1516).
Die voranstehend beschriebene Erfindung wurde zum Zwecke der Illustration und der Beschreibung präsentiert. Sie erhebt keinen Anspruch auf Vollständigkeit noch beabsichtigt sie, die Erfindung auf die exakte hierin offenbarte Form zu beschränken. In Anbetracht der voranstehenden Lehre sind viele Modifizierungen und Abänderungen möglich. Es ist beabsichtigt, dass der Umfang der Erfindung nicht durch die ausführliche Beschreibung sondern durch die hieran angehängten Ansprüche beschränkt wird.

Claims

Computerimplementiertes Verfahren, das in einem System verwendet wird, das Anfordernde (212–216) aufweist, die Zugriff auf eine Vielzahl von Ressourcen (218–222) anfordern, wobei das Verfahren dazu dient, Datenzugriff auf die Ressourcen unter Verwendung von Handles zu verwalten, und das Verfahren umfasst: Allozieren eines Bereiches in einem computerlesbaren Speicher für eine Datenbank, wobei die Datenbank eine Anordnung von Einträgen umfasst und jeder Eintrag ein Handle-Feld zum Speichern eines einzigartigen Handle-Wertes sowie ein Ressourcen-Feld zum Speichern entweder eines Ressourcen-Zeigers zu einer bestimmten Ressource oder eines Null-Zeigers hat; Zuweisen eines ungenutzten Handle-Felds in der Datenbank durch einen Zugriffs-Vermittler (200) bei der Annahme eines Ressourcen-Zeigers zu einer bestimmten Ressource von einem Anfordernden, der Zugriff auf die bestimmte Ressource anfordert, zu dem angenommenen Ressourcen-Zeiger zu der bestimmten Ressource, Speichern des angenommenen Ressourcen-Zeigers in dem Eintrag des ungenutzten Handles durch den Zugriffs-Vermittler (200) und Ausgeben des entsprechenden Handle-Wertes an den Anfordernden durch den Zugriffs-Vermittler (200), so dass gewährleistet ist, dass die bestimmte Ressource noch existiert, bevor dem Anfordernden Zugriff auf die bestimmte Ressource erteilt wird; Präsentieren des ausgegebenen Handle-Wertes für den Zugriffs-Vermittler (200) durch den Anfordernden; Bestimmen, dass der ausgegebene Handle gültig ist, durch den Zugriffs-Vermittler (200), wenn der ausgegebene Handle-Wert einem der Handle-Werte entspricht, die in der Datenbank gespeichert sind; Dereferenzieren eines gültigen ausgegebenen Handles durch den Zugriffs-Vermittler (200) in konstanter Zeit in den Ressourcen-Zeiger zu der bestimmten Ressource und Zurückführen eines Null-Zeigers, wenn der ausgegebene Handle als ungültig bestimmt worden ist; Freigeben ausgegebener Handles und Betrachten ihrer jeweiligen Handle-Werte als nicht zugewiesen für Handles, die von Anfordernden nicht mehr angefordert werden, durch den Zugriffs-Vermittler und Klassifizieren der vorgegebenen Handles als ungültig.
Verfahren nach Anspruch 1 das des Weiteren dynamisches Erweitern des Bereiches in Reaktion auf vordefinierte Bedingungen umfasst, indem: ein Erweiterungsbereich für eine erweiterte Handle-Datenbank alloziert wird, die eine Größe einer multiplikativen Konstante größer als der Bereich (1102) hat; Daten, die sich in dem Bereich befinden, in die erweiterte Handle-Datenbank kopiert werden (1108–1116); die kopierten Daten in der erweiterten Handle-Datenbank umorganisiert werden, um einen zukünftigen Konflikt von Handle-Werten zu verhindern (1108–1116); und der Bereich dealloziert wird (1122).
Verfahren nach Anspruch 1, das des Weiteren dynamisches Verkleinern des Bereiches in Reaktion auf vordefinierte Bedingungen umfasst, indem: ein Verkleinerungsbereich für eine verkleinerte Handle-Datenbank alloziert wird, die eine Größe hat, die kleiner ist als die Größe des Bereiches (1202); Daten, die sich in dem Bereich befinden, in die verkleinerte Handle-Datenbank kopiert werden (1208–1226); die kopierten Daten in der verkleinerten Handle-Datenbank umorganisiert werden, um einen zukünftigen Konflikt von Handle-Werten zu verhindern (1208–1226); und der Bereich dealloziert wird (1232).
Computerimplementiertes Verfahren, das in einem System verwendet wird, das Anfordernde (212-216) aufweist, die Zugriff auf eine Vielzahl von Ressourcen (218-222) anfordern, wobei das Verfahren dazu dient, Datenzugriff auf die Res sourcen unter Verwendung von Handles zu verwalten und das Verfahren in einer Multi-Thread-Umgebung eingesetzt wird und das Verfahren umfasst: Allozieren eines Bereiches in einem computerlesbaren Speicher für eine Datenbank, wobei die Datenbank eine Anordnung von Einträgen umfasst und jeder Eintrag ein Handle-Feld zum Speichern eines einzigartigen Handle-Wertes sowie ein Ressourcen-Feld zum Speichern entweder eines Ressourcen-Zeigers zu einer bestimmten Ressource oder eines Null-Zeigers hat; Zuweisen eines ungenutzten Handle-Feldes in der Datenbank durch einen Zugriffs-Vermittler (200) bei der Annahme eines Ressourcen-Zeigers zu einer bestimmten Ressource von einem Anfordernden, der Zugriff auf die bestimmte Ressource anfordert, zu dem angenommenen Ressourcen-Zeiger zu der bestimmten Ressource, Speichern des angenommenen Ressourcen-Zeigers in dem Eintrag des ungenutzten Handles durch den Zugriffs-Vermittler (200) und Ausgeben des entsprechenden Handle-Wertes an den Anfordernden durch den Zugriffs-Vermittler (200), so dass gewährleistet ist, dass die bestimmte Ressource noch existiert, bevor dem Anfordernden Zugriff auf die bestimmte Ressource gewährt wird; Präsentieren des ausgegebenen Handle-Wertes zu dem Zugriffs-Vermittler (200) durch den Anfordernden; Bestimmen, dass der ausgegebene Handle gültig ist, durch den Zugriffs-Vermittler (200), wenn der ausgegebene Handle-Wert einem der Handle-Werte entspricht, die in der Datenbank gespeichert sind; Dereferenzieren eines gültigen ausgegebenen Handles durch den Zugriffs-Vermittler (200) in konstanter Zeit in den Ressourcen-Zeiger zu der bestimmten Ressource und Zurückführen eines Null-Zeigers, wenn der ausgegebene Handle als ungültig bestimmt worden ist; Freigeben ausgegebener Handles und Betrachten ihrer jeweiligen Handle-Werte als nicht zugewiesen für Handles, die von Anfordernden nicht mehr angefordert werden, durch den Zugriffs-Vermittler und Klassifizieren der freigegebenen Handles als ungültig.
Verfahren nach Anspruch 4, das des Weiteren Bereitstellen eines Null-Zeigers (338) umfasst, wenn der bestätigte Bezugs-Handle als ungültig betrachtet wird.
Verfahren nach Anspruch 5, das des Weiteren umfasst: Ausgeben eines neuen Bezugs-Handles mit einem einzigartigen Wert an einen Verbraucher, wenn der Verbraucher Zugriff auf wenigstens eine der Ressourcen (310) anfordert; Freigeben ausgegebener Bezugs-Handle und Betrachten ihrer jeweiligen Handle-Werte als nicht zugewiesen für Bezugs-Handle, die von Verbrauchern (314) nicht mehr angefordert werden; und Klassifizieren der freigegebenen Handle als ungültig (346).
Verfahren nach Anspruch 6, das des Weiteren dynamisches Erweitern des Bereiches in Reaktion auf vordefinierte Bedingungen umfasst, indem: ein Erweiterungsbereich für eine erweiterte Handle-Datenbank alloziert wird, der eine Größe einer multiplikativen Konstante größer als der Bereich (1102) hat; Daten, die sich in dem Bereich befinden, in die erweiterte Handle-Datenbank kopiert werden (1108–1116); die kopierten Daten in der erweiterten Handle-Datenbank umgeordnet werden, um einen zukünftigen Konflikt von Handle-Werten (1108–1116) zu verhindern; und der Bereich dealloziert wird (1122).
Verfahren nach Anspruch 7, das des Weiteren dynamisches Verkleinern des Bereiches in Reaktion auf vordefinierte Bedingungen umfasst, indem: ein Verkleinerungsbereich für eine verkleinerte Handle-Datenbank alloziert wird, der eine Größe hat, die kleiner ist als die Größe des Bereiches (1202); Daten, die sich in dem Bereich befinden, in die verkleinerte Handle-Datenbank kopiert werden (1208–1226); die kopierten Daten in der verkleinerten Handle-Datenbank umorganisiert werden, um einen zukünftigen Konflikt von Handle-Werten zu verhindern (1208–1226); und der Bereich dealloziert wird (1232).