condition variable [closed]

Question

What are the principles of a condition variable in synchronization of the processes of operating systems?

Caloric

It might help if you explain in 2-3 sentences what you have understood and what you haven't understood. That will make it easier (and more likely) for someone to give you a usable answer. Overly general questions such as "please explain X" are not as likely to yield as good an answer as questions in the way of "I do not understand this ... about X" or "why does X do Y, and not Z". – Rajkot

Answer 1

Well, conditional variables allow you to wait for certain condition to occur. In practice your thread may sleep on conditional variable and other thread wakes it up.

Conditional variable also usually comes with mutex. This allows you to solve following synchronisation problem: how can you check state of some mutex protected data structure and then wait until it's state changes to something else. I.e.

/* in thread 1 */
pthread_mutex_lock(mx); /* protecting state access */
while (state != GOOD) {
    pthread_mutex_unlock(mx);
    wait_for_event();
    pthread_mutex_lock(mx);
}
pthread_mutex_unlock(mx);


/* in thread 2 */
pthread_mutex_lock(mx); /* protecting state access */
state = GOOD;
pthread_mutex_unlock(mx);
signal_event(); /* expecting to wake thread 1 up */

This pseudocode sample carries a bug. What happens if scheduler decides to switch context from thread 1 to thread 2 after pthread_mutex_unlock(mx), but before wait_for_event(). In this case, thread 2 will not wake thread 1 and thread 1 will continue sleeping, possibly forever.

Conditional variable solves this by atomically unlocking the mutex before sleeping and atomically locking it after waking up. Code that works looks like this:

/* in thread 1 */
pthread_mutex_lock(mx); /* protecting state access */
while (state != GOOD) {
    pthread_cond_wait(cond, mx); /* unlocks the mutex and sleeps, then locks it back */
}
pthread_mutex_unlock(mx);

/* in thread 2 */
pthread_mutex_lock(mx); /* protecting state access */
state = GOOD;
pthread_cond_signal(cond); /* expecting to wake thread 1 up */
pthread_mutex_unlock(mx);

Hope it helps.

Overpay

In a more general setup, you want to use while(state == GOOD). A condition variable assume the possibility of several threads waiting on the same condition. – Merocrine

This is a nice example, but wouldn't it be a little clearer if thread 1 was waiting while the state was not GOOD? As it stands, I don't see the logic in waiting while the state is currently GOOD, then waking up when the state changes to GOOD, since there is no state change (so really nothing to do)...Of course I might have misunderstood. can someone please clarify? – Branscum

@Branscum From what I can see, you're correct, but the site doesn't allow edits under six characters. The examples make sense to me if state == GOOD is changed to state != GOOD – Shankle

The 6-character-min-edit limitation can be worked around. Make the change you want and also add an additional comment, at the top say. Then if you want you can make a second edit and remove the additional comment. – Bozcaada

As in addition to saying thread 2 will not wake thread 1 and thread 1 will continue sleeping, possibly forever., it involves an undefined behavior, two unlock operations on the same mutex being required. – Paramnesia

thanks for this answer, but I'm still curious how the atomic unlock+sleep is implemented at lower level? There can't be a lock to protect it because you need to unlock anyway before truely sleep, and the problem goes back recursively – Drain