How do I know what shared variables I need to protect with a lock in c++ using boost?

Question

For example, multithreading would never work if mutexes were not resilient to multithreaded access (e.g., two simultaneous calls to mutex.lock() can't screw things up).

Does this extend to condition variables too? Specifically, I want to release a lock and then call cond.notify_one(). Theoretically, another thread could then grab the lock before the notification and begin it's own call to cond.notify_one(). Is there a guarantee that this will be well-behaved?

What about simple data structures allocated on the heap? Is it ok to allow concurrent access if the data structure is only being read, assuming the data structure is guaranteed not to self-adjust on a read? Is there documentation on which stl data structures, and member functions allow concurrent reads without requiring locking?

Answer 1

You need to synchronize access to any object where

1. the object is used by more than one thread and
2. at least one of those threads may modify the object.

There are various ways to do that synchronization: locks (mutexes) and atomics are probably the two most commonly used, though there are lock-free implementations of some data structures.

Is there documentation on which STL data structures, and member functions allow concurrent reads without requiring locking?

Any of the const-qualified member functions should be safe to call.

Herb Sutter has written a whole series of articles on Effective Concurrency that you will probably find useful. He discusses various design patterns, common pitfalls, lock hierarchies, and other concurrency topics.

Answer 2

Is it ok to allow concurrent access if the data structure is only being read

Yes. Read-only access can never generate multithreading conflicts.

Answer 3

Mutexes and condition variables are part of the "multi-threading toolchain", used to implement multithreaded applications. As such, they are by definition "thread safe".

Specifically, I want to release a lock and then call cond.notify_one(). Theoretically, another thread could then grab the lock before the notification and begin it's own call to cond.notify_one(). Is there a guarantee that this will be well-behaved?

In such a scenario, you'd want to manipulate the condition variable with the mutex held, precisely to avoid such race conditions.

What about simple data structures allocated on the heap?

Simple (as in byte buffers or C style structures) can be safely accessed concurrently. Any mutating objects will require synchronization.

Is there documentation on which stl data structures, and member functions allow concurrent reads without requiring locking?

As far as I am aware, the Standard C++ library packages are generally not thread safe.

Answer 4

Theoretically, another thread could then grab the lock before the notification and begin it's own call to cond.notify_one(). Is there a guarantee that this will be well-behaved?

You would typically let the other threads wait for the condition and not the lock but if you do then the thread that grabs the lock would prevent the tread being woken by the condition from grabbing the lock and the signaled thread will not be the one to continue, in stead it will wait for the lock.

This is the typical use pattern: Boost Conditions