Ich lese hier viele Posts mit der Frage, ob die Standardcontainer für C ++ (wie "list" oder "map" threadsicher sind und alle sagten, dass es nicht generell ist. Parallele Lesevorgänge sollten OK sein, aber parallele Schreibvorgänge oder parallele Lese- und Schreibvorgänge können zu Problemen führen.
Jetzt habe ich herausgefunden, dass www.cplusplus.com der Zugriff auf oder die Änderung der Liste während der meisten Operationen sicher ist.
Einige Beispiele:
Auf den Container wird zugegriffen (weder die const noch die nicht-const-Versionen ändern den Container). Es wird nicht auf zugeordnete Werte zugegriffen: Der gleichzeitige Zugriff auf oder das Ändern von Elementen ist sicher.
Der Container wurde geändert. Der gleichzeitige Zugriff auf vorhandene Elemente ist sicher, obwohl das Wiederholen von Bereichen im Container nicht möglich ist.
Missverständnis ich cplusplus.com oder muss ich noch etwas über die Sicherheit von Gewinden in Standardbehältern wissen?
Vielen Dank im Voraus!
PS: Ich frage nach C ++ 03 und nicht nach C ++ 11
Klingt nach rechts.
Beachten Sie, dass der Zugriff auf Werte in map von mehreren Threads, wenn Sie den tatsächlichen Wert ändern, ebenfalls geschützt werden muss. Wenn Sie wissen, dass zwei Threads verschiedene Einträge aktualisieren (ich meine nicht einfügen / entfernen), dann ist es sicher.
Parallele Lesevorgänge sollten in Ordnung sein, aber parallele Schreibvorgänge oder parallele Lese- und Schreibvorgänge können zu Problemen führen.
Das ist richtig. Das ist die allgemein angebotene Garantie für unsynchronisierten Zugriff auf Objekte in C ++. Solche "Probleme" werden formal Datenrennen genannt.
Jetzt habe ich herausgefunden, dass bei www.cplusplus.com der Zugriff oder die Änderung der Liste während der meisten Operationen sicher ist.
Nein, Container bieten nicht mehr als die Basisgarantie für gleichzeitige Lesevorgänge . Es wird einen Datenrennen geben, wenn ein Thread auf ihn zugreift, während ein anderer ihn ändert. Bei einigen Containern ist es jedoch manchmal sicher, auf Elemente des Containers zuzugreifen, während der Container selbst geändert wird.
Das erste Beispiel besagt, dass find nicht die Container- oder Zugriffselement -Werte (nur Schlüssel) ändert, also sicher ist, wenn andere Threads darauf zugreifen. oder Ändern (verschiedener) Werte, ohne den Container selbst zu ändern.
Das zweite Beispiel besagt, dass Sie sicher auf ein vorhandenes Element zugreifen können (indem Sie eine Referenz oder einen Iterator für dieses Element verwenden), da das Einfügen eines Elements die vorhandenen nicht stört.
Ich frage nach C ++ und nicht nach C ++ 11
Heutzutage ist C ++ C ++ 11. Wenn Sie nach historischen Versionen der Sprache fragen, hatten sie nichts über Threads zu sagen, daher ist die Frage im Allgemeinen nicht zu beantworten, nur für eine bestimmte Implementierung und ein Thread-Framework.
Vor C ++ 11 gab es im Standard keine Vorstellung von "thread". Daher ist die Frage, ob ein Container threadsicher ist, im Kontext von C ++ 03 bedeutungslos.
Wie Marcin bemerkte, hat C ++ 03 keine Vorstellung von Thread; Daher können Sie keine threadsichere Operation selbst für das gleichzeitige Lesen in zwei Threads nach einem vollständig abgeschlossenen Schreibvorgang annehmen.
Denken Sie über diesen Fall nach: Bei t = 0 erstellen Sie einen Thread, nennen wir A Bei t = 10 Sekunden schreibt Thread B (der vor dem Erstellen von Thread A existiert) in einen Container. Bei t = 1 Stunde versuchen Thread A und B den Container ohne Synchronisierung durch eine Bibliothek eines Drittanbieters (z. B. Pthread) zu lesen.
C ++ 03 garantiert nur, dass Thread B den richtigen Wert sehen wird. Aber es gibt keine Garantie, dass Thread A den richtigen Wert sehen wird, weil C ++ 03 erwartet, dass jedes Programm ein einzelner Thread ist, und so kann die C ++ 03 Spezifikation nur garantieren, dass die Reihenfolge der Ereignisse in der programmierten Reihenfolge sichtbar ist (wie in 1) Thread).
Tags und Links c++ multithreading stl c++03