Pthread_cond_wait ()

Understanding the role of pthread_cond_wait () is very important-it is the core of the POSIX thread signal sending system and the most difficult to understand.


First, let's consider the following situation: the thread locks the mutex object to view the linked list, but the list happens to be empty. This particular thread cannot do anything-it is designed to remove nodes from the list, but now there are no nodes. Therefore, it can only:


When a mutex object is locked, the thread will call pthread_cond_wait (& mycond, & mymutex ). Pthread_cond_wait () calls are quite complex, so we only execute one operation at a time.


The first thing pthread_cond_wait () does is to unlock the mutex object at the same time (so other threads can modify the linked list) and wait for the condition mycond to occur (when pthread_cond_wait () when receiving the "signal" from another thread, it will wake up ). The mutex object has been unlocked. Other threads can access and modify the linked list, and may add items. It is an atomic operation to require unlocking and blocking]


At this time, the call to pthread_cond_wait () has not yet returned. Unlocking A mutex will happen immediately, but the waiting condition mycond is usually a blocking operation, which means the thread will sleep and will not consume the CPU cycle until it wakes up. This is exactly what we are looking forward. The thread will sleep until a specific condition occurs. During this period, no busy queries that waste CPU time will occur. From the thread perspective, it is just waiting
Pthread_cond_wait () is returned.


Now, let's continue to explain that another thread (called thread 2) locks mymutex and adds an item to the linked list. After the mutex object is unlocked, thread 2 immediately calls the pthread_cond_broadcast (& mycond) function ). After this operation, thread 2 will immediately wake up all threads waiting for the mycond condition variable. This means that the first thread (still in the pthread_cond_wait () call) will be awake now.


Now, let's take a look at what happened to the first thread. You may think that after thread 2 calls pthread_cond_broadcast (& mymutex), The pthread_cond_wait () of thread 1 will return immediately. That's not the case! In fact, pthread_cond_wait () will execute the last operation: Re-lock mymutex. Once pthread_cond_wait ()
If the mutex object is locked, it will return and allow thread 1 to continue execution. At that time, it can immediately check the list and view the changes it is interested in.

Stop and review!

That process is very complicated, so let's review it first. The first thread first calls:




Pthread_mutex_lock (& mymutex );





Then, it checks the list. Something of interest is not found, so it calls:




Pthread_cond_wait (& mycond, & mymutex );





Then, the pthread_cond_wait () call performs many operations before the return:




Pthread_mutex_unlock (& mymutex );





It unlocks mymutex and then enters sleep state, waiting for mycond to receive the POSIX thread "signal ". Once a "signal" is received (quotes are enclosed because we are not discussing traditional UNIX signals, but the signals from pthread_cond_signal () or pthread_cond_broadcast () calls), it will wake up. But pthread_cond_wait () does not return immediately -- it also needs to do one thing: Re-lock mutex:




Pthread_mutex_lock (& mymutex );





Pthread_cond_wait () knows the changes behind mymutex, so it continues to lock the mutex for us before returning.