2012-10-05 108 views
0

我的互斥鎖似乎已解鎖。 我的代碼看起來是這樣的(而不是實際的代碼)(使用並行線程):pthread狀態信號不鎖定互斥鎖

thread 
    { 
    int id=...; 
    //locked aditional mutex _m2 
    mutex_lock(&_m); 
    varx=valuex;//irelevant 
    print("th%d signaling listener",id); 
    cond_signal(&_c); 
    print("th%d signaled listener",id); 
    mutex_unlock(&_m); 
    //unlocked additional mutex _m2 
    } 

listener 
    { 
    tc=0 
    mutex_lock(&_m); 
    while(tc<threadcount) 
     { 
     cond_wait(&_c,&_m); 
     print("working"); 
     tc++ 
     work; 
     } 
    mutex_unlock(&_m); 
    } 

正常(預測)出地說:

th0 signaling listener; 
    working; 
    th0 signaled listener; 

    th1 signaling listener; 
    working; 
    th1 signaled listener; 

我的輸出:

0 signaling listener; 
    working; 
    0 signaled listener; 

    1 signaling listener; 
    1 signaled listener; 

..所以線程跳過(監聽程序不執行也不鎖定_m)到打印輸出

我已經用他lgrind(full),我沒有任何錯誤,但是我的應用程序停止在監聽器上,因爲根據他,他正在等待所有完成。

備註: 監聽器可以連接。 其他互斥鎖_m2不起作用。 線程分離。我有大約800個分離的線程來避免堆棧問題,最多50個同時使用信號量來限制線程數。 爲3-4線程工作的代碼

回答

0

pthread_cond_signal()不解鎖任何互斥鎖。它不應該(不會傳遞給它的互斥量)。如果至少有一個線程正在等待條件變量發送信號,則該線程將在重新獲取它傳遞給pthread_cond_wait()的互斥量時進行調度。

在您的情況下,您的聽衆似乎正在等待其他線索信號(_c)的條件(_s)。

如果你解決了這個問題,你也有這樣的問題,你在等待條件變量的線程和發出信號的線程之間似乎沒有任何共享狀態。看起來你的tc計數器實際上應該是一個共享變量,受_m互斥量的保護。那麼你的線程會做:

pthread_mutex_lock(&_m); 
tc++; 
if (tc >= threadcount) 
    pthread_cond_signal(&_c); 
pthread_mutex_unlock(&_m); 

與聽者會做:

pthread_mutex_lock(&_m); 
while (tc < threadcount) 
    pthread_mutex_wait(&_c, &_m); 
pthread_mutex_unlock(&_m); 

然後偵聽只會繼續一旦所有的線程都打信號代碼,這似乎是你」之後。

或者你可以使用pthread_barrier_wait(),這似乎是你正在實施的。

+0

我的錯誤_s和_c是我錯過輸入它的同一個變量。我用我的數據隊列來解決我的代碼,並將其鎖定在推送和監聽器中。我會考慮屏障等待,因爲我的代碼確實有效,但我似乎有一些鎖helgrind報告失敗(1確切地說是在最後 - 也許是一個錯誤,防止互斥鎖解鎖)。看着障礙它並沒有幫助我。 – LucianMLI

+0

我確實有一個共享變量(x),但由於所有線程都只讀取它,因此我不會鎖定它。偵聽器僅檢查是否所有數據都已處理完,並且是否處理(q-mutexed)中的數據。 th將來自已知大小的共享變量(x)的更多數據添加到(q-mutexed)中。代碼有效。 – LucianMLI

+0

@LucianMLI:爲了正確使用pthread條件變量,必須使用某種可寫的共享狀態。 – caf