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

From:

Pete Becker <petebecker@acm.org>

Newsgroups:

comp.lang.c++

Date:

Wed, 14 Jun 2006 06:52:23 -0400

Message-ID:

<l5KdnRw32or4dxLZnZ2dnUVZ_rSdnZ2d@giganews.com>

Dilip wrote:

I just looked at the docs for std::map and it looks like for
insertion/removal no iterators are invalidated. So atleast in this
particular case, aren't I safe?

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.