Differences between Conditional variables, Mutexes and Locks

Question

For example the C++11 interfaces

I am having a hard time figuring out when to use which of these things (cv, mutex and lock). Can anyone please explain or point to a resource?

Thanks in advance.

Dysprosium

Answer 1

On the page you refer to, "mutex" is the actual low-level synchronizing primitive. You can take a mutex and then release it, and only one thread can take it at any single time (hence it is a synchronizing primitive). A recursive mutex is one which can be taken by the same thread multiple times, and then it needs to be released as many times by the same thread before others can take it.

A "lock" here is just a C++ wrapper class that takes a mutex in its constructor and releases it at the destructor. It is useful for establishing synchronizing for C++ scopes.

A condition variable is a more advanced / high-level form of synchronizing primitive which combines a lock with a "signaling" mechanism. It is used when threads need to wait for a resource to become available. A thread can "wait" on a CV and then the resource producer can "signal" the variable, in which case the threads who wait for the CV get notified and can continue execution. A mutex is combined with CV to avoid the race condition where a thread starts to wait on a CV at the same time another thread wants to signal it; then it is not controllable whether the signal is delivered or gets lost.

Paige

Isn't waiting (thread1) + signaling (thread2) with convars, exactly the same as locking (thread1) + unlocking(thread2) ? – Dysprosium

@hydroes: no. If thread1 is waiting on a lock, then some other thread must be holding it for thread1 to remain blocked. Once that other thread releases it, thread1 can unblock to take the mutex. With a condition variable, any thread can signal to unblock the waiter(s), not just some special thread that has been holding the lock the whole time. Also, you can broadcast a condition variable, to release all waiting threads. – Mcnelly

The very piece of missing documentation. Thanks! – Admittedly

@Antti Huima "A mutex is combined with CV to avoid the race condition where a thread starts to wait on a CV at the same time another thread wants to signal it; then it is not controllable whether the signal is delivered or gets lost." This is probably the key explanation that is missing elsewhere? – Lentic

A mutex is combined with CV to avoid the race condition part is incorrect. When there is no waiter on the condition variable the notification gets lost anyway. Spurios wake ups also happen. Mutex and condition variable are rather used to wait for a change in the shared state. And to eliminate race conditions mutex must be locked when the shared state is updated or read. Mutex doesn't need to be locked when signalling a condition variable, contrary to the advice in the answer (just read the documentation for std::condition_variable::notify_one and pthread_cond_signal). – Ternary

Answer 2

This question has been answered. I just add this that may help to decide WHEN to use these synchronization primitives.

Simply, the mutex is used to guarantee mutual access to a shared resource in the critical section of multiple threads. The luck is a general term but a binary mutex can be used as a lock. In modern C++ we use lock_guard and similar objects to utilize RAII to simplify and make safe the mutex usage. The conditional variable is another primitive that often combined with a mutex to make something know as a monitor.

I am having a hard time figuring out when to use which of these things (cv, mutex and lock). Can anyone please explain or point to a resource?

Use a mutex to guarantee mutual exclusive access to something. It's the default solution for a broad range of concurrency problems. Use lock_guard if you have a scope in C++ that you want to guard it with a mutex. The mutex is handled by the lock_guard. You just create a lock_guard in the scope and initialize it with a mutex and then C++ does the rest for you. The mutex is released when the scope is removed from the stack, for any reason including throwing an exception or returning from a function. It's the idea behind RAII and the lock_guard is another resource handler.

There are some concurrency issues that are not easily solvable by only using a mutex or a simple solution can lead to complexity or inefficiency. For example, the produced-consumer problem is one of them. If we want to implement a consumer thread reading items from a buffer shared with a producer, we should protect the buffer with a mutex but, without using a conditional variable we should lock the mutex, check the buffer and read an item if it's not empty, unlock it and wait for some time period, lock it again and go on. It's a waste of time if the buffer is often empty (busy waiting) and also there will be lots of locking and unlocking and sleeps.

The solution we need for the producer-consumer problem must be simpler and more efficient. A monitor (a mutex + a conditional variable) helps us here. We still need a mutex to guarantee mutual exclusive access but a conditional variable lets us sleep and wait for a certain condition. The condition here is the producer adding an item to the buffer. The producer thread notifies the consumer thread that there is and item in the buffer and the consumer wakes up and gets the item. Simply, the producer locks the mutex, puts something in the buffer, notifies the consumer. The consumer locks the mutex, sleeps while waiting for a condition, wake s up when there is something in the buffer and gets the item from the buffer. It's a simpler and more efficient solution.

The next time you face a concurrency problem think this way: If you need mutual exclusive access to something, use a mutex. Use lock_guard if you want to be safer and simpler. If the problem has a clue of waiting for a condition that must happen in another thread, you MIGHT need a conditional variable.

As a general rule of thumb, first, analyze your problem and try to find a famous concurrency problem similar to yours (for example, see classic problems of synchronization section in this page). Read about the solutions proposed for the well-known solution to peak the best one. You may need some customization.

Longo

Answer 3

I'm not too familiar w/ C++0x so take this answer w/ a grain of salt.

re: Mutex vs. locks: From the documentation you posted, it looks like a mutex is an object representing an OS mutex, whereas a lock is an object that holds a mutex to facilitate the RAII pattern.

Condition variables are a handy mechanism to associate a blocking/signaling mechanism (signal+wait) with a mutual exclusion mechanism, yet keep them decoupled in the OS so that you as system programmer can choose the association between condvar and mutex. (useful for dealing with multiple sets of concurrently-accessed objects) Rob Krten has some good explanations on condvars in one of the online chapters of his book on QNX.

As far as general references: This book (not out yet) looks interesting.

Cattail