PatentDe  


Dokumentenidentifikation DE112005002402T5 16.08.2007
Titel Hybride Hardware-/Software-Implementierung eines Transaktionsspeicherzugriffs
Anmelder Intel Corp., Santa Clara, Calif., US
Erfinder Kumar, Sanjeev, San Jose, Claif., US;
Hughes, Christopher, San Jose, Calif., US;
Kundu, Partha, Palo Alto, Calif., US;
Nguyen, Anthony, Mountain View, Calif., US
Vertreter BOEHMERT & BOEHMERT, 28209 Bremen
DE-Aktenzeichen 112005002402
Vertragsstaaten AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BW, BY, BZ, CA, CH, CN, CO, CR, CU, CZ, DE, DK, DM, DZ, EC, EE, EG, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, KM, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, LY, MA, MD, MG, MK, MN, MW, MX, MZ, NA, NG, NI, NO, NZ, OM, PG, PH, PL, PT, RO, RU, SC, SD, SE, SG, SK, SL, SM, SY, TJ, TM, TN, TR, TT, TZ, UA, UG, US, UZ, VC, VN, YU, ZA, ZM, ZW, EP, AT, BE, BG, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, IS, IT, LT, LU, LV, MC, NL, PL, PT, RO, SE, SI, SK, TR, OA, BF, BJ, CF, CG, CI, CM, GA, GN, GQ, GW, ML, MR, NE, SN, TD, TG, AP, BW, GH, GM, KE, LS, MW, MZ, NA, SD, SL, SZ, TZ, UG, ZM, ZW, EA, AM, AZ, BY, KG, KZ, MD, RU, TJ, TM
WO-Anmeldetag 21.09.2005
PCT-Aktenzeichen PCT/US2005/033917
WO-Veröffentlichungsnummer 2006039174
WO-Veröffentlichungsdatum 13.04.2006
Date of publication of WO application in German translation 16.08.2007
Veröffentlichungstag im Patentblatt 16.08.2007
IPC-Hauptklasse G06F 12/08(2006.01)A, F, I, 20050921, B, H, DE

Beschreibung[de]
AUSGANGSSITUATION 1. GEBIET

Ausführungsformen der Erfindung betreffen das Gebiet eines Transaktionsspeichers. Insbesondere betreffen Ausführungsformen der Erfindung eine hybride Hardware-/Software-Implementierung eines Transaktionsspeicherzugriffs.

2. BESCHREIBUNG DES STANDS DER TECHNIK

Der Transaktionsspeicherdienst ermöglicht Anwendungen, Programmen, Modulen usw., und insbesondere Anwendungsprogrammschnittstellen (APIs), den atomaren, konsistenten und isolierten Zugriff auf einen Speicher. So ist zum Beispiel ein Transaktionsspeicher als Teil einer Laufzeitmaschine zur Verwaltung von beständigen, zeigerreichen Datenstrukturen, wie zum Beispiel Datenbanken, und Verzeichnisdiensten verwendbar.

Ein API ist als ein Sprach- oder Nachrichtenformat vorstellbar, das von einer Anwendung, einem Programm, einem Modul usw. zum Kommunizieren mit einem Systemprogramm, wie zum Beispiel einem Betriebssystem oder einen Datenbanksystem (DBMS), verwendet wird. APIs sind implementierbar, indem Funktionsaufrufe in ein Programm geschrieben werden, die die Verknüpfung mit einer spezifischen Unterroutine zur Ausführung bereitstellen. Somit bringt ein API mit sich, daß irgendein Programmmodul oder irgendeine Programmroutine entweder bereits vorhanden ist oder eine Verknüpfung mit diesem bzw. dieser besteht, um Aufgaben zu erfüllen, die ein Funktionsaufruf anfordert.

Ein Transaktionsspeicher vereinfacht das Schreiben von parallelen Programmen, und die Verwendung eines Transaktionsspeichers ermöglicht den gleichzeitigen Ablauf von unterschiedlichen Threads, wodurch eine extrem hohe Verarbeitungseffizienz erreicht wird. Jedoch muß der Programmierer gegenwärtig bei der Verwendung eines Transaktionsspeichers eine schwierige Wahl treffen.

Eine Wahlmöglichkeit besteht in der Verwendung einer reinen Hardware-Implementierung eines Transaktionsspeicher-API, wo der Programmierer dafür verantwortlich ist, ständig die Hardware-Ressourcenanforderungen eines Programms zu verfolgen und zu gewährleisten, daß diese die verfügbaren Hardware-Ressourcen nicht übersteigen. Die Anwendbarkeit und Brauchbarkeit eines Transaktionsspeichers (im folgenden TM genannt) sind bei diesem Lösungsansatz begrenzt. Die Alternative besteht in der Verwendung einer reinen Software-Implementierung eines TM-API, die einfach zu programmieren ist, da es praktisch keine Ressourcenbegrenzung gibt. Der Software-Lösungsansatz leidet jedoch unter einem hohen Ausführungszeitaufwand.

Wenn man sich einen TM genauer betrachtet, so wird dieser aus Datenbanktransaktionen hergeleitet. In Datenbanken ist eine Transaktion eine Gruppe von Operationen, die vier Eigenschaften haben müssen, die als ACID-Eigenschaften bezeichnet werden. Die erste ACID-Eigenschaft ist die Atomarität. Die Atomarität erfordert, daß eine Datenbanktransaktion nach dem Prinzip „alles oder nichts" durchgeführt wird. Die Transaktion kann abgebrochen werden, weil entweder das Programm abbricht oder ein Fehler auftritt. Die Atomarität erfordert, daß entweder alle Operationen der Transaktion durchgeführt werden oder daß keine von ihnen durchgeführt wird. Die zweite ACID-Eigenschaft ist die Konsistenz. Die Konsistenz erfordert, daß dann, falls sich die Datenbank vor der Durchführung der Transaktion in einem konsistenten Zustand befindet, die Datenbank in einem konsistenten Zustand belassen werden sollte. Die dritte ACID-Eigenschaft ist die Isolation. Die Eigenschaft der Isolation legt fest, daß alle auszuführenden Transaktionen gewissermaßen als in einer Reihenfolge durchgeführt erscheinen müssen. Das heißt, daß sie serialisierbar sein sollten. Die letzte und vierte erforderliche ACID-Eigenschaft ist die Dauerhaftigkeit. Die Dauerhaftigkeit erfordert, daß eine Transaktion einen Absturz der Maschine überlebt. Das heißt, daß eine Transaktion auf ein stabiles Speichervorrichtung (zum Beispiel eine Platte) geschrieben werden muß, bevor sie ausgeführt werden kann. Es sollte jedoch beachtet werden, daß nicht alle TM-Implementierungen erfordern, daß eine Transaktion jede der vier oben beschriebenen Eigenschaften hat. So ist zum Beispiel bei einigen Implementierungen die Dauerhaftigkeit nicht erforderlich.

Über das Aufweisen aller oder einiger der oben beschriebenen ACID-Eigenschaften hinaus wird von Transaktionen und Datenbanken, die einen Transaktionsspeicher verwenden, oft auch gefordert, daß sie die Eigenschaften der gleichzeitigen Ausführung, der Deadlockfreiheit und des Nichtblockierens unterstützen. Typischerweise wird die gleichzeitige Ausführung von nicht in Konflikt kommenden Transaktionen durch Transaktionsspeichersysteme unterstützt. Einige Datenbankimplementierungen verwenden Verriegelungen (zum Beispiel Zweiphasenverriegelungen) zum Implementieren dieser Arten von Transaktionen. Folglich können in diesen Fällen Deadlocks auftreten. Die Deadlockfreiheit wird in Transaktionsspeichersystemen implementiert, indem ein Deadlock, sobald er entdeckt worden ist, einfach dadurch behoben wird, daß einige der Transaktionen abgebrochen werden. Die Eigenschaft des Nichtblockierens bzw. der Behinderungsfreiheit ist erforderlich, um zu verhindern, daß ein Thread den Fortgang anderer Threads in Transaktionsspeichersystemen behindert.

Gegenwärtig gibt es zwei übliche Lösungsansätze für die Implementierung von Transaktionsspeicherzugriffen unter Verwendung von APIs. Der eine davon ist eine reine Hardware-Implementierung und der andere eine reine Software-Implementierung. Die Hardware-Implementierung basiert auf einer Multiprozessorarchitektur, wie dargelegt in „Transaktionsspeicher: Architekturunterstützung für verriegelungsfreie Datenstrukturen" (Maurice Herlihy, J. Eliot B. Moss: Transactional Memory: Architectural Support for Lock-Free Data Structures, International Society for Computers and Their Application, (ISCA) 1993: 289-300). Dieser Lösungsansatz wird im folgenden als Reiner Hardware-Lösungsansatz bezeichnet.

Der Reine Hardware-Lösungsansatz stellt ein wirksames und problemlos zu verwendendes verriegelungsfreies Synchronisationsverfahren bereit. Der Reine Hardware-Lösungsansatz vermeidet viele der heiklen Korrektheitsprobleme, die mit dem parallelen Programmieren verknüpft sind, und garantiert außerdem ein Freisein von einer Prioritätsinversion, einem Convoying und Deadlocks, die typischerweise mit verriegelungsbasierten Synchronisationsverfahren verbunden sind.

Leider erfordert der Reine Hardware-Lösungsansatz eine sorgfältige Ressourcenverwaltung durch den Programmierer. Somit ist der Reine Hardware-Lösungsansatz bei einer ganzen Reihe von fortgeschritteneren Prozessorstrukturen sehr schwierig zu implementieren. Typischerweise muß die Software über die Prozessorimplementierung hinweg portierbar sein, und eine solche sorgfältige Abstimmung der Ressourcen auf der Anwendungsebene schränkt die Verwendung des Reinen Hardware-Lösungsansatzes ein. Außerdem verwendet der Reine Hardware-Lösungsansatz während des Betriebs nur den Transaktionscache im Transaktionsspeicher, und aufgrund dieser begrenzten Ressource ist nicht garantiert, daß Prozeß-Threads beendet werden, was zu Programmstörungen führt.

Ein anderer üblicher Lösungsansatz für die Verwendung von Transaktionsspeicherzugriffen mit APIs ist die Verwendung eines reinen Software-Lösungsansatzes, wie dies zum Beispiel dargelegt ist in „Software-Transaktionsspeicher für Datenstrukturen von Dynamischer Größe" (Maurice Herlihy, Victor Luchangco, Mark Moir, William N. Scherer III, Software Transactional Memory for Dynamic-Sized Data Structures, Principles of Distributed Computing (PODC) 2003). Dieser Lösungsansatz wird im folgenden als Reiner Software-Lösungsansatz bezeichnet. Die Stärke des Reinen Software-Lösungsansatzes besteht darin, daß der Programmierer die spezifischen Techniken, die bei der Bereitstellung der Transaktionsspeichersemantik angewandt wurden, völlig vergessen haben kann und daß die API besonders leicht zu programmieren ist. Leider führt die Technik des Reinen Software-Lösungsansatzes während des Betriebs zu beträchtlichen Verzögerungen, die durch den Software-Zusatzaufwand verursacht werden.

KURZBESCHREIBUNG DER ZEICHNUNGEN

1 ist ein Teilblockdiagramm eines Beispiels einer Rechnersystemkonfiguration, in der Ausführungsformen der Erfindung praktizierbar sind.

2 ist ein Diagramm, das ein Transaktionsspeicherobjekt gemäß einer Ausführungsform der Erfindung veranschaulicht.

3 ist eine Tabelle, die eine Befehlssatzarchitektur zum Implementieren von Hardware-/Software-Transaktionsspeichertransaktionen gemäß einer Ausführungsform der Erfindung veranschaulicht.

4A ist ein Ablaufdiagramm, das einen Prozeß der hybriden Hardware-/Software-Implementierung von Transaktionsspeicherzugriffen gemäß einer Ausführungsform der Erfindung veranschaulicht.

4B ist ein Ablaufdiagramm, das insbesondere einen Prozeß zur Überwachung hinsichtlich Überhang-(Orphan)-transaktionen gemäß einer Ausführungsform der Erfindung veranschaulicht.

5 ist ein Ablaufdiagramm, das einen Prozeß zum wirksamen Implementieren von Verriegelungen unter Verwendung der Hardware-/Software-Transaktions-ISA gemäß einer Ausführungsform der Erfindung veranschaulicht.

BESCHREIBUNG

In der folgenden Beschreibung werden die verschiedenen Ausführungsformen der Erfindung ausführlich beschrieben. Solche Einzelheiten sind jedoch eingeschlossen, um die Erfindung leichter verständlich zu machen und beispielhafte Ausführungsformen zum Ausführen der Erfindung zu beschreiben. Solche Einzelheiten sollten nicht dazu verwendet werden, die Erfindung auf die besonderen beschriebenen Ausführungsformen zu beschränken, weil andere Variationen und Ausführungsformen innerhalb des Umfangs der Erfindung möglich sind. Es sind zwar zahlreiche Einzelheiten für ein gründliches Verständnis der Ausführungsformen der Erfindung dargelegt, jedoch ist einem Fachmann verständlich, daß diese spezifischen Einzelheiten nicht erforderlich sind, um die Ausführungsformen der Erfindung zu praktizieren. In anderen Fällen werden solche Einzelheiten wie zum Beispiel gut bekannte Verfahren, Datenarten, Protokolle, Prozeduren, Bauteile, elektrische Strukturen und Schaltungen nicht ausführlich beschrieben oder werden in Blockdiagrammform gezeigt, um die Erfindung nicht unverständlich zu machen. Außerdem werden Ausführungsformen der Erfindung in besonderen Ausführungsformen beschrieben, sind jedoch auch in Hardware, Software, Firmware, Middleware oder als eine Kombination daraus implementierbar.

Ausführungsformen der Erfindung stellen eine hybride Hardware-/Software-Implementierung von TM-Zugriffen bereit, zum Beispiel für die Verwendung mit APIs, um Hochleistungszugriffe durch die Verwendung der eingebetteten Hardware-Unterstützung des Prozessors und, im Falle der Erschöpfung der Hardware-Ressourcen, die anschließende Rückkehr zu einer Software-Konfiguration bereitzustellen. Somit werden die Vorteile der Hardware-TM-Zugriffe und der Software-TM-Zugriffe gleichzeitig realisiert.

In einer Ausführungsform werden die Leistungsstrafen, die mit TM-API-Software-Lösungsansätzen verknüpft sind, beträchtlich reduziert, indem, wie weiter unten erörtert wird, in den häufigsten Fällen ein ursprüngliches Transaktionsobjekt modifiziert wird, um eine Hardware-TM-Unterstützung zu ermöglichen. Somit werden Fälle häufig verarbeitet, indem zur Erzielung einer hohen Leistung die eingebettete Hardware-Unterstützung (zum Beispiel ein TM-Cache) verwendet wird und falls ein Problem entsteht, zu einer Software-TM-Konfiguration zurückgekehrt wird, falls sich die Hardware-Ressourcen erschöpfen.

1 zeigt ein Teilblockdiagramm eines Beispiels einer Rechnersystemkonfiguration 100, in der Ausführungsformen der Erfindung praktizierbar sind. Die Systemkonfiguration 100 beinhaltet mindestens einen Prozessor 101 (zum Beispiel eine Zentraleinheit (CPU)), einen Chipsatz 103, Systemspeichervorrichtungen 105, eine oder mehrere Schnittstellen 111 zum Anschluß an ein oder mehrere Eingabe/Ausgabe-Vorrichtungen (E/A-Geräte) 113 und eine Netzschnittstelle 107.

Der Chipsatz 103 kann einen Speichersteuerhub (MCH) und/oder einen E/A-Steuerhub umfassen. Der Chipsatz 103 kann aus einem oder mehreren integrierten Schaltkreischips bestehen, die als Hub oder Kern für die Datenübertragung zwischen dem Prozessor 101 und anderen Komponenten des Rechnersystems 100 fungieren. Außerdem kann das Rechnersystem 100 zusätzliche Komponenten (nicht gezeigt) umfassen, wie zum Beispiel andere Prozessoren (zum Beispiel in einem Multiprozessorsystem), einen Coprozessor sowie andere Komponenten usw., wobei dies lediglich ein sehr grundlegendes Beispiel für ein Rechnersystem ist.

Im Sinne der vorliegenden Beschreibung bezieht sich der Begriff „Prozessor" oder „CPU" auf jede Maschine, die zum Ausführen einer Befehlsfolge in der Lage ist, und sollte so aufgefaßt werden, daß er Universalmikroprozessoren, Spezialmikroprozessoren, anwendungsspezifische integrierte Schaltungen (ASICs), Multimedia-Controller, Signalprozessoren und Mikrokontroller usw. umfaßt, ohne jedoch auf diese beschränkt zu sein. In einer Ausführungsform ist die CPU 101 ein Universalhochleistungsmikroprozessor, der zum Ausführen eines Intel-Architektur-Befehlssatzes in der Lage ist. So kann die CPU 101 zum Beispiel aus einer der INTEL® PENTIUM® Prozessorklassen sein, wie zum Beispiel ein Prozessor mit der INTEL® Architektur 32 Bit (IA-32), wie zum Beispiel ein PENTIUM® 4M.

Die CPU 101, der Chipsatz 103 und die anderen Komponenten greifen über den Chipsatz 103 auf die Systemspeichervorrichtungen 105 zu. Der Chipsatz 103 kann zum Beispiel bei Verwendung eines Speichersteuerhubs Speichertransaktionen erfüllen, die auf die Systemspeichervorrichtungen 105 abzielen.

Die Systemspeichervorrichtungen 105 können jede Speichervorrichtung umfassen, die für die Speicherung von digitalen Informationen ausgelegt ist, wie zum Beispiel ein statischer Speicher mit wahlfreiem Zugriff (SRAM), ein dynamischer Speicher mit wahlfreiem Zugriff (DRAM), ein synchroner dynamischer Speicher mit wahlfreiem Zugriff (SDRAM) und/oder ein SDRAM oder DRAM mit doppelter Datenrate (DDR) usw. Somit umfassen die Systemspeichervorrichtungen 105 in einer Ausführungsform einen flüchtigen Speicher. Außerdem können die Systemspeichervorrichtungen auch einen nichtflüchtigen Speicher, wie zum Beispiel einen Nur-Lese-Speicher (ROM), umfassen.

Außerdem können die Systemspeichervorrichtungen 105 auch andere Speichervorrichtungen, wie zum Beispiel Festplattenlaufwerke, Diskettenlaufwerke, optische Plattenlaufwerke usw., und geeignete Schnittstellen umfassen.

Außerdem können die Systemspeichervorrichtungen 105 im nichtflüchtigen Speicher ein Hardware-/Software-TM-Maschinenprogramm für den Betrieb durch den Prozessor 101 abspeichern, um Techniken gemäß Ausführungsformen der Erfindung für eine hybride Hardware-/Software-TM-Maschine zu implementieren, die im Prozessor 101 implementiert ist, um Transaktionsspeicherzugriffe und -transaktionen (die Begriffe „Zugriff" und „Transaktion" werden im folgenden als miteinander austauschbare Begriffe verwendet) innerhalb des Rechnersystems 100 freizugeben.

Die Systemspeichervorrichtungen können auch Speicherbereiche umfassen, die der Implementierung von Transaktionsspeichertransaktionen bei Datenbanken 108 gewidmet sind. So können die Datenbanken 108 zum Beispiel solche Datenbanken, wie z.B. Unternehmensdatenbanken, Finanzdatenbanken, Projektmanagementdatenbanken, Verzeichnisdienste usw. und andere zeigerreiche Datenstrukturen, die typischerweise bei Transaktionen des Transaktionsspeichertyps verwendet werden, umfassen.

Außerdem kann das Rechnersystem 100 geeignete Schnittstellen 111 zum Anschluß an E/A-Vorrichtungen 113, wie zum Beispiel Plattenlaufwerke, Monitore, Tastenblöcke, ein Modem, einen Drucker oder jede andere Art von geeigneten E/A-Vorrichtungen, umfassen.

Das Rechnersystem 100 kann auch eine Netzschnittstelle 107 umfassen, um das Rechnersystem 100 an ein Netzwerk 109, wie zum Beispiel ein lokales Netzwerk (LAN), ein Weitverkehrsnetz (WAN), das Internet usw., anzuschließen.

Die grundlegende Rechnersystemkonfiguration 100 von 1 ist ein Beispiel für eine Rechnersystemart, die bei der Implementierung einer hybriden Hardware-/Software-Implementierung von Transaktionsspeicherzugriffen verwendbar ist. Fachleute sollten erkennen, daß die beispielhafte Rechnersystemkonfiguration 100 von 1 lediglich ein Beispiel für ein grundlegendes Rechnersystem ist und daß viele andere Arten und Variationen möglich sind. Außerdem werden Fachleute erkennen, daß die beispielhafte Umgebung, die in 1 veranschaulicht ist, die Ausführungsformen der Erfindung nicht einschränken soll. Außerdem sollte erkannt werden, daß zusätzlich zu oder anstelle der Einzelrechnersystemkonfiguration 100 auch Cluster oder andere Gruppen von Rechnern (die der Rechnersystemkonfiguration 100 gleichen oder sich von dieser unterscheiden) beim Praktizieren von Ausführungsformen der Erfindung verwendbar sind.

Insbesondere kann, wie in 1 gezeigt wird, der Prozessor 101, der die Transaktionsmaschine 118 verwendet, einen hybriden Hardware-/Software-TM-Zugriffslösungsansatz implementieren. Insbesondere beinhaltet die Transaktionsmaschine 118 eine Standard-TM-Funktionalität zusammen mit einer verbesserten TM-Befehlssatzarchitektur (ISA), die durch die Transaktionsmaschine 118 implementiert wird (wird weiter unten noch ausführlicher erörtert), um Ausführungsformen der Erfindung zu implementieren, die sich auf eine hybride Hardware-/Software-TM-Maschine beziehen. Auch umfaßt der Prozessor 101 einen Transaktionscache 132 und einen regulären Speichercache 134, die miteinander koppelbar sind.

Wie weiter unten noch ausführlicher erörtert werden wird, ermöglicht die mit der Transaktionsmaschine 118 implementierte TM-ISA eine hybride Hardware-/Software-TM-Maschine für eine Verwendung mit beispielsweise APIs, um eine hohe Leistung unter Verwendung einer Hardware-Unterstützung (zum Beispiel Transaktionscache 132) in einem „Hardware-Modus" zu erzielen, und kehrt zu einer Software-Konfiguration (oder „Software-Modus") zurück, falls der Hardware-Cache 132 erschöpft ist. Auf diese Weise werden API-Anforderungen 116 zum Lesen und Schreiben von Daten in den Speicher 105 und die Datenbanken 108 optimiert. Es sollte beachtet werden, daß sich im folgenden „Hardware-Modus" auf die hauptsächliche Verwendung des Transaktionscache 132 zur Erzielung einer hohen Leistung bezieht, während sich im folgenden „Software-Modus" auf die hauptsächliche Verwendung des regulären Cache 134 und anderer Speicherressourcen bezieht, die eine langsamere Leistung bereitstellen, aber sich nicht erschöpfen.

Während Ausführungsformen der Erfindung und ihre verschiedenen Funktionselemente in besonderen Ausführungsformen beschrieben wurden und auch im folgenden beschrieben werden, sollte verständlich sein, daß diese Aspekte und Funktionalitäten in Hardware, Software, Firmware, Middleware oder als eine Kombination daraus implementierbar sind.

Unter Bezugnahme auf 2 ist dort ein Diagramm gezeigt, das ein Transaktionsspeicherobjekt gemäß einer Ausführungsform der Erfindung veranschaulicht. Wie in 2 gezeigt wird, wird ein TM-Objekt 202 durch einen Lokalisierer 204 identifiziert. Jedes gemeinsame Datenobjekt, das nicht nur lesbar (read only) ist, wird in einem Container plaziert (siehe TM-Objekt 202). Während einer Transaktion werden alle TM-Objekte 202 geöffnet, bevor auf sie zugegriffen wird. Das ordnet die Objekte der Transaktion zu, so daß das zugrundeliegende Software-System Konflikte zwischen Transaktionen erfassen kann. Typischerweise öffnet ein Thread ein Objekt mit einer API, die festlegt, ob auf das Objekt in einer Nur-Lese-Weise zugegriffen wird. Die Daten innerhalb des Transaktionsobjekts können manipuliert werden, sobald das Objekt geöffnet worden ist.

Der Lokalisierer 204 fungiert als Transaktionsobjektlokalisierer. Es gibt einen Transaktionsobjektlokalisierer, der für jedes Transaktionsobjekt aktiv ist, und zwar ungeachtet der Anzahl der Threads, die gleichzeitig auf das Objekt zugreifen. Die Zustandsliste 206 speichert die Speicheradressen der Zustände der Transaktionen, die gerade im Software-Modus auf das Objekt zugreifen. Typischerweise ist der Zustand einer Transaktion entweder AKTIV, AUSGEFÜHRT oder ABGEBROCHEN (214). Pro Transaktion gibt es nur einen Zustand. Transaktionen im Hardware-Modus haben auch einen Zustand, jedoch erscheinen sie niemals in der Zustandsliste 206, wie noch erörtert werden wird.

Der TM-Lokalisierer (204) speichert außerdem die Speicheradressen des Inhalts 218 der neuen Version des Objekts 210 und den Inhalt 220 der alten Version des Objekts 212. Wenn eine Transaktion ein TM-Objekt öffnet, um die neueste Version des Inhalts zu erhalten, hängt die Version, die sie erhält, vom Zustand der letzten Transaktion ab, die das Objekt zum Schreibens geöffnet hat (das heißt, nicht Nur-Lese). Falls der Zustand 214 des letzten Schreibers AKTIV oder ABGEBROCHEN ist, erhält die Transaktion, die das Objekt öffnet, die alte Version 220. Falls der Zustand 214 des letzten Schreibers AUSGEFÜHRT ist, erhält die Transaktion, die das Objekt öffnet, die neue Version 218.

Wenn eine Transaktion im Software-Modus ein TM-Objekt 202 zum Schreiben öffnet, plaziert sie die Adresse der neuesten Version (oben definiert) im alten Objektfeld 212 des TM-Lokalisiererobjekts 204. Die Transaktion erstellt eine Kopie des neuesten Inhalts und plaziert die Adresse dieser Kopie im neuen Objektfeld 210 des TM-Lokalisierers 204. Bis die Transaktion im Software-Modus ausgeführt wird, wird auf die neue Kopie des Objekts durch keinen anderen Thread zugegriffen. Daher ist die neue Kopie lokal. Sobald die Transaktion ausgeführt wird, wird die neue Version des TM-Objekts zu einem gemeinsamen Objekt und ist nicht mehr modifizierbar. Wenn eine Transaktion im Hardware-Modus ein TM-Objekt 202 zum Schreiben öffnet, erstellt sie keine Kopie des Inhalts. Eine Transaktion im Hardware-Modus modifiziert die neueste Version des Objekts direkt, wobei sie sich zum Zwischenspeichern von spekulativen Schreibvorgängen auf Hardware stützt, wie weiter unten erörtert werden wird.

Das TM-Objekt 202 schließt außerdem ein Modusfeld 208 ein, um anzuzeigen, ob sich das TM-Objekt 202 im Lesemodus oder im Schreibmodus befindet. Wenn eine Transaktion im Software-Modus ein TM-Objekt entweder im Lese- oder im Schreibmodus 208 öffnet, fügt sie die Adresse ihrer Zustandsvariable 214 zur Zustandsliste 206 hinzu. Das ermöglicht anderen Threads (sowohl im Software- als auch im Hardware-Modus) den Abbruch der Transaktion und macht Operationen des Validierens von einzelnen Objekten generell überflüssig. Eine Transaktion ist validierbar, indem einfach ein Platz untersucht wird, der den Zustand der Transaktion (Zustand 214) aufrechterhält. Wenn eine Transaktion ein TM-Objekt 202 öffnet und dessen Modusfeld 208 in den Nur-Lese-Modus gesetzt ist, müssen keine Transaktionen explizit abgebrochen werden, falls das Objekt im Nur-Lese-Modus geöffnet wird. Falls jedoch das Objekt im Schreibmodus geöffnet wird, müssen alle Transaktionen in der Zustandsliste 206 abgebrochen werden, falls ihr Zustand 214 AKTIV ist. Wenn eine Transaktion ein TM-Objekt 202 öffnet und das Modusfeld 208 durch die einzelne Transaktion in der Zustandsliste 206 (der aktuelle Schreiber) bereits auf Schreiben gesetzt ist, muß diese einzelne Transaktion abgebrochen werden, falls ihr Wert AKTIV 214 ist, und zwar ganz gleich, ob das TM-Objekt 202 im Nur-Lese-Modus oder im Schreibmodus geöffnet wird.

In dieser Implementierung läßt ein TM-Objekt 202 immer nur einen einzelnen Leser oder einen einzelnen Schreiber zu einem Zeitpunkt zu. Diese Einschränkung ist in einigen Ausführungsformen lockerbar, indem mehrere Transaktionsfelder in der Zustandsliste 206 zugelassen werden, um mehrere gleichzeitige Leser zuzulassen. Das stellt mehrere (aber begrenzte) Transaktionen zum Öffnen eines Objekts zu jedem gegebenen Zeitpunkt bereit. Dieses Limit ist auf einer Pro-Objekt-Basis einstellbar. Wie weiter unten noch erörtert werden wird, macht das TM-Objekt 202 Transaktionsspeichertransaktionen zugänglicher für die Implementierung durch eine Hardware-/Software-Hybridkonfiguration.

Ausführungsformen der vorliegenden Erfindung stellen eine Hardware-/Software-Transaktions-Befehlssatzarchitektur (ISA) bereit, die zuläßt, daß Transaktionsspeichertransaktionen entweder in einem „Hardware-Modus" oder in einem „Software-Modus" implementiert werden. Wenn ein Transaktionsspeicherzugriff im Hardware-Modus erfolgt, so geschieht das in erster Linie unter Verwendung des Transaktionscache 132 (1). Auf diese Weise ist eine sehr hohe Transaktionsleistung erzielbar, jedoch kommt es manchmal zur Erschöpfung der Hardware-Ressourcen. Außerdem muß der Prozessor im Hardware-Modus alle Speicherplätze verfolgen, auf die zugegriffen wird. Im Hardware-Modus werden Konflikte zwischen gleichzeitig ausgeführten Transaktionen erfaßt, und eine der konfliktverursachenden Transaktionen wird abgebrochen. Bei einem Abbruch werden die während der Transaktion geschriebenen Daten ungültig gemacht, und bei einer Festschreibung müssen diese Daten atomar Teil des Speicherzustands sein.

Insbesondere betreffen Ausführungsformen der Erfindung eine hybride Hardware-/Software-Implementierung eines Transaktionsspeicherzugriffs in einem Rechnersystem. Ein Prozessor, der einen Transaktionscache und einen regulären Cache umfaßt, wird in einem Rechnersystem verwendet. Ein Policy-Manager wählt entweder einen ersten Modus (im folgenden als „Hardware-Modus" bezeichnet) oder einen zweiten Modus (im folgenden als „Software-Modus" bezeichnet) aus, um Transaktionsspeicherzugriffe zu implementieren, die auf eine Speicherzugriffsanforderung einer Anwendungsprogrammschnittstelle (API) anspre chen. Im Hardware-Modus wird der Transaktionscache für Ausführung von Lese-/Schreib-Speicheroperationen verwendet, und im Software-Modus wird der reguläre Cache zur Ausführung der meisten Lese-/Schreib-Speicheroperationen verwendet (nur ein Platz wird im Transaktionscache gespeichert, wie weiter unten erörtert).

Der Policy-Manager wählt zuerst den Hardware-Modus aus, um Lese-/Schreiboperationen unter Verwendung von transaktionalen Lese-/Schreibbefehlen im Transaktionscache durchzuführen. Falls im Transaktionscache Speicherressourcen vorhanden sind, die für die Durchführung der Lese-/Schreiboperationen ausreichen, wird ein Festschreibungsbefehl ausgegeben, um den Transaktionsspeicherzugriff zu erfüllen. Falls jedoch im Transaktionscache miteinander im Konflikt stehende transaktionale Lese-/Schreiboperationen oder unzureichende Speicherressourcen erfaßt werden, wird ein Abbruchbefehl ausgegeben. Falls ein Abbruchbefehl für den ersten Modus ausgegeben wird, kann der Policy-Manager den Software-Modus auswählen, in dem reguläre Lese-/Schreiboperationen unter Verwendung von regulären Lese-/Schreibbefehlen im regulären Cache durchgeführt werden.

Wenn Transaktionsspeichertransaktionen ausschließlich in Hardware implementiert werden, ist die Anzahl der Speicherplätze, auf die eine einzelne Transaktion zugreifen kann, begrenzt. Falls eine Transaktion dieses Limit überschreitet, so erfolgt gemäß einer Ausführungsform der Erfindung ein Neustart der Transaktion im „Software-Modus". Wie weiter unten noch erörtert werden wird, verursacht, wenn eine Hardware-Transaktion invalidiert wird, die nächste Speicheroperation, die durch diesen Thread ausgeführt wird, eine Ausnahme (exception). Dadurch wird verhindert, daß eine ungültig gemachte Hardware-Transaktion weiterläuft und den Speicher beschädigt. Nach der Ausnahme und dem Eintritt in den Software-Modus werden Transaktionsspeicherzugriffe in erster Linie durch den regulären Cache und andere Speicherressourcen durchgeführt (siehe 1).

Zum Implementieren dieser hybriden Hardware-/Software-Implementierung von Transaktionsspeicherzugriffen stellen Ausführungsformen der Erfindung eine neuartige und nicht offensichtliche Transaktionsspeicherbefehlssatzarchitektur (ISA) bereit. Nun wird auf 3 Bezug genommen. 3 ist eine Tabelle, die einen Befehlssatz zum Implementieren von Hardware-/Software-Transaktionsspeichertransaktionen gemäß einer Ausführungsform der Erfindung veranschaulicht.

Wie in 3 gezeigt wird, umfaßt die Hardware-/Software-Transaktions-ISA 300 einen Transaktionsbeginnbefehl 302 mit zwei Modi ein. „Begin Transaction All" soll Transaktionen im „Hardware-Modus" bezeichnen, während „Begin Transaction Select" für Transaktionen im „Software-Modus" verwendet wird. Insbesondere markiert der Transaktionsbeginnbefehl 302 den Beginn einer Transaktion. „Begin Transaction All" für den „Hardware-Modus" verursacht, daß alle Speicherzugriffe standardmäßig transaktional sind (zum Beispiel unter Verwendung eines Transaktionscache), während „Begin Transaction Select" nur die Speicheroperationen transaktional macht, die explizit spezifiziert sind.

Es sollte beachtet werden, daß Hardware-Transaktionen nicht verschachtelbar sind (im Gegensatz zu Transaktionen auf Software-Basis). Daher kann nicht mit einer neuen Hardware-Transaktion begonnen werden, bevor eine vorhergehende Transaktion entweder festgeschrieben oder abgebrochen worden ist. Der Abbruch einer Transaktion erfolgt entweder durch die Ausführung eines Abbruchtransaktionsbefehls 306 oder bei der Konfrontation mit einem Datenkonflikt, wie weiter unten noch erörtert werden wird.

Der Festschreibungsbefehl 304 wird zum Markieren des Endes einer Transaktion verwendet und ermöglicht, daß der gesamte Inhalt des Transaktionsspeichers einschließlich des Transaktionscache architektonisch wird. Insbesondere wird zugelassen, daß Transaktionsspeicherungen den Systemzustand modifizieren, und Transaktionslasten werden aus dem Transaktionscache gelöscht. Eine Festschreibungstransaktion kann nicht begonnen werden, falls nicht vorher eine vorherige Transaktion begonnen wurde.

Die Abbruchtransaktion 306 bricht die gerade laufende Transaktion ab und streicht alle vorher zwischengespeicherten Transaktionsschreibdaten. Ein Fehler tritt auf, falls vorher keine Transaktion begonnen wurde.

Außerdem beinhaltet die Hardware-/Software-Transaktions-ISA 300 auch Lade-/Speicherungs-Transaktionsbefehle 308 zum Durchführen von Transaktionsspeicher-Lade-/Speicherungsoperationen.

Außerdem beinhaltet die Hardware-/Software-Transaktions-ISA 300 auch reguläre Lade-/Speicherungsbefehle zum Durchführen von Nichttransaktionsspeicher-Lade-/Speicherungsoperationen.

Es sind auch Checkpoint- und Wiederherstellungszustandsbefehle 312 bereitgestellt.

Der Checkpointstoppbefehl speichert den aktuellen Registerzustand im Speicher. Der Wiederherstellungsbefehl stellt den aktuellen Registerzustand aus dem Speicher wieder her.

Die Hardware-/Software-Transaktions-ISA 300 schließt auch einen Überhangtransaktionsausnahmsbefehl 314 ein. Eine Transaktion ist als Überhang (orphan) definiert, falls sie nicht festschreiben kann. Das kann zum Beispiel auftreten, falls ein anderer Prozeß in eine Stelle geschrieben hat, den er transaktional gelesen hat. In diesem Fall kann eine Überhangtransaktion den Speicher in einem inkonsistenten Zustand sehen und verursachen, daß das Programm eine Ausnahme verursacht, wie zum Beispiel Teilen durch Null oder Zugreifen auf eine Speicheradresse, die außerhalb des Bereichs liegt. Sie könnte auch, was noch schlimmer wäre, falsche Werte in gültige Speicherplätze schreiben und den Systemzustand korrumpieren.

Der Überhangtransaktionsausnahmebefehl vermeidet diese Komplikationen. Insbesondere generiert der erste durch einen Thread ausgeführte Ladebefehl, nachdem seine Transaktion ein Überhang geworden ist, eine Überhangtransaktionsausnahme 314, wie weiter unten noch erörtert werden wird.

Wenden wir uns nun 4A zu. 4A ist ein Ablaufdiagramm, das einen Prozeß 400 einer hybriden Hardware-/Software-Implementierung von Transaktionsspeicherzugriffen gemäß einer Ausführungsform der Erfindung veranschaulicht. Der Prozeß 400 nutzt die Tatsache aus, daß bei einer Implementierung im „Hardware-Modus" (zum Beispiel unter primärer Verwendung des Transaktionscache des Prozessors) in den meisten normalen Fällen Transaktionsspeicherzugriffe sehr schnell und optimal abgeschlossen werden. Der Prozeß berücksichtigt jedoch auch, daß bei einer Implementierung durch den Prozessor im Hardware-Modus die Transaktion möglicherweise nicht abgeschlossen werden kann. Daher fällt sie in einen „Software-Modus" zurück, der die Transaktionen garantiert immer abschließt. Dagegen verwendet der „Software-Modus" in erster Linie den regulären Cache und andere Speicherressourcen. Wie weiter unten noch erörtert werden wird, verursacht, wenn eine Hardware-Transaktion invalidiert wird, die nächste Speicheroperation eine Überhangtransaktionsausnahme, die verhindert, daß die invalidierte Hardware-Transaktion weiterläuft und den Speicher korrumpiert.

Wenn wir uns den Prozeß 400 im einzelnen anschauen, so wird in Block 402 eine Transaktion (zum Beispiel von einem API ausgehend) begonnen. In Block 404 wählt ein Policy-Manager entweder den Hardware- oder den Software-Modus aus, um die Transaktion zu beginnen. In einer Ausführungsform wird der Hardware-Modus zuerst ausgewählt, um die schnelle Hardware-Verarbeitung auszunutzen (zum Beispiel über einen Transaktionscache), und der Software-Modus ist als Back-Up verwendbar.

Nachdem der Hardware-Modus ausgewählt worden ist, wird von der Hardware-/Software-Transaktions-ISA 300 ein Befehl „Begin Transaction All" 302 initiiert, so daß der Modus auf „Hardware" gestellt wird. Außerdem wird von der Hardware-/Software-Transaktions-ISA auch ein Ladetransaktionsbefehl 308 initiiert, um den Transaktionsspeicherzustand zu laden. Als nächstes werden in Block 408 Lese-/Schreiboperationen für die Transaktion am Platz an TM-Objekten durchgeführt, wie das bereits erörtert worden ist, unter Verwendung von transaktionalen Lese-/Schreiboperationen. Falls die Hardware-Transaktion abgeschlossen werden kann (falls zum Beispiel Hardware-Ressourcen vorhanden sind, die für die Erfüllung der Transaktion mit dem Transaktionscache ausreichen), wird ein Festschreibungstransaktionsbefehl generiert und, wie in Block 410 gezeigt wird, der Zustand auf „Festschreiben" gestellt und die Transaktion festgeschrieben. Der Prozeß für die Transaktion ist somit festgeschrieben worden (Block 415).

Falls jedoch die Transaktion nicht in Hardware festschreibbar ist (weil es zum Beispiel keine ausreichenden Hardware-Ressourcen im Transaktionscache gibt), wird ein Abbruchtransaktionsbefehl initiiert und der Zustand auf „Abbrechen" gestellt und die Transaktion abgebrochen (Block 420). Somit ist der Prozeß abgebrochen (Block 422).

Wenn die Transaktion abgebrochen ist, wird ein Überhangtransaktionsausnahmebefehl 424 generiert. Das kann aufgrund einer konfliktverursachenden transaktionalen Lese-/Schreiboperation oder aufgrund von unzureichenden Hardware-Ressourcen erfolgen. In beiden Fällen wird der Transaktionsspeicher gelöscht und die Transaktion erneut versucht (Block 426). Typischerweise wählt der Policy-Manager, falls das Scheitern im Hardware-Modus auftrat, für den nächsten Versuch den Software-Modus aus.

Die Festschreibungs- und Abbruchbefehle werden nun kurz ausführlicher erörtert. Insbesondere ist, wie bereits erörtert, der Transaktionsspeicher unter Verwendung eines Transaktionscache implementierbar. So kann zum Beispiel, wie in 1 gezeigt wird, der Prozessor 101 einen Transaktionscache 132 und einen regulären Cache 134 umfassen. Alle Plätze, die bzw. in die unter Verwendung von Lade- und Speicherungstransaktionen 308 von der Hardware-/Software-Transaktions-ISA 300 gelesen werden bzw. geschrieben wird, werden im Transaktionscache gespeichert. Alle Transaktionsschreibdaten bleiben im Transaktionscache, bis die Transaktion festschreibt. Falls in einen Platz im Transaktionscache, der durch die Transaktion gelesen wurde, durch einen anderen Thread geschrieben wird, wird die Transaktion zum Überhang und schließlich abgebrochen.

Ein Festschreibungstransaktionsbefehl 304 markiert das Ende der Transaktion und ermöglicht, daß der gesamte Inhalt des Transaktionscache architektonisch wird. (So wird zum Beispiel zugelassen, daß Transaktionsspeicherungen den Systemzustand modifizieren, und Transaktionslasten werden aus dem Transaktionscache gelöscht.)

Eine Transaktion ist als Überhang definiert, falls sie nicht festschreiben kann. Eine Transaktion kann zum Beispiel zum Überhang werden, falls ein anderer Thread in einen Platz geschrieben hat, den er gelesen hat. Eine Überhangtransaktion kann den Speicher in einem inkonsistenten Zustand sehen und verursachen, daß der Prozessor eine Ausnahme verursacht, wie zum Beispiel Teilen durch Null oder Zugreifen auf einen Speicherplatz, der außerhalb des Bereichs liegt. Sie könnte vielleicht, was noch schlimmer wäre, falsche Werte in gültige Speicherplätze schreiben und den Systemzustand korrumpieren. Daher wird, wenn dies eintritt, ein Überhangtransaktionsausnahmebefehl 314 initiiert und die Aktion abgebrochen 422.

Somit gestatten der Prozeß 400 und die Hardware-/Software-Transaktions-ISA 300 die asynchrone Verwendung von Ausnahmen, um einem Thread mitzuteilen, daß die Transaktion, die er gerade ausführt, zum Überhang geworden ist. Sobald eine Transaktion zum Überhang geworden ist, wird der Thread abgebrochen, und der Thread darf keine Daten verbrauchen, die von neuen Ladeoperationen aus dem Speicher zurückgesendet werden.

Um das zu erreichen, wird bei jedem Laden eine spezielle Ausnahme verwendet. Insbesondere erzwingt das erste Laden, nachdem ein Thread zum Überhang geworden ist, eine Ausnahme des Ladens, und der Thread wird abgebrochen. Ein Exceptionhandler ist dann für das Zurückspringen zum Beginn der Transaktion verantwortlich, was, wie bereits erörtert, als Säuberungs- und Neuversuchsblock 426 erreichbar ist. Somit ist ein Benutzer-Exceptionhandler, der mit dem Abbruchtransaktionsbefehl 306 implementiert wird, für den Abbruch der Transaktion und das Abspulen des Stapels und den Neustart der abgebrochenen Transaktion unter Verwendung einer Säuberung und eines Neuversuchs 426 verantwortlich.

Im folgenden wird kurz auf 4B Bezug genommen. 4B ist ein Ablaufdiagramm, das insbesondere einen Prozeß 448 zur Überwachung hinsichtlich Überhangtransaktionen veranschaulicht. In Block 450 wird nach einer Ladetransaktion ein Statusflag auf „Transaktion gültig" gestellt. Als nächstes überwacht der Prozeß 448, ob von einem anderen Prozessor oder Thread ein Konflikt ausgeht (Block 452). Falls in Block 454 kein Konflikt erfaßt wird, wird die Verarbeitung fortgesetzt (Block 456). Falls jedoch in Block 454 ein Konflikt erfaßt wird, wird das Statusflag auf „Transaktion ungültig" zurückgesetzt, um zu markieren, daß die Transaktion abgebrochen wurde (Block 460). Alle Ladevorgänge, die der ersten Ladetransaktion nachfolgen, überprüfen das Statusflag, um zu verifizieren, daß es auf „Transaktion gültig" gestellt ist vor einem Festschreiben (zum Beispiel Zurücksenden von Daten an den Prozessor). Andererseits wird, falls das Statusflag rückgesetzt ist, kein Festschreiben der Ladetransaktion zugelassen, und der bereits erörterte Abbruchprozeß erfolgt.

Kehren wir nun zu 4A zurück. Unter der Annahme, daß eine Hardware-Transaktion aufgrund einer konfliktverursachenden Transaktions-Lese-/Schreiboperation oder aufgrund der Erschöpfung der Hardware-Ressourcen abgebrochen worden ist, kann der Policy-Manager in Block 404 den „Software-Modus" auswählen, um die Erfüllung der Transaktion zu gewährleisten. In Block 430 wird vom Hardware-/Software-Transaktions-ISA 300 ein Befehl „Begin Transaction Select" 302 initiiert, so daß der Modus auf „Software" gestellt und der Transaktionszustand geladen wird. Es sollte beachtet werden, daß der Prozessor, wenn er im Software-Modus läuft, nicht alle Speicherzugriffe als transaktional behandelt. Für jede Transaktion wird nur auf einen Platz auf transaktionale Weise zugegriffen (zum Beispiel unter Verwendung der Ladetransaktionsbefehle 308), nämlich auf den Platz, der den Zustand der Transaktion enthält.

Als nächstes werden in Block 432 Lese-/Schreiboperationen für die Transaktion durchgeführt, indem reguläre Lese-/Schreiboperationen kopiert und verwendet werden (zum Beispiel reguläre Lade-/Speicherungsbefehle 310). Außerdem werden der reguläre Cache und andere Speicherressourcen anstelle des Transaktionscache werwendet. Falls die Lese-/Schreiboperationen für die Transaktion durchführbar sind, wird ein Festschreibungstransaktionsbefehl 304 initiiert und der Zustand auf „Festschreiben" gestellt (Block 434). Somit werden die Lese-/Schreiboperationen in einen Speicher festgeschrieben (Block 415).

Falls andererseits eine konfliktverursachende transaktionale Schreiboperation erfaßt wird, kann der Prozeß abgebrochen und der Zustand auf „Abbrechen" gesetzt werden (Block 436). Somit wird die Transaktion in Block 422 abgebrochen, und auf der Grundlage der Ausnahme einer konfliktverursachenden Schreibtransaktion 438 kann der Prozeß 400 im Software-Modus die Transaktionsoperation löschen und im Software-Modus erneut versuchen (Block 440).

In einer anderen Ausführungsform der Erfindung ist die bereits erörterte Hardware-/Software-Transaktions-ISA 300 zum wirksamen Implementieren von Verriegelungen verwendbar. Wenn, kurz gesagt, eine Verriegelungserlangungsfunktion aufgerufen wird, versucht der Prozessor, den kritischen Abschnitt (zum Beispiel der Code zwischen dem Erlangen der Verriegelung und dem späteren Aufheben der Verriegelung) im Hardware-Modus unter Verwendung von Transaktionsspeichererweiterungen auszuführen. Falls das scheitert, kehrt der Prozeß in den Software-Modus zurück.

Es gibt drei potentielle Gründe dafür, warum die Erfüllung eines kritischen Abschnitts im Hardware-Modus scheitern kann. Es kann zum Beispiel eine Ressourcenerschöpfung auftreten, bei der der für die Aufrechterhaltung des Transaktionszustands verwendete Transaktionscache überläuft. Es kann auch zu einer Kollision von Daten kommen. Falls zum Beispiel zwei Threads versuchen, ihren kritischen Abschnitt im Hardware-Modus auszuführen und miteinander im Konflikt stehende Operationen an denselben Daten durchzuführen, kann auch das ein Scheitern verursachen. So kann zum Beispiel ein Thread in eine Cachezeile schreiben, die der andere Thread bereits gelesen hat. Auch kann der Übergang in den Software-Modus scheitern. Falls zum Beispiel ein Thread eine Verriegelung im Software-Modus ergreift, werden alle anderen Threads, die sich mitten im kritischen Abschnitt befanden, die diese Verriegelung benötigen, abgebrochen.

Es sollte beachtet werden, daß sich bei jeder Verriegelung mehrere Threads im Hardware-Modus im kritischen Abschnitt befinden können oder ein einzelner Thread die Verriegelung im Software-Modus halten kann. Um im Hardware-Modus in der kritischen Abschnitt einer Verriegelung einzutreten, vergewissert sich ein Thread, daß eine Verriegelung verfügbar ist und tritt in den kritischen Abschnitt ein, ohne diesen als verriegelt zu markieren. Um in einem Software-Modus in den kritischen Abschnitt einer Verriegelung einzutreten, vergewissert sich ein Thread, daß eine Verriegelung verfügbar ist und markiert diese als verriegelt. Dadurch werden alle Threads abgebrochen, die sich im Hardware-Modus bereits im kritischen Abschnitt befinden, und alle neuen Threads entweder im Hardware- oder im Software-Modus werden am Eintreten in den kritischen Abschnitt gehindert.

Betrachten wir nun 5. 5 ist ein Ablaufdiagramm, das einen Prozeß 500 zum wirksamen Implementieren von Verriegelungen unter Verwendung der Hardware-/Software-Transaktions-ISA 300 gemäß einer Ausführungsform der Erfindung veranschaulicht. In Block 502 wird eine Verriegelung erlangt oder initiiert. In Block 504 wählt der Policy-Manager einen Modus aus. Typischerweise wird, wie bereits erörtert, zuerst der Hardware-Modus ausgewählt, um zu versuchen, die Transaktionsspeichertransaktionen möglichst wirksam auszuführen. Dann wird in den Software-Modus zurückgekehrt, falls der Hardware-Modus die Transaktion nicht erfüllen kann.

Als nächstes wird in Block 506 die Verriegelung begonnnen und der Modus durch den Befehl „Begin Transaction All" 302 der Transaktions-ISA 300 auf „Hardware" gestellt. In Block 508 werden die Lese-/Schreiboperationen für die Transaktion (zum Beispiel im Transaktionscache) unter Verwendung von transaktionalen Lese-/Schreiboperationen (zum Beispiel Lade-/Speicherungstransaktionen 308) durchgeführt. Falls die Transaktion erfüllt wird, wird die Verriegelung aufgehoben (Block 510) und die Transaktion ausgeführt.

Falls jedoch aufgrund einer konfliktverursachenden transaktionalen Lese-/Schreiboperation 520 eine Ausnahme auftritt, wird die Verriegelung abgebrochen. Dann wird eine Säuberungs- und Neuversuchsoperation (Block 522) initiiert und die Verriegelung im Software-Modus versucht. Somit wählt ein Policy-Manager in Block 504 den Software-Modus aus.

In diesem Fall wird die Verriegelung im Software-Modus begonnen und der Zustand der Verriegelung auf „Verriegelt" gestellt (Block 530). Als nächstes (Block 532) werden die Lese-/Schreiboperationen unter Verwendung von regulären Lese-/Schreiboperationen (zum Beispiel reguläre Lade-/Speicherungsbefehle 310) durchgeführt. Im Software-Modus wird die Verriegelung typischerweise immer abgeschlossen und die Verriegelung wird dann aufgehoben und der Verriegelungszustand auf „Endriegeln" gestellt (Block 534). Dadurch wird der Prozeß 500 beendet.

Zur Erzielung weiterer Leistungsvorteile kann der Prozessor eine Konfliktlösung durchführen. Insbesondere kann der Prozessor, wenn ein Datenkonflikt erfaßt wird, den Konflikt lösen und die Erfüllung einer der Transaktionen zulassen. Die verbleibenden konfliktverursachenden Transaktionen sind in Abhängigkeit davon aufschieb- oder abbrechbar, ob in irgendeinen der Speicherplätze, den sie gelesen haben, durch einen anderen Thread geschrieben worden ist. Außerdem kann, wenn eine Ausnahme 520 (zum Beispiel eine Überhangtransaktionsausnahme) aufgetreten ist (wie bereits erörtert), eine Aufzeichnung dahingehend erfolgen, ob die Transaktion aufgrund einer Ressourcenerschöpfung oder aufgrund eines Datenkonflikts zum Überhang geworden ist. Ein Exceptionhandler kann dann so modifiziert werden, daß er nur im Falle der Erschöpfung der Ressource in den Software-Modus zurückfällt. Wenn nur ein Datenkonflikt aufgetreten ist, kann eine Modifizierung implementiert werden, bei der die Transaktion erneut im Hardware-Modus versucht wird, anstatt automatisch in den Software-Modus umzuschalten.

Während Ausführungsformen der vorliegenden Erfindung und ihre verschiedenen Funktionselemente in besonderen Ausführungsformen beschrieben wurden, sollte verständlich sein, daß die Ausführungsformen der vorliegenden Erfindung in Hardware, Software, Firmware, Middleware oder als eine Kombination daraus implementierbar und in Systemen, Teilsystemen, Komponenten oder Teilkomponenten davon verwendbar sind. Wenn sie in Software oder Firmware implementiert sind, sind die Elemente der vorliegenden Erfindung die Befehle/Codesegmente zur Ausführung der notwendigen Aufgaben. Die Programm- oder Codesegmente können auf einem maschinenlesbaren Datenträger (zum Beispiel ein prozessorlesbares Medium oder ein Computerprogrammprodukt) gespeichert werden oder durch ein Rechnerdatensignal in Form einer Trägerwelle oder ein durch einen Träger moduliertes Signal über ein Übertragungsmedium oder eine Kommunikationsverbindung übertragen werden. Der maschinenlesbare Datenträger kann jedes Medium umfassen, das Informationen in einer Form speichern oder übertragen kann, die durch eine Maschine (zum Beispiel ein Prozessor, ein Rechner usw.) lesbar und ausführbar ist. Beispiele für das maschinenlesbare Medium umfassen eine elektronische Schaltung, eine Halbleiterspeichervorrichtung, ein ROM, einen Flash-Speicher, ein löschbares programmierbares ROM (EPROM), eine Diskette, eine Kompaktbildplatte CD-ROM, eine optische Platte, eine Festplatte, ein faseroptisches Medium, eine Hochfrequenzverbindung (HF-Verbindung) usw. Das Rechnerdatensignal kann jedes Signal umfassen, das sich über ein Übertragungsmedium (zum Beispiel elektronische Netzwerkkanäle, Glasfasern, Luft, elektromagnetische Medien, HF-Verbindungen, Strichcodes usw.) ausbreiten kann. Die Codesegmente sind über Netzwerke (zum Beispiel Internet, Intranet usw.) herunterladbar.

Es sind Ausführungsformen der Erfindung unter Bezugnahme auf veranschaulichende Ausführungsformen beschrieben worden, wobei diese Beschreibungen nicht als einschränkend aufgefaßt werden sollen. Verschiedene Modifizierungen der veranschaulichenden Ausführungsformen sowie andere Ausführungsformen der Erfindung, die für Fachleute auf dem Gebiet, auf das sich Ausführungsformen der Erfindung beziehen, erkennbar sind, werden als innerhalb des Geistes und des Umfangs der Erfindung liegend betrachtet.

Zusammenfassung

Ausführungsformen der Erfindung betreffen eine hybride Hardware-/Software-Implementierung von Transaktionsspeicherzugriffen in einem Rechnersystem. Ein Prozessor, der einen Transaktionscache und einen regulären Cache umfaßt, wird in einem Rechnersystem verwendet, das einen Policy-Manager umfaßt, um entweder einen ersten Modus (ein Hardware-Modus) oder einen zweiten Modus (ein Software-Modus) auszuwählen, um Transaktionsspeicherzugriffe zu implementieren. Im Hardware-Modus wird der Transaktionscache zum Durchführen von Lese-/Schreib-Speicheroperationen verwendet, und im Software-Modus wird der reguläre Cache zum Durchführen von Lese-/Schreib-Speicheroperationen verwendet.


Anspruch[de]
Vorrichtung, umfassend:

einen Prozessor, umfassend einen Transaktionscache und einen regulären Cache, und

einen Policy-Manager zum Auswählen entweder eines ersten Modus oder eines zweiten Modus zum Implementieren von Transaktionsspeicherzugriffen,

wobei im ersten Modus der Transaktionscache zum Durchführen von Lese-/Schreib-Speicheroperationen verwendet wird und im zweiten Modus der reguläre Cache zum Durchführen von Lese-/Schreib-Speicheroperationen verwendet wird.
Vorrichtung nach Anspruch 1, wobei der Policy-Manager den ersten Modus auswählt, um Lese-/Schreiboperationen unter Verwendung von transaktionalen Lese-/Schreibbefehlen im Transaktionscache durchzuführen. Vorrichtung nach Anspruch 2, wobei, falls im Transaktionscache Speicherressourcen vorhanden sind, die für die Durchführung der Lese-/Schreiboperationen ausreichen, ein Festschreibungsbefehl ausgegeben wird, um den Transaktionsspeicherzugriff zu erfüllen. Vorrichtung nach Anspruch 2, wobei, falls miteinander im Konflikt stehende transaktionale Lese-/Schreiboperationen erfaßt werden, ein Abbruchbefehl ausgegeben wird. Vorrichtung nach Anspruch 2, wobei, falls im Transaktionscache unzureichende Speicherressourcen erfaßt werden, ein Abbruchbefehl ausgegeben wird. Vorrichtung nach Anspruch 5, wobei, falls ein Abbruchbefehl für den ersten Modus ausgegeben wird, der Policy-Manager den zweiten Modus auswählt, in dem reguläre Lese-/Schreiboperationen unter Verwendung von regulären Lese-/Schreibbefehlen im regulären Cache durchgeführt werden. Vorrichtung nach Anspruch 6, wobei beim Betrieb im zweiten Modus ein Abbruchbefehl ausgegeben wird, falls eine konfliktverursachende Schreibtransaktion erfaßt wird. Vorrichtung nach Anspruch 6, wobei, falls keine konfliktverursachende Schreibtransaktion erfaßt wird, ein Festschreibungsbefehl ausgegeben wird, um den Speicher zugriff zu erfüllen. Verfahren, umfassend:

Auswählen entweder eines ersten Modus oder eines zweiten Modus zum Implementieren von Transaktionsspeicherzugriffen,

Durchführen von Lese-/Schreib-Speicheroperationen im ersten Modus unter Verwendung eines Transaktionscache, und

Durchführen von Lese-/Schreib-Speicheroperationen im zweiten Modus unter Verwendung eines regulären Cache.
Verfahren nach Anspruch 9, außerdem umfassend:

Auswählen des ersten Modus, und

Durchführen von Lese-/Schreiboperationen im Transaktionscache unter Verwendung von transaktionalen Lese-/Schreibbefehlen.
Verfahren nach Anspruch 10, dadurch wobei es, falls im Transaktionscache Speicherressourcen vorhanden sind, die für die Durchführung der Lese-/Schreiboperationen ausreichen, außerdem das Ausgeben eines Festschreibungsbefehls zum Erfüllen des Transaktionsspeicherzugriffs umfaßt. Verfahren nach Anspruch 10, wobei es, falls miteinander im Konflikt stehende transaktionale Lese-/Schreiboperationen erfaßt werden, außerdem das Ausgeben eines Abbruchbefehls umfaßt. Verfahren nach Anspruch 10, wobei es, falls im Transaktionscache unzureichende Speicherressourcen erfaßt werden, außerdem das Ausgeben eines Abbruchbefehls umfaßt. Verfahren nach Anspruch 13, wobei es, falls ein Abbruchbefehl im ersten Modus ausgegeben wird, außerdem umfaßt:

Auswählen des zweiten Modus, und

Durchführen von regulären Lese-/Schreiboperationen im regulären Cache unter Verwendung von regulären Lese-/Schreibbefehlen.
Verfahren nach Anspruch 14, wobei es während des Betriebs im zweiten Modus außerdem das Ausgeben eines Abbruchbefehls umfaßt, falls eine konfliktverursachende Schreibtransaktion erfaßt wird. Verfahren nach Anspruch 14, wobei es, falls keine konfliktverursachende Schreibtransaktion erfaßt wird, außerdem das Ausgeben eines Festschreibungsbefehls umfaßt, um den Speicherzugriff zu erfüllen. Maschinenlesbares Medium, auf dem Befehle gespeichert sind, die, wenn sie durch eine Maschine ausgeführt werden, die Maschine zum Durchführen der folgenden Operationen veranlassen, umfassend:

Auswählen entweder eines ersten Modus oder eines zweiten Modus zum Implementieren von Transaktionsspeicherzugriffen,

Durchführen von Lese-/Schreib-Speicheroperationen im ersten Modus unter Verwendung eines Transaktionscache, und

Durchführen von Lese-/Schreib-Speicheroperationen im zweiten Modus unter Verwendung eines regulären Cache.
Maschinenlesbares Medium nach Anspruch 17, außerdem umfassend Befehle, die die Maschine zum Durchführen der folgenden Operationen veranlassen:

Implementieren des ersten Modus, und

Durchführen von Lese-/Schreiboperationen im Transaktionscache unter Verwendung von transaktionalen Lese-/Schreibbefehlen.
Maschinenlesbares Medium nach Anspruch 18, außerdem umfassend Befehle, die die Maschine zum Durchführen der Operation des Ausgebens eines Festschreibungsbefehls zum Erfüllen des Transaktionsspeicherzugriffs veranlassen, falls im Transaktionscache Speicherressourcen vorhanden sind, die für die Durchführung der Lese-/Schreiboperationen ausreichen. Maschinenlesbares Medium nach Anspruch 18, außerdem umfassend Befehle, die die Maschine zum Durchführen der Operation des Ausgebens eines Abbruchbefehls veranlassen, falls miteinander im Konflikt stehende transaktionale Lese-/Schreiboperationen erfaßt werden. Maschinenlesbares Medium nach Anspruch 18, außerdem umfassend Befehle, die die Maschine zum Durchführen der Operation des Ausgebens eines Abbruchbefehls veranlassen, falls im Transaktionscache unzureichende Speicherressourcen erfaßt werden. Maschinenlesbares Medium nach Anspruch 21, wobei es, falls ein Abbruchbefehl im ersten Modus ausgegeben wird, außerdem Befehle umfaßt, die die Maschine zum Durchführen der folgenden Operationen veranlassen:

Auswählen des zweiten Modus, und

Durchführen von regulären Lese-/Schreiboperationen im regulären Cache unter Verwendung von regulären Lese-/Schreibbefehlen.
Maschinenlesbares Medium nach Anspruch 22, das während des Betriebs im zweiten Modus außerdem Befehle umfaßt, die die Maschine zum Durchführen der Operation des Ausgebens eines Abbruchbefehls veranlassen, falls eine konfliktverursachende Schreibtransaktion erfaßt wird. Maschinenlesbares Medium nach Anspruch 22, außerdem umfassend Befehle, die die Maschine zum Durchführen der Operation des Ausgebens eines Festschreibungsbefehls zum Erfüllen des Speicherzugriffs veranlassen, falls keine konfliktverursachende Schreibtransaktion entdeckt wird. Rechnersystem, umfassend:

einen Prozessor, umfassend einen Transaktionscache und einen regulären Cache, und

einen Policy-Manager zum Auswählen entweder eines ersten Modus oder eines zweiten Modus zum Implementieren von Transaktionsspeicherzugriffen, die auf eine Anforderung eines Speicherzugriffs in einer Datenbank einer Anwendungsprogrammschnittstelle (API) ansprechen,

wobei im ersten Modus der Transaktionscache zum Durchführen von Lese-/Schreib-Speicheroperationen verwendet wird und im zweiten Modus der reguläre Cache zum Durchführen von Lese-/Schreib-Speicheroperationen verwendet wird.
Rechnersystem nach Anspruch 25, wobei der Policy-Manager den ersten Modus auswählt, um Lese-/Schreiboperationen unter Verwendung von transaktionalen Lese-/Schreibbefehlen im Transaktionscache durchzuführen. Rechnersystem nach Anspruch 26, wobei, falls im Transaktionscache Speicherressourcen vorhanden sind, die für die Durchführung der Lese-/Schreiboperationen ausreichen, ein Festschreibungsbefehl ausgegeben wird, um den Transaktionsspeicherzugriff zu erfüllen. Rechnersystem nach Anspruch 26, wobei, falls einen Konflikt verursachende transaktionale Lese-/Schreiboperationen erfaßt werden, ein Abbruchbefehl ausgegeben wird. Rechnersystem nach Anspruch 26, wobei, falls im Transaktionscache unzureichende Speicherressourcen erfaßt werden, ein Abbruchbefehl ausgegeben wird. Rechnersystem nach Anspruch 29, wobei, falls ein Abbruchbefehl für den ersten Modus ausgegeben wird, der Policy-Manager den zweiten Modus auswählt, in dem reguläre Lese-/Schreiboperationen unter Verwendung von regulären Lese-/Schreibbefehlen im regulären Cache durchgeführt werden. Rechnersystem nach Anspruch 30, wobei beim Betrieb im zweiten Modus ein Abbruchbefehl ausgegeben wird, falls eine konfliktverursachende Schreibtransaktion erfaßt wird. Rechnersystem nach Anspruch 30, wobei, falls keine konfliktverursachende Schreibtransaktion erfaßt wird, ein Festschreibungsbefehl ausgegeben wird, um den Speicherzugriff zu erfüllen.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com