是否在同步GCD隊列上放置一個阻止阻塞並暫停其他阻塞的阻塞？

Question

我讀過應該使用GCD同步隊列（dispatch_sync）來實現代碼的關鍵部分。一個例子是從賬戶餘額中減去交易金額的塊。同步調用的有趣部分是一個問題，它是如何影響多線程上其他塊的工作的？

讓我們想象一下，有3個線程在異步模式下使用並執行主隊列和自定義隊列中的系統和用戶定義塊。這些塊都按照某種順序並行執行。現在，如果一個塊放在一個具有同步模式的自定義隊列中，是否意味着所有其他塊（包括其他線程）都被掛起，直到成功執行塊爲止？或者這意味着只有一些鎖將被放在該塊上，而其他鎖仍然會執行。但是，如果其他塊使用與同步塊相同的數據，那麼其他塊將不可避免地等待，直到該鎖將被釋放。

恕我直言，這並不重要，它是一個或多個核心，同步模式應凍結整個應用程序的工作。但是，這些只是我的想法，所以請評論和分享你的見解:)

Answer 1

同步調度會暫停執行代碼，直到調度塊完成。立即派遣異步回報，該塊相對於調用代碼異步執行：

dispatch_sync(somewhere, ^{ something }); 
// Reached later, when the block is finished. 

dispatch_async(somewhere, ^{ something }); 
// Reached immediately. The block might be waiting 
// to be executed, executing or already finished. 

而且有兩種調度隊列，串行和並行的。序列號按照它們被添加的順序嚴格地逐個分派塊。當一個完成時，另一個開始。這種執行只需要一個線程。併發隊列同時並行地分派塊。那裏有更多的線程在使用。

如果您認爲合適，您可以混合使用sync/async dispatch和串行/併發隊列。如果您想要使用GCD來保護對關鍵部分的訪問，請使用單個串行隊列並分配此隊列上共享數據的所有操作（同步或異步，無關緊要）。這樣，總會有僅一個街區與共享數據進行操作：

- (void) addFoo: (id) foo { 
    dispatch_sync(guardingQueue, ^{ [sharedFooArray addObject:foo]; }); 
} 

- (void) removeFoo: (id) foo { 
    dispatch_sync(guardingQueue, ^{ [sharedFooArray removeObject:foo]; }); 
} 

現在，如果guardingQueue是一個串行隊列，添加/刪除操作不能發生衝突，即使addFoo:和removeFoo:方法都是從不同的同時調用線程。

Answer 2

不，它不。

同步的部分是塊放在隊列中，但控制不返回調用函數，直到塊返回。

GCD的許多用途是異步的;你把一個塊放在一個隊列中，而不是等待塊完成它的工作控制傳回給調用函數。

這對其他隊列沒有影響。

Answer 3

如果您需要序列化某個資源的訪問權限，那麼您至少可以訪問兩個機制。如果你有一個帳戶對象（即對於給定的帳號獨特 ），那麼你可以這樣做：

@synchronize(accountObject) { ... } 

如果你沒有一個對象，但使用C結構，其中有隻有一個 對於給定的帳號這樣的結構，那麼你可以做到以下幾點：

// Should be added to the account structure. 
// 1 => at most 1 object can access accountLock at a time. 
dispatch_semaphore_t accountLock = dispatch_semaphore_create(1); 

// In your block you do the following: 
block = ^(void) { 
    dispatch_semaphore_wait(accountLock,DISPATCH_TIME_FOREVER); 
    // Do something 
    dispatch_semaphore_signal(accountLock); 
}; 

// -- Edited: semaphore was leaking. 
// At the appropriate time release the lock 
// If the semaphore was created in the init then 
// the semaphore should be released in the release method. 
dispatch_release(accountLock); 

有了這個，不管你的隊列併發的水平，可以保證只有一個線程將隨時訪問帳戶給定的時間。

還有更多類型的同步對象，但這兩個很容易使用，並且相當靈活。