DE112010005821T5

DE112010005821T5 - Kontextwechsel

Info

Publication number: DE112010005821T5
Application number: DE112010005821T
Authority: DE
Inventors: James Barwick
Original assignee: Empire Technology Development LLC
Current assignee: Empire Technology Development LLC
Priority date: 2010-08-23
Filing date: 2010-08-23
Publication date: 2013-06-06
Also published as: US20120047516A1; US9658877B2; TWI537831B; WO2012026877A1; TW201214289A; KR101480856B1; KR20130063003A; JP2013536524A; JP5636109B2

Abstract

Die Offenlegung betrifft generell Techniken, Verfahren und Einrichtungen zum Steuern eines Kontextwechsels in einer zentralen Verarbeitungseinheit. Alternativ werden Verfahren und Einrichtungen zum Bieten einer Sicherheit für Speicherblöcke bereitgestellt. Alternativ werden Verfahren und Einrichtungen bereitgestellt, die eine Transaktionsverarbeitung unter Verwendung einer Mehrkernvorrichtung ermöglichen.

Description

Hintergrund
Aufgrund von Einschränkungen dahin gehend, wie schnell eine zentrale Verarbeitungseinheit (Central Processing Unit CPU) getaktet werden kann, und Einschränkungen dahin gehend, wie klein und schnell Schaltungen und Transistoren ausgeführt werden können, hat sich die Industrie Prozessoptimierungen und parallelem Rechnen zugewandt, um die Leistung von Rechnerplattformen zu erhöhen. Dadurch wurden die Konzepte von Mehrkern- und Vielkernprozessoren eingeführt.
Es werden Mehrkernprozessoren sowohl bei homogenen als auch heterogenen Modellen entwickelt. Ein grundlegendes Problem bei Mehrkern- und Vielkernprozessoren ist die Frage der Skalierbarkeit des Betriebssystems. Betriebssysteme müssen heutzutage die Anzahl von zur Verfügung stehenden CPU-Kernen beobachten und Prozesse und Threads in jedem dieser Kerne einplanen. Dies ist ein zeitaufwendiger Vorgang für Betriebssysteme, da das Betriebssystem Prozesse durch Speichern eines Status und Laden eines neuen Status und Kontextes in die CPU ein- bzw. auslagern muss, bevor das Betriebssystem der CPU eine Anweisung zum Ausführen eines Prozesses erteilt.
Übersicht
Bei einigen Ausführungsformen umfasst ein Prozessor mehrere Kerne auf einem einzelnen Chip zum Ausführen mehrerer Anweisungen; und einen Kontextwechsel-Controller auf dem einzelnen Chip zum Steuern der Ausführung von Anweisungen in jedem der mehreren Kerne.
Bei einigen Ausführungsformen umfasst ein Verfahren zum Durchführen eines Prozesswechsels das Empfangen eines Befehls, der eine Prozess-ID zum Identifizieren eines Prozesses enthält, zum Ausführen in einem Kontext-Controller in einer zentralen Verarbeitungseinheit; Zugreifen auf den Prozess auf der Basis der Prozess-ID in einem Speicher in der zentralen Verarbeitungseinheit; und Einplanen des Prozesses, auf den zugegriffen wird, zum Ausführen in einem der mehreren Kerne in der zentralen Verarbeitungseinheit.
Bei einigen Ausführungsformen umfasst ein Verfahren zum Sichern eines Speicherblocks das Identifizieren eines Speicherblocks, auf den zugegriffen wird; Erzeugen einer Zugriffsmaske für den Speicherblock; und Markieren des Speicherblocks mit einer Prozessidentifizierungsinformation und der erzeugten Maske.
Bei einigen Ausführungsformen umfasst eine Einrichtung zum Ermöglichen einer Transaktionsverarbeitung unter Verwendung einer Mehrkernvorrichtung (multi core device) eine zentrale Verarbeitungseinheit (CPU) mit mehreren Kernen; einen Speicherbus-Controller, der über einen prozessorseitigen Bus mit der CPU gekoppelt ist; einen Hauptspeicherkern, der über einen ersten speicherseitigen Bus mit dem Speicherbus-Controller gekoppelt ist; und einen Transaktionsspeicherkern, der über einen zweiten speicherseitigen Bus mit dem Speicherbus-Controller gekoppelt ist, wobei die CPU den Datenstrom über einen Speicherbus leitet, der von dem Speicher-Controller auf der Basis des Werts eines für den Speicherbus-Controller vorgesehenen Wechsels als der erste und/oder zweite speicherseitige Bus ausgewählt worden ist.
Das Vorstehende ist eine Übersicht und enthält somit notwendigerweise Vereinfachungen, Verallgemeinerungen und Auslassungen von Details; folglich erkennen Kenner der Technik, dass die Übersicht nur der Erläuterung dient und nicht als Einschränkung angesehen werden darf. Weitere Aspekte, Merkmale und Vorteile der Vorrichtungen und/oder Prozesse und/oder anderer hier beschriebener Gegenstände werden anhand der hier dargelegten Lehren offensichtlich. Die Übersicht dient zum Vorstellen einer Auswahl von Konzepten in einer vereinfachten Form, die nachstehend in der detaillierten Beschreibung näher erläutert werden. Diese Übersicht dient nicht dem Aufzeigen von Schlüsselmerkmalen oder wesentlichen Merkmalen des beanspruchten Gegenstands, noch dient sie der Verwendung als Hilfe zum Festlegen des Schutzumfangs des beanspruchten Gegenstands.
Kurze Beschreibung der Zeichnungen
Die oben beschriebenen und weitere Merkmale der vorliegenden Offenlegung werden anhand der folgenden Beschreibung und der beiliegenden Patentansprüche in Zusammenhang mit den beiliegenden Zeichnungen offensichtlich. Unter der Maßgabe, dass diese Zeichnungen nur verschiedene Ausführungsformen gemäß der Offenlegung zeigen und daher nicht als ihren Schutzumfang einschränkend angesehen werden dürfen, wird die Beschreibung der Offenlegung durch Verwendung der beiliegenden Zeichnungen zusätzlich präzisiert und detailliert.
1 ist ein Beispiel für eine Ausgestaltung einer zentralen Verarbeitungseinheit nach einigen Ausführungsformen der vorliegenden Offenlegung;
2 zeigt ein Beispiel für ein Ablaufdiagramm eines Verfahrens zum Einplanen eines Prozesses nach einigen Ausführungsformen der vorliegenden Offenlegung;
3 zeigt ein Beispiel für eine Ausgestaltung einer CPU und eines Speichers nach einigen Ausführungsformen der vorliegenden Offenlegung;
4 zeigt ein Beispiel für ein Ablaufdiagramm eines Verfahrens zum Markieren eines Speicherblocks nach einigen Ausführungsformen der vorliegenden Offenlegung;
5 zeigt ein Beispiel für eine Hardware-Ausgestaltung nach einigen Ausführungsformen der vorliegenden Offenlegung; und
6 zeigt ein Beispiel für ein Logikdiagramm nach einigen Ausführungsformen der vorliegenden Offenlegung.
Detaillierte Beschreibung
In der folgenden detaillierten Beschreibung wird auf die beiliegenden Zeichnungen Bezug genommen, die Teil derselben bilden. In den Zeichnungen bezeichnen gleichartige Symbole typischerweise gleichartige Komponenten, sofern sich aus dem Zusammenhang nichts anderes ergibt. Die erläuternden Ausführungsformen, die in der detaillierten Beschreibung, den Zeichnungen und den Patentansprüchen dargelegt sind, dürfen nicht als Einschränkung angesehen werden. Es können weitere Ausführungsformen verwendet werden und andere Veränderungen vorgenommen werden, ohne dass dadurch vom Geist oder Schutzumfang des hier dargestellten Gegenstands abgewichen wird. Es ist offensichtlich, dass die Aspekte der vorliegenden Offenlegung, wie sie hier generell beschrieben und in den Figuren gezeigt sind, in einer großen Vielzahl von unterschiedlichen Ausgestaltungen angeordnet, ersetzt, kombiniert und ausgelegt werden können, wobei all dies ausdrücklich vorgesehen und Teil dieser Offenlegung ist.
Diese Offenlegung betrifft unter anderem Verfahren, Einrichtungen, Computerprogramme und Systeme, die mit einer Prozessverwaltungskomponente in Beziehung stehen, welche dazu ausgestaltet ist, die Zeit zu eliminieren oder zu verringern, die benötigt wird, um von einem Prozess zu einem anderen zu wechseln, wodurch eine Parallelität verbessert wird. Die Prozessverwaltungskomponente kann als eine Hardware-Ebene-Komponente implementiert sein, die einen Kontextwechsel durchführt. Ein Kontext kann ein Speicherstatus sein, der in Zusammenhang steht mit einem Prozess, einschließlich, jedoch nicht beschränkt auf, CPU-Register für Datensegmente, Stapelsegmente, erweiterte Segmente, Codesegmente, immediate Register oder andere relevante CPU-Register, die in der CPU enthalten sind, oder Register, die in einem E/A-Controller enthalten sind. Die Hardware-Komponente, z. B. der Kontext-Controller, kann in der CPU ausgebildet sein. Die CPU, die auf einem einzelnen Chip (oder einem Mehrfachchip in einem CPU-Substrat. Es sei darauf hingewiesen, dass in dieser Offenlegung der Ausdruck ”Chip” oder ”einzelner Chip” nicht im wörtlichen Sinne eine einzeln hergestellte Schaltung bedeutet. Er dient zum Beschreiben eines CPU-Pakets im weitesten Sinne, das eine oder mehrere diskrete Verarbeitungsschaltungen oder -kerne enthalten kann. Der Ausdruck ”Substrat”, der ebenfalls im weitesten Sinne ein CPU-Paket beschreibt, das mehrere Verarbeitungseinheiten enthält, kann in dieser Offenlegung den Ausdruck ”Chip” oder ”einzelner Chip” ersetzen) ausgebildet ist, kann einen Kontext-Controller oder eine Vielzahl von Verarbeitungskernen aufweisen. Somit braucht der Kontext-Controller nicht auf einen Speicherbandbreiten-Zugriff zu warten und braucht nicht darauf zu warten, dass ein eigentlicher CPU-Kern zur Verfügung steht, um auf in einem Primärspeicher gespeicherte Daten bezüglich des Status des auszuführenden Kontextes zuzugreifen und diese abzurufen. Ein Kontext kann von dem Kontext-Controller in der CPU in einen Ausführungsstatus eingelagert oder aus diesem ausgelagert werden, ohne dass bezüglich Kontextdaten auf den Primärspeicher zugegriffen werden muss. Der Kontext-Controller besitzt die Information, die erforderlich ist, um einen Kontextwechsel in einem lokalen Cachespeicher auf dem CPU-Chip durchzuführen.
Diese Offenlegung betrifft ferner unter anderem Techniken, mit denen ermöglicht wird, dass eine Prozess-ID für die Hardware sichtbar wird, wobei Speicherblöcke mit einer Markierung, die die Prozess-IDs enthält, innerhalb der Abbildstrukturen eines virtuellen Speichers ausgebildet sind, wodurch ein Maß an Sicherheit erzeugt wird.
Diese Offenlegung betrifft ferner unter anderem das Bereitstellen einer Ausgestaltung, die zwei Speicherkerne aufweist, wodurch ein redundanter Speicher für den Fall z. B. eines Ausfalls eines Transaktionsprozesses zur Verfügung gestellt wird.
Kernarchitektur
1 zeigt ein Beispiel für eine grafische Darstellung einer CPU und eines Primärspeichers, die den Prinzipien einiger Ausführungsformen der vorliegenden Offenlegung entsprechen. Wie in 1 zu sehen ist, weist eine CPU 102 einen Kontext-Controller 104, Kerne 0–8 106, einen Kontext-Cachespeicher/Bus 108 und L1- und L2-Caches 110 und einen L3-Cache 111 auf. Es sei darauf hingewiesen, dass zwar nur Kerne 0–8 gezeigt sind, jedoch weitere Kerne in der CPU 102 ausgebildet sein können. Jeder der Kerne 0–8 106 ist mit seinem jeweiligen L1- und L2-Cache 110 gekoppelt. Jeder der L2-Caches 110 ist mit dem L3-Cache 111 gekoppelt. Der L3-Cache 111 ist auf kommunizierfähige Weise mit einem Primärspeicher 120 verbunden. Die CPU 102 kann auf einem einzelnen Chip, z. B. einer einzelnen integrierten Schaltung, implementiert sein.
Jeder der Kerne 0–8 106 ist auf kommunizierfähige Weise mit dem Kontext-Controller 104 verbunden und ist jeweils unabhängig zum Ausführen von Prozessen oder Anweisungen entsprechend einer bestimmten Anweisungssatzarchitektur auf Befehl des Kontext-Controllers 104 ausgebildet.
Der Kontext-Controller 104 ist innerhalb der gesamten Chipstruktur der CPU 102 ausgebildet. Der Kontext-Controller 104 ist dazu ausgebildet, auf Ausführungsanweisung des Betriebssystems Kontextdetails aus dem Primärspeicher 120 zu empfangen, z. B. herauszuziehen, wenn der Prozesskontext im lokalen Cache nicht zur Verfügung steht, und die CPU 120 weist einen Speicherblock zum Speichern einer Information bezüglich der laufenden Prozesse auf.
Der Kontext-Cachespeicher/Bus 108 ermöglicht es dem Kontext-Controller 104, direkt mit jedem Kern 106 zu interagieren und dadurch einen Prozess in jeden Kern und aus jedem Kern zu bewegen. Der Cachespeicher speichert Kontext für Prozesse, einschließlich Prozessdefinitionen, die von dem Betriebssystem und/oder virtuellen Maschinen definiert werden. Diese Prozesse und Definitionen können auch in einem Kontext-Cache 112 gespeichert werden. Es sei darauf hingewiesen, dass es mehr von dem Betriebssystem definierte Kontexte geben kann, die im Kontext-Cache 112 auf dem Chip gespeichert werden können. Daher muss der Kontextwechsel möglicherweise zum Primärspeicher gehen, wenn der Kontext nicht auf dem Chip zur Verfügung steht.
Ein Primärspeicher 120 kann eine Interrupt-Vektor-Tabelle 122, weitere Interrupts 124, einen unbekannten Kontext 126, Kontextdetails 128, einschließlich Überlauf aus dem Kontext-Cache 112, ein Timer-Interrupt 130 und eine Kontext-Cache-Kopie 132 aufweisen. Wie für Kenner der Technik offensichtlich ist, speichert der Primärspeicher ein Kontextdefinitionsabbild, das eine Information für laufende Prozesse bildet, und ermöglicht Zugriff auf das Abbild durch den Kontext-Controller 104, wenn eine Kontexteinlagerung oder -auslagerung durchgeführt wird.
Wie oben beschrieben ist, speichert der Cachespeicher Prozessdefinitionen im Kern. Wenn sich der Cache auffüllt, werden die Prozessdefinitionen dann im Primärspeicher gespeichert. Bei einem Kontextwechsel wird dann, wenn beim Kontextwechsel die Prozess-ID im Cache nicht gefunden werden kann, dem Betriebssystem ein unbekanntes Kontext-Interrupt 126 zur Verfügung gestellt, so dass das Betriebssystem den Kontext-Controller über die Kontextabbildstelle im Primärspeicher informieren kann. Der Kontext-Controller 104 hat direkten Zugriff auf die definierten Prozesse, die in dem Kontext-Cache 112 laufen oder nicht laufen. Der Kontext-Controller 104 interagiert direkt mit dem Primärspeicher und zieht von dem Betriebssystem definierte neue Kontexte heraus. Der Kontext-Controller kann typischerweise ”Unbekannter Kontext”- und ”Kontext gestoppt”-Interrupts ausgeben, so dass das Betriebssystem weiß, wann der Kontext nicht im Cache definiert ist oder nicht existiert. Die Kontexte können durch die Prozess-ID identifiziert werden (einschließlich beispielsweise Thread-ID und/oder ID einer virtuellen Maschine). Die L1-, L2-, L3-Caches können sich normal verhalten, so wie es von den CPU-Herstellern, wie z. B. Intel, z. B. im neuen i7-Prozessor vorgesehen ist. Die Kontextwechsel erfolgen über den Kontext-Controller, und Interrupts und ein Zugriff außerhalb des Chips erfolgen nur, wenn dies erforderlich ist.
Aufgrund des Bereitstellens der in 1 gezeigten Ausgestaltung braucht das Betriebssystem nicht jeden der Kerne in der CPU zu verwalten. Die Funktionalität des Betriebs des Betriebssystems bei der Verwaltung der Prozesse ist daher stärker vereinfacht und ermöglicht die erforderliche Hardware-Skalierung.
Gemäß der Kernarchitektur kann eine Prozessorvirtualisierung durch Entfernen der Sichtbarkeit der Anzahl von CPU-Kernen aus dem Betriebssystem erreicht werden. Das Betriebssystem kann nur den Kontext-Controller erkennen, wodurch sich das Betriebssystem auf das Priorisieren von Prozessen, das Einreihen von Prozessen in eine Warteschlange und die Speicherverwaltung konzentrieren kann.
Der Kontext-Controller kann Ausführungs- und Standby-Prozesskontexte auf dem Chip zwischenspeichern und Prozesse auf der Basis der Prozesspriorität ausführen, die in eine zur Verfügung stehende Thread-Warteschlange oder einen Kern eingereiht sind. Dadurch wird ermöglicht, dass die Prozesse ausgeführt werden, ohne dass das Betriebssystem Prozesse Zeitscheiben zuordnen muss. Prozessausführung und Kontextwechsel würden automatisch anhand der Priorität erfolgen und durch den Kontextwechsel für die Prozesse gesteuert, für die der Kontextwechsel gilt.
Das Betriebssystem braucht dann nur Ausführungsprozesse zu verfolgen und einer Priorität unterliegende Ausführungsbefehle an den Kontext-Controller auszugeben. Der Kontext-Controller kann den Kontextregisterspeicher wie erforderlich auf einen zur Verfügung stehenden Kern auslagern.
Prozesswechsel
Ein aktueller Prozess-Kontextwechsel beginnt damit, dass das Betriebssystem einen Kontextblock in einem Hauptspeicher erstellt, der ein Segment für CPU-Registerabbilder und Abbilder des virtuellen Speichers in n-Wege-Assoziativarrays enthält.
Die HPCS-(High Performance Context Switch = Hochleistungs-Kontextwechsel)Verfahrensweise, wie sie von dem hier diskutierten Kontext-Controller ausgeführt wird, besteht im Zwischenspeichern von CPU-Kontexten über die Prozess-ID in einem auf dem Chip befindlichen Cache, so dass das Betriebssystem keinen hochlatenten Wechsel durchzuführen braucht.
1. Prozesswechsel mit symmetrischer Mehrfachverarbeitung (Symmetrical Multi Processing – SMP)
Ein Echtzeituhr-Interrupt erfolgt periodisch (als Zeitscheibe bezeichnet), wodurch die Prozessausführung vom laufenden Prozess weg zurück zum Betriebssystem wechselt, so dass das Betriebssystem dann feststellen kann, ob ein Prozess ausgeführt werden muss. Dies wird als ”präemptives Multitasking” bezeichnet. Die CPU speichert automatisch das aktuelle Register auf einem ”Stapel” im Hauptspeicher, wenn das Interrupt auftritt.
Das Betriebssystem kann dann festlegen, welcher Kern und welcher Prozess als Nächstes auszuführen ist. Es kann einen Kern finden, den Kern unterbrechen, wobei das aktuelle Kernregisterabbild in den Hauptspeicher ausgelagert wird, einen neuen Registersatz im Hauptspeicher einrichten, auf dem ”Stapel” gespeicherte Register einstellen, falls erforderlich, und dann ein IRET (Return From Interrupt = Rückkehr aus einem Interrupt) durchführen, wodurch die CPU-Register aus dem Hauptspeicher zurück zur CPU-Thread-Warteschlange bewegt werden können.
Die Echtzeituhr kann wieder unterbrechen, und der Prozess wird wiederholt.
2. Prozesswechsel mit Hochleistungs-Kontextwechsel (HPCS)
Ein Echtzeituhr-Interrupt erfolgt periodisch, wodurch die Ausführung von einem laufenden Prozess weg zurück zum Betriebssystem wechselt.
2 zeigt ein Beispiel für ein Ablaufdiagramm eines Verfahrens zum Einplanen eines Prozesses nach einigen Ausführungsformen der vorliegenden Offenlegung. Der in dem gezeigten beispielhaften Diagramm gezeigte Ablauf kann von dem Kontext-Controller durch Empfangen und Zuweisen von zur Ausführung vorgesehenen Prozessen in der zentralen Verarbeitungseinheit durchgeführt werden.
Das Betriebssystem kann festlegen, welche Prozess-ID in der CPU in der nächsten Zeitscheibe ausgeführt werden kann. Das Betriebssystem kann dann einen SCTX-Befehl (neue CPU-Anweisung) zur Ausführung an den Kontext-Controller in der CPU ausgeben, der die Prozess-ID identifiziert. Der Kontext-Controller empfängt den Befehl (Block 204). Der Kontext-Controller in der CPU kann beispielsweise auf der Basis der empfangenen Prozess-ID feststellen, ob der Kontext-Controller den Prozess kennt, und zwar durch Feststellen, ob der Prozess im Speicher in der CPU gespeichert ist. Wenn der Prozess im Cachespeicher in der CPU gespeichert ist, kann der Kontext-Controller auf den Prozess zugreifen (Block 206). Dann kann der Kontext-Controller mit einer Kontextinformation von seinem zwischengespeicherten Pool von Kontexten die Prozess-ID für einen zur Verfügung stehenden CPU-Kern einplanen oder in eine Warteschlange einreihen (Block 208).
Wenn der Kontext-Controller den Prozess nicht kennt, kann er ein ”Unbekannter Prozess”-Interrupt erzeugen, und in diesem Fall kann eine gegenüber dem bekannten Kontextwechsel modifizierte Verfahrensweise ausgeführt werden, bei der einfach der Speicherblock identifiziert wird, der den Kontextregistersatz für den Kontext-Controller der CPU enthält, welcher den Kontext zum Cache überträgt und die Prozess-ID zur Ausführung einplant.
Der Kontext-Controller der CPU führt eine Zwischenspeicherung des Registersatzes in einem (nicht gezeigten) internen Puffer auf dem Chip durch. Die IRET-Befehle (Return From Interrupt = Rückkehr aus einem Interrupt) bewegen den ”Stapel”-Satz von dem bekannten Speicher zurück zur CPU, wodurch das ”Unbekannter Kontext”-Interrupt beendet wird.
Wenn der Kern ”voll” ist (was bedeutet, dass es keine weiteren Prozessslots gibt), kann die CPU ein ”Prozess unterbrochen”-Interrupt ausgeben, das das Betriebssystem darüber benachrichtigen kann, dass ein Prozess gestoppt und in eine Warteschlange platziert worden ist, als der SCTX-Befehl ausgeführt wurde. Wenn der Cache voll ist und es keine weiteren Warteschlangenslots gibt, kann ein ”Prozessauslagerung”-Interrupt auftreten, und das Betriebssystem kann angewiesen werden, den aktuellen Kontext zu speichern. Dies erfolgt dadurch, dass dem Kontext-Controller der CPU der Speicherblock aufgezeigt wird, in dem der Kontext zu speichern ist, der außerhalb des Chips ausgelagert ist.
Die CPU kann fortfahren, den unterbrochenen Prozesskontext zu speichern. Daher braucht dieser nicht ”ein-/ausgelagert” zu werden, wenn ein Prozess unterbrochen wird. Das Betriebssystem kann beobachten, dass sich der Prozess im ”Wartestatus” befindet. Das Betriebssystem kann einen ”Jetzt ausführen”-(SCTX-)Befehl in einer Zeitscheibe ausgeben, damit ein Warteschlangenprozess in einen Laufstatus geschaltet wird. Wenn sich ein Prozess in einem Wartestatus befindet, ist keine Registerauslagerung aus dem Hauptspeicher erforderlich.
Jeder Prozess kann mit einer Prioritätsanzeige versehen werden, die der Kontext-Controller verwenden kann, wenn er feststellt, bei welchem Prozess ein ”Prozess unterbrochen”-Interrupt auszuführen ist, wenn der Kern voll ist. Auf der Basis des Modus und der Priorität kann der Kontext-Controller die Prozesskontexte ausführen, die in einer Reihenfolge im Cache gespeichert sind. Das Betriebssystem müsste bei Bedarf eine Cacheauslagerung erzwingen, indem es die Prozesswechsel-Interrupts und Timer-Interrupts empfängt und Prozessveränderungen erforderlichenfalls an den Kontext-Controller übermittelt.
Die Echtzeituhr kann wieder unterbrechen, und der Prozess wird wiederholt.
Bei implementieren des oben beschriebenen Prozesses braucht das Betriebssystem nicht festzustellen, an welchem Kern eine Ausführung durchgeführt werden soll, Das Betriebssystem kann niemals einen Kern direkt unterbrechen. Somit zeigen Latenz und Systemdurchsatz eine entgegengesetzte Reaktion, wenn sich die Anzahl von Kernen in der CPU vergrößert. Während sich der bekannte SMP-Durchsatz verringert, wenn sich die Anzahl von CPU-Kernen vergrößert, wird durch Anwenden eines HPCS der Durchsatz verbessert, wenn sich die Anzahl von Kernen vergrößert.
Das Betriebssystem kann die Kontrolle über die Verarbeitungspriorität behalten. Das Betriebssystem weist den Kontext-Controller dahin gehend an, welche Prozess-ID zum Ausführen benötigt wird. Das Betriebssystem informiert den Kontext-Controller darüber, welcher Prozess laufen soll, und dann bewegt der Kontext-Controller den Prozess in einen CPU-Kern.
Die Hardware greift auf eine gespeicherte Information darüber zu, wo sich der Prozess befindet, um einen Kontextwechsel durchzuführen. Anhand einer Prozess-ID weiß der Kontext-Controller, wo die Information zu finden ist, um einen Kontextwechsel auf der Basis der Speicherabbild-Basisadresse, die von dem Betriebssystem für den Kontextwechsel zur Verfügung gestellt wird, durchzuführen. Der Kontext-Controller verwaltet den Speicher und nicht zweckbestimmte Kerne und besitzt Informationen bezüglich der laufenden Prozesse.
Jeder Prozess weist eine Priorität auf. Wenn ein weiterer Prozess auszuführen ist, legt der Kontext-Controller fest, welcher Prozess ausgelagert werden kann. Es werden Tabellen geführt, die zeigen, welche Prozesse auf welchen Kernen laufen. Die Tabelle kann in einem zweckbestimmten Speicherpuffer gespeichert werden und kann eine Information darüber speichern, ob ein Prozess läuft oder nicht, welche Priorität der Prozess hat etc. Somit werden sämtliche Anweisungen, die zum Bewegen eines Prozesses in einen und aus einem Kern erforderlich sind, von der Hardware im Kontext-Controller verarbeitet.
Bei der oben beschriebenen Ausgestaltung braucht das Betriebssystem die eigentlichen Prozessor-CPU-Anweisungen nicht in den und aus dem Hauptspeicher zu bewegen. Die Prozessinformation, die zum Laufen benötigt wird, befindet sich in der CPU selbst. Daher wird die Kontextwechsellatenz durch die Anzahl von CPU-Zyklen verringert, die zum Erhalten der Information erforderlich waren, wenn sich die Information nicht auf dem Chip selbst befunden hat. Ferner kann der Kontextwechsel automatisch einen Cache mit bekannten Kontexten durchlaufen, ohne das Betriebssystem einzubeziehen, außer wenn das Betriebssystem den Zyklus unterbrechen möchte. Dies wird als Auto-Kontextwechsel bezeichnet.
Sicherheit
Da immer mehr gleichzeitig ablaufende Prozesse und virtuelle Maschinen in gemeinsam genutzten Umgebungen geschaffen werden, wie z. B. Cloud Computing, müssen Schritte unternommen werden, um Datensicherheit zu bieten. Da es schwierig oder unmöglich sein kann, eine Hardware programmatisch zu verändern, ist das Bieten von Sicherheit auf der Hardware-Ebene eine der attraktivsten Optionen zum Bieten einer sicheren Rechnerumgebung.
Die einigen Ausführungsformen der vorliegenden Offenlegung entsprechenden Prinzipien bewirken, dass die Prozess-ID für die Hardware sichtbar wird, wobei Speicherblöcke mit virtuellen Speicherabbildern ausgebildet sind, die die Prozess-ID aufweisen und Sicherheitsbits enthalten, wodurch auf der Hardware-Ebene ein Maß an Sicherheit geboten wird, das sicherer ist als auf der Software-Ebene.
Bei der Kombination einer Prozess-ID-Markierung und einer Zugriffsmaske können Speicherblöcke in einem Benutzerbereich als sicher und für eine Prozessmaske sichtbar markiert sein, so dass Blöcke von Prozessen gemeinsam genutzt werden können und trotzdem sicher bleiben. Durch Schaffen einer Kombination der Prozess-ID-Markierung und einer Zugriffsmaske kann bei gemeinsam genutzten Rechnerdiensten, wie z. B. Cloud Computing, die Möglichkeit des Speicherzugriffs durch nicht autorisierte Quellen verhindert werden. Die einigen Ausführungsformen der vorliegenden Offenlegung entsprechenden Prinzipien können auf jedes System angewendet werden, bei dem Sicherheit auf der Hardware-Ebene erforderlich sein kann. Um dies zu erreichen, wird die Sicherheit von dem Betriebssystem weg auf die Hardware-Ebene übertragen.
Sicherheitsmodelle in heutigen CPUs bieten 4 Sicherheitsebenen: Ebene 0 – Kernelbereich, Ebene 1 – Gerätetreiber, Ebene 2 – Gerätetreiber, Ebene 3 – Benutzerbereich. Diese vier Sicherheitsebenen verleihen dem Betriebssystem (im Kernelbereich) die Fähigkeit, Daten- und Speicherzugriffssicherheit über den virtuellen Benutzerbereich und die Gerätetreiber zu bieten. Weitere Schritte können unternommen werden, um eine Prozessebenen-Sicherheit im Benutzerbereich auf der Hardware-Ebene zu bieten. Diese Offenlegung unterscheidet sich von gängigen ”Segmentierungs”-Techniken, die derzeit in der Industrie angewendet werden. Eine Segmentierung verhindert nicht, dass die Kernelbereichstreiber der Ebene 0 auf einen geschützten Speicherblock zugreifen. Die Konzepte dieser Offenlegung unterscheiden sich von der ”Segmentierung” und zeigen Techniken zum Sichern des Speichers auf der Hardware-Ebene auf, so dass selbst Prozesse auf Kernelebene nicht auf geschützte Speicherblöcke zugreifen können.
Das Modell nach einigen Ausführungsformen der vorliegenden Offenlegung bietet Datensicherheit. Bei einer alternativen Ausführungsform kann der Hochleistungs-Kontextwechsel (HPCS) oder Kontext-Controller verwendet werden, wie oben diskutiert worden ist, der die Sicherheit auf der Prozessebene im Benutzerbereich betrifft. Wenn das Betriebssystem einen Thread-Kontext erstellt, kann es eine Datenzugriffsmaske für den Prozess bereitstellen, der im Prozesskontext gespeichert ist. Bei einer Ausführungsform kann dies durch den HPCS durchgeführt werden.
3 zeigt ein Beispiel für eine Ausgestaltung der Komponenten gemäß den Prinzipien einiger Ausführungsformen der vorliegenden Offenlegung. 3 umfasst eine CPU 302. Es sei darauf hingewiesen, dass die CPU 302 als eine bekannte CPU implementiert werden kann. Alternativ kann die CPU 302 mit dem Kontext-Controller 102 implementiert werden, wie in Zusammenhang mit 1 diskutiert worden ist. Die CPU 302 kann ein Register 304 aufweisen. Die CPU 302 ist kommunizierfähig mit einem Speicher-Controller 306 verbunden, um auf einen Speicher 308 zuzugreifen. Der Speicher 308 weist Speicherblöcke 310 auf. Die Architektur ist ähnlich wie die, jedoch eindeutig verschieden von den aktuellen Architekturen des L3-Ebenen-Caching in heutigen modernen und gängigen CPUs.
Die Speicherblöcke 310 können konfiguriert werden, wodurch die Anzahl von Sicherheitsbits auf die Prozessebene erweitert wird. Der CPU-Kern kann die Ausführungsprozesse erkennen und kann definieren, ob der Benutzerprozess sicher ist oder nicht.
Die CPU 302 kann das Register 304 aufweisen, das Prozess-IDs der Prozesse in einem Kontext enthält. Ein Speicherblock kann eine Markierung mit Sicherheitsbits, d. h. eine Maske und die Prozess-ID, aufweisen. Beim Lesen eines Speicherblocks können die Sicherheitsbits und/oder Prozess-IDs, die in der Markierung enthalten sind, verglichen werden, um festzustellen, ob Daten aufgrund einer Übereinstimmung der Prozess-IDs zurückgeschickt werden können. Die CPU kann einen intern laufenden Kontext und eine Speicherzugriffslogik aufweisen, um einen einfachen Bitvergleich durchzuführen, damit ein Datenabruf aus dem Speicher ermöglicht wird. Ein 64-Bit-Register kann implementiert sein, das die Abbildung von Prozessen ermöglicht; und ein 64-Bit-Register in einem virtuellen Speicherbereich, so dass die CPU Vergleiche mit dem virtuellen Speicherbereich und dem tatsächlichen Prozesskontext durchführen kann.
4 zeigt ein Beispiel für ein Ablaufdiagramm eines Verfahrens zum Markieren eines Speicherblocks nach einigen Ausführungsformen der vorliegenden Offenlegung. Wenn das Betriebssystem einen Speicherblock einem Prozess zuordnet, wählt und identifiziert es einen Speicherblock (Block 402). Das Betriebssystem kann eine Datenzugriffsmaske erzeugen (Block 404), z. B. einen erzeugten sicheren Schlüssel, z. B. ein SSHA-, RSA-, CRYPT- etc. Passwort. Das Betriebssystem kann den Speicherblock mit der Prozess-ID und der Maske markieren (Block 406). Die Markierung, die die Prozess-ID und die Maske enthält, wird von den Virtuell-Speicher-Abbildtabellen der CPU aufrechterhalten. Wenn der Prozess ausgeführt wird, kann er auch seine Prozessmaske erzeugen. Wenn die CPU eine Virtuell-Speicher-Abbildseite lädt und mit dem Lesen der Seite beginnt, kann das ALE-(Address Latch Enable = Adressverriegelungs-)Signal von der CPU, das anzeigt, wenn der Speicher festgelegt und zum Lesen bereit ist, die UND-Maske des Prozess-ID-Kontextes und die Speicherseitenkontext-Sicherheitsmaske durchlaufen und während des gesamten Lesezyklus im Low-Zustand bleiben, wenn die Maske nicht übereinstimmt.
Sämtliche Speicherwerte, die von den Speicherleseanweisungen zurückgeschickt worden sind, können Nullen (0) oder Einsen (1) sein, wenn die Maske nicht übereinstimmt. Durch Ausgestalten der Maske auf diese Weise ist der Speicher vor dem Leseprozess verborgen.
Wenn die Maskenwerte übereinstimmen, dann kann sich das ALE-Signal als normaler Haltespeicher und Übertragungsspeicher zu und von dem anfordernden Prozess verhalten.
Somit werden die Speicherbewegungsanweisungen auf Anforderung eines Prozesskontextes ausgeführt. Kontexte können durch den HPCS auf dem Chip mit Sicherheitsmaske(n) gespeichert werden. Sicherheitsmasken werden beim Lesen eines virtuellen Speicherblocks von der CPU verwendet, um festzustellen, ob das ALE-Signal aktiviert werden soll.
Auf der Hardware-Ebene ist das Speicherabbild mit einem Satz von Sicherheitsregeln unter Verwendung von 2 Bits (d. h. vier Ebenen) definiert. Diese Regeln werden als Information in jedem virtuellen Speicherblock platziert und identifizieren Prozesse, die auf den Speicher zugreifen können.
Das BS erstellt seine eigenen Prozess-IDs. In vielen Fällen erstellt es Thread-IDs. Beim Erstellen eines Speicherabbilds und Definieren eines Prozess- und Ausführungskontextes wird dem Speicherabbildungsspeicher und dem Prozessausführungskontext eine Nummer zur Verfügung gestellt, die übereinstimmt, und eine Schaltungsanordnung innerhalb der CPU erkennt die Übereinstimmung und ermöglicht den Zugriff.
Beim Erstellen von Prozess-IDs kann der Speicher-E/A-Controller (Speicher-Controller) den Speicher von einem Block zu einem anderen bewegen. Der Speicher-Controller kann wissen, dass die Speicherbewegung von einem Block zu einem anderen die gleiche sein muss, z. B. kann er wissen, wann er eine Speicherbewegung von dem Hauptspeicher zu der CPU oder von Speicher zu Speicher durchführt. Der Speicher-Controller kann wissen, ob sich die ”von”- und ”zu”-Stellen in derselben Prozess-ID oder in der gleichen Sicherheit befinden. Beim Ausführen der eigentlichen Anweisung hat der Speicher-Controller Zugriff auf den Virtuell-Speicher-Abbildspeicher, so dass dann, wenn er die Speicherbewegungsanweisungen ausführt, der Speicheradressenbereich die Prozess-ID-Information enthält. Die Prozess-ID-Information wird vom zweckbestimmten Cachebereich, z. B. einem Speicherabbild, zur Verfügung gestellt. Beim Zugreifen auf den Speicher von dem Hauptspeicher zur CPU liefert der Speicher-Controller auf der Basis des laufenden Kontextes der CPU die Daten an den CPU-Controller zurück oder nicht. Zum Verbessern der Leistung kann es möglich sein, dass sich der Speicher-Controller in derselben physischen CPU befindet wie der CPU-Chip und die HPCS-Schaltungen.
Somit ist ein (nicht gezeigter) Cachebereich vorgesehen, der einen eindeutig definierten Prozesskontextdefinitions-Speicherblock aufweist. Abbilder des virtuellen Speichers sind eindeutig definiert. Die Speicher-Controller sind in der Lage, die Daten in den Abbildern des virtuellen Speichers nicht nur zu benutzen, um ”befindet sich die ”zu”- und ”von”-Adresse im geschützten Speicher?” zu bestimmen, sondern auch, um die Bits auf 64 Bits zu erweitern, die eine Prüfung durchführen, um festzustellen, ob die Prozesse übereinstimmen.
Wenn die Bewegung von Speicher zu Speicher auf der Basis der Abbilder des virtuellen Speichers erfolgt, werden die ”zu”- und ”von”-Adressen als derselbe Sicherheitskontext bestimmt. Wenn die Bewegung vom Speicher zur CPU erfolgt, kann die CPU wissen, um was für einen Ausführungskontext es sich handelt und ob es erlaubt ist, auf die Daten zuzugreifen.
Es sei darauf hingewiesen, dass der Sicherheitskontext, wie er hier diskutiert wird, in einer Ausgestaltung implementiert sein kann, bei der das Betriebssystem den Kontextwechsel steuert. Es sei ferner darauf hingewiesen, dass der Sicherheitskontext, wie er hier diskutiert wird, in einer Ausgestaltung implementiert sein kann, bei der der Kontext-Controller 102 den Kontextwechsel steuert.

Speicherblöcke werden vom Betriebssystem so zugeordnet, dass die Abbildtabellen (Zuordnungstabellen) der CPU zur Verfügung gestellt werden und Abbildtabellen sowohl Prozess-IDs as auch Speichermasken enthalten. Diese Speicherzuordnungstabellen werden manchmal als Abbilder des virtuellen Speichers bezeichnet und weisen die gleiche Struktur auf, die auch in heutigen modernen CPUs vorhanden ist. Die hier diskutierten Sicherheitskonzepte dienen der Beschreibung eines Mechanismus zum eindeutigen Formatieren der Prozess-IDs und der Einträge in der Zuordnungstabelle, die der CPU die Information liefern, die erforderlich ist, um der CPU und den Speichern-Controllern eine Sicherheit auf der Hardware-Ebene zu verleihen. Ein typischer Abbildeintrag würde in etwa wie folgt aussehen:

Speicherzuordnungs-Handle	Prozess-ID	Prozessmaske	Physischer Speicher
0x0000 3000 0000 0000	0x0100 0000 0000 1234	0x1234 5678 9ABC DEF0	0x0000 0000 0000 1234
0x0000 4000 0000 0000	0x1100 0000 0000 1234	0x1234 5678 9ABC DEF0	0x0000 0000 1000 1234
0x0000 5000 0000 0000	0x2100 0000 0000 1234	0x1234 5678 9ABC DEF0	0x0000 0000 2000 1234
0x0000 6000 0000 0000	0x3100 0000 0000 1234	0x1234 5678 9ABC DEF0	0x0000 0000 3000 1234

Die vorstehende Speicherzuordnungstabelle ist identisch mit heutigen Speicherzuordnungstabellen und Virtuell-SpeicherAbbildtabellen, die in modernen CPUs verwendet werden, mit der Ausnahme, dass anstelle von zwei Einträgen in der Tabelle (Zuordnungs-Handle und Adresse des physischen Speichers) die Zuordnungsabbilder 4 (vier) Einträge enthalten würden, die die verarbeitete und die Zugriffsmaske enthalten. Die Prozess-ID wird in Absatz [0083] genauer diskutiert.

Transaktionsspeicher
Da immer mehr gleichzeitig ablaufende Prozesse und virtuelle Maschinen in gemeinsam genutzten Umgebungen geschaffen werden (wie z. B. Cloud Computing), wird die Frage der gemeinsamen Nutzung eines Speichers allmählich zu einem Anliegen.
Eine ”Transaktion” kann ein Ereignis sein, bei dem ein Prozess Daten aktualisieren und verändern kann, während ein anderer Prozess eine frühere Version dieser Daten liest. Wenn ein Prozess seine Änderungen durchführt oder speichert, würden die neuen Daten den anderen Prozessen zur Verfügung gestellt.
Ein weiterer Aspekt einer ”Transaktion” ist, dass der eine Prozess seine Änderungen verwerfen und zu der früheren Version seiner Daten zurückkehren kann.
Frühere Versuche zum Schaffen einer Transaktionsverarbeitung durch das Betriebssystem haben zu Implementierungsproblemen geführt, da die Speicherverwaltung auf dieser Ebene zu langsam und unpraktisch wird. Entsprechend den Prinzipien einiger Ausführungsformen der vorliegenden Offenlegung ist jedoch eine Brücke vorgesehen, die eine Hochleistungs-Transaktionsverarbeitung in Mehrkern- und Mehrprozess-Umgebungen ermöglicht. Mit dem beschriebenen System werden Technologien von der Rechnerindustrie für die Mehrkern-, Vielkern- und Mehr-Chip-CPU-Technologie, einschließlich Homogen- und Heterogenkern-Technologien, verbessert.
5 zeigt ein Beispiel für ein Blockdiagramm einer Hardware-Ausgestaltung entsprechend den Prinzipien einiger Ausführungsformen der vorliegenden Offenlegung. Wie in 5 gezeigt ist, weist die Hardware-Ausgestaltung einen CPU-Kern 502, einen Speicherbus-Controller 504, einen Hauptkern 506 und einen Transaktionskern 508 auf.
Das System bietet eine CPU-Prozesskontext-Verbesserung von Abbildern des virtuellen Speichers, einen Speicherbus zum Ermöglichen von Speichertransaktionen, eine Parallel- oder Dual-Ebenen-Speicherarchitektur und ein Betriebssystem zum Durchführen eines Transaktionsspeicheraufbaus und Commits.
Das primäre Problem bei gemeinsam genutzten Rechnerdiensten (wie z. B. Cloud Computing) ist die Eröffnung der Möglichkeit des Speicherzugriffs durch mehrere Quellen. Speicherzugriffsveränderungen ”blockieren” typischerweise einen Leser, so dass der Leser vor dem Lesen warten muss, bis Updates beendet sind.
Transaktionsprozesse ermöglichen es Lesern, fortzufahren, ohne blockiert zu werden. Dies ermöglicht einen höheren Verarbeitungsdurchsatz von parallel ablaufenden Prozessen.
Das System kann bei einigen Ausführungsformen der vorliegenden Offenlegung den HPCS oder Kontext-Controller aufweisen, wie oben beschrieben ist, und kann die Prozess-ID-Information zum Ausführen von Kontext innerhalb des CPU-Kerns beibehalten. Der ”Prozess” wird einer Transaktion unterzogen, wobei der gesamte Speicher, auf den innerhalb der ”Prozess-ID” zugegriffen wird, einer Transaktion unterzogen wird.
Wenn mehr Entwickler mit dem ”Threading” und Mehrprozessanwendungen zufrieden sind, kann ein Entwickler vom Betriebssystem eine ”einer Transaktion unterzogene” Prozess-ID anfordern.
Vorprozess-Betriebssystemanforderungen
Jeder Prozess, für den ein einer Transaktion unterzogener Speicher notwendig ist, erfordert die Erstellung einer ”einer Transaktion unterzogenen” Prozess-ID durch das Betriebssystem.
Das Betriebssystem kann eine Prozess-ID mit den für den freigegebenen Speicherzugriff (Transaktion oder Sicherheit) freigegebenen Attribut-Flags erzeugen. Eine Prozess-ID kann ein 64-Bit-Wert sein, wie z. B.: 0x2001 0000 0000 1234.
Die CPU-Sicherheits- und Transaktions-Flags können im letzten Nibble beibehalten werden. Die verbleibenden Prozess-IDs sind für das Betriebssystem und die virtuellen Maschinen bestimmt, wie z. B.: OxTVVV XXXX XXXX SSSS, wobei: T = ”Transaktions-/Sicherheits-Flags”; V = ”Virtuell-Maschinen-Identifizierer”; X = ”Betriebssystems- und Benutzerprozess-ID”; S = ”Betriebssystems- und Benutzerprozess-Thread-ID” sind.
Wenn das Betriebssystem einen Thread-Kontext erstellt, kann es eine Daten-Zugriffsmaske für den Prozess zur Verfügung stellen, die in dem Prozesskontext gespeichert werden kann. Dies kann durch den HPCS verwaltet werden. Siehe den Sicherheitsabschnitt bezüglich Sicherheitsbits und Zugriffsmasken.
Ferner können die Virtuell-Speicher-Abbild-Assoziativarrays, die vom Betriebssystem aufrechterhalten werden, ein zusätzliches Assoziativarrayelement aufweisen, das die Prozess-ID enthält, die den Speicherblock zugeordnet hat.
Wenn die CPU einen ”Seitenfehler” ausgibt und das Speicherblockabbild in das Virtuell-zu-Physisch-Speicherabbild der CPU auslagern muss, kann die Prozess-ID Teil der Information in dem Speicherzuordnungsblock sein, die in die CPU-Kontextregister für die Abbildung des virtuellen Speichers eingesetzt ist.

Das Assoziativarray kann beispielsweise wie folgt implementiert werden (die Adressen dienen nur der Erläuterung):

Block	Virtuelle Adresse	Physische Adresse	Prozess-ID
1	0x0000 0000 0000	0x2803 0000 0000	0x0001 0000 0000
2	0x2000 0000 0000	0x2804 0000 0000	0x1001 0000 0000
3	0x4000 0000 0000	0x78BD 0000 0000	0x2001 0000 0000
4	0x5000 0000 0000	0xF932 0000 0000	0x3001 0000 0000

Diese Abbilder des virtuellen/physischen Speichers werden typischerweise in n-Wege-Assoziativarrays (typischerweise 4-Wege) innerhalb der Abbilder des Betriebssystems und des CPU-Kontextes gehalten.
Das hier diskutierte Speicherabbild umfasst die Prozess-ID, die den virtuellen Speicherblock zugeordnet hat. Die Prozess-IDs zeigen ein Beispiel für das hohe Nibble, so dass das hohe Nibble wie folgt ist:
0x0 – Keine Sicherheit
0x1 – Sicherheit – Zugriff nur mittels dieser Prozess-ID
0x2 – Transaktion – Die Prozess-ID wird einer Transaktion unterzogen
0x3 – Sicher/Transaktion – Die Prozess-ID ist gesichert und wird einer Transaktion unterzogen
Wenn das Betriebssystem korrekte Prozess-IDs und Abbilder der Virtuell-Speicher-Zuordnung erzeugt hat, kann der Transaktionskern freigegeben werden.
Merkmale, die einigen Ausführungsformen der vorliegenden Offenlegung entsprechen, bieten vier Rechnerarchitekturausgestaltungen.
Der Transaktionskern: Ein redundanter Speicherkern zur Verwendung bei Transaktionsprozessen. Dieser Kern ist ein Duplikat des gesamten Speichers in einem Hauptspeicher.
Die CPU-Chipsätze können gleichzeitig in zwei Speicherbusse schreiben.
Speicherzugriff: Jeder Speicherblock kann innerhalb des Speicherseiten-Assoziativarray-Cache, das die Seitenblock-Zugriffsebene als Schreiben/Lesen, Nur-Lesen oder Transaktion identifiziert, markiert werden.
Transaktions-Speicherung/Commit/Zurücksetzung. Wenn jeder Prozess abgeschlossen ist oder eine Transaktion abgeschlossen ist, kann die CPU angewiesen werden, die Speicherseite zwischen dem Transaktionskern und dem Hauptspeicher zu ”kopieren”.
Transaktionskern
Gemäß den Prinzipien einiger Ausführungsformen der vorliegenden Offenlegung ist ein redundanter Speicherkern, der als ”Transaktionskern” bezeichnet wird, vorgesehen, der parallel zu dem Hauptspeicherkern laufen kann. Dies ist ein einfacher Aufbau des Speicherbusses und der Speicherzugriffs-Chipsätze zum bedingten Zugreifen auf zwei Speicherkerne gleichzeitig. Diese Speicherkerne nutzen gemeinsam genau den gleichen linearen Adressraum, was ein gleichzeitiges Schreiben ermöglicht. Bei einigen Ausführungsformen, die den Prinzipien einiger Ausführungsformen der vorliegenden Offenlegung entsprechen, kann die Verwaltungsverantwortung vom Betriebssystem auf den CPU-Kern, z. B. den Kontext-Controller, übertragen werden.
Diese Kernausgestaltung zeigt, dass die CPU den Bus mit einer drei Zustände aufweisenden Zugriffsleitung auf einem Chipsatz steuern kann, die den Bus-Controller beeinflusst, wenn ALE (Address Latch Enable = Adressverriegelung) gesetzt ist. Die Zustände können sein:
Aus (drei Zustände) – Der Zugriffswechsel ist weder hoch noch niedrig. Das bedeutet, dass keine Daten während des Zugriffszyklus übertragen werden können.
Hoch – Zugriffswechsel ist ausgeschaltet. Beim Schreibzyklus sind beide Kernbusse aktiv und ermöglichen, dass das Schreiben in beiden Kernen erfolgt. Beim Lesezyklus ist nur der Hauptkern aktiv.
Niedrig – Zugriffswechsel ist eingeschaltet. Beim Schreib- und Lesezyklus ist nur der Transaktionskern aktiv.
Es sei darauf hingewiesen, dass diese Verarbeitung für das Betriebssystem und die CPU vollständig transparent ist. Daher hat dieser Prozess des Bereitstellens eines Zweitspeichers keine Auswirkung auf den Prozessdurchsatz.
Schreiben in den Speicher und Lesen aus dem Speicher
Beim Lese-/Schreibzyklus unter Verwendung einer Prozess-ID kann die CPU mittels des vom Betriebssystem zur Verfügung gestellten Abbilds des virtuellen Speichers auf den physischen Speicherplatz zugreifen.
Der Schreibprozess macht es erforderlich, dass die CPU den drei Zustände aufweisenden Zugriffswechsel korrekt aktiviert. Sie kann dies durch Vergleichen der Prozess-ID des Ausführungskontextes und der Prozess-ID des Abbilds des virtuellen Speichers durchführen, wodurch das drei Zustände aufweisende Flag korrekt gesetzt werden kann.
Zuerst kann sie die Kontextprozess-ID und das Abbild des virtuellen Speichers vergleichen, was automatisch dadurch von den CPU-Registern durchgeführt werden kann, dass sie den Prozesskontext und das Abbild des virtuellen Speichers laden. Dies ist eine Funktion der CPU-Register, und es werden keine Anweisungen benötigt zum Ausführen der Bedingung:
Annahme der Kontextprozess-ID A und der Virtuell-Speicher-Prozess-ID B.
Die Bits sind Zahlen von 0 bis 63. Bit 60 ist ein Sicherheitsbit. Bit 61 ist ein Transaktionsbit.
CPU-Register vergleichen A mit B (Bits niedriger als 60, Bits 0 bis 59). Das führt zum A=B-Signal.
Das daraus resultierende Zugriffs-Flag wird von der logischen Schaltung dargestellt, die in 6 gezeigt ist.
Das Transaktions-Flag (Bit 61) schaltet das Transaktionskern- oder Hauptkern-Speicher-Flag ein. Das Sicherheits-Flag (Bit 60) ermöglicht es dem drei Zustände aufweisenden Puffer festzustellen, ob ein Zugriff für die Prozess-ID bewilligt ist.
Das Sicherheits-Flag ist komplex. Bei einer Transaktion kann es dies dann, wenn der Zugriffsprozess nicht der Prozess B ist und ein Leseprozess am Speicherblock von Prozess B erfolgt, vom Hauptspeicher aus durchführen, und wenn es zu schreiben versucht, kann das Schreiben blockiert werden, da bei einem Schreibvorgang versucht würde, in beide Speicherebenen zu schreiben, wie es von einem niedrigen Zugriffs-Flag vorgegeben ist.
Die Sicherheitsregeln lauten:
Wenn A=B, dann ist das Zugriffs-Flag freigegeben (0 oder 1), ODER
Wenn Bit 60 abgeschaltet ist, dann ist das Zugriffs-Flag freigegeben (0 oder 1), ODER
Wenn Bit 60 abgeschaltet ist UND Bit 61 eingeschaltet ist (es eine Transaktion ist) UND es kein Schreibzyklus ist UND A<>B ist, dann ist das Zugriffs-Flag freigegeben (0 oder 1)
Das Zugriffs-Flag wird so gehandhabt, dass:
Wenn Bit 61 eingeschaltet ist UND A=B ist, dann erfolgt ein Setzen auf 0 für Lesen/Schreiben von einem Transaktionskern
Wenn Bit 61 eingeschaltet ist UND A<>B ist, dann erfolgt ein Setzen auf 1, so dass Lesevorgänge vom Hauptkern erfolgen und ein Schreibvorgang in beiden Kernen erfolgt.
Wenn drei Zustände vorhanden sind (auf der Basis des Sicherheits-Flag), kann der Speicher nicht vom Speicher-Controller den Speicherbus entlang geführt werden. Diese Sicherheitsregel ist von dem Logikdiagramm in 6 dargestellt.
Bei einer Transaktion kann nicht ermöglicht werden, dass Prozess A (wenn er nicht gleich B ist) in den Transaktionsspeicher von Prozess B schreibt. Daher wird das Zugriffs-Flag abgeschaltet und kann der Speicherbus-Controller keinen Schreibvorgang durchführen.
Bei Lesevorgängen können dann, wenn das Zugriffs-Flag in drei Zuständen ist, sämtliche vom Speicher-Controller zurückgeführten Speicherwerte Nullen (0) oder Einsen (1) sein oder drei Zustände aufweisen, wodurch ein erfolgreiches Lesen verhindert wird.
Kontexttransaktions-Speicherung/Commit/Zurücksetzung
Bei der Prozessausführung erfolgen Speichermodifikationen nur dann am Transaktionsspeicher, wenn Bit 61 in der Virtuell-Speicher-Abbild-Prozess-ID eingeschaltet ist.
Wenn der Prozess vom Betriebssystem (oder zu jedem geeigneten Zeitpunkt vom Prozess selbst) beendet worden ist, kann das Betriebssystem eine Prozesskontext-Commit-Anweisung an die CPU ausgeben.
Die CPU kann die Prozesskontext-Commit-Anweisung übernehmen und die Virtuell-Speicherblock-/Physisch-Speicherblock-Information an den Speicher-Controller ausgeben.
Der Speicher-Controller kann den Speicherblock vom Transaktionskern direkt in den Hauptspeicherkern (oder im Fall einer Zurücksetzung vom Hauptspeicherkern in den Transaktionskern) kopieren. Dieses Kopieren muss außerhalb der CPU durch DMA-Controller (oder Parallelbus-Controller), die vom Speicherbus-Controller verwaltet werden) erfolgen.
Die Richtung des Kopierens ist außerordentlich wichtig. Es kann eine Anweisung für eine Kopie-”speichern”-Anweisung an den Speicherbus und eine ”Zurücksetzungs”-Anweisung für eine Kopie in umgekehrter Richtung geben. Dies ermöglicht es einer Transaktion, sämtliche Änderungen abzubrechen und sich zu einer vorhergehenden Kopie des Speicherblocks ”zurückzusetzen”.
Bei dieser Lösung ist das Commit eine einzelne Anweisung, und die gesamte Speicherbewegung erfolgt in der Hardware.
Verwendung des Kerns
Der Prozess zum Ausführen einer Transaktion durch Anwendungsprozesse kann einfach sein. Die Schritte zum Durchführen einer Transaktion mit der beschriebenen Architektur sind wie folgt:
Das Betriebssystem erzeugt eine Prozess-ID mit Transaktions-Flag. Das Betriebssystem erstellt einen Prozesskontext für den Thread. Der Prozesskontext wird für die Thread-Ausführung an die CPU übertragen, und Abbilder des virtuellen Speichers werden in die Aktivierung ausgelagert (genauso wie Abbilder und Kontexte in aktuellen Architekturen ausgeführt werden). Anwendung oder Thread-Lesevorgang/Schreibvorgänge in Speicher, wie normalerweise durchgeführt wird. Jede Speicherblockzuordnung steht mit der Prozess-ID im Abbild des virtuellen Speichers in Verbindung, die vom Betriebssystem aufrechterhalten wird. Anwendung oder Thread wird beendet. Das Betriebssystem gibt eine Prozessbeendigung an die CPU aus, um den Kontext zu entfernen, und gibt eine Transaktions-Commit-Anweisung (oder Transaktions-Zurücksetzungs-Anweisung) für die Prozess-ID aus, mit der die CPU angewiesen wird, den Speicherbus anzuweisen, jeden virtuellen Speicherblock für die Prozess-ID zwischen dem Transaktionsspeicherkern und dem Hauptspeicherkern zu kopieren. Das Betriebssystem gibt die virtuellen/physischen Speicherblöcke für die Prozess-ID für andere Prozesse frei.
Es sei darauf hingewiesen, dass die Speicherblöcke, die innerhalb des Prozesses zugeordnet werden, Teil derselben Transaktion sind. Erst wenn der Prozess beendet ist, wird der Speicher in den Hauptkern kopiert. Die Transaktion ist die Zeitspanne einer Prozess-/Thread-Ausführung.
Es sei darauf hingewiesen, dass die Verfahren, Einrichtungen, Ausgestaltungen, Architekturen etc., die hier diskutiert worden sind, in anderen Industrien anwendbar sind. Zum Beispiel: 1) Filmindustrie. Animations-Rendering durch Mehrprozess-Film-Rendering in gemeinsam genutzten Systemen; 2) Spieleindustrie. Echtzeit-Parallel-Multiprocessing-Szene-Rendering in gemeinsam genutzten Systemen; 3) Ausbildung/Forschung. Echtzeit-Parallel-Multi-Equation-Verarbeitung in gemeinsam genutzten Systemen; 4) Finanzen. Echtzeit-Markteinschätzung und statistische Verarbeitung in gemeinsam genutzten Systemen; 5) Wissenschaft. Parallele Datenverarbeitung in gemeinsam genutzten Systemen; 6) Computerwesen. Bei der Virtualisierung von Hypervisoren brauchen zur Verfügung stehende CPUs nicht länger beobachtet zu werden, es brauchen einfach nur Virtuell-Server-Prozess-Priorisierungs-Warteschlangen etc. bereitgestellt zu werden.
Es verbleibt nur ein geringer Unterschied zwischen Hardware- und Software-Implementierungen von Aspekten von Systemen; die Verwendung von Hardware oder Software ist im Allgemeinen (jedoch dahin gehend nicht immer, dass bei bestimmten Kontexten die Wahl zwischen Hardware und Software signifikant werden kann) eine Auslegungsfrage, die einen Kompromiss zwischen Kosten und Effizienz erforderlich macht. Es gibt verschiedene Mittel, mit denen Prozesse und/oder Systeme und/oder andere Technologien, die hier beschrieben sind, ausgeführt werden können (z. B. Hardware, Software und/oder Firmware), und das bevorzugte Mittel kann mit dem Kontext variieren, in dem die Prozesse und/oder Systeme und/oder anderen Technologien angewendet werden. Beispielsweise kann dann, wenn ein Implementierer festlegt, dass Geschwindigkeit und Genauigkeit vorrangig sind, der Implementierer für den hauptsächlichen Einsatz eines Hardware- und/oder Firmware-Mittels optieren; wenn Flexibilität vorrangig ist, kann der Implementierer für die hauptsächliche Implementierung von Software optieren; oder alternativ kann der Implementierer für eine Kombination aus Hardware, Software und/oder Firmware optieren.
In der vorstehenden detaillierten Beschreibung sind verschiedene Ausführungsformen der Vorrichtungen und/oder Prozesse durch Blockdiagramme, Ablaufdiagramme und/oder Beispiele dargestellt worden. Wenn solche Blockdiagramme, Ablaufdiagramme und/oder Beispiele eine oder mehrere Funktionen und/oder Operationen enthalten, ist es für Kenner der Technik offensichtlich, dass jede Funktion und/oder Operation in solchen Blockdiagrammen, Ablaufdiagrammen oder Beispielen einzeln oder gemeinsam von einer großen Palette von Hardware, Software, Firmware oder praktisch jeder geeigneten Kombination daraus implementiert werden können. Bei einer Ausführungsform können mehrere Teile des hier beschriebenen Gegenstands über anwenderspezifisch-integrierte Schaltungen (ASICs), feldprogrammierbare Gate-Arrays (FPGAs), Digitalsignalprozessoren (DSPs) oder andere integrierte Formate implementiert werden. Kenner der Technik erkennen jedoch, dass einige Aspekte der hier offengelegten Ausführungsformen vollständig oder teilweise auf äquivalente Weise in integrierte Schaltungen implementiert werden können, wie z. B. ein oder mehrere Computerprogramme, die auf einem oder mehreren Computern laufen (z. B. ein oder mehrere Programme, die auf einem oder mehreren Computersystemen laufen), wie z. B. ein oder mehrere Programme, die auf einem oder mehreren Prozessoren laufen (z. B. ein oder mehrere Programme, die auf einem oder mehreren Mikroprozessoren laufen), wie z. B. Firmware oder wie z. B. jede geeignete Kombination daraus, und dass das Auslegen der Schaltungsanordnung und/oder das Schreiben des Codes für die Software und/oder die Firmware für Kenner der Technik anhand dieser Offenlegung durchführbar ist. Ferner erkennen Kenner der Technik, dass die Mechanismen des hier beschriebenen Gegenstands als Programmprodukt in einer Vielzahl von Formen verteilt werden können und dass erläuternde Ausführungsformen des hier beschriebenen Gegenstands unabhängig vom speziellen Typ des signalführenden Mediums angewendet werden können, das verwendet wird, um die eigentliche Verteilung durchzuführen. Beispiele für ein signalführendes Medium umfassen, sind jedoch nicht beschränkt auf, die folgenden: ein beschreibbares Medium, wie z. B. eine Floppy Disk, ein Festplattenlaufwerk, eine Compact Disk (CD), eine digitale Videodiskette (DVD), ein digitales Band, ein Computerspeicher etc.; und ein Übertragungsmedium, wie z. B. ein digitales und/oder analoges Kommunikationsmedium (z. B. ein faseroptisches Kabel, ein Wellenleiter, eine verdrahtete Kommunikationsverbindung, eine drahtlose Kommunikationsverbindung etc.).
Kenner der Technik erkennen, dass es auf dem Sachgebiet üblich ist, Vorrichtungen und/oder Prozesse in der hier dargestellten Form zu beschreiben und danach praktisches Ingenieurwissen anzuwenden, um solche beschriebenen Vorrichtungen und/oder Prozesse in Datenverarbeitungssysteme zu integrieren. Das heißt, dass zumindest ein Teil der hier beschriebenen Vorrichtungen und/oder Prozesse über ein angemessenes Maß an Experimenten in ein Datenverarbeitungssystem integriert werden kann. Kenner der Technik erkennen, dass ein typisches Datenverarbeitungssystem im Allgemeinen eines oder mehrere umfassen von einem Systemeinheit-Gehäuse, einer Videoanzeigevorrichtung, einem Speicher, wie z. B. einem flüchtigen und nicht flüchtigen Speicher, Prozessoren, wie z. B. Mikroprozessoren und Digitalsignalprozessoren, Rechnerentitäten, wie z. B. Betriebssysteme, Treiber, grafische Benutzerschnittstellen und Anwendungsprogramme, eine oder mehrere Interaktionsvorrichtungen, wie z. B. ein Touchpad oder Berührungsbildschirm, und/oder Steuersysteme, einschließlich Feedbackschleifen und Steuerungsmotoren (z. B. Feedback für die Erfassung von Position und/oder Geschwindigkeit; Steuerungsmotoren zum Bewegen und/oder Einstellen von Komponenten und/oder Mengen). Ein typisches Datenverarbeitungssystem kann unter Verwendung geeigneter handelsüblicher Komponenten implementiert werden, wie sie typischerweise bei Datenverarbeitungs-/-übertragungs- und/oder Network Computing-/Netzwerkskommunikations-Systemen zu finden sind.
Der hier beschriebene Gegenstand umfasst manchmal unterschiedliche Komponenten, die in unterschiedlichen anderen Komponenten enthalten oder mit diesen verbunden sind. Es sei darauf hingewiesen, dass solche dargestellten Strukturen nur Beispiele sind und in der Tat zahlreiche andere Architekturen implementiert werden können, mit denen die gleiche Funktionalität erreicht wird. In einem konzeptionellen Sinn ist jede geeignete Anordnung von Komponenten zum Erreichen der gleichen Funktionalität effektiv ”zugehörig”, so dass die gewünschte Funktionalität erreicht wird. Somit können jeweils zwei Komponenten, die hier kombiniert sind, um eine spezielle Funktionalität zu erreichen, als so zueinander ”zugehörig” betrachtet werden, dass die gewünschte Funktionalität unabhängig von Architekturen oder dazwischenliegenden Komponenten erreicht wird. Gleichermaßen können jeweils zwei so zueinander gehörige Komponenten auch betrachtet werden als ”in miteinander in Wirkverbindung stehend” oder ”betriebsmäßig miteinander gekoppelt”, um die gewünschte Funktionalität zu erreichen, und jeweils zwei Komponenten, die einander so zugehörig sein können, können auch betrachtet werden als ”betriebsmäßig miteinander koppelbar”, um die gewünschte Funktionalität zu erreichen. Spezifische Beispiele für betriebsmäßig koppelbar umfassen, sind jedoch nicht beschränkt auf, physisch paarbare und/oder physisch interagierende Komponenten und/oder Komponenten, die in der Lage sind, drahtlos zu interagieren, und/oder drahtlos interagierende Komponenten und/oder logisch interagierende Komponenten und/oder Komponenten, die in der Lage sind, logisch zu interagieren.
Bezüglich der Anwendung von Ausdrücken im Wesentlichen im Plural und/oder Singular können Kenner der Technik vom Plural in den Singular und/oder vom Singular in den Plural umsetzen, wie es für den Kontext und/oder die Anwendung zweckdienlich ist. Die verschiedenen Singular/Plural-Umsetzungen können aus Gründen der Klarheit hier ausdrücklich angegeben sein.
Es ist für Kenner der Technik offensichtlich, dass im Allgemeinen hierin und insbesondere in den beiliegenden Patentansprüchen (z. B. den kennzeichnenden Teilen der beiliegenden Patentansprüche) verwendete Ausdrücke generell als ”offene” Ausdrücke gemeint sind (z. B. sollte der Ausdruck ”einschließlich” als ”einschließlich, jedoch nicht beschränkt auf” ausgelegt werden, der Ausdruck ”mit” sollte als ”mit mindestens” ausgelegt werden, der Ausdruck ”weist auf” sollte als ”weist auf, ist jedoch nicht beschränkt auf” ausgelegt werden etc.). Es ist für Kenner der Technik ferner offensichtlich, dass dann, wenn beabsichtigt ist, eine spezifische Anzahl in einer angegebenen zahlenmäßigen Nennung in einem Anspruch zu nennen, diese Absicht ausdrücklich in dem Anspruch genannt wird, und bei Nichtvorhandensein einer solchen zahlenmäßigen Nennung diese Absicht nicht gegeben ist. Beispielsweise können als Hilfe zum besseren Verständnis die folgenden beiliegenden Patentansprüche die Verwendung der Phrasen ”mindestens ein” und ”ein oder mehrere” enthalten, um zahlenmäßige Nennungen in den Ansprüchen anzugeben. Die Verwendung darf jedoch nicht dahin gehend ausgelegt werden, dass sie bedeutet, dass die Angabe einer zahlenmäßigen Nennung in den Ansprüchen durch die unbestimmten Artikel ”ein” oder ”eine” einen speziellen Anspruch, der eine solche angegebene zahlenmäßige Nennung enthält, auf Offenlegungen beschränkt, die nur eine solche zahlenmäßige Nennung enthalten, selbst wenn der gleiche Anspruch die Phrasen ”ein oder mehr” oder ”mindestens ein” und unbestimmte Artikel, wie z. B. ”ein” oder ”eine” aufweist (z. B. sollte ”ein” und/oder ”eine” typischerweise so ausgelegt werden, das ”mindestens ein” oder ”ein oder mehr” gemeint ist); das Gleiche gilt für die Verwendung von bestimmten Artikeln, die für die Angabe von zahlenmäßigen Nennungen in den Ansprüchen verwendet werden. Ferner erkennen Kenner der Technik, dass selbst dann, wenn eine spezifische Anzahl bei einer angegebenen zahlenmäßigen Nennung in den Ansprüchen ausdrücklich genannt ist, eine solche zahlenmäßige Nennung typischerweise so ausgelegt werden muss, dass mindestens die genannte Anzahl gemeint ist (z. B. bedeutet die bloße zahlenmäßige Nennung von ”zwei” ohne weitere Attribute typischerweise mindestens zwei oder zwei oder mehr). In denjenigen Fällen, in denen eine Nennung analog zu ”A, B und/oder C” verwendet wird, ist im Allgemeinen eine solche Konstruktion in dem Sinne vorgesehen, wie ein Kenner der Technik die Konstruktion verstehen würde (z. B. würde ”ein System mit A, B und/oder C” umfassen, jedoch nicht beschränkt sein auf, Systeme mit A allein, B allein, C allein, A und B zusammen, A und C zusammen, B und C zusammen und/oder A, B und C zusammen etc.). Es ist für Kenner der Technik ferner offensichtlich, dass praktisch jedes disjunktive Wort und/oder jede disjunktive Phrase, das/die zwei oder mehr alternative Ausdrücke bieten, ganz gleich, ob in der Beschreibung, den Patentansprüchen oder den Zeichnungen, so verstanden werden müssen, dass sie die Möglichkeit beinhalten, einen Ausdruck, einen der beiden Ausdrücke oder beide Ausdrücke zu umfassen. Beispielsweise ist die Phrase ”A oder B” so zu verstehen, dass sie die Möglichkeit ”A” oder ”B” oder ”A und B” umfasst.
Obwohl hier verschiedene Aspekte und Ausführungsformen offengelegt worden sind, sind weitere Aspekte und Ausführungsformen für Kenner der Technik offensichtlich. Die verschiedenen hier offengelegten Aspekte und Ausführungsformen dienen der Erläuterung und dürfen nicht als Einschränkung angesehen werden, wobei der Schutzumfang und der Geist von den nachfolgenden Patentansprüchen festgelegt sind.

Claims

Prozessor, der umfasst: eine Vielzahl von auf einem einzelnen Chip ausgebildeten Kernen zum Ausführen einer Vielzahl von Anweisungen; und einen auf dem einzelnen Chip ausgebildeten Kontextwechsel-Controller zum Steuern der Ausführung der Anweisungen in jedem der Vielzahl von Kernen.
Prozessor nach Anspruch 1, der ferner umfasst: einen auf dem einzelnen Chip ausgebildeten Speicher zum Speichern von Identifizierern jeder der Vielzahl von Anweisungen und den Status jeder der Vielzahl von Anweisungen.
Verfahren zum Durchführen eines Prozesswechsels, das umfasst: Empfangen eines Befehls, der eine Prozess-ID zum Identifizieren eines Prozesses enthält, zum Ausführen in einem Kontext-Controller, der in einer zentralen Verarbeitungseinheit ausgebildet ist; Zugreifen auf den Prozess auf der Basis der Prozess-ID in einem Speicher, der in der zentralen Verarbeitungseinheit ausgebildet ist; und Einplanen des Prozesses, auf den zugegriffen wird, zum Ausführen in einem einer Vielzahl von Kernen in der zentralen Verarbeitungseinheit.
Verfahren nach Anspruch 1 (Translator's note: ”1” should probably read ”3”.), das ferner umfasst: Feststellen, ob der Prozess in dem Speicher in der zentralen Verarbeitungseinheit gespeichert ist; Erzeugen eines Interrupt, wenn der Prozess nicht in dem Speicher in der zentralen Verarbeitungseinheit gespeichert ist; und Zugreifen auf eine Information bezüglich des Prozesses in einem Speicher außerhalb der zentralen Verarbeitungseinheit.
Verfahren nach Anspruch 4, das ferner umfasst: Empfangen einer Anzeige eines Registersatzes in einem Speicher außerhalb der zentralen Verarbeitungseinheit in Reaktion auf das Interrupt.
Verfahren nach Anspruch 5, das ferner umfasst: Zwischenspeichern des Registersatzes in der zentralen Verarbeitungseinheit in Reaktion auf das Empfangen der Anzeige des Registersatzes in dem Speicher außerhalb der zentralen Verarbeitungseinheit.
Verfahren zum Sichern eines Speicherblocks, das umfasst: Identifizieren eines Speicherblocks, auf den zugegriffen wird; Erzeugen einer Zugriffsmaske für den Speicherblock; und Markieren des Speicherblocks mit einer Prozessidentifizierungsinformation und der erzeugten Maske.
Verfahren nach Anspruch 7, wobei die Markierung, die eine Prozessidentifizierungsinformation enthält, und die erzeugte Maske in einer Virtuell-Speicher-Abbildtabelle in einer zentralen Verarbeitungseinheit gespeichert werden.
Verfahren nach Anspruch 7, das ferner umfasst: Empfangen einer Anforderung zum Zugreifen auf den Speicherblock, wobei die Anforderung eine Ausführungsprozessmaske enthält; Feststellen, ob die Zugriffsmaske mit der Ausführungsprozessmaske übereinstimmt; und Gewähren von Zugriff auf den Speicherblock, wenn die Zugriffsmaske mit der Ausführungsprozessmaske übereinstimmt.
Einrichtung, die eine Transaktionsverarbeitung unter Verwendung einer Mehrkernvorrichtung ermöglicht und die umfasst: eine zentrale Verarbeitungseinheit (CPU) mit einer Vielzahl von Kernen; einen Speicherbus-Controller, der über einen prozessorseitigen Bus mit der CPU gekoppelt ist; einen Hauptspeicherkern, der über einen ersten speicherseitigen Bus mit dem Speicherbus-Controller gekoppelt ist; und einen Transaktionsspeicherkern, der über einen zweiten speicherseitigen Bus mit dem Speicherbus-Controller gekoppelt ist, wobei die CPU den Datenstrom über die ersten und zweiten speicherseitigen Busse auf der Basis des Werts eines für den Speicherbus-Controller vorgesehenen Wechsels leitet.
Einrichtung nach Anspruch 10, wobei die CPU ferner einen Kontext-Controller aufweist, wobei der Kontext-Controller den Datenstrom leitet.
Einrichtung nach Anspruch 10, wobei der erste Speicher als ein Transaktionsspeicher ausgebildet ist und der zweite Speicher als ein Hauptspeicher ausgebildet ist; wobei der Wechsel als ein drei Zustände aufweisender Zugriffswechsel ausgestaltet ist; und wobei auf der Basis des Zustands des drei Zustände aufweisenden Zugriffswechsels die CPU Daten sowohl in den Transaktionsspeicher als auch den Hauptspeicher schreibt und Daten nur aus dem Hauptspeicher liest.
Einrichtung nach Anspruch 10, wobei der erste Speicher als ein Transaktionsspeicher ausgebildet ist und der zweite Speicher als ein Hauptspeicher ausgebildet ist, wobei der Wechsel als ein drei Zustände aufweisender Zugriffswechsel ausgestaltet ist; und wobei auf der Basis des Zustands des drei Zustände aufweisenden Zugriffswechsels die CPU Daten nur aus dem Transaktionsspeicher liest und nur in diesen schreibt.
Einrichtung nach Anspruch 10, wobei der erste Speicher und der zweite Speicher mit dem gleichen linearen Adressraum ausgebildet sind.
Einrichtung nach Anspruch 10, wobei der Speicher-Controller dazu ausgebildet ist, den Datenstrom von dem ersten Speicher zu dem zweiten Speicher zu leiten.
Verfahren zum Durchführen einer Speichertransaktionsverarbeitung, das umfasst: Erzeugen einer dem Prozess zugeordneten Prozess-ID (PID), wobei die PID ein Transaktions-Flag aufweist; Speichern der PID in einem Abbild des virtuellen Speichers; Ausführen eines der PID zugeordneten Thread, wobei der Thread entsprechend dem Abbild des virtuellen Speichers mit dem Speicher interagiert; und Ausgeben einer der PID zugeordneten Anweisung zum Leiten des Datenstroms zwischen einem Transaktionsspeicherkern und einem Hauptspeicherkern.
Verfahren nach Anspruch 16, das ferner umfasst: Erstellen eines Prozesskontextes für einem dem Prozess zugeordneten Thread; Ausführen des Thread auf der Basis des Prozesskontextes; und Ausgeben einer Prozessbeendigung zum Entfernen des Prozesskontextes.
Verfahren nach Anspruch 17, das ferner umfasst: Ausgeben einer der PID zugeordneten Transaktions-Commit-Anweisung; und Kopieren mindestens eines der PID zugeordneten virtuellen Speicherblocks zwischen dem Transaktionsspeicherkern und dem Hauptspeicherkern.
Verfahren nach Anspruch 17, das ferner umfasst: Ausgeben einer der PID zugeordneten Transaktions-Zurücksetzungs-Anweisung; und Kopieren mindestens eines der PID zugeordneten virtuellen Speicherblocks von dem Transaktionsspeicherkern in den Hauptspeicherkern.
Verfahren nach Anspruch 16, das ferner umfasst: Zuordnen der PID zu einer virtuellen und physischen Speicheradresse; und Steuern eines Zugriffs-Flag auf der Basis des Transaktions-Flag.