1

Possible Duplicate:
Do I need to protect read access to an STL container in a multithreading environment?

If some thread reading :set or :map when another thread writing to this set or map, what will happen? Exception?

Now i use read-write locks, but i want to remove locks, because writining operations are not often and reading operation very often.

Community
  • 1
  • 1
RomanKarpuk
  • 57
  • 1
  • 7
  • 1
    Standard containers are not thread-safe if they're modified by one of the threads. – Xeo Aug 12 '12 at 14:21
  • @Xeo, so what will happen when one thread reads the container when another writes to it? Exception? – RomanKarpuk Aug 12 '12 at 14:23
  • 3
    @RomanKarpuk undefined behaviour! – juanchopanza Aug 12 '12 at 14:41
  • The standard containers are only thread safe if they are not being mutated (ie if all calls are to `const qualified` methods). Once mutation starts there are no guarantees. Also note that the map/set operators can potentially mutate the structure when using `operator[]` – Martin York Aug 12 '12 at 16:11

3 Answers3

4

Race conditions will happen: depending on the CPU's ordering of the things done, you will receive different results each time. If an iterator is invalidated (by e.g. deleting an item in one thread and the other thread has an iterator pointing to that now invalid memory) and then used in the other thread, you will get undefined behavior, so be wary of dead babies, clay golems, and haunts, along with the more likely segfaults, delayed segfaults, and runtime crashes.

C++11 introduces mutex and other threading facilities: guard your reads and writes with those if you must.

rubenvb
  • 74,642
  • 33
  • 187
  • 332
  • "you will get a segfault" - you might get a segfault. If the node to which the invalidated iterator points has been freed and reallocated for something else, you might get a less obvious bug. – Steve Jessop Aug 12 '12 at 15:27
  • The worst kid of bug is not a segfault but one that seems to work and crashes much latter in the workflow. Be thankful when in segfaults at the point of the error. – Martin York Aug 12 '12 at 16:13
  • @Loki: I've had worse bug behavior than crashing later in the workflow. For example, not crashing but causing some completely unrelated part of the program to produce the wrong answer. But I totally agree that the sooner and more obviously that a buggy program does something wrong, the better. So a segfault on a line with an error in it is pretty good as things go. – Steve Jessop Aug 12 '12 at 17:55
  • @SteveJessop: I enhanced the segfault part of the answer. – rubenvb Aug 12 '12 at 19:40
0

mutexs,locks.... brrr try to use free lock containers. for example Intel "threading building blocks" aka TBB http://threadingbuildingblocks.org/files/documentation/a00130.html

kain64b
  • 2,258
  • 2
  • 15
  • 27
0

Standard containers aren't thread-safe, and they aren't specified to have "fail fast" iterators in the Java sense. So there are at least two things that can go wrong with unprotected concurrent access:

  1. a data race on the container, which is undefined behavior
  2. one thread invalidates an iterator and later another thread uses an equal-valued iterator. This is also undefined behavior but it isn't necessarily a data race, and would be a bug in a single-threaded program too. It's just a bit easier to lose track of multiple iterators on the same container when they're used in different threads.

One might say that the C++ philosophy is to "succeed fast", and never mind what happens when the programmer fails ;-). Hence there are no built-in locks that would be redundant for many users. Instead it's your problem -- you'd rather be unhappy that the locks are slowing down this program, than unhappy that they're slowing down this program and every other program you ever wrote that used set, even when the set isn't concurrently accessed.

writing operations are not often and reading operation very often.

That's exactly the situation where reader-writer locks should perform well. The only way you can improve your situation is if you can reduce the write operations from "not often" to "never", which presumably you can't.

Steve Jessop
  • 273,490
  • 39
  • 460
  • 699