pthread_cond_wait sum of a mutex in combination. You must first acquire a lock before calling pthread_cond_wait. First released automatically lock when pthread_cond_wait specified function is executed, and then wait for changes in the condition variable. Before the function call returns, will automatically re-lock the specified mutex.
int pthread_cond_signal(pthread_cond_t * cond);
pthread_cond_signal cond message sent by the condition variable, if a plurality of messages waiting, only a wake-up. pthread_cond_broadcast can wake up at all. Pthread_cond_signal immediately after the call to release the mutex, because the last step pthread_cond_wait is specified mutex To re-lock if the mutex is not released after pthread_cond_signal, pthread_cond_wait still blocked.
Either wait mode, and a mutex must cooperate to prevent multiple threads simultaneously request pthread_cond_wait () (or pthread_cond_timedwait (), the same below) competitive conditions (Race Condition). mutex mutex lock must be ordinary (PTHREAD_MUTEX_TIMED_NP) or to accommodate lock (PTHREAD_MUTEX_ADAPTIVE_NP), and must be locked by the thread before calling pthread_cond_wait () (pthread_mutex_lock ()) , while waiting in queue before the update condition, mutex remains locked, and in the thread hangs waiting before entering the unlock. Before leaving condition is satisfied so pthread_cond_wait (), the mutex is re-locked to the locking operation into the pthread_cond_wait () corresponding to the front.
There are two forms of excitation conditions, a pthread_cond_signal () the activation of a thread waiting condition, wherein the activation order according to enqueue the presence of a plurality of threads waiting; and a pthread_cond_broadcast () activate all the waiting threads.
The following is another explanation: the function is given in the entire process. Why re-mutex lock after wake-up thread?
Learn pthread_cond_wait () role is very important - it is the core of POSIX threads signaling system, but also the most difficult to understand sections.
First, let us consider the following: View a list of links to threads and locks the mutex, but the list happens to be empty. This particular thread can not do anything - It is designed to remove a node from the list, but now no nodes. Therefore, it can only be:
locked mutex, the thread will call pthread_cond_wait (& mycond, & mymutex) . pthread_cond_wait () call is quite complex, so every time we perform only one of its operations.
pthread_cond_wait () does the first thing is that while mutex unlock (so other threads can modify the linked list), and wait for conditions mycond occur (such as pthread_cond_wait () received another thread "signal" when, it will wake up). Now the mutex is unlocked, other threads can access and modify the list of links, you may also add items. [ Required occlusion is unlocked and an atomic operation ]
At this time, pthread_cond_wait () call has not been returned. Mutex unlocking will happen immediately, but usually a wait condition mycond blocking operation, which means that the thread will sleep before waking up it does not consume CPU cycles. This is what we expect happens. Thread will sleep until certain conditions occur , any waste of CPU busy time of the query does not occur during this period. From the point of view of threads, it is just waiting for pthread_cond_wait () call returns.
Now continuing, it is assumed that another thread (referred to as "No. 2 threads") has been locked mymutex and adds a list of links. After the mutex unlocked, No. 2 threads call the function immediately pthread_cond_broadcast (& mycond). After this operation, the 2nd thread will wait for all mycond condition variable thread wake up immediately. This means that the first thread (still in pthread_cond_wait () call) will now wake up .
Now, look at what happened the first thread. You might think that after the No. 2 thread calls pthread_cond_broadcast (& mymutex), No. 1 thread pthread_cond_wait () returns immediately. Not like that! In fact, pthread_cond_wait () will perform the last operation: relock mymutex . Once pthread_cond_wait () to lock the mutex, it will return to No. 1 and allows the thread to continue. At that time, it can immediately check the list to see change its interest.
Look at an example (if you can understand it?):
In Thread1:
pthread_mutex_lock(&m_mutex);
pthread_cond_wait(&m_cond,&m_mutex);
pthread_mutex_unlock(&m_mutex);
In Thread2:
pthread_mutex_lock(&m_mutex);
pthread_cond_signal(&m_cond);
pthread_mutex_unlock(&m_mutex);
Why use it with pthread_mutex? This is in response to thread 1 in the call pthread_cond_wait () thread 1 but has not yet entered a state of wait cond time, thread 2 calls the situation at this time of cond_singal. If you do not mutex lock, then this cond_singal lost. Plus a locked case, the thread must wait until the mutex 2 to be released (ie pthread_cod_wait () to release the lock and enter wait_cond state, then locked thread 2) when I could call cond_singal.
After pthread_cond_signal pthread_mutex_lock and which can be placed between pthread_mutex_unlock, and can be placed pthread_mutex_lock pthread_mutex_unlock, but each has disadvantages.
Between:
pthread_mutex_lock
xxxxxxx
pthread_cond_signal
pthread_mutex_unlock
drawback: at achieving a thread, the thread will result in waiting wake (due cond_signal) from the kernel and then back to the kernel space (because there will be locked atomic behavior after cond_wait return), so there will be a return to the issue of performance. But there NPTL or LinuxThreads, do not have this problem, because the Linux thread, there are two queues, queue and are cond_wait mutex_lock queue, cond_signal just let the thread moves from cond_wait mutex_lock queue queue, rather than returned to the user space, there will be no loss of performance.
So in Linux I recommend using this mode.
After:
pthread_mutex_lock
xxxxxxx
pthread_mutex_unlock
pthread_cond_signal
advantages: said before that potential performance loss does not occur, because before the signal has been released lock
Cons: If you have previously unlock and signal, there is a low priority thread is mutex on wait, then the low priority thread will seize the high priority thread (cond_wait thread), which put in the middle of the above model is not the case.