問一個(gè)linux多線程的問題

tklist

1. #include<pthread.h>
   
2. #include<unistd.h>
   
3. #include<stdio.h>
   
4. #include<string.h>
   
5. #include<stdlib.h>
   
6. #include<time.h>
   
7. static pthread_mutex_t mtx=PTHREAD_MUTEX_INITIALIZER;
   
8. static pthread_cond_t cond=PTHREAD_COND_INITIALIZER;
   
9. 
   
10. int global_val = 0;
    
11. 
    
12. void* test(void *argv) {
    
13.     printf("test before lock\n");
    
14.     pthread_mutex_lock(&mtx);
    
15.     while(global_val == 0) {
    
16.         pthread_cond_wait(&cond,&mtx);
    
17.     }
    
18.     pthread_mutex_unlock(&mtx);
    
19.     printf("@@@@@%d\n",global_val);
    
20. }
    
21. void* add(void *argv) {
    
22.     sleep(1);
    
23.     printf("add before lock\n");
    
24.     pthread_mutex_lock(&mtx);
    
25.     global_val++;
    
26.     printf("###%d\n",global_val);
    
27.     pthread_mutex_unlock(&mtx);
    
28.    
    
29. }
    
30. int main() {
    
31.     pthread_t tid1,tid2;
    
32.     global_val = 0;
    
33.     pthread_create(&tid1,NULL,test,NULL);
    
34.     sleep(1);
    
35.     pthread_create(&tid2,NULL,add,NULL);
    
36.     printf("main begin\n");
    
37.     pthread_mutex_lock(&mtx);
    
38.     global_val = 5;
    
39.     sleep(3);
    
40.     pthread_cond_signal(&cond);
    
41.     printf("signal over before unlock\n");
    
42.     sleep(3);
    
43.     pthread_mutex_unlock(&mtx);
    
44.     pthread_join(tid1,NULL);
    
45.     pthread_join(tid2,NULL);
    
46. }

復(fù)制代碼

我要模擬的情況是有一個(gè)test線程阻塞在pthread_cond_wait(&cond,&mtx);，另外一個(gè)add線程阻塞在pthread_mutex_lock(&mtx);
然后主線程調(diào)用pthread_cond_signal(&cond);和pthread_mutex_unlock(&mtx); 這個(gè)時(shí)候會是哪個(gè)線程搶到鎖？
pthread_cond_wait的線程會高優(yōu)先級搶到鎖嗎，還是說隨機(jī)的？
我上面測試代碼是add線程搶到了鎖。
我的測試代碼輸出：
test before lock
main begin
add before lock
signal over before unlock
###6
@@@@@6

skycs13

按照入列順序激活，你的例子中test的lock mutex的操作發(fā)生在pthread_cond_signal之后，而add的lock mutex的操作發(fā)生在一開始，因此add線程先入列，因此先unlock add線程的鎖。
你可以做一下測試，將add線程的sleep(1) 改為sleep(5), 讓主線程先pthread_cond_signal，然后add線程lock mutex, 這樣就是test 的 lock mutex 操作先入列，add的后入列，最后再在主線程unlock mutex， 打印順序肯定是test線程搶到了鎖，其實(shí)也不能說是搶對吧，先來先得

tklist

嗯，測試你的說的那種情況確定是這樣的。但是現(xiàn)在我把第42行的sleep(3)注釋掉，其他的保存不變。這個(gè)時(shí)候就是test線程先搶到鎖。這個(gè)和你說的矛盾。回復(fù) 2# skycs13


   

skycs13

在你把42行的sleep（3）去掉的時(shí)候，在pthread_cond_signal的時(shí)候，立馬就把鎖給釋放了，這個(gè)時(shí)候，主線程先signal條件變量，然后釋放鎖，瞬間就把test的條件變量激活，而在這個(gè)時(shí)候，add線程還在sleep（5）里面，要等個(gè)2（5-3）秒鐘才從sleep（5）中出來，在你去掉sleep（3）之后，根本談不到對鎖的競爭了。這個(gè)時(shí)候就是個(gè)順序的過程。

tklist

額，我的意思是add里面sleep的時(shí)間改回去變成1回復(fù) 4# skycs13


   

skycs13

我所測試的結(jié)果跟你的不同，我用的是gcc 4.8.2, 我的是add先搶到鎖。你想一下，pthread_cond_signal是在3秒之后才掉用，而add只sleep了一秒就調(diào)用了，按理來說，對于應(yīng)該是add這個(gè)線程先入列而test后入列，也應(yīng)該是先激活add線程，我的結(jié)果global_val打印出來都是6回復(fù) 5# tklist