When is a condition variable needed, isn't a mutex enough?

Question

I'm sure mutex isn't enough that's the reason the concept of condition variables exist; but it beats me and I'm not able to convince myself with a concrete scenario when a condition variable is essential.

Differences between Conditional variables, Mutexes and Locks question's accepted answer says that a condition variable is 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

Where I get confused is that, a thread can wait on a mutex too, and when it gets signalled, is simply means the variable is now available, why would I need a condition variable?

P.S.: Also, a mutex is required to guard the condition variable anyway, when makes my vision more askew towards not seeing condition variable's purpose.

Answer 1

Mutex is for exclusive access to shared resources, while conditional variable is for waiting for a condition to be true. They are two different types of kernel resource. Some people might think they can implement conditional variable by themselves with mutex, a common pattern is "flag + mutex":

lock(mutex)

while (!flag) {
    sleep(100);
}

unlock(mutex)

do_something_on_flag_set();

but this doesn't work, because the thread never releases the mutex during the wait, other threads cannot set the flag in a thread-safe way. This is why you need kernel support for conditional variables, so when a thread is waiting on a condition variable, the associated mutex is not hold by the thread until it's signaled.

Answer 2

In my opinion, maybe you can use two mutex to implement mutex + cond_var

here is the way:

• replace pthread_cond_wait(&cond_var, &mutex) with

pthread_mutex_unlock(&mutex);
pthread_mutex_trylock(&mutex_new);
pthread_mutex_lock(&mutex_new);
pthread_mutex_lock(&mutex);

• replace pthread_cond_signal(&cond_var) with

pthread_mutex_unlock(&mutex_new);

but there is still a problem, maybe producer do signal things between

pthread_mutex_unlock(&mutex);
producer signal!
pthread_mutex_trylock(&mutex_new);

then consumer never wake up, but conditional var won't let this happen

Answer 3

Slowjelj is right, but to shed some light on the problem, look at the python code below. We have a buffer, a producer, and a consumer. And think if you could rewrite it just with mutexes.

import threading, time, random
cv = threading.Condition()
buffer = []
MAX = 3

def put(value):    
    cv.acquire()
    while len(buffer) == MAX:            
        cv.wait()        
    buffer.append(value)
    print("added value ", value, "length =", len(buffer))
    cv.notify()
    cv.release()

def get():    
    cv.acquire()
    while len(buffer) == 0:            
        cv.wait()        
    value = buffer.pop()
    print("removed value ", value, "length =", len(buffer))
    cv.notify()
    cv.release()

def producer():
    while True:
        put(0) # it doesn't mater what is the value in our example
        time.sleep(random.random()/10)

def consumer():
    while True:
        get()
        time.sleep(random.random()/10)

if __name__ == '__main__':
    cs = threading.Thread(target=consumer)    
    pd = threading.Thread(target=producer)
    cs.start()            
    pd.start()
    cs.join()
    pd.join()

Answer 4

I was thinking about this too and the most important information which I think was missing everywhere is that mutex can be owned (or changed) by only one thread at a time. So if you have one producer and more consumers, the producer would have to wait on mutex to produce. With cond. variable it can produce at any time.

Answer 5

I think it is implementation defined.
The mutex is enough or not depends on whether you regard the mutex as a mechanism for critical sections or something more.

As mentioned in http://en.cppreference.com/w/cpp/thread/mutex/unlock,

The mutex must be locked by the current thread of execution, otherwise, the behavior is undefined.

which means a thread could only unlock a mutex which was locked/owned by itself in C++.
But in other programming languages, you might be able to share a mutex between processes.

So distinguishing the two concepts may be just performance considerations, a complex ownership identification or inter-process sharing are not worthy for simple applications.

---

For example, you may fix @slowjelj's case with an additional mutex (it might be an incorrect fix):

Thread1:

lock(mutex0);
while(1) {
    lock(mutex0); // Blocks waiting for notification from Thread2
    ... // do work after notification is received
    unlock(mutex1); // Tells Thread2 we are done
}

Thread2:

while(1) {
    lock(mutex1); // lock the mutex so Thread1 will block again
    ... // do the work that precedes notification
    unlock(mutex0); // unblocks Thread1
}

But your program will complain that you have triggered an assertion left by the compiler (e.g. "unlock of unowned mutex" in Visual Studio 2015).

Answer 6

The conditional var and the mutex pair can be replaced by a binary semaphore and mutex pair. The sequence of operations of a consumer thread when using the conditional var + mutex is:

1. Lock the mutex

2. Wait on the conditional var

3. Process

4. Unlock the mutex

The producer thread sequence of operations is

1. Lock the mutex

2. Signal the conditional var

3. Unlock the mutex

The corresponding consumer thread sequence when using the sema+mutex pair is

1. Wait on the binary sema

2. Lock the mutex

3. Check for the expected condition

4. If the condition is true, process.

5. Unlock the mutex

6. If the condition check in the step 3 was false, go back to the step 1.

The sequence for the producer thread is:

1. Lock the mutex

2. Post the binary sema

3. Unlock the mutex

As you can see the unconditional processing in the step 3 when using the conditional var is replaced by the conditional processing in the step 3 and step 4 when using the binary sema.

The reason is that when using sema+mutex, in a race condition, another consumer thread may sneak in between the step 1 and 2 and process/nullify the condition. This won't happen when using conditional var. When using the conditional var, the condition is guarantied to be true after the step 2.

The binary semaphore can be replaced with the regular counting semaphore. This may result in the step 6 to step 1 loop a few more times.

Answer 7

You need condition variables, to be used with a mutex (each cond.var. belongs to a mutex) to signal changing states (conditions) from one thread to another one. The idea is that a thread can wait till some condition becomes true. Such conditions are program specific (i.e. "queue is empty", "matrix is big", "some resource is almost exhausted", "some computation step has finished" etc). A mutex might have several related condition variables. And you need condition variables because such conditions may not always be expressed as simply as "a mutex is locked" (so you need to broadcast changes in conditions to other threads).

Read some good posix thread tutorials, e.g. this tutorial or that or that one. Better yet, read a good pthread book. See this question.

Also read Advanced Unix Programming and Advanced Linux Programming

P.S. Parallelism and threads are difficult concepts to grasp. Take time to read and experiment and read again.

Answer 8

Even though you can use them in the way you describe, mutexes weren't designed for use as a notification/synchronization mechanism. They are meant to provide mutually exclusive access to a shared resource. Using mutexes to signal a condition is awkward and I suppose would look something like this (where Thread1 is signaled by Thread2):

Thread1:

while(1) {
    lock(mutex); // Blocks waiting for notification from Thread2
    ... // do work after notification is received
    unlock(mutex); // Tells Thread2 we are done
}

Thread2:

while(1) {
    ... // do the work that precedes notification
    unlock(mutex); // unblocks Thread1
    lock(mutex); // lock the mutex so Thread1 will block again
}

There are several problems with this:

1. Thread2 cannot continue to "do the work that precedes notification" until Thread1 has finished with "work after notification". With this design, Thread2 is not even necessary, that is, why not move "work that precedes" and "work after notification" into the same thread since only one can run at a given time!
2. If Thread2 is not able to preempt Thread1, Thread1 will immediately re-lock the mutex when it repeats the while(1) loop and Thread1 will go about doing the "work after notification" even though there was no notification. This means you must somehow guarantee that Thread2 will lock the mutex before Thread1 does. How do you do that? Maybe force a schedule event by sleeping or by some other OS-specific means but even this is not guaranteed to work depending on timing, your OS, and the scheduling algorithm.

These two problems aren't minor, in fact, they are both major design flaws and latent bugs. The origin of both of these problems is the requirement that a mutex is locked and unlocked within the same thread. So how do you avoid the above problems? Use condition variables!

BTW, if your synchronization needs are really simple, you could use a plain old semaphore which avoids the additional complexity of condition variables.