sTL container threadsafe, abe wie?
-
Hallo Leute,
die STL Container sind ja gewissemaßen threadsave.. aber wie wurde das realisert? da musst doch mit critcalsections gearbeitet werden? wir für jedes vector objekt ein mutex angelegt?
-
BorisDieKlinge schrieb:
die STL Container sind ja gewissemaßen threadsave.. aber wie wurde das realisert? da musst doch mit critcalsections gearbeitet werden? wir für jedes vector objekt ein mutex angelegt?
Quelle? Bzw woher hast du das, dass threadsave das heist?
-
-
Du bist lustig.
Da stehen die Bedingungen, wann der Zugriff (schreibend und lesend mit Variationen) Threadsafe ist.Nun, da brauchsts keine Synchronisationsmechanismen, wenn z.B. nur lesend (zu einem Zeitpunkt) zugreifsts. Dies ist implementationsabhänig aber offensichtlich bei der MS Impl. der Fall.
(Ich weiss nicht ob sich der Standard dazu äussert.. typischerweise nicht.)Für die Fälle welche nicht als Threadsafe aufgeführt sind benötigst Du Synchronisationsmechanismen.
Nur am Rande ein Bsp. als Analogie:
Bei eine 32bit Maschine sind lesende Zugriffe auf einen 64bit Integer auch Threadsafe, wenn keine schreibende Zugriffe gemacht werden.Gruss Simon
-
ohh.. dann hab ich das missverstanden
ok gut zu wissen.. ist bei
object x; CRITICAL_SECTION _critSection; TRHEAD A{ EnterCriticalSection (& _critSection); x.foo(); LeaveCriticalSection (& _critSection); } THREAD B{ EnterCriticalSection (& _critSection); x.foo(); LeaveCriticalSection (& _critSection); }
wäre so eine implementaion 100% threadsave ? oder gibts es dennoch anomalien welche ein hänger verursachen?
-
Wenn du die Threads am Schluss doch wieder ganz ausbremst, dann lass sie gleich weg.
-
das ist nur ein beispiel..
-
Aber Achtung mit Iteratoren.
Wenn z.B. Thread A ein Iterator auf einen vector hält und Thread B ein neues Element hinzufügt kann es sein das der Iterator ungültig wird (ohne das es Thread A mitbekommt)!