Ist std::string thead-safe mit gcc 4.3?

Entwickle ich ein Multithread-Programm läuft auf Linux (kompiliert mit G++ 4.3) und wenn Sie suchen, um für ein bisschen Sie finden viele schreckliche Geschichten über std::string nicht thread-safe ist mit GCC. Dies ist vermutlich auf die Tatsache zurückzuführen, dass es intern verwendet copy-on-write, die verheerende Auswirkungen mit tools wie Helgrind.

Ich habe ein kleines Programm, das kopiert eine Zeichenfolge in eine andere Zeichenfolge und wenn Sie inspizieren die beiden Zeichenfolgen, die Sie beide teilen die gleichen internen _M_p Zeiger. Wenn ein string geändert wird, ändert sich der Zeiger, so dass das copy-on-write-stuff ist in Ordnung.

Was ich bin besorgt obwohl was passiert, wenn ich Teile einer Zeichenfolge zwischen zwei threads (zum Beispiel indem er als ein Objekt in einer threadsicher dataqueue zwischen zwei threads). Ich habe bereits versucht zu kompilieren, mit der '-pthread' option, aber das scheint nicht viel Unterschied. Also meine Frage:

Gibt es eine Möglichkeit zu zwingen, std::string threadsicher? Ich würde nicht dagegen, wenn die copy-on-write-Verhalten deaktiviert wurde, dies zu erreichen.
Wie haben andere Leute das Problem gelöst? Oder bin ich paranoid?

Ich kann nicht scheinen zu finden, eine definitive Antwort, so dass ich hoffe, Euch kann mir helfen..

Edit:

Wow, das ist eine ganze Menge von Antworten in so kurzer Zeit. Danke!!! Ich werde auf jeden Fall nutzen Jack ' s Lösung, wenn ich Sie deaktivieren möchten, KUH. Aber jetzt die wichtigste Frage: muss ich wirklich deaktivieren KUH? Oder ist die 'Buchführung' erfolgt für KUH-thread-safe? Ich bin momentan im libstdc++ - Quellen, aber das wird einige Zeit dauern, um herauszufinden,...

Edit 2

OK durchsuchten die libstdc++ - source-code und ich finde so etwas in libstd++-v3/include/bits/basic_string.h:

  _CharT*
   _M_refcopy() throw()
   {
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
     if (__builtin_expect(this != &_S_empty_rep(), false))
#endif
            __gnu_cxx::__atomic_add_dispatch(&this->_M_refcount, 1);
     return _M_refdata();
   }  //XXX MT

Also es ist definitiv etwas, das es zu atomaren änderungen an der Referenz-Zähler...

Abschluss

Ich bin-Kennzeichnung sellibitze Kommentar als Antwort hier, weil ich denke, wir haben zu der Schlussfolgerung gelangt, dass dieser Bereich ist immer noch ungelöst, jetzt. Zur Umgehung der KUH Verhalten würde ich vorschlagen, Jack Lloyd ' s Antwort. Ich danke Ihnen allen für eine interessante Diskussion!

+1 gute Frage! Leider, die Menschen nur Lesen "threadsicher" und denke "Nein!". Sie besser Lesen Sie die gesamte Frage! 🙂
Da std::string ist eine Instanz der template std::basic_string es könnte möglich sein, für Sie zu werfen Sie einen Blick auf den source-code. Versuchen Sie, für jedes makro, das würde wiederum on/off thread-Sicherheit.
Übrigens, copy-on-write ist langsam in multi-threaded-Umgebungen, Sie sollten nicht benutzen willst, nicht bereit.
Siehe auch stackoverflow.com/questions/1661154/...

InformationsquelleAutor Benjamin | 2009-10-20

c++multithreading string

15

Threads sind noch nicht Teil des standard. Aber ich glaube nicht, dass jeder Anbieter kann sich, ohne std::string, thread-sicher, heute. Hinweis: Es gibt verschiedene Definitionen von "thread-safe" und mir vielleicht von Ihnen unterscheiden. Es macht natürlich wenig Sinn, Sie zu schützen, die einen container wie std::vector für gleichzeitigen Zugriff standardmäßig, auch wenn Sie es nicht brauchen. Das würde gegen die "zahlen Sie nicht für Dinge, die Sie nicht verwenden" Geist von C++. Der Benutzer sollte immer verantwortlich für die Synchronisation wenn er/Sie teilen möchte-Objekte zwischen verschiedenen threads. Die Frage ist hier, ob eine Bibliothek-Komponente verwendet und teilt einige versteckte Daten-Strukturen können dazu führen, dass die Daten Rennen, auch wenn "Funktionen angewendet werden auf verschiedene Objekte" aus der Sicht des Benutzers.

Den C++0x draft (N2960) enthält der Abschnitt "data-race-Vermeidung", die im Grunde sagt, dass die Bibliothek-Komponenten können auf gemeinsame Daten zugreifen, die vom Benutzer ausgeblendet, wenn, und nur wenn es aktiv vermeidet mögliche Daten Rennen. Es klingt wie ein copy-on-write-Implementierung von std::basic_string sein muss als die sichere w.r.t. multi-threading als eine andere Implementierung, in denen interne Daten nie geteilt, zwischen den verschiedenen string-Instanzen.

Bin ich mir nicht 100% sicher, ob libstdc++ kümmert es schon. Ich denke, es ist. Um sicher zu sein, überprüfen Sie heraus die Dokumentation
- Vielen Dank auch für diese ausführliche Antwort. Ich check die Seite, die Sie verlinkt aber es bleibt ein wenig vage, meiner Meinung nach, sprechen über Container im Allgemeinen (und, dass Sie sollte eine ausreichende Fixierung) und nicht so viel über Zeichenfolgen. :)) Der data-race-Vermeidung scheint zumindest eine "Entschuldigung" gehen Sie einfach weiter und nehme an, alles wird in Ordnung sein, zwischen den threads da, die direkt schiebt die Verantwortung auf die Menschen in der Implementierung der Bibliothek (vorausgesetzt natürlich, dass ich als Programmierer übergeben des strings by value anstatt by reference)...
InformationsquelleAutor sellibitze
11

Wenn Euch das nichts ausmacht Deaktivierung der copy-on-write, dies ist möglicherweise die beste Vorgehensweise. std::string KUH funktioniert nur, wenn es weiß, dass es das kopieren einer anderen std::string, so dass Sie kann dazu führen, dass immer reservieren eines neuen Blocks des Speichers und stellen eine tatsächliche Kopie. Zum Beispiel diesen code:
```
#include <string>
#include <cstdio>

int main()
   {
   std::string orig = "I'm the original!";
   std::string copy_cow = orig;
   std::string copy_mem = orig.c_str();
   std::printf("%p %p %p\n", orig.data(),
                             copy_cow.data(),
                             copy_mem.data());
   }
```
wird zeigen, dass die zweite Kopie (mit c_str) verhindert, dass die KUH. (Weil der std::string sieht nur einen nackten const char*, und hat keine Ahnung, Woher es kam oder was seine Lebensdauer sein mag, so hat Sie ein neues privates kopieren).
- Kleine Einschränkung: die Zuordnung zu dem Ergebnis c_str (), schneidet die Zeichenfolge zurück, wenn orig contains embedded nulls. Es wäre sicherer, verwenden Sie die assign-Methode (oder Konstruktor) unter einen const char* und ein size_type, und pass in der "orig.data()" und "orig.size()" zu.
- Wenn ich mich entscheide zu gehen für das deaktivieren 'KUH' route, werde ich auf jeden Fall nutzen diese (und die Bemerkung Hinzugefügt von Eric). Schön gemacht 🙂
- Sehr guter Punkt, ich kann nicht glauben, dass ich nicht der Meinung, wie würde die Interaktion mit Nullen. Danke.
- Alternativ können Sie mit der Initialisierung von Iteratoren, denke ich.
InformationsquelleAutor Jack Lloyd
3

Diese Abschnitt der libstdc++ - Interna Staaten:

Die C++ - Standardbibliothek string Funktionen
erfordert ein paar Atomare Operationen
bieten thread-Sicherheit. Wenn Sie nicht
irgendwelche besonderen Aktion, die Bibliothek
verwenden stub-Versionen dieser
Funktionen, die nicht thread-sicher sind.
Sie wird funktionieren, es sei denn, Ihr
Anwendungen sind multi-threaded.

Die Referenz-Zählung sollte die Arbeit in einer multi-threaded Umgebung. (es sei denn, Ihr system nicht die notwendigen atomics)
- Es wäre schön, wenn es eine schnelle Möglichkeit zu sagen, wenn der real-oder stub-Funktionen verwendet wurden. Vielleicht suchen Sie in den Maschinen-code und überprüfen Sie, ob ein LOCK-Präfix...
InformationsquelleAutor poindexter
0

Kein STL-container ist thread-sicher. Auf diese Weise verfügt die Bibliothek über einen Allgemeinen Zweck (beide verwendet werden, in single-threading-Modus oder ein multi-threading-Modus). In multithreading, müssen Sie die Synchronisations-Mechanismus.
- Der Unterschied mit string ist aber, dass auch es als Wert übergeben induziert threading betrifft - dies kann etwas unerwartet, um das Mindeste zu sagen.
- Danke Leute für so schnelle Antworten! Ich kenne kein STL-container ist threadsicher (und richtig verwenden, sperren Wrapper, wenn ich Sie brauche werden threadsicher), aber soweit ich weiß, ist der std::string ist die einzige, die "heimlich" verwenden Sie den gleichen datastore für identische strings. Meine Sorge ist, dass die copy-on-write-Buchhaltung ist nicht thread safe an alle, bin ich richtig da?
- Ich verstehe nicht, warum bekommt das so viele upvotes. Jungs, bitte achten Sie auf die eigentliche Frage
InformationsquelleAutor Cătălin Pitiș
0

Scheint es, dass dieses fest war vor einer Weile: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5444 war geschlossen, als das gleiche Problem als http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5432, das wurde behoben in 3.1).

Siehe auch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6227
- Ich denke, dass der Fehler bezieht sich auf die iostreams code aber nicht den string code?
- Ach ja, richtig. Ich bezog mich auf diese wie in Bezug auf basic_string (#5444) geschlossen wurde, mit der gleichen Auflösung als 5432. Ich bearbeitet meine Antwort, dies zu klären.
- Dank Eric! Solange wir hinzufügen bugtracker posten, auch dies scheint im Zusammenhang: gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
- Ich fand eine andere große Diskussion zu diesem Thema: etbe.coker.com.au/2009/06/22/valgrindhelgrind-und-stl-string
InformationsquelleAutor Éric Malenfant
0

Laut dieser bug Problem, std::basic_string's copy-on-write-Implementierung noch nicht vollständig thread-sicher. <ext/vstring.h> ist eine Umsetzung ohne KUH und scheint zu tun, viel besser in einem nur-lese-Kontext.

InformationsquelleAutor Wim

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.