SCC4TM
Speculative Concurrency Control for Transactional Memory
Beginn | 1. September 2011 |
Ende | 31. Dezember 2014 |
Finanzierung | Technische Universität Hamburg-Harburg |
Projektbeschreibung
Durch die Veränderungen auf dem Markt von Personal-Computern hin zu Prozessoren mit mehreren Cores (Recheneinheiten) werden zunehmend mehr parallele Programme entwickelt, die nebenläufig mehrere Aufgaben in separaten Ausführungssträngen (Threads/Prozessen) gleichzeitig lösen. Der Zugriff auf gemeinsame Daten im Hauptspeicher muss dabei kontrolliert werden, um Inkonsistenzen zu vermeiden. Beispielsweise können hierzu die gemeinsamen Daten für die Zeit der Benutzung gesperrt werden, sodass nur ein Ausführungsstrang exklusiven Zugriff erhält. Ausführungsstränge, die nicht auf denselben Daten arbeiten, müssen dann aber ebenfalls warten. Alternativ kann der Datenraum zerlegt werden und ein Ausführungsstrang sperrt immer nur die Abschnitte, die er braucht. Bei falscher Verwendung treten dabei Verklemmungen zwischen Ausführungssträngen auf: Ausführungsstrang A besitzt eine Sperre auf ein Datum a und benötigt ein Datum b, das aber im Besitz eines Ausführungsstrangs B ist, welcher seinerseits das Datum a benötigt -- beide Ausführungsstränge warten ewig. Eine Alternative zum manuellen kontrollieren nebenläufiger Datenzugriffe durch den Programmierer ist die Verwendung von sogenanntem Transaktionalen Speicher (engl. Transactional Memory, abk. TM). Dabei werden die kritischen Operationen auf gemeinsamen Daten in sogenannten Transaktionen zusammen gefasst und der Datenzugriff wird durch eine Nebenläufigkeitskontrolle (engl. Concurrency Control, abk. CC) automatisch kontrolliert. Charakteristische Eigenschaft von CC für Transaktionen ist das Rollback: Bei auftretenden Inkonsistenzen oder Verklemmungen wird die in einer Transaktion bisher geleistete Arbeit verworfen und von vorn begonnen. Damit werden auch einige Operationen verworfen, die nicht Ursache des Konflikts waren. Daher existieren Verfahren, die Transaktion in Teilabschnitte zu zerlegen und bei einem Rollback möglichst nahe an den Punkt der Entstehung des Konflikts zurückzufahren. Diese Vorschläge sind von der Programmstruktur abhängig und machen dadurch die parallele Programmierung komplizierter. Auch verursachen sie Mehraufwand für das CC, der im gleichen Ausführungsstrang geleistet werden muss. Ziel dieses Vorhabens ist es, durch den Einsatz von zusätzlichen Cores, das CC für TM weiter zu optimieren. Dazu soll ein Ausführungsstrang in einer Transaktion in mehrere Ausführungsstränge aufgespalten werden, die jeweils auf eigenen Cores ausgeführt werden. Die Ansätze zur Optimierung reichen von der einfachen Verlagerung des Arbeitsaufwandes des CC in separate Ausführungsstränge über die Lösung von Problemen von CC im gleichen Ausführungsstrang bis hin zur gleichzeitigen, spekulativen Ausführung alternativer Programmverläufe für eine einzige Transaktion.