Linux multithreaded Programming tutorial series eight __HTML5

A detailed explanation of conditional variables

At the end of the previous article, I described a more specific challenge: how it should handle the situation if a thread was waiting for a particular condition to occur. It can repeatedly lock and unlock the mutex, and each time the shared data structure is checked to find a value. But this is a waste of time and resources, and the efficiency of this busy query is very low. The best way to solve this problem is to use pthread_cond_wait () calls to wait for special conditions to occur.

Understanding the role of pthread_cond_wait () is important-it is the core and most incomprehensible part of the POSIX thread signaling system.

First, let's consider the following scenario: The thread locked the mutex for viewing the linked list, but the list happens to be empty. This particular thread can do nothing-its design intent is to drop a node from the list, but now there is no node. Therefore, it can only:

When a mutex object is locked, the thread invokes Pthread_cond_wait (&mycond,&mymutex). The pthread_cond_wait () call is rather complex, so we only do one of its operations at a time.

The first thing that pthread_cond_wait () does is to unlock the mutex at the same time (so that other threads can modify the linked list) and wait for the condition Mycond to occur (so that when pthread_cond_wait () receives a "signal" from another thread, It will awaken). The mutex is now unlocked, other threads can access and modify the linked list, and may also add items.

At this point, the pthread_cond_wait () call has not returned. Unlocking a mutex occurs immediately, but the wait condition Mycond is usually a blocking operation, which means that the thread will sleep and will not consume CPU cycles until it wakes up. That is exactly what we are looking forward to. Threads will sleep until certain conditions occur, and no busy queries that waste CPU time will occur during this period. From a thread's point of view, it is just waiting for the pthread_cond_wait () call to return.

Now continue, assuming that another thread (called "Route Line 2") locks the Mymutex and adds an item to the linked list. After the mutex is unlocked, the Line 2 route calls the function Pthread_cond_broadcast (&mycond) immediately. After this operation, Route Line 2 will cause all threads waiting for the mycond condition variable to wake up immediately. This means that the first thread (still in the pthread_cond_wait () call) will now wake up.

Now, take a look at what happened to the first thread. You may think that after the Line 2 route calls Pthread_cond_broadcast (&mymutex), the pthread_cond_wait () of Route Line 1 will return immediately. Not like that. In fact, pthread_cond_wait () will perform the last action: re-lock the Mymutex. Once pthread_cond_wait () locks the mutex, it returns and allows the Line 1 line to continue execution. At that time, it can check the list immediately to see the changes it is interested in. stop and review.

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

1	Pthread_mutex_lock (&mymutex);

Then, it checks the list. Not finding something interesting, so it calls:

1	Pthread_cond_wait (&mycond, &mymutex);

The pthread_cond_wait () call then performs a number of actions before returning:

1	Pthread_mutex_unlock (&mymutex);

It unlocks the Mymutex and then goes to sleep, waiting for Mycond to receive the POSIX thread "signal." Once you receive the "signal" (quoted because we are not talking about the traditional UNIX signal, but from the pthread_cond_signal () or pthread_cond_broadcast () call), it wakes up. But pthread_cond_wait () does not return immediately--it does one thing: re-lock the mutex:

1	Pthread_mutex_lock (&mymutex);

Pthread_cond_wait () knows that we are looking for changes in the Mymutex "behind", so it continues to operate, locking the mutex for us before returning. pthread_cond_wait () quiz

Now that you have reviewed the pthread_cond_wait () call, you should know how it works. You should be able to describe all the actions that pthread_cond_wait () performed sequentially. Try it. If you understand pthread_cond_wait (), the rest is fairly easy, so read the above section again until you remember. OK, after reading, can you tell me what state the mutex must be in before calling Pthread_cond_wait (). After the pthread_cond_wait () call returns, what is the state of the mutex object. The answer to both questions is "lockdown." Now that the pthread_cond_wait () call has been fully understood, it's time to continue to look at something simpler-initialization and real sending and broadcasting processes. By then, we will be able to know the C code that contains the multithreaded work queue. Initializing and purging

A conditional variable is a real data structure that needs to be initialized. The following is the initialization method. First, define or assign a condition variable, as follows: