The myth of the Linux thread lock

http://www.ibm.com/developerworks/cn/linux/thread/posix_thread3/#1

When multithreading wants to wait for a condition to be set up, use pthread_cond_wait to block the thread,

• First clear the role of wait, pthread wait and lock can block the thread waiting for "condition" is established, the difference is:

after wait, the sending condition (Pthread_cond_broadcast ()) is valid, the previous occurrence has been discarded, that is, the first call of wait will certainly block the thread, and will not run down because the condition has been established;

While the condition of lock will remain unlock after it is established (the semaphore is not locked), the first call to lock on the thread will not necessarily block, but depends on the condition state.

• So the question is, why does the pthread_cond_wait call have to ensure that this thread has been lock ? Why should wait be designed like this?

It is said that if there is a condition in wait, it will be missed because wait failed to join the queue in time, just like this?

Try it out, it's OK to call wait while this thread is not locked, and wait will work as well.

The following is a test code to illustrate the problem:

void * FOO1 (void * p) {        while (1) {                printf ("Foo1 wait begin\n");                Pthread_cond_wait (&c,&m);                printf ("Foo1 wait end\n"); sleep (1);}        } void * Foo2 (void * p) {        while (1) {                printf ("Foo2 wait begin\n");                Pthread_cond_wait (&c,&m);                printf ("Foo2 wait end\n"); sleep (1);}        } void * Foo3 (void * p) {        while (1) {                getchar ();                Pthread_cond_broadcast (&c);        }} int Pthreadtest () {        pthread_t  tid[10];        Pthread_create (tid+2,null,foo1,null);        Pthread_create (tid+1,null,foo2,null);        Pthread_create (tid+3,null,foo3,null);        Pthread_join (* (tid+1), NULL);        Pthread_join (* (tid+2), NULL);}

Results

Foo2 wait End
Foo2 wait begin
Foo1 Wait End
FOO1 wait begin

Foo2 wait End
Foo2 wait begin
Foo1 Wait End
FOO1 wait begin

The result is that when the wait wakes up, the mutex is locked, and the other thread is awakened when the thread loops over again and then calls wait again to release the mutex.

so , is it possible for a different mutex between threads to wake up to two threads of wait at the same time, that is, can you simply use cond to control wait wakeup? Each thread is a mutex so that it does not lock its semaphore by another thread, let's test it below:

void * FOO1 (void * p) {        while (1) {                printf ("Foo1 wait begin\n");                Pthread_cond_wait (&c,&m11111);                printf ("Foo1 wait end\n"); sleep (1);}        } void * Foo2 (void * p) {        while (1) {                printf ("Foo2 wait begin\n");                Pthread_cond_wait (&c,&m22222);                printf ("Foo2 wait end\n"); sleep (1);}        }

Results:

Foo2 wait End
Foo2 wait begin

Foo2 wait End
Foo2 wait begin

This????? , only one thread is awakened (which thread is awakened depending on which thread was executed first), and Pthread_cond_broadcast claims to activate all waiting threads, but it doesn't seem easy, It could be wait. The same cond is the fact that his activation mode is serial (that is, after each pthread_cond_signal depending on whether the next time the signal is determined by the wait), another possibility is that there is a problem with the mutex of the later running thread.

Then change the pthread_cond_broadcast to pthread_cond_signal after the test to see, the result:

Foo1 Wait End
FOO1 wait begin

Foo2 wait End
Foo2 wait begin

Foo1 Wait End
FOO1 wait begin

Foo2 wait End
Foo2 wait begin

Does this mean that the activation method, which is unrelated to the mutex, is actually serial? Try again after each pthread_cond_broadcast call unlock (&m11111), the result:

Foo1 Wait End
Foo2 wait End

FOO1 wait begin
Foo2 wait begin

Foo1 Wait End
Foo2 wait End

FOO1 wait begin
Foo2 wait begin

Well, it's supposed to be that the post-running thread can't lock its own mutex while the wait wakes up, but according to the results of the signal just now, who else has lock its mutex?

After thinking, I finally got dizzy ... If a question is not understood, it will produce religion, such as: "Don't ask why, that's what the book says!" ”

so the real reason is: a specific condition can have only one mutex object, and the condition variable should represent a special conditional change in the "inside" of the mutex data. A mutex can have many condition variables (for example, Cond_empty, Cond_full, Cond_cleanup), but only one mutex object per condition variable.

at the same time, wait has only one correct usage : If a thread is waiting for a specific condition to occur, how should it handle the situation? It can repeatedly lock and unlock mutex objects, checking the shared data structure each time 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 the pthread_cond_wait () call to wait for special conditions to occur.

so let's keep this in mind : As he uses it ... Otherwise, it's just going to get obsessed

The myth of the Linux thread lock