NPTL Thread synchronization Mode

NPTL provides a mutex pthread_mutex_t type for thread synchronization to prevent improper operation of global variables due to multithreading concurrency. Using pthread_mutext_t to protect data already enables basic data synchronization, and NPTL provides pthread_cond_t condition variables to use with pthread_mutext_t for efficient thread synchronization protection data. With the mutex variable pthread_mutext_t Why do you introduce conditional variable pthread_cond_t? The reason is to prevent the CPU idling, after one thread obtains the mutex, the other thread would like to get the mutex, it will continue to query whether the mutex is free to occupy itself, so wasted CPU cycle. After introducing the conditional variable pthread_cond_t, if the condition is not satisfied, the thread goes to sleep without wasting CPU cycles. The general structure of thread synchronization for NPTL is as follows: Thread1: Pthread_mutex_lock (&mutex);  while(!condition) pthread_cond_wait (&cond, &mutex); /*actual operation, modify condition to invalid*/Pthread_mutex_unlock (&mutex); Thread2:pthread_mutex_lock (&mutex); /*actual operation, modify condition to be valid*/pthread_cond_signal (&cond); Pthread_mutex_unlock (&mutex); Standard code structure is like above, for the above structure to ask a few questions? 1. Why put Pthread_cond_wait in the while (!condition) loop, why have while (!condition) is there? 2Why is pthread_cond_t working with pthread_mutex_t, using pthread_cond_signal threads that don't use pthread_mutext lines? Before answering the above questions, let's introduce the core pthread_cond_wait (&cond, &mutex) What will be done under different circumstances. 1The program runs to the pthread_cond_wait () condition and the code continues to execute downward. 2. When the program runs to the pthread_cond_wait () condition does not occur, the function call first releases the mutex (opens the lock) and causes the current thread to go to sleep. 3The thread that sleeps on pthread_cond_wait () is awakened by signal, and pthread_cond_wait () first obtains the lock (attempts to regain the mutex until it is acquired). The behavior of pthread_cond_wait () is a foreshadowing of the discussion below.　　Now to consider answering the above question, we can from the multi-threaded disorderly execution as a pointcut, thread1 may be executed than thread2 first, thread2 may also be executed than Thread1 first. 1First consider if the thread2 is executed first and has been executed to pthread_cond_signal () but Thread1 is not even running, let alone into the pthread_cond_wait () state, this time there is no while(!condition) What will happen? Obviously Thread2 has sent the Singal, but there is no receiver, at this time there is a loss of signal, that is, if there is no while(!condition) When the Thread1 enters the pthread_cond_wait () will sleep, wake-up signal loss occurs, in this case if there is while(!condition) does not execute pthread_cond_wait () directly executes the following code. So withif(!condtion) Is it possible to solve the above problem? Good is to solve the above problems, but will bring new problems. Consider this scenario: if signal also wakes up multiple wait threads on the condition (Pthread_cond_broadcast or the legendary "surprise group" effect), then using if (!condtion) is not possible. This is because each of the many threads that are awakened must have a critical section that will first enter the protected area of the mutex (recall that the pthread_cond_wait () function described above will attempt to hold the lock until it is held until the thread wakes up), Linux prescribes a low-priority line enters upgradeable obtains the mutex, then takes action, modifies the condition variable, releases the mutex, and the other thread that is sleeping but also tries to acquire the mutex is awakened, and then executes directly down, This can cause multi-threaded synchronization to fail. If you use the while (!condtion) Again, there will be no synchronization failure. 2The second question is relatively simple, and if cond is not used with a mutex, any thread that can access cond may wake up the thread that sleeps on a mutex, so a mutex is required to protect cond to ensure that a qualified thread can wake up on a thread. The key to understanding conditional variables is to understand what pthread_cond_wait () has done!
Reprinted from: http://www.cnblogs.com/zhuyp1015/p/4370170.html

NPTL Thread synchronization Mode