@synchronized vs GCD dispatch_barrier_async

Question

我已經開始控制隊列的第一次，感覺像我有一個很好的處理如何使用它們和榮譽給蘋果，使他們非常直接地使用。

但是，我遇到的是多線程讀取和寫入相同對象的挑戰。在this question我得到了this fine answer，這讓我要求大家確認一下，以確保我瞭解@synchronized vs GCD dispatch_barrier_async的優缺點。

這是我看到它的方式：

@synchronized 

PRO：您可以@synchronized包裝任何對象，只要你有訪問/指針指向它，因此很容易共享數據模型是通過iOS 4的支持（可能更早）

`dispatch_barrier_async` with custom DISPATCH_QUEUE_CONCURRENT 

：從不同對象的程序

PRO安全處理

PRO：比@synchronized

CON更快：DISPATCH_QUEUE_CONCURRENT僅可用在IOS 5（如所討論的here），因此沒有可用的支撐的iOS 4

CON：不容易當控制對來自許多其他對象的對象的讀/寫時使用，因爲隊列最容易僅用於創建它們的對象（沒有一些工作去繞過這個限制）

綜上所述，最好的工具取決於程序的需求，以上考慮。

如果有人有什麼要補充或指出，我會很感激。

Answer 1

好了，幾件事情要指出：

1）當您使用@synchronized，它在拉的iOS（或OSX）爲一個應用程序的整個異常框架。我知道OSX上的這一點，它對性能有很大的影響，在iOS上無法確定，但預計會一樣。也就是說，這是用大錘驅動釘子 - 這種能力在其他選擇可用之前就已經完成了。我個人避免像瘟疫一樣使用它，並且移植了其他開源框架來使用調度信號（我再次感謝Mike Ash）！

2）您對「DISPATCH_QUEUE_CONCURRENT」的評論是一種紅鯡魚 - 從iOS 4開始，系統給了你3個併發隊列，所以如果你需要定義自己的隊列，你確實在推動信封。通過分派，您可以等待，異步和同步，串行和併發等組，然後分派。這裏有如此豐富的內容，你甚至可以想到1）。你使用的越多，你就會越多地使用它們！

編輯：我用我的iOS 4.3應用程序中的自定義併發隊列，以及所有的邁克灰灰障礙技術。隊列。.h文件顯示爲可用：

__OSX_AVAILABLE_STARTING(__MAC_10_6,__IPHONE_4_0) 
DISPATCH_EXPORT DISPATCH_CONST DISPATCH_WARN_RESULT DISPATCH_NOTHROW 
dispatch_queue_t 
dispatch_get_global_queue(dispatch_queue_priority_t priority, unsigned long flags); 

/*! 
* @const DISPATCH_QUEUE_SERIAL 
* @discussion A dispatch queue that invokes blocks serially in FIFO order. 
*/ 
#define DISPATCH_QUEUE_SERIAL NULL 

/*! 
* @const DISPATCH_QUEUE_CONCURRENT 
* @discussion A dispatch queue that may invoke blocks concurrently and supports 
* barrier blocks submitted with the dispatch barrier API. 
*/ 
#define DISPATCH_QUEUE_CONCURRENT (&_dispatch_queue_attr_concurrent)