dispatch_barrier_sync和dispatch_barrier_async

dispatch_barrier_sync和dispatch_barrier_async的共同點(diǎn):

1、都會等待在它前面插入隊列的任務(wù)(1、2、3)先執(zhí)行完

2、都會等待他們自己的任務(wù)(0)執(zhí)行完再執(zhí)行后面的任務(wù)(4、5、6)

dispatch_barrier_sync和dispatch_barrier_async的不共同點(diǎn):

在將任務(wù)插入到queue的時候,dispatch_barrier_sync需要等待自己的任務(wù)(0)結(jié)束之后才會繼續(xù)程序,然后插入被寫在它后面的任務(wù)(4、5、6),然后執(zhí)行后面的任務(wù)

而dispatch_barrier_async將自己的任務(wù)(0)插入到queue之后,不會等待自己的任務(wù)結(jié)束,它會繼續(xù)把后面的任務(wù)(4、5、6)插入到queue

所以,dispatch_barrier_async的不等待(異步)特性體現(xiàn)在將任務(wù)插入隊列的過程,它的等待特性體現(xiàn)在任務(wù)真正執(zhí)行的過程

原文鏈接「匪末」:https://blog.csdn.net/u013046795/article/details/47057585

思考?使用鎖與使用線程同步保證線程安全的區(qū)別?參考答案:跟圖片的加載緩存的使用場景,高頻次有關(guān)系,在這里使用sync,并不需要在去開辟新的線程,浪費(fèi)性能,只需要在原有線程,提交到synchronizationQueue隊列中,阻塞的執(zhí)行即可。這樣省去大量的開辟線程與使用鎖帶來的性能消耗

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容