iOS多线程编程：线程同步总结 NSCondtion

1：原子操做 - OSAtomic系列函数

iOS平台下的原子操做函数都以OSAtomic开头，使用时须要包含头文件<libkern/OSBase.h>。不一样线程若是经过原子操做函数对同一变量进行操做，能够保证一个线程的操做不会影响到其余线程内对此变量的操做，由于这些操做都是原子式的。由于原子操做只能对内置类型进行操做，因此原子操做可以同步的线程只能位于同一个进程的地址空间内。

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 plaincopy

1. //线程A  

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

3.    

4. while(true)  

5. {  

6.     [condLock lock];  

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下的线程同步机制稍显单薄，但也正是这种简洁简化了其使用。