2016-08-19 3 views
1

Wie lautet der aktuelle Status des Transaktionsspeichervorschlags für C++ 17? Wird es in den Standard aufgenommen, um in eine zukünftige Version von Standard C++ aufgenommen zu werden, oder ist es nur ein experimentelles Proof-of-Concept-Feature, dessen Standardisierungsstatus noch nicht bekannt ist?Standard-C++ - Transaktionsspeicherstatus

Ich frage, weil einige Dokumente des Standardisierungskomitees widersprüchliche Kommunikation hier zu geben scheinen. Auf der einen Seite haben wir P0265R0 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0265r0.pdf) sagen, dass Transaktionsspeicher wird nicht standardisiert werden, auf der anderen Seite gibt es eine N4492 Papier von Stroustrup (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4492.pdf) mit Transaktionsspeicher in C++ 17 Feature-Liste aufgelistet.

Antwort

3

Kurz genug: der transaktionale Speicher TS ist bereits veröffentlicht, und eine zweite Version wird entwickelt. Das Komitee plant jedoch nicht, es in den Standard im Nah-Feature aufzunehmen. Es gibt mehrere Gründe für diese Auswahl:

  • Es gibt nicht genug Implementierungserfahrung. Nur g ++ implementiert es seit GCC6. Das Ziel von TSs besteht teilweise darin, Implementierungs- und Benutzererfahrungen zu sammeln, so dass ein so großes Feature in Bezug auf dieses Thema noch zu "unreif" ist.

  • Nicht jedes Ziel unterstützt Transaktionsspeicher, und es hat einen hohen Implementierungskosten, während nicht jeder es benötigt. Aus diesen Gründen ist der Ausschuss offenbar nicht sicher, ob der TS überhaupt Teil des C++ - Hauptstandards sein sollte. Es könnte auch für immer als ein TS leben.

  • Darüber hinaus glaubt nicht jeder, dass jede Funktion des transaktionalen Speichers TS es wert ist, in den C++ - Hauptstandard aufgenommen zu werden. Einige finden, dass synchronized das Hauptmerkmal ist, während andere glauben, dass atomare Blöcke der wirkliche Spielwechsler sind. Der TS macht einen weiteren kognitiven Overhead, mit dem sich Bibliotheks-Implementierer befassen müssen (sowie einige neue Schlüsselwörter, was im Allgemeinen nicht als eine gute Sache angesehen wird).

+0

Gute Antwort. Es ist eine Schande, denn es ist die einzige zusammensetzbare Technik, AFAICT. Im Prinzip fühlt sich das gleichzeitige Programmieren so an, als ob es vor 15 Jahren gewesen wäre, mit allem, was von Grund auf neu programmiert werden müsste (wieder, da nichts zusammensetzbar ist, so dass es keine wiederverwendbaren Bausteine ​​gibt). –

+0

@AmiTavory was wäre etwas, dass Transaktionen kompostierbarer als und warum? –

+1

@JanusTroelsen Angenommen, Sie finden ein Projekt, das einen supercoolen Gleichzeitigkeitsalgorithmus für eine Hashtabelle mit einem Mutex- oder Lockfree-Primitiv darstellt. Dann finden Sie dasselbe für eine verknüpfte Liste. Anschließend möchten Sie einen LRU-Cache mithilfe einer Hashtabelle und einer verknüpften Liste erstellen. AFAIU, die Kombinationen dieser Lösungen, ist keine Lösung für die Kombination von Problemen (es ist nicht genug, dass die Hash-Tabelle und die Liste gleichzeitig sind; der LRU-Status könnte inkonsistent sein). Wenn Sie jedoch eine TSM-Hashtabelle und eine verknüpfte Liste verwenden, können Sie eine TSM-LRU trivial erstellen. –