POSIX threads for Linux network programming (iv)

POSIX condition variable and mutex sample producer--Consumer issues

One, POSIX condition variables

A synchronization between threads: Thread A needs to wait for a condition to be set up to continue, now that the condition is not established, thread a blocks the wait, and thread B causes the condition to be created during execution, and wakes thread A to continue executing.

In the Pthread library, a conditional variable (Condition Variable) is used to block waiting for a condition, or to wake up a thread that waits for this condition. The Condition Variable is represented by a variable of type pthread_cond_t, and similar to the initialization and destruction of a mutex, the Pthread_cond_init function initializes a Condition Variable, The attr parameter is null to represent the default property, and the Pthread_cond_destroy function destroys a condition Variable. If the conditionvariable is statically assigned, it can also be initialized with a macro definition Pthead_cond_initializer, which is equivalent to initializing with the Pthread_cond_init function and the attr parameter to NULL.

A condition variable is always used in combination with a mutex. A thread can invoke pthread_cond_wait to block the wait on a condition variable, this function does the following three steps:

1. Release the Mutex

2. Blocking waiting

3. When awakened, regain the mutex and return

Note: 3 operations are atomic, and the reason to release the mutex at first is because the other thread needs to enter the critical section to change the condition, or there are other threads that need to enter the critical section to wait for the condition.

A thread can invoke the first thread that pthread_cond_signal wakes up on a condition variable, or it can call Pthread_cond_broadcast wake up in this condition All threads waiting on the variable.

The above function can be man-specific.

Second, the use of conditions variable specifications

(i), Waiting condition code

Pthread_mutex_lock (&mutex);

while (condition is false)

Pthread_cond_wait (cond, mutex);

Modify condition

Pthread_mutex_unlock (&mutex);

(ii), send notification code to the condition

Pthread_mutex_lock (&mutex);

Set condition to True

Pthread_cond_signal (cond);

Pthread_mutex_unlock (&mutex);

Assuming that the first paragraph is for the consumer thread, the second paragraph is for the producer thread. Why is it possible for a consumer thread to use a while instead of an if? In Man pthread_cond_wait There is a sentence: If a signal is delivered to a thread waiting for a condition variable, upon return the SIG NAL handler the thread resumes waiting for the condition variable as if it is not interrupted, or it shall return zero du E to spurious wakeup.

That is, if a thread that is waiting for a condition variable receives a signal, the thread will wait for the condition variable to be returned from the signal processing function as if it had not been interrupted, or to have been falsely awakened to return 0. If the situation is false awakening, then in fact, the condition has not been changed, then if you do not continue to judge the condition of the true and false to continue to execute, the modification conditions will have problems, so you need to use the while loop to judge again, if the conditions or false must continue to wait.

When the producer has more threads, that is, the production faster, on this side of the assumption is unbounded buffer (such as linked list), you can keep production, use pthread_cond_signal notice, if there is no consumer thread waiting conditions, then this notice will be discarded, But also does not affect the overall code implementation, no consumer thread waiting, indicating that the product resources sufficient, that is, while the failure to judge, will not enter the waiting state, direct consumer products (that is, modify the conditions).