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

From:

"=?iso-8859-1?q?Kirit_S=E6lensminde?=" <kirit.saelensminde@gmail.com>

Newsgroups:

comp.lang.c++

Date:

14 Jun 2006 23:30:09 -0700

Message-ID:

<1150353009.413068.73840@u72g2000cwu.googlegroups.com>

Dilip wrote:

Kirit S=E6lensminde wrote:

Dilip wrote:

Thomas J. Gritzan wrote:

Dilip schrieb:
<OT>
You should not write to a variable in one thread while reading the =

same

variable in other threads. Its not just about invalidating iterator=

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?

For my company's framework (FOST.3) we've been through this too. What
we did was to define a synchronisation object that allowed a limited
number of read locks or a single write lock. You can have a number of
readers, but only a single write thread at a time accessing the data
structure.

That smells like a ReaderWriterLock, right? I decided it might not be
of use to me since I make way too many updates to the map.

It is indeed exactly that sort of lock. One exclusive writer and many
readers.

You're going to need to use something like this though or re-architect
so that you don't need to lock at all. I'm afraid those are your only
safe options. To start with get it working correctly, then see if it is
too slow. If so then re-tihink what you're doing.

You will need to work out what the correct way to gain the locks is
going to be. Normally I would say that a writer attempting a lock would
stop any new readers, but depending on your application you may want to
allow them. Reducing the number of readers that you allow may allow the
writer to get in more quickly and improve the overall speed. Similarly,
increasing them might work better in your application. You'll need to
experiment to find out.

Clearly you also need to ensure that the locks are held for the
smallest possible time.