pthread_cond_wait

考虑下面两种情况：

• Example 1

thread 1:
    pthread_mutex_lock(&mutex);
    while (!condition)
        pthread_cond_wait(&cond, &mutex);
    /* do something that requires holding the mutex and condition is true */
    pthread_mutex_unlock(&mutex);


thread2:
    pthread_mutex_lock(&mutex);
    /* do something that might make condition true */
    pthread_cond_signal(&cond);
    pthread_mutex_unlock(&mutex);

• Exmaple2

thread 1:
    pthread_mutex_lock(&mutex);
    while (!condition)
        pthread_cond_wait(&cond, &mutex);
    /* do something that requires holding the mutex and condition is true */
    pthread_mutex_unlock(&mutex);


thread2:
    pthread_mutex_lock(&mutex);
    /* do something that might make condition true */
    pthread_mutex_unlock(&mutex);

    pthread_cond_signal(&cond);

两者区别仅仅是thread先signal 还是先unlock. From man pthread_cond_init, 例子中用的example1. 而且在很多开源软件中发现都是使用example1.

Question

  1:example 2 有问题吗？如果没有那么example1 & example2 区别是什么？哪个效率高？

   see:1:http://stackoverflow.com/questions/4544234/calling-pthread-cond-signal-without-locking-mutex

             In this thread, someone said if used example2: "this can result in less optimal scheduling of threads"? Why?

          2:http://stackoverflow.com/questions/6419117/signal-and-unlock-order

          3:http://stackoverflow.com/questions/1640389/pthreads-pthread-cond-signal-from-within-critical-section

  2:最开始认为example1是有问题，先signal后unlock会有问题。极端情况，在signal之后unlock之前sleep，那么thread1会唤醒吗?

如果内核的实现是这样,cond与mutex有不同的等待队列，那么不论谁先谁后，都无所谓的。这里仅仅是猜测估计要看kernel关于这部分的实现。