Speicherkonsistenzmodelle

Ein Speicherkonsistenzmodell legt fest, welche Werte Lesezugriffe beobachten können, wenn gleichzeitige Threads auf gemeinsam genutzten Speicher zugreifen, und definiert die Reihenfolgegarantien, auf die sich Programmierer verlassen können.

Definition

Ein Speicherkonsistenzmodell ist eine formale Spezifikation der Werte, die Leseoperationen in einer gleichzeitigen Ausführung zurückgeben können, wobei die Reihenfolge der Speicherzugriffe festgelegt wird, die die Sprache, der Compiler und die Hardware einhalten müssen.

Scope

Dieses Thema behandelt das Spektrum der Konsistenzmodelle von sequentieller Konsistenz bis hin zu relaxierten und schwachen Modellen, die Happens-Before-Relation und Daten-Race-freie Garantien, Hardware-Speicherordnungen (wie Total Store Order) und Speichermodelle auf Sprachebene für C++ und Java. Es wird erläutert, warum relaxierte Modelle existieren, wie Fences und Atomics die Reihenfolge wiederherstellen und wie man über gleichzeitigen Speicher fundiert argumentiert.

Core questions

• Welche Reihenfolgen von Speicheroperationen darf ein Programm legal beobachten?
• Warum existieren relaxierte Speichermodelle und was erlauben sie?
• Wie vereinfacht die Daten-Race-freie Garantie die Argumentation?
• Wie erzwingen Fences und atomare Operationen die Reihenfolge?

Key theories

Sequentielle Konsistenz

Lamport definierte die sequentielle Konsistenz, bei der eine Multiprozessor-Ausführung als eine einzige Verschachtelung von Operationen erscheinen muss, die die Programmreihenfolge jedes Prozessors respektiert, das stärkste intuitive Basismodell.

Relaxierte Konsistenz und die SC-für-DRF-Garantie

Adve und Gharachorloo erläutern relaxierte Modelle und das Prinzip, dass Daten-Race-freie Programme sich verhalten, als wären sie sequentiell konsistent, wodurch Leistung und Programmierbarkeit in Einklang gebracht werden.

Speichermodelle auf Sprachebene

Manson, Pugh und Adve formalisierten das Java-Speichermodell unter Verwendung einer Happens-Before-Relation, die definiert, welche Optimierungen legal sind und welche Garantien selbst racy Programme erhalten.

Clinical relevance

Da Mehrkernprozessoren und optimierende Compiler Speicheroperationen neu anordnen, sind Speichermodelle auf Sprachebene unerlässlich, um korrekten, portablen nebenläufigen Code zu schreiben. Sie teilen Programmierern mit, wann Synchronisation erforderlich ist, und definieren die Garantien, die Bibliotheken und Laufzeiten bieten können.

History

Lamport formalisierte die sequentielle Konsistenz 1979. Als die Hardware aus Leistungsgründen relaxierte Ordnungen einführte, kodifizierte Adve und Gharachorloos Tutorial von 1996 die Landschaft der Konsistenzmodelle und das Daten-Race-freie Framework. Sprachdesigner bauten dann Speichermodelle in Spezifikationen ein, wobei das Java-Speichermodell (2005) und das C++11-Speichermodell den modernen Ansatz etablierten.

Debates

Semantik von racy Programmen

Eine schwierige Frage ist, welche Garantien, wenn überhaupt, Programmen mit Daten-Races gegeben werden sollen; Sprachmodelle müssen 'aus dem Nichts' auftauchende Werte verhindern, während sie dennoch aggressive Compiler- und Hardware-Optimierungen zulassen.

Key figures

• Leslie Lamport
• Sarita Adve
• Kourosh Gharachorloo
• William Pugh
• Jeremy Manson

Seminal works

• lamport1979
• adve1996
• manson2005

Frequently asked questions

Warum verwenden nicht alle Systeme einfach sequentielle Konsistenz?

Sequentielle Konsistenz verbietet viele Compiler- und Hardware-Optimierungen, die die Leistung verbessern. Daher verwenden die meisten realen Systeme relaxierte Modelle und stellen Synchronisationsprimitive bereit, um eine stärkere Ordnung nur dort wiederherzustellen, wo sie benötigt wird.

Was ist die Daten-Race-freie Garantie?

Unter vielen Speichermodellen von Programmiersprachen wird einem Programm, das keine Daten-Races enthält (alle widersprüchlichen Zugriffe sind ordnungsgemäß synchronisiert), garantiert, dass es sich so verhält, als wäre der Speicher sequentiell konsistent.