關于GCD(Grand Centra Dispatch)和NSOperation的學習

Serial Dispatch Queue,這叫做串行隊列,要等待上一個執行完,再執行下一個;

Concurrent Dispatch Queue,叫做并行隊列,不需要上一個執行完,就能執行下一個;
這兩種,均遵循FIFO原則 (并行隊列中,執行順序遵循FIFO原則,但是結果不確定)FIFO原則:(先進先出,后進后出)

1.dispatch_get_mainqueue()? 獲取主線程(應用內只有一個,且用于刷新主頁面)

2.dispatch_get_global_queue()? 全局隊列,也是一個并行隊列, 四個優先級:1.最高:dispatch_queue_priority_high;2.默認:dispatch_queue_priority_default;3.低:dispatch_queue_priority_low;4.后臺:dispatch_queue_priority_backgroud

3.dispatch_set_target_queue(mySerialQueue, myGlobalQueue);//指定第一個參數與第二個參數優先級相同

4.dispatch_after? 該函數并不是延遲執行,而是延遲加入隊列

5.dispatch_group 就是線程組

6.dispatch_barrier_async(queue,***); 相當于柵欄,把前面并發的執行完,然后執行柵欄線程完了之后,才會觸發后面的并行隊列:主要作用:// 在訪問數據庫或文件時, 為了提高效率, 讀取操作放在并行隊列中執行. 但是寫入操作必須在串行隊列中執行(避免資源搶奪問題). 為了避免麻煩, 此時dispatch_barrier_async函數作用就出來了, 在這函數里進行寫入操作, 寫入操作會等到所有讀取操作完畢后, 形成一道柵欄, 然后進行寫入操作, 寫入完畢后再把柵欄移除, 同時開放讀取操作.

dispatch_barrier_sync和dispatch_barrier_async:

共同點:1、等待在它前面插入隊列的任務先執行完;2、等待他們自己的任務執行完再執行后面的任務。

不同點:1、dispatch_barrier_sync將自己的任務插入到隊列的時候,需要等待自己的任務結束之后才會繼續插入被寫在它后面的任務,然后執行它們;2、dispatch_barrier_async將自己的任務插入到隊列之后,不會等待自己的任務結束,它會繼續把后面的任務插入到隊列,然后等待自己的任務結束后才執行后面任務。處理多線程時讀寫操作造成線程不安全,使用 dispatch_barrier 時,有如下幾種隊列來加入 dispatch_barrier:1、dispatch_get_main_queue中加入 dispatch_barrier,明顯不合理,這些文件讀存操作不應該在主現場執行,并且不應該在穿行隊列執行,不然將毫無意義;2、自定義串行隊列:一個很壞的選擇;障礙不會有任何幫助,因為不管怎樣,一個串行隊列一次都只執行一個操作;3、全局并發隊列:要小心;這可能不是最好的主意,因為其它系統可能在使用隊列而且你不能壟斷它們只為你自己的目的;4、自定義并發隊列:這對于原子或臨界區代碼來說是極佳的選擇。任何你在設置或實例化的需要線程安全的事物都是使用障礙的最佳候選。(OK)

7.dispatch_apply? 表現得就像一個for循環,但它能并發地執行不同的迭代。這個函數是同步的,所以和普通的for循環一樣,它只會在所有工作都完成后才會返回。當在 Block 內計算任何給定數量的工作的最佳迭代數量時,必須要小心,因為過多的迭代和每個迭代只有少量的工作會導致大量開銷以致它能抵消任何因并發帶來的收益。而被稱為跨越式(striding)的技術可以在此幫到你,即通過在每個迭代里多做幾個不同的工作。用處:并發隊列:對于并發循環來說是很好選擇,特別是當你需要追蹤任務的進度時。(串行隊列的效果還不如普通的for循環)

8. dispatch_semaphore_t (信號量)

dispatch_semaphore是GCD基于計數器的一種多線程同步機制,解決因為多線程的特性而引發數據出錯的問題,與他相關的共有三個函數,分別是

dispatch_semaphore_create,dispatch_semaphore_signal,dispatch_semaphore_wait。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容