這是GCD介紹的第二篇
在我之前的文章中，我們已經學習過了在異步的程序中競態條件是一個很常見的問題。就是當一份數據同時被多個線程操作，產生的結果將不可預測。
該問題的一個典型解決方法就是使用互斥鎖(mutual exclusion)。這里有一個使用 Posix threads API的例子：
#import <Foundation/Foundation.h>
#import <pthread/pthread.h>
// Each player gets 100 gems to start
int playerAGems = 100;
int playerBGems = 100;
// Data structure to hold information about the mutual exclusion object
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
void *thread1(void *arg) {
// Move 20 gems from player A to player B
pthread_mutex_lock(&mutex); // Wait until we gain access to the mutex
playerAGems -= 20;
playerBGems += 20;
NSLog(@"Player A now has %d gems, and player B has %d gems.", playerAGems, playerBGems);
pthread_mutex_unlock(&mutex); // Unlock the mutex
return NULL;
}
void *thread2(void *arg) {
// Move 50 gems from player B to player A
pthread_mutex_lock(&mutex);
playerAGems += 50;
playerBGems -= 50;
NSLog(@"Player A now has %d gems, and player B has %d gems.", playerAGems, playerBGems);
pthread_mutex_unlock(&mutex);
return NULL;
}
int main() {
pthread_mutex_init(&mutex, NULL); // Initialize the mutex
pthread_t t1; // Data structure to hold information about thread 1
pthread_t t2; // Data structure to hold information about thread 2
pthread_create(&t1, NULL, thread1, NULL);
pthread_create(&t2, NULL, thread2, NULL);
dispatch_main();
}
運行這個程序若干次，每次產生的結果是你所預期的嗎？
<p>
注釋掉
pthread_mutex_lock()和pthread_mutex_unlock()，然后再運行幾次，有什么不同？
在這個例子中，線程1和線程2同時運行。假如說線程1先走到pthread_mutex_lock()，線程1就獲得了一個互斥鎖，并且繼續執行。
如果在線程1還持有鎖的時候，線程2走到pthread_mutex_lock(),這時線程2會暫停執行(或者叫阻塞)，直到這個鎖被解開。
這就使得線程1可以被玩家1和玩家2原子級的修改，也就是說，不會被別的線程干擾。當線程1執行完畢，就會調用pthread_mutex_unlock()，線程2就可以接著執行并持有一個互斥鎖。
一個線程的解鎖和下一個線程的加鎖是串行的，也是原子級的。也就是說永遠不會出現一種2個線程都沒加鎖的中間狀態。互斥鎖會從一個線程直接傳遞到下一個線程。
用隊列，不用互斥鎖
讓我們用GCD重寫一下這個例子。黑喂狗：
#import <Foundation/Foundation.h>
#import <pthread/pthread.h>
// Each player gets 100 gems to start
int playerAGems = 100;
int playerBGems = 100;
dispatch_queue_t queue;
void *thread1(void *arg) {
// Move 20 gems from player A to player B
dispatch_sync(queue, ^{
playerAGems -= 20;
playerBGems += 20;
NSLog(@"Player A now has %d gems, and player B has %d gems.", playerAGems, playerBGems);
});
return NULL;
}
void *thread2(void *arg) {
// Move 50 gems from player B to player A
dispatch_sync(queue, ^{
playerAGems += 50;
playerBGems -= 50;
NSLog(@"Player A now has %d gems, and player B has %d gems.", playerAGems, playerBGems);
});
return NULL;
}
int main() {
queue = dispatch_queue_create("Synchronization queue", DISPATCH_QUEUE_SERIAL);
pthread_t t1, t2;
pthread_create(&t1, NULL, thread1, NULL);
pthread_create(&t2, NULL, thread2, NULL);
dispatch_main();
}
在這個例子中，我們繼續用
pthread_create()來創建新線程。在以后的文章中，我將告訴你們怎么使用全局并發隊列來達到一樣的效果。
注意到了2種寫法相似和不同的地方沒有？我們用串行隊列取代了互斥鎖，但是邏輯還是基本一樣。回憶一下，串行隊列是一種能夠串行執行我們加入到其中的block的數據結構。
我們不是調用pthread_mutex_lock()，而是使用dispatch_sync()來把線程鎖在隊列中。dispatch_sync()告訴GCD去入隊我們的block，并且等待block執行結束才會進行接下來的操作。
假如線程1先運行到dispatch_sync()，它的block(從玩家A拿走20個寶石，給玩家B 20個寶石)被入隊到我們的串行隊列中，線程1的運行就會被阻塞，直到這個block執行結束。又因為這時隊列里是空的，這個block是第一個入隊的，所以它將會被立即執行。
"入隊的block在哪一個線程上執行？"問這個問題沒有什么意義，因為GCD會計算出應該搶占哪個線程去運行你入隊的block。
然后當前一個block還在運行的時候，線程2走到了dispatch_sync(),它的block(給玩家A50個寶石，從玩家B拿走50個寶石)將會被入隊到串行隊列中，排在目前正在運行的block后面，等待它執行完畢才能執行。因為線程2需要等待它的block執行結束，所以這時線程2將處于暫停狀態。
第一個block最終運行完畢，然后從隊列的頭部出隊，使得線程1恢復執行。這時線程2中的block就是隊列的第一個元素，它將被執行，當它執行完畢時，線程2將恢復執行。
恭喜！你已經學會了怎么用串行隊列代替互斥鎖。在接下來的文章中，我們將學習一下并發隊列，它是一個強而有力的小伙伴。
