C++ neue Operator-Thread-Sicherheit in Linux und gcc 4

Question

In Kürze werde ich mit der Arbeit an einer parallelen Version eines Algorithmus zur Netzverfeinerung beginnen, der gemeinsamen Speicher verwendet.

Ein Universitätsprofessor wies uns darauf hin, dass wir bei der Thread-Sicherheit sehr vorsichtig sein müssen, da weder der Compiler noch das Programm stl threadfähig sind.

Ich habe nach dieser Frage gesucht und die Antwort hängt vom Compiler ab (einige versuchen, die etwas thread-aware) und die Plattform (ob die vom Compiler verwendeten Systemaufrufe thread-safe sind oder nicht).

Also, in Linux, der gcc 4-Compiler produziert Thread-sicheren Code für den neuen Operator?

Wenn nicht, wie lässt sich dieses Problem am besten lösen? Problem ? Vielleicht jeden Anruf für den neuen Betreiber sperren?

Answer 1

Sie müssen schon sehr genau hinschauen, um eine Plattform zu finden, die Threads unterstützt, aber keinen Thread-Safe hat. new . In der Tat ist die Fadensicherheit von new (et malloc ) ist einer der Gründe, warum es so langsam ist.

Wenn Sie andererseits eine thread-sichere STL wünschen, können Sie Folgendes in Betracht ziehen Intel TBB die über threadfähige Container verfügt (obwohl nicht alle Operationen auf ihnen threadfähig sind).

Answer 2

Im Allgemeinen ist die new Operator ist thread-sicher - die Garantien für die Thread-Sicherheit bei Aufrufen der STL und der Standardbibliothek werden jedoch durch den Standard geregelt - das bedeutet nicht, dass sie keine Threads kennen - sie haben in der Regel sehr gut definierte Garantien für die Thread-Sicherheit bei bestimmten Operationen. Zum Beispiel ist die Iteration durch eine Liste in einer nur lesenden Weise thread-sicher für mehrere Leser, während die Iteration durch eine Liste und die Durchführung von Aktualisierungen nicht sicher ist. Sie müssen die Dokumentation lesen, um zu sehen, was die verschiedenen Garantien sind, obwohl sie nicht so aufwändig sind und in der Regel Sinn ergeben.

Answer 3

Während ich über Konzepte spreche, die ich nicht verwendet habe, sollte ich erwähnen, dass Sie, wenn Sie Shared Memory verwenden, wahrscheinlich sicherstellen wollen, dass Sie nur POD-Typen verwenden, und dass Sie Placement New verwenden.

Zweitens, wenn Sie Shared Memory verwenden, wie es auf Linux-Systemen allgemein verstanden wird, dann verwenden Sie möglicherweise mehrere Prozesse - keine Threads - um Speicher zuzuweisen und "Dinge zu tun", wobei Sie Shared Memory als Kommunikationsschicht verwenden. Wenn dies der Fall ist, dann ist die Thread-Sicherheit Ihrer Anwendung und Ihrer Bibliotheken nicht wichtig - was jedoch wichtig ist, ist die Thread-Sicherheit von allem, was die gemeinsame Speicherzuweisung nutzt! Dies ist eine andere Situation als die eines Prozesses mit vielen Threads. In diesem Fall ist die Frage nach der Thread-Sicherheit des new-Operators ein berechtigtes Anliegen und könnte durch die Platzierung von new gelöst werden, wenn dies nicht der Fall ist, oder durch die Definition eigener Allokatoren.

Answer 4

Nun, dies ist keine endgültige Antwort auf meine Frage, ich habe nur herausgefunden, dass Google eine Hochleistungs-Multithreading-Malloc .

Wenn Sie also Zweifel haben, ob Ihre Implementierung thread-sicher ist, sollten Sie vielleicht die Google-Leistungstools .