Re: Semantics of STL containers (std::map) in a multithreaded scenario

Dilip wrote:


No, there's a deeper problem. The map is guaranteed to be properly
sorted when the code returns from an insertion or removal, but during
that operation it doesn't have to be. So halfway through an insertion it
can be in a nonsensical state, and if you try to read it from another
thread you'll get nonsense. The brute force solution is to make all
external operations on the map atomic, by locking a mutex when the
operation starts, and unlocking it when the operation ends. That will
work for your scenario, since you said you don't care about missing
updates in your reader. But more generally, multi-threading has to be
designed in from the top down, not hacked in from the bottom. As it is,
you're trying to put your socks on after you've put your shoes on.

--

Pete Becker
Roundhouse Consulting, Ltd.