差在調用pthread_mutex_unlock

後，我想實現一個併發隊列，和實施的骨架如下：差在調用pthread_mutex_unlock

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 
}

我之前或解鎖mutex後打電話pthread_cond_signal。

我的問題是兩種方法的淨效應有什麼區別？

來源

2017-02-20 gjha

關於此手冊頁中有一段：https://linux.die.net/man/3/pthread_cond_signal – mch

這可能是相關的：http://stackoverflow.com/questions/4544234/calling- pthread-cond-signal-without-locking-mutex/4544494，但是OTOH，當你改變共享狀態時你確實持有互斥量，所以也許在你的情況下在_signal之前解鎖互斥量是可以的。 –

看來你可以在做_signal之前釋放互斥鎖。在某些系統上，這甚至可以減少不必要的上下文切換。

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

來源

2017-02-20 10:15:44

如果你有不同的優先級爭奪上try_pop()，然後信號解鎖離開，其中一個高優先級的線程被阻塞在pthread_cond_wait()窗口後的線程，但是低優先級的線程之間進入try_pop()解鎖和信號，允許它跳到高優先級線程的前面。解鎖之前的信號傳輸將阻止這一點。

如果沒有有不同的線程優先級爭這樣，那麼信號在解鎖之後將允許信號線醒來，立即採取互斥體，而不是從「等待條件變量」動先到一箇中間的「等待互斥體」狀態。

真的，其實很少。這不可能產生任何可衡量的差異。

來源

2017-02-21 00:03:53 caf

差在調用pthread_mutex_unlock

回答

相關問題