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? By
"reading" I mean iterating through with const_iterators, and also
copying them to other containers with the assignment operator.

What I mean is, am I guaranteed that, say, I don't know, obtaining a
const_iterator via std::list<int>::begin() isn't doing any internal
housekeeping or anything that would potentially make it not thread-
safe?

What about set and map?

Thanks,
Jason

<jason.cipriani@gmail.com> wrote in message
news:57343849-dda5-4f5a-a2d7-07900be64a8a@d1g2000pra.googlegroups.com...
>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? By
> "reading" I mean iterating through with const_iterators, and also
> copying them to other containers with the assignment operator.
>
> What I mean is, am I guaranteed that, say, I don't know, obtaining a
> const_iterator via std::list<int>::begin() isn't doing any internal
> housekeeping or anything that would potentially make it not thread-
> safe?

Right. Since you don't know for sure if an implementation does will not do
something that renders it not thread-safe during const iterations, you can't
reliably use it with multiple threads. You can cross your fingers and hope
for the best...




> What about set and map?

I don't know. The documentation for the particular STL that you are using
should shed some light on the issue. I was thinking about implementing some
thread-safe STL containers, but never got around to doing it:

http://groups.google.com/group/comp....c9c2673682d4cf

On 2008-04-04 17:26, jason.cipriani@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? By
> "reading" I mean iterating through with const_iterators, and also
> copying them to other containers with the assignment operator.
>
> What I mean is, am I guaranteed that, say, I don't know, obtaining a
> const_iterator via std::list<int>::begin() isn't doing any internal
> housekeeping or anything that would potentially make it not thread-
> safe?
>
> What about set and map?

Reading should always be safe (unless you have a very weird library
implementation). However you might need a lock to ensure that no other
thread is writing at the same time as the first thread is reading, look
into readers-writer locks to solve this.

--
Erik Wikström

On Apr 4, 8:26pm, "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? By
> "reading" I mean iterating through with const_iterators, and also
> copying them to other containers with the assignment operator.

For the copy (using assignment operator), the contention resource (if
it is being shared across threads) would become the conatiner to which
you are copying from the original list/vector/any other container. So,
you won't need synchronization for the original object but will need
it for the object it is being copied to.

>
> What I mean is, am I guaranteed that, say, I don't know, obtaining a
> const_iterator via std::list<int>::begin() isn't doing any internal
> housekeeping or anything that would potentially make it not thread-
> safe?
>
> What about set and map?

The answer can probably be generalized across STL containers (depends
on STL implementation docs/guarantees as well). A usual mistake could
be modifying std::map with operator[]. It can be considered a bug in a
non-multithreaded app as well and might be a bit tough to catch in a
bigger codebase. So, that would be one point where I would be
cautious. Moreover, if there is a parallelized code section,
maintaining const-ness for the object that is just being read can be
useful to catch such errors. Just a thought.

"Erik Wikström" <Erik-wikstrom@telia.com> wrote in message
news:cmsJj.5691$R_4.4665@newsb.telia.net...
> On 2008-04-04 17:26, jason.cipriani@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? By
>> "reading" I mean iterating through with const_iterators, and also
>> copying them to other containers with the assignment operator.
>>
>> What I mean is, am I guaranteed that, say, I don't know, obtaining a
>> const_iterator via std::list<int>::begin() isn't doing any internal
>> housekeeping or anything that would potentially make it not thread-
>> safe?
>>
>> What about set and map?
>
> Reading should always be safe (unless you have a very weird library
> implementation).

I would agree that reading "should be safe", but I cannot be 100% sure in
all cases unless the documentation for a given STL explicitly states that
concurrent reads are indeed safe.


> However you might need a lock to ensure that no other
> thread is writing at the same time as the first thread is reading, look
> into readers-writer locks to solve this.

Right.

jason.cipriani@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? By
> "reading" I mean iterating through with const_iterators, and also
> copying them to other containers with the assignment operator.
>
> What I mean is, am I guaranteed that, say, I don't know, obtaining a
> const_iterator via std::list<int>::begin() isn't doing any internal
> housekeeping or anything that would potentially make it not thread-
> safe?
>
> What about set and map?

If "nothing is writing them" is indeeed true, you *should* be okay most of
the time. However, how can you be 100% sure that something won't write to
it somewhere? Somehow you need to get the entries into the container for
your threads to read. If something is writing to a container while
something else is reading it, bad things happen.

It is much eaiser to wrap the container in a thread safe class then to make
sure your code doesn't write to a container when something is reading it.

--
Jim Langston
tazmaster@rocketmail.com

"Jim Langston" <tazmaster@rocketmail.com> wrote in message
news:kguJj.20$_71.13@newsfe02.lga...
> jason.cipriani@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? By
>> "reading" I mean iterating through with const_iterators, and also
>> copying them to other containers with the assignment operator.
>>
>> What I mean is, am I guaranteed that, say, I don't know, obtaining a
>> const_iterator via std::list<int>::begin() isn't doing any internal
>> housekeeping or anything that would potentially make it not thread-
>> safe?
>>
>> What about set and map?
>
> If "nothing is writing them" is indeeed true, you *should* be okay most of
> the time. However, how can you be 100% sure that something won't write to
> it somewhere? Somehow you need to get the entries into the container for
> your threads to read. If something is writing to a container while
> something else is reading it, bad things happen.
>
> It is much eaiser to wrap the container in a thread safe class then to
> make sure your code doesn't write to a container when something is reading
> it.

Right. I would advise to read the documentation of the STL and find out if
concurrent reads are okay. If they are, then use an external rwmutex, wrap
the container with one, for synchronization. All mutators get write access,
everything else gets read access.

On 4 avr, 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?

What does your implementation say? I know that this is
supported by the STLport, the SGI implementations and to some
degree by g++, and I suspect that it is more or less universal,
but in the end, the standard doesn't say anything---yet---so all
you have are the guarantees of your implementation.

> By "reading" I mean iterating through with const_iterators,
> and also copying them to other containers with the assignment
> operator.

> What I mean is, am I guaranteed that, say, I don't know,
> obtaining a const_iterator via std::list<int>::begin() isn't
> doing any internal housekeeping or anything that would
> potentially make it not thread- safe?

> What about set and map?

The most wide spread convention is to extend the general Posix
rules to them, e.g. to make them obey the rules which apply to a
T[] under Posix. But as I said, the standard doesn't guarantee
it yet, so you'll have to check the documentation of your
implementation. (Good luck in finding it:-).)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34