Ich bin verwirrt, weil aus dem Lesen der Wiki-Seite es scheint, nur ein checkValidate und Commit-System für Lasten und speichert. Ist der Zweck, Synchronisationsprobleme zu lösen? Ist es eine Softwareprogrammierung, die auf aktueller Hardware aufbaut, oder ist es eine Hardwareimplementierung über eine ISA? Was ist der Unterschied zwischen jeder Implementierung (HW/SW)?Was ist Transaktionsspeicher?
Danke.
Auf Transaktionsebene ist Transaktionsspeicher Teil der Cache-Ebene. Es erlaubt der Software, einige Operationen im Speicher zu "versuchen" und sie dann später zu "committen", wenn keine anderen Multiprozessoren im System irgendeinen Speicher geändert haben, der gelesen oder geschrieben wurde. In sehr parallelen SMP-Umgebungen, in denen die meisten Zugriffe nicht kollidieren, kann dies schneller sein, als wenn alle Threads dieselben (stark beanspruchten) Synchronisationsgrundelemente sperren.
Dies macht jedoch die Aufgabe des Anwendungsprogrammierers schwieriger, da die Software in der Lage sein muss, die Transaktion wiederherzustellen ("Rollback"), wenn die Übertragung fehlschlägt.
Vom gcc Wiki:
In general, implementations come in two forms: a Software Transactional Memory (STM) system uses locks or other standard atomic instructions to do its job. A Hardware Transactional Memory (HTM) system uses multi-word synchronization operations of the CPU to implement the requirements of the transaction directly (e.g., see the Rock processor). Because most HTM systems are likely to be best effort facilities (i.e., not all transactions can be executed using HTM), practical TM implementations that incorporate HTM also have a STM component and are thus termed Hybrid Transactional Memory systems.
Transactional Memory ist das Konzept der Transaktionen statt Sperren unter Verwendung von Prozessen zu synchronisieren, die parallel ausgeführt werden und einen gemeinsamen Speicher zu.
Bei einer sehr vereinfachten Ebene mit Schlössern synchronisieren Sie Codeabschnitte identifizieren (kritische Abschnitte genannt), die gleichzeitig von verschiedenen Threads ausgeführt werden darf und erwerben und Verschlüsse um die kritischen Abschnitte. Da jede Sperre nur von jeweils einem Thread gehalten werden kann, ist gewährleistet, dass nach dem Eintreten eines Threads in einen kritischen Abschnitt alle Operationen des Abschnitts abgeschlossen sind, bevor ein anderer Thread in einen kritischen Bereich gelangt, der durch die gleiche (n) Sperre (n) geschützt ist.
Mit dem Transaktionsspeicher können Sie Codeabschnitte als Transaktionen festlegen. Das transaktionale Speichersystem (das in Hardware, Software oder beidem implementiert werden kann) versucht dann, Ihnen die Garantie zu geben, dass jeder Lauf eines Programms, in dem mehrere Threads Transaktionen parallel ausführen, einem anderen Lauf des Programms entspricht, in dem die Transaktionen werden nacheinander ausgeführt, niemals gleichzeitig.
Das transaktionale Speichersystem ermöglicht dies, indem Transaktionen parallel ausgeführt werden und ihr Zugriff auf Transaktionsvariablen überwacht wird. Wenn das System einen Konflikt zwischen dem Zugriff zweier Transaktionen auf dieselbe Variable feststellt, wird einer von ihnen den Vorgang abbrechen und an den Anfang der ausgeführten Transaktion "zurückrollen". Die Transaktion wird dann automatisch neu gestartet, und der Gesamtzustand des Systems ist so, als hätte es den vorherigen Lauf nie gestartet.
Ein Ziel des Transaktionsspeichers ist die einfache Programmierung und Sicherheit; Ein korrekt implementiertes TM-System, das die korrekte Verwendung der Transaktionen erzwingt, gibt Garantien, dass es keine Parallelitätsfehler (Deadlocks, Race Conditions, etc.) im Programm gibt und nur erfordert, dass der Programmierer die Transaktionen bestimmt (und manchmal Transaktionsvariablen, wenn das System nicht nur den gesamten Speicher implizit als Transaktionsvariablen betrachtet), ohne genau ermitteln zu müssen, welche Sperren benötigt werden, erfassen Sie sie in der richtigen Reihenfolge, um Deadlocks usw. zu vermeiden."Transacitons werden korrekt verwendet" impliziert, dass es keine gemeinsame Nutzung von Daten zwischen Threads ohne Transaktionsvariablen, keinen Zugriff auf Transaktionsdaten außer Transaktionen und keine "nicht rückrechenbaren" Operationen in Transaktionen gibt; Bibliotheksbasierte Softwaretransaktionsspeichersysteme für imperative Sprachen wie C, Java usw. sind im Allgemeinen nicht in der Lage, all dies zu erzwingen, was die Möglichkeit einiger der Parallelitätsfehler wieder einführen kann.
Ein weiteres Ziel des Transaktionsgedächtnisses ist die zunehmende Parallelität; Wenn Sie eine ganze Reihe von parallelen Operationen haben, die auf einige Datenstrukturen zugreifen, die möglicherweise schreiben, aber nur wenige von denen tatsächlich tun, dann erfordert lock-basierte Synchronisation in der Regel alle Operationen seriell ausgeführt werden, um die Chance zu vermeiden Datenkorruption. Der transaktionale Speicher würde es ermöglichen, dass fast alle Operationen parallel ablaufen und nur die Parallelität verloren geht, wenn ein Prozess tatsächlich in die Datenstruktur schreibt.
In der Praxis (als ich vor ein paar Jahren mein Honours-Projekt recherchierte), hat hardwarebasierte Transaktionsspeicher nicht wirklich abgenommen, und aktuelle Softwaretransaktionsspeichersysteme haben erhebliche Gemeinkosten. Daher ist das Software-Transaktions-Gedächtnis mehr auf "vernünftige Leistung ausgerichtet, die sich moderat gut mit den verfügbaren Prozessoren skalieren lässt und ziemlich einfach zu programmieren ist", anstatt Ihnen absolute maximale Leistung zu geben.
Es gibt jedoch eine große Variabilität zwischen verschiedenen Transaktionsspeichersystemen; Ich spreche hier auf einer ziemlich abstrakten und vereinfachten Ebene.
Ich denke, du übertreibst hier. TM-Algorithmen sind ebenso subtil wie traditionelle Synchronisationstechniken. Und die resultierenden Fehler können ebenso unergründlich sein. In jedem Fall benötigen Sie in der Regel eine funktionierende traditionelle Variante als Fallback für Transaktionskollisionen, also gibt es kein kostenloses Mittagessen. Aus diesen Gründen hat sich STM weitgehend nicht durchgesetzt. HTM in Haswell sieht vielversprechend aus, aber mehr aus einer Performance-Perspektive als eine einfache Programmierung. –
** Wenn ** das STM-System darauf abzielt, starke Sicherheitsgarantien zu geben ** und ** gibt es einen Mechanismus zur Durchsetzung, dass (a) transaktional geteilte Daten nur aus Transaktionen heraus zugänglich sind, (b) Transaktionen niemals Nebenwirkungen haben STM-Programme sind garantiert frei von Race Conditions und Deadlocks. Wenn Sie an STM-Implementierungen gearbeitet haben, ist dies richtig. Schlechter Gebrauch eines solchen STM-Systems kann Ihnen aufgrund von Konflikten miserable Leistung bringen, aber es kann Ihnen keine Deadlocks oder Race Conditions geben, die nur unter extrem präzisen Timing-Bedingungen Probleme verursachen. – Ben
Diese Voraussetzungen gelten jedoch nicht für bibliotheksbasierte STM-Implementierungen für C, denn ohne Sprachintegration gibt es keine Möglichkeit, (a) und (b) zu erzwingen, und mit C ist es sowieso ziemlich schwierig, etwas durchzusetzen. Ich weiß nicht so viel über HTM, aber mein Verständnis ist, dass du wieder eine Sprachintegration benötigst, um Sicherheitsgarantien zu geben, also kommt HTM von C oder Assembler nicht mit dem kostenlosen Mittagessen, nein. – Ben