iOS培训之多线程编程：线程同步总结

北京尚学堂提供

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才会正常返回。这种机制在需几多个线程顺序化的完成某个任务时比较有用，例程如下：

除了显示的生成NSLock系列对象，还可以通过将代码放到@synchronized内来达到同步的目的，一段放入其内的代码，不同的线程是不能重入的例如：

[plain]view plaincopy

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返回进行规避。具体示例代码如下：

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

相较于Windows平台下提供的丰富的线程同步机制，iOS下的线程同步机制稍显单薄，但也正是这种简洁简化了其使用。

Another article:

锁是线程编程同步工具的基础。锁可以让你很容易保护代码中一大块区域以便你可以确保代码的正确性。

1 使用POSIX互斥锁

POSIX互斥锁在很多程序里面很容易使用。为了新建一个互斥锁，你声明并初始化一个pthread_mutex_t的结构。为了锁住和解锁一个互斥锁，你可以使用pthread_mutex_lock和pthread_mutex_unlock函数。列表4-2显式了要初始化并使用一个POSIX线程的互斥锁的基础代码。当你用完一个锁之后，只要简单的调用pthread_mutex_destroy来释放该锁的数据结构。 Listing 4-2

Using a mutex lock pthread_mutex_t mutex;

void MyInitFunction()

{

pthread_mutex_init(&mutex, NULL);

}

void MyLockingFunction()

{

pthread_mutex_lock(&mutex);

// Do work. pthread_mutex_unlock(&mutex);

}

注意：上面的代码只是简单的显式了使用一个POSIX线程互斥锁的步骤。你自己的代码应该检查这些函数返回的错误码，并适当的处理它们。

4.6.2 使用NSLock类

在Cocoa程序中NSLock中实现了一个简单的互斥锁。所有锁（包括NSLock）的接口实际上都是通过NSLocking协议定义的，它定义了lock和unlock方法。你使用这些方法来获取和释放该锁。

除了标准的锁行为，NSLock类还增加了tryLock和lockBeforeDate:方法。方法tryLock试图获取一个锁，但是如果锁不可用的时候，它不会阻塞线程。相反，它只是返回NO。而lockBeforeDate:方法试图获取一个锁，但是如果锁没有在规定的时间内被获得，它会让线程从阻塞状态变为非阻塞状态（或者返回NO）。

下面的例子显式了你可以是NSLock对象来协助更新一个可视化显式，它的数据结构被多个线程计算。如果线程没有立即获的锁，它只是简单的继续计算直到它可以获得锁再更新显式。

BOOL moreToDo = YES;

NSLock *theLock = [[NSLock alloc] init];

while (moreToDo) {

if ([theLock tryLock]) {

[theLock unlock];

}

}

4.6.3 使用@synchronized指令

@synchronized指令是在Objective-C代码中创建一个互斥锁非常方便的方法。@synchronized指令做和其他互斥锁一样的工作（它防止不同的线程在同一时间获取同一个锁）。然而在这种情况下，你不需要直接创建一个互斥锁或锁对象。相反，你只需要简单的使用Objective-C对象作为锁的令牌，如下面例子所示：

- (void)myMethod:(id)anObj

{

@synchronized(anObj)

{

// Everything between the braces is protected by the @synchronized directive.

}

}

创建给@synchronized指令的对象是一个用来区别保护块的唯一标示符。如果你在两个不同的线程里面执行上述方法，每次在一个线程传递了一个不同的对象给anObj参数，那么每次都将会拥有它的锁，并持续处理，中间不被其他线程阻塞。然而，如果你传递的是同一个对象，那么多个线程中的一个线程会首先获得该锁，而其

他线程将会被阻塞直到第一个线程完成它的临界区。

作为一种预防措施，@synchronized块隐式的添加一个异常处理例程来保护代码。该处理例程会在异常抛出的时候自动的释放互斥锁。这意味着为了使用@synchronized指令，你必须在你的代码中启用异常处理。了如果你不想让隐式的异常处理例程带来额外的开销，你应该考虑使用锁的类。

4.6.4 使用其他Cocoa锁

以下个部分描述了使用Cocoa其他类型的锁。

·使用NSRecursiveLock对象

NSRecursiveLock类定义的锁可以在同一线程多次获得，而不会造成死锁。一个递归锁会跟踪它被多少次成功获得了。每次成功的获得该锁都必须平衡调用锁住和解锁的操作。只有所有的锁住和解锁操作都平衡的时候，锁才真正被释放给其他线程获得。

正如它名字所言，这种类型的锁通常被用在一个递归函数里面来防止递归造成阻塞线程。你可以类似的在非递归的情况下使用他来调用函数，这些函数的语义要求它们使用锁。以下是一个简单递归函数，它在递归中获取锁。如果你不在该代码里使用NSRecursiveLock对象，当函数被再次调用的时候线程将会出现死锁。 NSRecursiveLock *theLock = [[NSRecursiveLock alloc] init];

void MyRecursiveFunction(int value) {

[theLock lock];

if (value != 0) {

--value;

MyRecursiveFunction(value);

}

[theLock unlock];

}

MyRecursiveFunction(5);

注意：因为一个递归锁不会被释放直到所有锁的调用平衡使用了解锁操作，所以你必须仔细权衡是否决定使用锁对性能的潜在影响。长时间持有一个锁将会导致其他线程阻塞直到递归完成。如果你可以重写你的代码来消除递归或消除使用一个递归锁，你可能会获得更好的性能。

·使用NSConditionLock对象

NSConditionLock对象定义了一个互斥锁，可以使用特定值来锁住和解锁。不要把该类型的锁和条件（参见“条件”部分）混淆了。它的行为和条件有点类似，但是它们的实现非常不同。

通常，当多线程需要以特定的顺序来执行任务的时候，你可以使用一个NSConditionLock对象，比如当一个线程生产数据，而另外一个线程消费数据。生产者执行时，消费者使用由你程序指定的条件来获取锁（条件本身是一个你定义的整形值）。当生产者完成时，它会解锁该锁并设置锁的条件为合适的整形值来唤醒消费者线程，之后消费线程继续处理数据。

NSConditionLock的锁住和解锁方法可以任意组合使用。比如，你可以使用unlockWithCondition:和lock消息，或使用lockWhenCondition:和unlock消息。当然，后面的组合可以解锁一个锁但是可能没有释放任何等待某特定条件值的线程。

下面的例子显示了生产者-消费者问题如何使用条件锁来处理。想象一个应用程序包含一个数据的队列。一个生产者线程把数据添加到队列，而消费者线程从队列中取出数据。生产者不需要等待特定的条件，但是它必须等待锁可用以便它可以安全的把数据添加到队列。

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

while(true) {

[condLock lock];

[condLock unlockWithCondition:HAS_DATA];

}

因为初始化条件锁的值为NO_DATA，生产者线程在初始化的时候可以毫无问题的获取该锁。它会添加队列数据，并把条件设置为HAS_DATA。在随后的迭代中，生产者线程可以把到达的数据添加到队列，无论队列是否为空或依然有数据。唯一让它进入阻塞的情况是当一个消费者线程充队列取出数据的时候。

因为消费者线程必须要有数据来处理，它会使用一个特定的条件来等待队列。当生产者把数据放入队列时，消费者线程被唤醒并获取它的锁。它可以从队列中取出数据，并更新队列的状态。下列代码显示了消费者线程处理循环的基本结构。

while (true) {

[condLock lockWhenCondition:HAS_DATA];

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

// Process the data locally.

}

·使用NSDistributedLock对象

NSDistributedLock类可以被多台主机上的多个应用程序使用来限制对某些共享资源的访问，比如一个文件。锁本身是一个高效的互斥锁，它使用文件系统项目来实现，比如一个文件或目录。对于一个可用的NSDistributedLock对象，锁必须由所有使用它的程序写入。这通常意味着把它放在文件系统，该文件系统可以被所有运行在计算机上面的应用程序访问。

不像其他类型的锁，NSDistributedLock并没有实现NSLocking协议，所有它没有lock方法。一个lock方法将会阻塞线程的执行，并要求系统以预定的速度轮询锁。以其在你的代码中实现这种约束，NSDistributedLock提供了一个tryLock方法，并让你决定是否轮询。

因为它使用文件系统来实现，一个NSDistributedLock对象不会被释放除非它的拥有者显式的释放它。如果你的程序在用户一个分布锁的时候崩溃了，其他客户端无法访问该受保护的资源。在这种情况下，你可以使用breadLock方法来打破现存的锁以便你可以获取它。但是通常应该避免打破锁，除非你确定拥有进程已经死亡并不可能再释放该锁。

和其他类型的锁一样，当你使用NSDistributedLock对象时，你可以通过调用unlock方法来释放它。

出版：北京尚学堂

网址：https://www.360docs.net/doc/984956208.html,

QQ群：516745661