Pthread_cond_wait () Usage

Pthread_cond_wait () Usage
Pthread_cond_wait () is a method for implementing multi-thread synchronization in linux. It indicates that the thread can continue executing the code after pthread_cond_wait () only when the shared variable of a thread meets certain conditions, as shown in the following sample code snippet, the code example in the thread_func () function is a common way to wait for shared variables. Here we mainly focus on the use of while (head = NULL ).

Struct xxx * head;/** global thread sharing variable */pthread_mutex_t CTX = PTHREAD_MUTEX_INITIALIZER;/** mutex lock used for condition variables */pthread_cond_t cond = PTHREAD_COND_INITIALIZER; /** define the condition variable */staticvoid * thread_func (void * arg) for global thread sharing {/** first obtain the mutex lock, indicates that only one thread waiting condition variable can be found at a time * if only one thread listening condition variable is not kept, this may cause the thread to "surprise" phenomenon */pthread_mutex_lock (& CTX ); /** the following explains why we need to judge the value of head = NULL first (assuming we need to wait for head = NULL) * According to pthread-related documents: Suppose thread 1 is executed to pthread_cond_w. When ait () is used, the thread first releases the CTX mutex lock, * and then waits for pthread_cond_signal () or pthread_cond_broadcast () the sent "condition satisfies the signal" * if another thread 2 obtains the-based content-based data integration, if head = NULL and a signal is sent, and * is completed, the mtlock is released. At this time, thread 3 may be waiting to obtain the mutex lock. Now there are two situations: 1. thread 3 * obtains the lock, and then performs some operations on the head. Later, it may send a signal and release the mutex lock. 2. thread 1 obtains the mutex * Lock. In this case, thread 1 continues the logic of the original waiting. Because the lock is released while waiting, it needs to be acquired again, * At this time, the program executes the while (head = NULL) Judgment, OK, now you can understand why we need to judge head = NULL here? Because in Case 1, thread 3 may obtain the lock earlier than thread 1 and then operate on the head and make the head! = NULL. In fact, a large system may have more * threads competing for a mutex lock at the same time. There may be more changes to the value of shared variables, that is to say, thread 1 releases the lock after it enters the wait state. * when it receives the wake-up signal and re-acquires the lock, it may not be the first thread to obtain the lock after receiving the signal, that is, when the lock is obtained, * Other threads may obtain the lock and change the head value. For example, in the above example, although thread 2 sends a signal when head = NULL. * Thread 1 determines whether head = NULL is satisfied. If the condition is not met, the user will release the lxms lock again and enter the signal waiting process, repeat the above wake-up logic * until the head = NULL, the logic after the program executes, and finally releases the MTLS mutex lock */while (head! = NULL) {pthread_cond_wait (& cond, & CTX) ;}/ ** head = logic executed when NULL */... pthread_mutex_unlock (& CTX); // after the data operation in the critical section is completed, release the mutex lock return0 ;}

The signals mentioned above are not just unix/linux semaphores or system signals. They only represent a thread-wake communication method.