iOS多線程編程:線程同步總結 NSCondtion

1:原子操做 - OSAtomic系列函數

iOS平臺下的原子操做函數都以OSAtomic開頭,使用時須要包含頭文件<libkern/OSBase.h>。不一樣線程若是經過原子操做函數對同一變量進行操做,能夠保證一個線程的操做不會影響到其餘線程內對此變量的操做,由於這些操做都是原子式的。由於原子操做只能對內置類型進行操做,因此原子操做可以同步的線程只能位於同一個進程的地址空間內。app

2:鎖 - NSLock系列對象

iOS平臺下的鎖對象爲NSLock對象,進入鎖經過調用lock函數,解鎖調用unlock函數(由於iOS中大部分的線程同步類都繼承自NSLocking協議,因此其加鎖/解鎖的操做基本都爲lock/unlock函數),同一個NSLock對象成功調用lock函數後,在其顯式unlock以前任何線程都不能再對此NSLock對象加鎖,以達到互斥訪問的目的。除了lock函數,對NSLock加鎖的函數還包括tryLock以及lockBeforeDate函數,lock函數在成功加鎖之間會一直阻塞,而tryLock會嘗試加鎖,若是不成功,不會阻塞,而是直接返回NO,lockBeforeDate則是阻塞到傳入的NSDate日期爲止。函數

除了NSLock,iOS還提供了NSRecursive、NSConditionLock類型的鎖類型。NSRecursive與NSLock最大的區別就是NSRecursive是可重入的,也就是說一個線程能夠對一個NSRecursive對象屢次調用lock,只要解鎖時調用相同次數的unlock函數即可。NSConditionLock是一種帶有條件的鎖對象,除了基本的lock與unlock函數,還提供了lockWithCondition以及unlockWithCondition,這兩個函數接收整型類型的數據做爲參數,只有當一個unlockWithCondition對象被調用時,對應的lockWithCondition纔會正常返回。這種機制在需幾多個線程順序化的完成某個任務時比較有用,例程以下:測試

[plain] view plaincopyspa

  1. //線程A  操作系統

  2. id condLock = [[NSConditionLock alloc] initWithCondition:NO_DATA];  .net

  3.    

  4. while(true)  線程

  5. {  對象

  6.     [condLock lock];  blog

  7.     /* Add data to the queue. */  繼承

  8.     [condLock unlockWithCondition:HAS_DATA];  

  9. }  

[plain] view plaincopy

  1. //線程B  

  2. while (true)  

  3. {  

  4.     [condLock lockWhenCondition:HAS_DATA];  

  5.     /* Remove data from the queue. */  

  6.     [condLock unlockWithCondition:(isEmpty ? NO_DATA : HAS_DATA)];  

  7.    

  8.     // Process the data locally.  

  9. }  


除了顯示的生成NSLock系列對象,還能夠經過將代碼放到@synchronized內來達到同步的目的,一段放入其內的代碼,不一樣的線程是不能重入的例如:

[plain] view plaincopy

  1. - (void)myMethod:(id)anObj  

  2. {  

  3.     @synchronized(anObj)  

  4.     {  

  5.         //此處代碼在同一時刻只能有一個線程執行.  

  6.     }  

  7. }  


NSLock系列對象都是能夠具名的,也就是說,這些對象能夠用於不一樣進程內部的線程的同步。

3:事件 - NSCondtion

NSConditon類型提供了wait與signal函數,分別表明了等待事件的操做以及觸發事件的操做。除了wait函數,NSCondition還提供了waitUntilDate函數,其功能與NSLock中的lockBeforeDate大體相同,簡要來講就是提供了一個帶超時的wait函數。

雖然NSCondition與Windows環境下Event類型所完成的功能大體相似,但對一個熟悉Event類型的開發人員來講,NSConditon的行爲會有點奇怪:

第一點:由於遵循NSLocking協議,因此NSCondition在觸發與等待過程的先後要分別調用lock與unlock函數,前面提到過,當一個遵循NSLocking協議的對象調用lock後,其餘的對此對象的lock調用都會阻塞。那麼,若是兩個線程A和B,A要觸發事件,B接收事件,B線程在調用lock後,經過調用wait函數進入等待事件觸發的狀態,那麼,A線程豈不是再也沒有機會對這個事件進行觸發了(由於此對象已經被B線程lock)?祕密就在於wait函數的調用,其實,在wait函數內部悄悄的調用了unlock函數,也就是說在調用wati函數後,這個NSCondition對象就處於了無鎖的狀態,這樣A線程就能夠對此對象加鎖並觸發該NSCondition對象。當一個事件被其餘線程觸發時,在wait函數內部獲得此事件被觸發的通知,而後對此事件從新調用lock函數,而後函數返回,而在函數外部,看起來好像接收事件的線程歷來沒有放開NSCondition對象的全部權,B線程直接由阻塞狀態進入了觸發狀態。

第二點:當有多個線程進入阻塞狀態,等待同一個AutoReset的Event對象被觸發時,在Windows環境下喚醒哪個線程是沒有固定的順序的,也就是說操做系統對喚醒哪個線程不會提供任何的保證。而在iOS平臺上,通過筆者測試,其被觸發的順序與,而且只與調用wait函數的順序相關,與其餘(好比線程優先級)條件沒有關係。這一點在開發時須要進行額外的考慮。

第三點:wait函數並非徹底可信的。這一點比較讓人蛋疼,也就是說wait返回後,並不表明對應的事件必定被觸發了,所以,爲了保證線程之間的同步關係,使用NSCondtion時每每須要加入一個額外的變量來對非正常的wait返回進行規避。具體示例代碼以下:

[plain] view plaincopy

  1. //等待事件觸發的線程  

  2. [cocoaCondition lock];  

  3. while (timeToDoWork <= 0)  

  4.     [cocoaCondition wait];  

  5.    

  6. timeToDoWork--;  

  7.    

  8. // Do real work here.  

  9.    

  10. [cocoaCondition unlock];  

  11.   

  12. //出發事件的線程  

  13. [cocoaCondition lock];  

  14. timeToDoWork++;  

  15. [cocoaCondition signal];  

  16. [cocoaCondition unlock];  



個timeToDoWork就是那個額外須要的變量,在NSCondition的使用中,這個變量是必不可少的。

NSConditon對象也是具名的,也就是說,其可於不一樣進程內部的線程同步。



相較於Windows平臺下提供的豐富的線程同步機制,iOS下的線程同步機制稍顯單薄,但也正是這種簡潔簡化了其使用。

相關文章
相關標籤/搜索