Transaktionalen Speicher optimieren mit STO

Transkript

1 Transaktionalen Speicher optimieren mit STO Schriftliche Ausarbeitung zum Hauptseminar Martin Rabe Technische Universität Ilmenau 6. Februar 2017 Abstract Um die meiste Performance aus heutigen Multikernprozessoren heraus zu holen ist es nötig, dass die Anwendungsprogramme einen hohen Parallelisierungsgrad unterstützen. Dies stellt die Anwendungsprogrammierer vor neue Herausforderungen. Die aktuellen Mechanismen zur Synchronisation solcher Anwendungen in Betriebssystemen sind sehr komplex, fehleranfällig und ab einem gewissen Parallelisierungsgrad nicht mehr performant. Transaktionaler Speicher ist eine vielversprechende Alternative, die sich aber noch in der Entwicklungsphase befindet. Die in dieser Arbeit vorgestellte Softwareimplementierung von Transaktionalem Speicher stellt eine Möglichkeit dar die Performanceprobleme konventioneller Implementierung von Transaktionalem Speicher zu lösen. Dies geschieht indem die Semantik von Datenstrukturen ausgenutzt wird. Dadurch werden Protokollierungskosten minimiert und die False-Conflict-Vermeidung maximiert. 1 Einführung 1.1 Free Lunch is over Der Perfomancegewinn durch immer schnellere Prozessoren kann nicht weiter gesteigert werden. Seit 2004 sind die Taktraten von Prozessoren nicht mehr deutlich gewachsen. Dies begründet sich darin, dass die Technik an physikalische Grenzen gestoßen ist. Diese Grenzen sind zum Einen der Stromverbrauch der Prozessoren und zum Anderen die immer mehr werdende Wärme, die abgeleitet werden muss. Dieser fehlende Zuwachs an Taktrate stellt die Softwareentwickler vor neue Herausforderungen. Konnten sie sich bis jetzt immer darauf verlassen, dass performanzhungrige Anwendungen von der ständig steigenden Prozessorperformanz abgefangen werden, ist dies nun nicht mehr so. Allerdings wächst die Transistorzahl in den Prozessoren weiter an. Das bedeutet, die Lösung des Problems der Softwareentwickler besteht darin, dass eine Unterstützung an Parallelität aufseiten der Anwendungsprogramme vonnöten ist. Leider bringt diese parallele Abarbeitung neue Anforderungen an die Programme mit sich. So muss zum Beispiel dafür gesorgt werden, dass zwei Prozesse, die parallel auf die gleiche Datenstruktur im Speicher zugreifen, synchronisiert werden. 1

2 1.2 State of the Art In aktuellen Betriebssystemen wird das Problem der Synchronisation mehrerer Prozesse (Nebenläufigkeitsproblem) mit Hilfe von Semaphoren gelöst. Eine Semaphore ist ein abstrakter Datentyp der eine Methode zum Sperren (P-Operation) und eine Methode zum Freigeben (V-Operation) besitzt. Dabei kann immer nur ein Prozess eine Semaphore sperren, alle anderen müssen warten. Abbildung 1: Das Erzeuger-Verbraucher-Problem. Als Beispiel zeigt Abb. 1 wie zwei Prozesse synchronisiert werden können, von denen einer Daten in einen gemeinsamen Puffer schreibt und der andere Prozess aus diesem Puffer liest. Dieses Beispiel löst dabei die Probleme des wechselseitigen Ausschlusses, d.h. immer nur einer der beiden Prozesse kann auf die geteilte Ressource zugreifen, und den Schutz vor Puffer Über- und Unterlauf. Wie zu erkennen ist benötigt die Lösung dieses einfachen Problems bereits drei Semaphoren. Des Weiteren ist der erzeugende Prozess davon abhängig, dass der verbrauchende Prozess die Semaphore zum Schutz vor Über- und Unterlauf korrekt freigibt und auch umgekehrt. Das bedeutet, dass die Benutzung von Semaphoren ein großes Fehlerpotenzial bietet, falls bei der Implementierung von Anwendungen auch nur eine V-Operation oder eine P-Operation vergessen wird. Im ersten Fall könnte es passieren, dass zwei Prozesse gleichzeitig auf eine gemeinsame Datenstruktur zugreifen. Im zweiten Fall wird eine Semaphore nicht wieder freigegeben und somit können andere Prozesse die diese Semaphore benutzen wollen nicht weiter arbeiten. Des Weiteren bedeutet jede Sperrung einer Semaphore, dass alle anderen Prozessorkerne angehalten werden müssen um ein gleichzeitiges Sperren von Semaphoren zu verhindern, was zu einer starken Einschränkung der parallelen Abarbeitung von Prozessen führt. 1.3 Transaktionale Systeme Um eine bessere Lösung des Nebenläufigkeitsproblems als durch Semaphoren zu erhalten, kann eine Technik aus den Datenbanksystemen übernommen werden. Datenbanksysteme benutzen Transaktionen um parallele Zugriffe auf Tabellen zu ermöglichen. Eine Transaktion besteht aus einer Arbeitsphase (AP) und einer Commit-Phase (CP). In der AP wird auf einer lokalen Kopie der Daten gearbeitet und in der CP wird mittels Versionsnummern 2

3 überprüft ob in der AP Konflikte mit anderen Transaktionen entstanden sind. Falls Konflikte entstanden sind wird die Transaktion abgebrochen, falls nicht werden die lokalen Änderungen global sichtbar gemacht. In Abb. 2 sieht man den Aufbau eines Transaktionalen Systems, welches den korrekten parallelen Zugriff auf Tabellen gewährleistet. Bei diesem Aufbau setzt der Transaktions-Manager (TM) die Eigenschaften um, die eine gleichzeitige Nutzung der Objekte ermöglichen. Der TM weiß wann eine Transaktion beginnt bzw. aufhört und welche Objekte von ihr benutzt wurden. Somit kann er die Eigenschaften Atomarität, Konsistenz, Isolation und Dauerhaftigkeit umsetzten. Diese Eigenschaften gewährleisten, dass parallele Zugriffe auf die Tabellen über den TM fehlerfrei erfolgen. Abbildung 2: Aufbau eines Transaktionalen Systems. Somit ist ein Transaktionales System für Softwareentwickler einfacher zu benutzen als Semaphoren, da nur noch festgelegt werden muss, wann eine Transaktion beginnt und aufhört. Um den Rest kümmert sich das Transaktionale System. 1.4 Transaktionaler Speicher Für die Benutzung von Transaktionalen Systemen für Speicherzugriffe haben sich zwei Implementierungsansätze herausgebildet. Zum einen wird Transaktionaler Speicher in Hardware umgesetzt und zum anderen in Software. Hardware Transaktionaler Speicher (HTS) ist performanter als Software Transaktionaler Speicher (STS). Aber STS lässt sich vor allem in dem jetzigen Entwicklungsstadium, in dem neue Konzepte ausprobiert werden, vor allem für die Wissenschaft leichter nutzen, da er einfacher anzupassen ist als HTS. Die im Folgenden vorgestellte Umsetzung von Transaktionalem Speicher basiert auf Software und versucht die Performanzprobleme konventioneller STS-Implementierungen zu lösen. Diese Probleme sind vor allem, dass gängige Implementierungen von STS auf Speicherwort-Granularität arbeiten (ein Vertreter dieser Art ist TL2) und somit sehr hohe Protokollierungskosten haben. Ein weiterer Ansatz um die Performanz zu steigern ist die Vermeidung von False-Conflicts. Als Beispiel eines False-Conflicts wird folgende Datenstruktur betrachtet: struct { string name; int age; } 3

4 Wenn diese Datenstruktur mit nur einer Versionsnummer versehen ist, würden zwei parallele Transaktionen, bei der die eine die Variable name und die andere die Variable age verändert, in Konflikt stehen. Somit müsste eine von beiden abbrechen, was verschwendete Arbeit bedeutet, da kein wirklicher Konflikt vorlag. Die im Folgenden vorgestellte STS-Implementierung STO versucht die Performanzprobleme konventioneller STS zu beseitigen. Das Paper ist im Weiteren wie folgt gegliedert. In Kapitel 2 werden die grundlegenden Konzepte, auf denen STO basiert, erklärt. Danach wird in Kapitel 3 die Implementierung beschrieben. Dann wird in Kapitel 4 erläutert wie STO von Anwendungsentwicklern in Programmen genutzt werden kann. In Kapitel 5 wird die Implementierung von STO evaluiert und in Kapitel 6 wird eine Zusammenfassung gegeben. 2 Konzepte In diesem Kapitel werden die Konzepte von STO erläutert. STO steht für Software Transaktionale Objekte. Es ist schneller als konventionelle Implementierungen von STS, da es auf abstrakten Datentypen arbeitet und nicht auf Speicherwort-Granularität. Es senkt durch die Nutzung dieser Datentypen den Protokollierungsaufwand und steigert gleichzeitig durch Ausnutzung der Semantik von Datentypen die False-Conflict-Vermeidung. Das Commit-Protokoll arbeitet mit abstrakten Lese-, Schreiboperationen und Prädikaten auf Datentypen, anstatt konkreten Speicherzugriffen. Die Prädikate sind eine von den Verfassern neu entwickelte Methodik für die False-Conflict-Vermeidung. Sie beschreiben eine Bedingung unter der ein erfolgreicher Commit stattfinden darf (eine genauere Beschreibung findet in Kapitel 3.4 statt). Die Prädikate stellen somit eine Alternative zu den Versionsnummervergleichen dar. Die Datenstrukturen unterstützen das Commit-Protokoll und setzen die konkreten Sperren, Versionsverifikation und Datenstrukturveränderungen durch. Wegen dieser Ausnutzung von Datenstrukturen und ihrer Semantik gibt es viel weniger Objekte zu protokollieren als zum Beispiel bei dem bereits erwähntem STS TL2. 3 Implementierung In diesem Kapitel wird die Implementierung von STO erläutert. 3.1 Aufbau Abb. 3 zeigt den Aufbau von STO. Dabei können die für die Umsetzung eines Transaktionalen Systems wichtigen Komponenten in zwei Bestandteile unterteilt werden. Zum einen ist das der STO- Kern und zum anderen ist das eine Bibliothek mit transaktionalen Datentypen. Der Kern implementiert das Commit-Protokoll. Zu diesem Zweck enthält er ein je Thread ein Tracking-Set, welches die von diesem Thread ausgeführten Operationen auf den Datentypen protokolliert. Damit wird also eine Transaktion repräsentiert. Dieses Tracking-Set ist ein Array von transaktionalen Items. Diese enthalten jeweils die Lese-Version, den geschriebenen Wert oder ein Prädikat. Die Bibliothek enthält die transaktionalen Datentypen, welche so implementiert sein müssen, dass sie einen nebenläufigen Zugriff von unterschiedlichen Threads unterstützen und ihre Operationen transaktionssicher sind, d.h. ACI-Eigenschaften erfüllen. Dies erzwingt drei Voraussetzungen: 4

5 Abbildung 3: Aufbau von STO. Versionsnummern Die Versionsnummern werden benötigt um Aktualisierungen zu verfolgen. Tracking-Set-Integration Um das Tracking-Set zu integrieren müssen folgende drei Dinge beachtet werden: Bei jedem Lesezugriff muss die gelesene Versionsnummer vermerkt werden. Jedes mal wenn logisch der Objektzustand verändert wird müssen Informationen über die Modifikation in das Tracking-Set gespeichert werden. Wenn eine Transaktion einen Zustand liest, den sie bereits selbst verändert, hat muss das Tracking-Set nach ausstehenden Veränderungen durchsucht werden und diese müssen genutzt werden. Des Weiteren müssen alle Commit- und Abort-Aktionen im Tracking-Set vermerkt werden (z.b. Validation, Installation, Rollback). Commit-Unterstützung Die Commit-Unterstützung der Datentypen ermöglicht es Datentypenwicklern große Flexibilität (z.b. können Sperren pessimistisch gesetzt werden). In der von den Autoren zur Verfügung gestellten Bibliothek gibt es bereits vorimplementierte Datentypen von Vektoren und Bäumen bis hin zu Hash-Tabellen. Zusätzlich existiert auch einen Datentyp TGeneral, der als Schnittstelle zur Speicherwort-Granularität genutzt werden kann. Die Bibliothek kann aber auch nach Bedarf beliebig erweitert werden. 3.2 Beispieldatentyp Im Folgenden wird die Implementierung eines transaktionalen Datentyps am Beispiel erklärt. Dies wird anhand des Datentyps TBox<T> durchgeführt. Dieser Datentyp ist ein Wrapper für einen Datentyp wie z.b. int. Ein transaktionales Lesen wird dabei wie folgt implementiert: operator T() const { auto item = Sto::item(this, 0); if (item.has_write()) return item.write_value<t>(); else return item.read(value_, vers_); } 5

6 Dabei setzt diese Operation die im letzten Kapitel aufgezeigten Eigenschaften durch. So wird, wenn die Transaktion schon auf dieses Objekt geschrieben hat, der Wert aus dem Tracking-Set und nicht vom globalen Zustand gelesen. Als nächstes wird ein Beispiel der Integration des Commit-Protokolls in den Datentypen betrachtet. Dieses Beispiel implementiert die Übertragung der lokalen Änderungen auf den globalen Zustands: // commit callbacks: void install(titem item) { value_.store(item.write_value<t>()); vers_.set_version(sto::commit_id()); } Dabei ist zu erkennen, dass die neue Version immer gleich der Commit-ID gesetzt wird. Als letztes noch ein Beispiel der von diesem Datentyp zur Verfügung gestellten Nutzdaten: private: TWrapped<T> value_; 3.3 Commit-Protokoll In Abb. 4 ist der Ablauf des Commit-Protokolls dargestellt. Es basiert auf dem 2-Phasen-Multiserver- Commit-Protokoll, dessen beide Phasen jeweils nochmal in zwei Unterphasen geteilt wurden. Es läuft somit in vier Phasen ab: Phase 1 In Phase 1 wird zunächst versucht alle modifizierten Datentypen zu sperren. Falls dies nicht möglich ist, da zum Beispiel gerade eine andere Transaktion diesen Datentyp gesperrt hat, kommt es zum Abbruch der Transaktion und es geht mit der Phase Cleanup weiter. Falls alle Datentypen korrekt gesperrt werden konnten geht es mit der Phase 2 weiter. Phase 2 In Phase 2 werden alle im Tracking-Set gespeicherten Leseversionsnummern mit den aktuell im globalen Zustand vorhandenen verglichen. Falls eine Versionsnummer des Tracking-Sets nicht mit der Versionsnummer des globalen Zustandes übereinstimmt kam es in der Zwischenzeit zu einer Veränderung des gelesenen Wertes und somit zu einem Konflikt. Somit muss die Transaktion abbrechen, d.h. es geht mit Phase Cleanup weiter. Falls alle Versionsnummern übereinstimmen geht es mit Phase 3 weiter. Phase 3 An dieser Stelle sind alle Konfliktprüfungen erfolgreich abgeschlossen und es kommt zum Commit. Dazu werden in Phase 3 alle lokalen Änderungen global sichtbar gemacht und die zugehörigen Versionsnummern werden aktualisiert. Danach geht es weiter mit der Phase Cleanup. Phase Cleanup Die Cleanup Phase wird immer ausgeführt, auch bei einem Abbruch der Transaktion. In dieser werden eventuelle Sperren wieder freigegeben und Aufräumarbeiten auf den Datenstrukturen durchgeführt. 3.4 Beispiel: False-Conflict-Vermeidung und Prädikate Im Folgenden wird die Möglichkeit der False-Conflict-Vermeidung unter Ausnutzung der Semantik von Datentypen näher erklärt. Des Weiteren wird die von den Autoren neu entwickelte Methodik 6

7 Abbildung 4: Das Commit-Protokoll von STO. der Prädikate vorgestellt. Dies wird anhand des Beispieldatentyps eines Zählers erläutert. Der Zähler hat drei Operationen increment, decrement und test, wobei increment und decrement +1 bzw. -1 rechnen und nichts zurückgeben. Die Operation test gibt true zurück falls der Zähler größer als 0 ist, sonst false. Bei einer naiven Implementierung lesen und schreiben sowohl increment also auch decrement. Somit stehen beide in Konflikt. test liest nur und steht dadurch mit anderen Ausführungen von test nicht in Konflikt, aber mit parallelen increment und decrement. Eine Implementierung sollte aber solche Konfliktabhängigkeiten nach Möglichkeit vermeiden. In diesem Beispiel ist das möglich, da increment und decrement den aktuellen Wert des Zählers nicht nach außen sichtbar machen. Somit reicht es ein akkumuliertes Delta im Tracking-Set zu vermerken und zur Commit-Zeit anzuwenden. Bei der Operation test funktioniert das nicht, da bei ihr der momentane Zustand nach außen sichtbar wird. Hier kommt die Methodik der Prädikate zum Einsatz. Diese ermöglicht, es anstatt den genauen Wert zu lesen und dessen Versionsnummer in das Tracking-Set zu speichern, ein Prädikat, welches die momentane Eigenschaft des Wertes beschreibt, in das Tracking-Set zu speichern. In diesem Beispiel würde das bedeuten: [1, ], falls test true [, 0], falls test false Diese Prädikate sind datentypspezifisch und werden anstelle von den Leseversionsnummern im Tracking-Set gespeichert. Im Commit-Protokoll werden sie ausgewertet und in Leseversionsnummern umgewandelt. Dies geschieht in Phase 1, somit kann das Commit-Protokoll sonst unverändert umgesetzt werden. Die Benutzung von Prädikaten verursacht allerdings einen Overhead, welcher sich nur unter bestimmten Einsatzzwecken lohnt. Eine genaue Betrachtung dieses Phänomens findet in der Evaluation statt. 4 Integration In diesem Kapitel wird gezeigt wie STO von Anwendungsentwickler genutzt werden kann. Neben dem Einbinden der Bibliothek ist während der Programmierung nur ein Markieren der kritischen 7

8 Abschnitte, welche durch das Transaktionale System geschützt werden sollen, vonnöten. Dies geschieht durch das Umschließen des Abschnittes durch TRANSACTION und RETRY. Bei RETRY kann zusätzlich noch eine Bedingung angegeben werden, unter der bei Abbruch der Transaktion eine erneute Ausführung statt finden soll. Des Weiteren müssen alle Objekte, welche von mehreren Prozessen benutzt werden, durch transaktionale Datentypen repräsentiert werden. Objekte, welche nur lokal genutzt werden, können ganz normal verwendet werden. Im Folgenden ein Beispiel einer Funktion die eine Banküberweisung durchführt: bool transfer(tbox<int>& bal1, TBox<int>&bal2, int amt) { TRANSACTION { if (amt < 0 bal1 < amt) return false; bal1 = bal1 - amt; bal2 = bal2 + amt; } RETRY(true); return true; } 5 Evaluation 5.1 Grundlagen In diesem Kapitel werden die Grundlagen der Evaluation erläutert. Die Hypothese, welche mit der Evaluation überprüft werden soll, ist: STO könnte performanter als konventionelle Implementierungen für STS sein, da es nicht auf Speicherwort-Granularität sondern auf Datentypen basiert und zusätzlich noch deren Semantik ausnutzt. Die in der Evaluation genutzte Umgebung ist STAMP [MCKO08]. STAMP ist eine etablierte Testumgebung mit der schon viele HTS- und STS-Implementierungen getestet wurden. Es ist mit dem bereits in der Einleitung erwähnten TL2 implementiert. Es benutzt viele Datentypen wie Listen, Warteschlangen und Zuweisungen, aber auch einige Zugriffe auf Speicherwort-Granularität, wofür der STO Datentyp TGeneral benutzt wird. 5.2 Szenarien Die in der Evaluation untersuchten Szenarien setzen sich aus einer großen Breite an Einsatzgebieten zusammen. Im Detail sind das: Intruder Intruder ist ein Szenario aus der Netzwerksicherheit. Bei diesem Test wird ein Network Intrusion Test durchgeführt. Genome Genome kommt aus der Bioinformatk und führt eine DNA-Sequenzierung durch. 8

9 Kmeans Kmeans kommt aus dem Bereich des Data-Mining und implementiert eine K-means Clustanalyse. Labyrinth Labyrinth kommt aus dem Ingenieurwesen und führt eine Routenplanung in einem Labyrinth durch. Vacation Vacation kommt aus der Online-Transaktionsverarbeitung und repräsentiert ein Reisebuchungssystem. 5.3 Ergebnisse In Abb. 5 sind die Ergebnisse der Evaluation bei den verschiedenen Szenarien dargestellt. Die Tests wurden sowohl mit 4 als auch mit 16 Kernen durchgeführt. Die Balken geben die Beschleunigung gegenüber der sequenziellen Ausführung des selben Test an. In dieser vielfältigen Reihe von Szenarien ist STO immer besser als TL2. Der größte Zuwachs ist bei dem Intruder-Szenario zu bemerken. Das liegt daran, dass Intruder viele Listen benutzt, welche bei dem auf Speicherwort basierten TL2 zu großen Tracking-Sets führt. So hat das größte Tracking-Set von TL2 40x mehr Items als das größte Tracking-Set von STO zu protokollieren. Abbildung 5: Ergebnisse der Evaluation bei 4 und 16 Kernen. Eine andere interessante Entwicklung zeigt sich bei dem Vacation-Szenario. Dieser Test wurde in zwei verschiedenen Versionen durchgeführt. Einmal mit gleich verteilten Zugriffen auf alle vorhandenen Datentypen und einmal mit beschränkten Zugriffen auf nur 1% der vorhandenen Daten, wodurch sich ein sehr große Wahrscheinlichkeit für Konflikte ergibt. Bei diesem Szenario lässt sich besonders gut erkennen, welchen Einfluss die Prädikate auf die False-Conflict-Vermeidung haben. Ohne Prädikate stellt die parallele Reservierung von einem Gut einen Konflikt dar, auch wenn sie eigentlich nicht in Konflikt stehen, wenn genügend Güter zur Verfügung stehen. Prädikate können genutzt werden um die Existenz von mehr als den zu buchenden Gütern zu prüfen und nicht den genauen Wert. Dadurch zeigen die Prädikate bei beschränktem Zugriff auf die Datentypen großes 9

10 Potenzial in der Vermeidung von False-Conflicts. Transaktionen von STO mit Prädikaten haben eine relativ geringe Abbruchrate. Bei 16 Kernen ist die Beschleunigung 4.3x größer als bei STO ohne Prädikaten, welches im diesem Szenario sogar langsamer ist als die sequenzielle Ausführung. Bei normal verteilten Zugriffen auf alle Datentypen stellt allerdings die Benutzung von Prädikaten einen so großen Overhead da, dass hier die Beschleunigung kleiner ist als bei STO ohne Prädikaten. Um zu zeigen, dass der Zuwachs auch an der Datenstrukturnutzung liegt wurde STAMP auch mit STO unter ausschließlicher Benutzung des Datentyps TGeneral getestet. Also auf Speicherwort- Granularität ohne Ausnutzung der Semantik der Datenstrukturen. Die Resultate dieses Tests waren vergleichbar mit denen von TL2. Somit liegt es wirklich an der Datenstrukturnutzung und nicht an eventuellen andere performanteren Herangehensweisen von STO. 6 Zusammenfassung Um die Effizienzprobleme konventioneller Software Transaktionaler Speicher Implementierungen zu lösen wurde der Ansatz von Software Transaktionalen Objekten erklärt. Dieser Ansatz verringert die Protokollierungskosten von Implementierungen auf Basis von Speicherwort-Granularität durch Ausnutzung von Datenstruktur-Granularität. Zusätzlich wird durch die Beachtung der Semantik dieser Datenstrukturen die False-Conflict-Vermeidung erhöht. Die vorgestellte Methodik der Prädikate erhöht die False-Conflict-Vermeidung in sehr Konflikt starken Anwendungen. Diese Methodik ist aber mit hohem Overhead verbunden und führt bei konfliktarmen Anwendungen zu einer Verschlechterung der Performance. In der Evaluation wurde anhand verschiedener Anwendungsszenarien gezeigt, dass dieser Ansatz konventionellen Software Transaktionalen Speicher Implementierungen auf Basis von Speicherwort- Granularität überlegen ist. Des Weiteren bietet STO die Möglichkeit durch die Entwicklung eigener transaktionaler Datentypen eine Optimierung für spezielle Anwendungsprogramme an. Literatur [HIH + 16] [Kü] Nathaniel Herman, Jeevana Priya Inala, Yihe Huang, Lillian Tsai, Eddie Kohler, Barbara Liskov, and Liuba Shrira. Type-aware transactions for faster concurrent code. In Proceedings of the Eleventh European Conference on Computer Systems, EuroSys 16, pages 31:1 31:16, New York, NY, USA, ACM. Winfried E. Kühnhauser. Betriebssysteme. media/vsbs/ws_2016/betriebssysteme/kap2.pdf. [Online; Zugriff ]. [MCKO08] Chi Cao Minh, JaeWoong Chung, Christos Kozyrakis, and Kunle Olukotun. Stamp: Stanford transactional applications for multi-processing. In Proc. IEEE Int l Symp. on Workload Characterization (IISWC 08), page 35 46, [Sut05] Herb Sutter. The Free Lunch Is Over. concurrency-ddj.htm, [Online; Zugriff ]. 10