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

iOS多线程编程：线程同步总结 NSCondtion
1：原子操作 - OSAtomic系列函数
iOS平台下的原子操作函数都以OSAtomic开头，使用时需要包含头文件。不同线程如果通过原子操作函数对同一变量进行操作，可以保证一个线程的操作不会影响到其他线程内对此变量的操作，因为这些操作都是原子式的。因为原子操作只能对内置类型进行操作，所以原子操作能够同步的线程只能位于同一个进程的地址空间内。
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.
3.
id?condLock?=?[[NSConditionLock?alloc]?initWithCondition:NO_DATA];??
4.
5.
???
6.
7.
while(true)??
8.
9.
{??
10.
11.
????[condLock?lock];??
12.
13.
????/*?Add?data?to?the?queue.?*/??
14.
15.
????[condLock?unlockWithCondition:HAS_DATA];??
16.
17.
}??
18.
[plain]?view plaincopy
1.
//线程B??
2.
3.
while?(true)??
4.
5.
{??
6.
7.
????[condLock?lockWhenCondition:HAS_DATA];??
8.
9.
????/*?Remove?data?from?the?queue.?*/??
10.
11.
????[condLock?unlockWithCondition:(isEmpty???NO_DATA?:?HAS_DATA)];??
12.
13.
???
14.
15.
????//?Process?the?data?locally.??
16.
17.
}??
18.

除了显示的生成NSLock系列对象，还可以通过将代码放到@synchronized内来达到同步的目的，一段放入其内的代码，不同的线程是不能重入的例如：
[plain]?view plaincopy
1.
-?(void)myMethod:(id)anObj??
2.
3.
{??
4.
5.
????@synchronized(anObj)??
6.
7.
????{??
8.
9.
????????//此处代码在同一时刻只能有一个线程执行.??
10.
11.
????}??
12.
13.
}??
14.

NSLock系列对象都是可以具名的，也就是说，这些对象可以用于不同进程内部的线程的同步。
3：事件 - NSCondtion
NSConditon类型提供了wait与**函数，分别代表了等待事件的操作以及触发事件的操作。除了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.
3.
[cocoaCondition?lock];??
4.
5.
while?(timeToDoWork?<=?0)??
6.
7.
????[cocoaCondition?wait];??
8.
9.
???
10.
11.
timeToDoWork--;??
12.
13.
???
14.
15.
//?Do?real?work?here.??
16.
17.
???
18.
19.
[cocoaCondition?unlock];??
20.
21.
??
22.
23.
//出发事件的线程??
24.
25.
[cocoaCondition?lock];??
26.
27.
timeToDoWork++;??
28.
29.
[cocoaCondition?**];??
30.
31.
[cocoaCondition?unlock];??
32.

这个timeToDoWork就是那个额外需要的变量，在NSCondition的使用中，这个变量是必不可少的。
NSConditon对象也是具名的，也就是说，其可于不同进程内部的线程同步。


相较于Windows平台下提供的丰富的线程同步机制，iOS下的线程同步机制稍显单薄，但也正是这种简洁简化了其使用。
学习链接/ios/?tg=5009295340
学习交流群：317140762