Say you have this code
pthread_mutex_lock(&cam->video_lock); while(cam->status == WAIT_DISPLAY) // <-- Why is this a 'while' and not an 'if'? pthread_cond_wait(&cam->video_cond, &cam->video_lock); pthread_mutex_unlock(&cam->video_lock);
My question is, why do you need a while loop here. Wouldn't pthread_cond_wait just wait until the signalling thread signals cam_video_cond? OK, I know you might have a case where cam->status is not equal to WAIT_DISPAY when pthread_cond_wait is called, but in that case you could just check it through an if condition rather than using while.
Am I missing something here? My understanding of pthread_cond_wait is that it just waits for infinite if cam_video_cond is not signalled. Moreover, it unlocks the cam_video_lock mutex when called, but when the condition is signalled, before returning, it relocks cam_video_lock. Am I right?
It is recommended that a condition wait be enclosed in a "while loop" that checks the predicate. Additionaly: According to difficulty with creating awakening conditions, which might be unpredictable in multithread systems, threads may wake up whenever for whatever reason.
To guarantee liveness, programs must test the while loop condition before invoking the wait() method. This early test checks whether another thread has already satisfied the condition predicate and sent a notification. Invoking the wait() method after the notification has been sent results in indefinite blocking.
condition_variable::wait wait causes the current thread to block until the condition variable is notified or a spurious wakeup occurs, optionally looping until some predicate is satisfied (bool(stop_waiting()) == true).
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.
It is recommended that all threads check the condition after returning from pthread_cond_wait because there are several reasons the condition might not be true. One of these reasons is a spurious wakeup; that is, a thread might get woken up even though no thread signalled the condition.
Source : Spurious wakeup
Spurious wakeups are one reason, but legitimate but extraneous wakeups are another.
Consider:
You put a job on a queue.
You signal the condition variable, waking thread A.
You put a job on a queue.
You signal the condition variable, waking thread B.
Thread A gets scheduled, does the first job.
Thread A finds the queue non-empty and does the second job.
Thread B gets scheduled, having been woken, but finds the queue still empty.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With