std::map thread-Sicherheit

Ist Verweis auf Objekt in std::map ist thread-sicher?

std::map< std::string, Object >   _objects;

anzeigen können geändert werden, aus vielen threads, und dieser Zugang wird synchronisiert, aber Bezug zum Wert (Objekt - &) zugänglich nur von 1 Instanz und Faden. schreiben Sie Operationen mit dem Objekt - & sicher ist, wenn ein anderer thread werden Elemente hinzufügen anzeigen? wird es reservieren?

InformationsquelleAutor der Frage deeptowncitizen | 2013-02-25

  1. 16

    Den C++11-standard garantiert, dass const Methode Zugang zu den Behältern ist sicher aus verschiedenen threads (ie, beide benutzen const Methoden).

    Darüber hinaus [container.Anforderungen.dataraces] Staaten

    Implementierungen sind erforderlich, um zu vermeiden, Daten Rennen, wenn der Inhalt von
    das enthaltene Objekt in verschiedene Elemente in der gleichen Reihenfolge,
    ausgenommen vector<bool>

    In anderen Worten, außer für vector<bool> geändert wird, verschiedene Inhalte auch nicht ein data race.

    Nun, wenn ein thread ungültig macht einen iterator von einem anderen thread verwendet, klar ist das ein Daten-Rennen (und Ergebnisse zu undefiniertem Verhalten). Wenn ein thread nichtconst Zugang zu einem container, und ein anderer tut const Zugang, ist, dass ein data-race - (und undefiniertem Verhalten). (Hinweis: eine Reihe von Funktionen sind "als const" für die Zwecke von multithreading, einschließlich beginend - und anderen Funktionen (und Methoden), sind nichtconst einfach, weil Sie nicht zurück-const Iteratoren. [] ist in diesem set enthaltenen pseudo-const für thread-Sicherheit Gründe, außer für map und unordered_set etc -- 23.2.2.1).

    Jedoch scheint es, dass, wenn Sie eine Referenz auf ein element innerhalb des Containers, und sich in Operationen, die nicht zu entkräften, dass der Verweis in einem anderen thread, und Schreibe nie, dass dieses element in einem anderen thread, kann man sicher Lesen, dass die Referenz. Ebenso, wenn bei den anderen threads noch nie gelesen, aus dem element, dann zu schreiben, dass dieses element sollte nicht nicht definiertes Verhalten zur Folge.

    Normen, Referenzen, 17.6.5.9.5 scheint zu garantieren, dass die Funktionen aus der standard-Bibliothek wird nicht weglaufen und lese/schreib-Elemente unnötig.

    So die kurze Antwort: Sie sind sicher, so lange, wie der andere thread nicht direkt Durcheinander mit diesen bestimmten Eintrag in der map.

    InformationsquelleAutor der Antwort Yakk - Adam Nevraumont

  2. 6

    Elemente in einer Karte stabil sind, bekommen Sie nicht verschoben oder für ungültig erklärt, es sei denn, das element ist gelöscht von der Karte. Wenn nur ein thread zu schreiben, um ein bestimmtes Objekt, und änderungen an der Karte selbst sind richtig synchronisiert, dann ich glaube es sicher sein wird. Ich bin sicher, es ist sicher in der Praxis, und ich denke, es ist sicher in der Theorie auch.

    Der standard garantiert, dass verschiedene Elemente, die modifiziert werden können durch die verschiedenen threads, in [container.Anforderungen.dataraces]

    Trotz (17.6.5.9), Implementierungen sind erforderlich, um zu vermeiden, Daten Rennen, wenn Sie den Inhalt des enthaltenen Objekts in verschiedene Elemente in der gleichen Reihenfolge, ausgenommen vector<bool> werden geändert, gleichzeitig.

    Diese können Sie nur ändern Sie die Elemente, die nicht zum einfügen neuer Elemente in die Karte, während die ändern Elemente. Für manche Container wie std::vector Modifikation der Vektor selbst vielleicht auch ändern, Elemente von Umverteilung und Sie zu bewegen, aber [assoziativ.Bestand]/9 sorgt std::map wird nicht ungültig, bestehende Elemente.

    Da keine member-Funktion von std::map ist erforderlich, um Zugriff auf das zweite Element seiner Elemente (d.h. die mapped_type) ich denke, [res.auf.Daten.Rennen]/5, sagt kein anderer thread wird den Konflikt mit schreibt, dass die beim ändern der Karte. (Dank an Yakk für das Letzte Stück des Puzzles)

    InformationsquelleAutor der Antwort Jonathan Wakely

Schreibe einen Kommentar