strings und Threads

[Ringding]

Ich hab mal eine Frage zur Verwendung von strings in mehreren Threads.

Es ist ja hinlänglich bekannt, dass STL-Objekte nicht unsynchronisiert von mehreren Threads angegriffen (verändert) werden dürfen. Lesezugriff (const-Methoden) sollte aber nach meinem Verständnis möglich sein.

Was ist nun aber mit basic_string, der in manchen Implementierungen refcounted implementiert ist? Dann hat er wohl einen Copy-Constructor, der das const-Objekt irgendwie manipulieren muss. Wie sehr wurde nach eurer Erfahrung dabei auf thread safety geachtet? Soweit ich weiß, schweigt sich der Standard zu dieser Thematik aus.

[kwaart]

Zu dem Thema wäre es am besten, die Doku der eigenen STL-Implementation zu Rate zu ziehen. Bei den Implementationen mit RefCount gibt es meistens Vorkehrungen für Thread-Applikationen (also entweder eine Synchronisation beim Zugriff auf den Refcount, oder sogar eine alternative Implementation ohne RefCount). Wenn man ganz sichergehen will, kann man STLport verwenden, die hat auf jeden Fall(meines Wissens wahlweise) eine String-Implementation ohne RefCount...

[Ringding]

Naja das hab ich schon befürchtet.

Weiß vielleicht jemand auswendig, wie sich das bei der libstdc++ verhält, die standardmäßig beim gcc 3.3 und 3.4 für Linux (x86) dabei ist?

Und gibt's vielleicht irgendwelche Standardzusätze in Arbeit/Schwebe, die sich mit der Problematik der Threadsicherheit befassen?

[Ringding]

Also falls es wen interessiert, ich habe jetzt nachgeschaut - die libstdc++ in den genannten Versionen ist refcounted und Thread- & SMP-aware.

[RHBaum]

IMHO "Thread aware" heisst nicht, das die Objekte selbst thread safe sind, sondern dass unterschiedliche Instanzen interne keine globalen veraiablen mit anderen Instanzen gemeinsam nutzen ....

Viele Implementationen nutzen fuer die Speichervaltung intern globale Objecte, die nicht threadsafe sind ....

sprich thread 1 greift auf ne instanz von std::basic_string zu muss speicher allocieren, dazu verwendet es nen globales object ....

in der zwischenzeit bekommt aber thread 2 die cpu zeit, arbeitet mit ner anderen instanz von std::basic_string (nich mal per write cached verbunden) und braucht auch neuen speicher, befragt aber das selbe globale object, welches aber durch den 1. thread noch in verwendung ist und in einen nicht threadsicheren zustand ... -> rums

also threadaware bedeutet nich,d as du nicht selbst fuer threadsicherheit sorgen musst, sondern bedeutet, das sich unterschiedliche instancen nicht gegenseitig beeinflussen ....

Beispiele fuer nicht threadsafe Biblios sind :
QT (es darf nur einen Oberflaechenthread geben) ... sprich da kannst locken wie du willst, sobald 2 threads auf GUI Objecte zugreifen ... knallts ....

sonst ... hmmm faellt mir auf anhieb nix ein :p

Ciao ...

[Jester]

ist halt auch fraglich, inwiefern es was bringt alle Sachen threadsicher zu machen. Oft geht das auf dem Level wo die Sachen implementiert werden auch garnicht.

Ich kann die threadsicherste Implementierung eines std::string verwenden...

std::string hallo; // shared variable

// irgendwo im Code:
hallo.clear();
assert(hallo=="");

da kann das assert trotzdem feuern, weil irgendein anderer Thread hallo zwischen dem clear und dem assert verändert hat.

Das Locking ist einfach nicht auf dem richtigen Level.

[Ringding]

Du hast anscheinend nicht verstanden, worum es hier geht. Dass mehrere Threads nicht den gleichen String verändern dürfen, ist eh klar. Bei einer Implementation von string über einen shared buffer und refcount würde dieses Problem aber auch auftreten, wenn zwei verschiedene Strings von zwei verschiedenen Threads angegriffen würden. Man kann ja dann als Benutzer nicht wissen, welche Strings sich gegenseitig beeinflussen.

[Jester]

Ringding schrieb:

Du hast anscheinend nicht verstanden, worum es hier geht.

Ich hab im ersten Satz genau eingegrenzt worüber ich schreibe. Im Beitrag von RHBaum ging es um thread-safe libraries. Und ich habe aufgezeigt, daß es u.U. garnix bringt alles threadsicher zu machen.

Schade, daß Du nicht im Stande bist das zu lesen/verstehen.

[RHBaum]

Aber in dem Falle hat er recht ...
durch WriteOnDemad bekommst du kritische situationen ....

diese kritischen situationen kannst du aber nur durch die impl entschaerfen, weil du als anwender gar nich die informationen zu hasst ....

offiziell hasst du 2 instanzen, die du nicht mit dem gleichen mutex locken wirst. also muss der string intern selber sicherstellen, das er bei WOD die gemeinsame Basis sperrt, nich das der eine thread noch zum spaeteren bearbeiten kopiert, waehrend der andere thread schon selber die basis veraendert ...

die bibo allein kann dir auch gar nicht threadsicherheit herstellen, also bist als user gefragt ...
aber du als user hasst keine chance, wenn die bibo selber nicht selber threadsicher arbeitet, dir also mit "schmutzigen" Tricks nen strich durch die rechnung macht ...

Ciao ...