Re: STL container read thread-safety.
On 4 avr, 22:30, Michael.Boehni...@gmail.com wrote:
On 4 Apr., 17:26, "jason.cipri...@gmail.com"
<jason.cipri...@gmail.com> wrote:
I know that the overall thread safety of STL containers is
not guaranteed. However, if I have an std::vector<int> or an
std::list<int>, and multiple threads are reading them but
nothing is writing them, do I still need to synchronize
access to them?
Iterators are self-contained and do not modify the sequence
they reference to.
Maybe. Copying an iterator can certainly modify data associated
with the container in the implementation I regularly use.
As long as you do not modify any shared data in your
concurrent threads, there is no need for synchronization.
As long as you conform to the requirements specified by your
implementation, there is no need for sychronization. At least
in the past, g++ has required synchronization even with
read-only accesses. (I'm not sure concerning the current
status; I think they have long term plans to move to the more
usual guarantees, but I'm not really sure of it.)
The referenced container type does not matter, vector, list,
set - applies to all of them.
Where do you read that?
You need to be a little careful in regard to std::map -
dereferencing a non-existing element by [] operator actually
creates it.
Which is modifying the container, anyway you look at it. Most
(but not all) implementations require external synchronization.
You can use this operator in threads only with synchronization
mechanisms in place, or you must be sure you are referencing
existing elements only.
Again, where did you read that?
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34