StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>You need to understand the thread-safety guarantees the C++ standard (and implementations of C++2003 for possibly concurrent systems) give. The standard containers are a thread-safe in the following sense:</p> <ol> <li>It is OK to have multiple concurrent threads reading the same container.</li> <li>If there is one thread modifying a container there shall be no concurrent threads reading or writing the same container.</li> <li>Different containers are independent of each other.</li> </ol> <p>Many people misunderstand thread-safety of container to mean that these rules are imposed by the container implementation: they are not! It is your responsibility to obey these rules.</p> <p>The reason these aren't, and actually can't, be imposed by the containers is that they don't have an interface suitable for this. Consider for example the following trivial piece of code:</p> <pre><code>if (!c.empty() { auto value = c.back(); // do something with the read value } </code></pre> <p>The container can control the access to the calls to <code>empty()</code> and <code>back()</code>. However, between these calls it necessarily needs to release any sort of synchronization facilities, i.e. by the time the thread tries to read <code>c.back()</code> the container may be empty again! There are essentially two ways to deal with this problem:</p> <ol> <li>You need to use external locking if there is possibility that a concurrent thread may be changing the container to span the entire range of accesses which are interdependent in some form.</li> <li>You change the interface of the containers to become <a href="http://en.wikipedia.org/wiki/Monitor_%28synchronization%29" rel="nofollow">monitors</a>. However, the container interface isn't at all suitable to be changed in this direction because monitors essentially only support "fire and forget" style of interfaces.</li> </ol> <p>Both strategies have their advantages and the standard library containers are clearly supporting the first style, i.e. they require external locking when using concurrently with a potential of at least one thread modifying the container. They don't require any kind of locking (neither internal or external) if there is ever only one thread using them in the first place. This is actually the scenario they were designed for. The thread-safety guarantees given for them are in place to guarantee that there are no internal facilities used which are not thread-safe, say one per-object iterator object or a memory allocation facility shared by multiple threads without being thread-safe, etc.</p> <p>To answer the original question: yes, you need to use external synchronization, e.g. in the form of mutex locks, if you modify the container in one thread and read it in another thread.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload