разница между pthread_cond_signal до и после pthread_mutex_unlock

Question

Я пытаюсь осуществить параллельную очередь, и скелет реализации заключается в следующем:

struct queue 
{ 
    int try_pop() 
    { 
     pthread_mutex_lock(&mutex_); 
     int rt; 
     while((rt = do_pop()) == -1) 
     { 
      pthread_cond_wait(&cond_,&mutex_); 
     } 
     pthread_mutex_unlock(&mutex_); 
     return rt; 
    } 

    bool push(int num) 
    { 
     pthread_mutex_lock(&mutex_); 
     push_impl(num); 
#if 0 
     /*signal before unlock*/ 
     pthread_cond_signal(&cond_); 
     pthread_mutex_unlock(&mutex_); 
#else 
     /*signal after unlock*/ 
     pthread_mutex_unlock(&mutex_); 
     pthread_cond_signal(&cond_); 
#endif 
     return true; 
    } 

    // private function and data member 
} 

Я могу назвать pthread_cond_signal до или после разблокирования mutex.

Мой вопрос в том, какая разница между чистым эффектом двух подходов?

Answer 1

Кажется, вам разрешено освобождать мьютексы перед выполнением _signal. В некоторых системах это может даже уменьшить ненужное переключение контекста.

См http://www.domaigne.com/blog/computing/condvars-signal-with-mutex-locked-or-not/

Answer 2

Если у вас есть нити разных приоритетов соперничающих на try_pop(), затем сигнализации после отпирания оставляет окно, где приоритетная нить блокируется в pthread_cond_wait(), но с низким приоритетом нити входит try_pop() в между разблокировать и сигнал, позволяя ему прыгать перед высокоприоритетной нитью. Сигнализация перед разблокировкой предотвратит это.

Если вы не имеют разные приоритеты потоков спорящие так, то после разблокировки сигнализации позволят сигнализировала нить, чтобы проснуться и немедленно принять мьютекс, вместо того, чтобы перейти от «ожидания переменного состояния» к промежуточному состоянию «Ожидание на мьютексе».

Действительно, в этом очень мало. Это вряд ли приведет к какой-либо измеримой разнице.