Ich habe Intels "whatif" -Seite und ihren Transactional Memory-Compiler ausgecheckt (jeder Thread muss atomare Commits machen oder den Systemspeicher zurückrollen, wie eine Datenbank).Hat jemand versucht, Transaktionsspeicher für C++?
Es scheint eine vielversprechende Möglichkeit, Sperren und Mutexe zu ersetzen, aber ich kann nicht viele Zeugnisse finden. Hat jemand hier irgendwelche Eingaben?
Ich habe nicht verwendet Intels Compiler jedoch Herb Sutter auf es einige interessante Kommentare hatte ...
Von Sutter Speaks: The Future of Concurrency
Sehen Sie eine Menge Interesse und Nutzung von Transaktionsspeicher, oder ist das Konzept zu schwer für die meisten Entwickler zu begreifen?
Es ist noch nicht möglich zu beantworten, wer es benutzt, weil es noch nicht auf den Markt gebracht wurde. Intel hat einen Software-Transaktionsspeicher-Compiler-Prototyp. Aber wenn die Frage ist "Ist es zu schwer für Entwickler zu verwenden?" Die Antwort ist, dass ich sicherlich nicht hoffe. Der springende Punkt ist, dass es einfacher ist als Schlösser. Es ist die einzige große Sache auf dem Forschungshorizont, die die Hoffnung aufdrängt, unseren Gebrauch von Schlössern stark zu reduzieren. Es wird Schlösser niemals komplett ersetzen, aber es ist unsere einzige große Hoffnung, sie teilweise zu ersetzen.
Es gibt einige Einschränkungen. Insbesondere sind einige E/A von Natur aus nicht transaktional - Sie können keinen atomaren Block verwenden, der den Benutzer nach seinem Namen fragt und den Namen von der Konsole ausliest, und den Block einfach automatisch abbrechen und erneut versuchen, wenn er mit einer anderen Transaktion in Konflikt gerät; Der Benutzer kann den Unterschied erkennen, wenn Sie ihn zweimal auffordern. Der Transaktionsspeicher eignet sich hervorragend für Dinge, die nur den Speicher berühren.
Jeder große Hardware- und Softwareanbieter, den ich kenne, hat mehrere Transaktionsspeicher-Tools in R & D. Es gibt Konferenzen und wissenschaftliche Arbeiten zu theoretischen Antworten auf grundlegende Fragen. Wir sind noch nicht auf der Model T-Bühne, wo wir es ausliefern können. Sie werden wahrscheinlich frühe, begrenzte Prototypen sehen, bei denen Sie keinen unbegrenzten Transaktionsspeicher haben können - wo Sie nur 100 Speicherplätze lesen und schreiben können. Das ist immer noch sehr nützlich, um mehr Lock-Free-Algorithmen zu aktivieren.
Über wo es für Entwickler zu schwierig ist: siehe das Papier "Ist Transaktionsprogrammierung tatsächlich einfacher" von Rossbach et al: http://www.cs.utexas.edu/~rossbach/pubs/wddd09-rossbach.pdf –
In einigen Fällen kann ich das als nützlich und sogar notwendig ansehen.
Aber selbst wenn der Prozessor spezielle Anweisungen hat, die diesen Prozess erleichtern, gibt es immer noch einen großen Overhead im Vergleich zu einem Mutex oder Semaphor. Abhängig davon, wie es implementiert wird, kann es sich auch auf die Echtzeit-Performance auswirken (muss Interrupts entweder stoppen oder verhindern, dass sie in Ihre freigegebenen Bereiche schreiben).
Meine Erwartung ist, dass, wenn dies implementiert wurde, es nur für Teile eines bestimmten Speicherplatzes benötigt würde, und so die Auswirkungen begrenzt werden könnten.
-Adam
Das klingt nicht wie Transaktionsspeicher ... Was ist der Overhead im Vergleich zu Mutexe und Semaphoren? –
Es gibt mehrere Orte, an denen der Overhead höher ist. Ein offensichtliches Beispiel ist das Zurückrollen einer Transaktion. Es macht auch Caching schwieriger und trägt mehr Overhead, da alles sofort in den Speicher zurückgeschrieben werden muss. Transaktionsspeicher ist für einige Anwendungen eine gute Idee, beeinträchtigt jedoch die Systemleistung und sollte daher nicht für jede Anwendung und jedes System bereitgestellt werden. –
Ah, aber mehrere Neustarts sind der pathologische Fall für Transaktionen. Wie vergleicht sich das mit dem pathologischen Fall für Sperren (langes Blockieren, Springen zwischen Caches)? –
Dr. Dobbs hatte einen Artikel über das Konzept im vergangenen Jahr: Transactional Programmierung von Calum Grant - http://www.ddj.com/cpp/202802978
Es enthält einige Beispiele, Vergleiche und Schlussfolgerungen seine Beispiel-Bibliothek.
Sun Microsystems hat angekündigt, dass sie im nächsten Jahr einen neuen Prozessor mit dem Codenamen Rock veröffentlichen, der Hardware-Unterstützung für Transaktionsspeicher bietet.Es wird einige Einschränkungen geben, aber es ist ein guter erster Schritt, der es Programmierern erleichtern sollte, Locks/Mutexes durch Transaktionen zu ersetzen und erwarten gute Leistung daraus.
Für einen interessanten Vortrag zu diesem Thema, der von Mark Moir, einem der Forscher bei Sun, der an Transactional Memory und Rock arbeitet, gegeben wurde, sehen Sie sich diese link an.
Für weitere Informationen und Ankündigungen von Sun über Rock und Transaktionsspeicher im Allgemeinen, diese link.
Die obligatorische wikipedia entry :)
Schließlich this link, an der University of Wisconsin-Madison, eine Bibliographie der meisten der Forschung enthält, war und über Transactional Memory getan wird, ob es sich um einen Hardwarefehler oder Software verbunden.
Sind diese Frage und ihre Antworten noch aktuell? –
@ JanusTroelsen prüfen Sie die verfügbaren Implementierungen in https://en.m.wikipedia.org/wiki/Transactional_memory –
Related: https://www.realworldtech.com/haswell-tm/ für David Kanter schreiben von einigen unter -Hood-Details darüber, wie es tatsächlich auf Intel-CPUs implementiert ist. Und auch ein paar nette Dinge über das Transaktionsgedächtnis im Allgemeinen. –