iOS 线程同步 资源抢夺

• 线程同步: 多线程开发保证公共访问的资源不被同时访问.设计到线程安全,一个好的设计是最好的保护. 在线程交互的的情况下根据你操作的资源类型选择合适的方式是必要的.

alt text

原子操作

• atomic,处理简单的数据类型.它不妨碍竞争线程.对于简单的数据操作比如递增一个计数器,原子操作比使用锁具有跟高的性能,如上图

POSIX 互斥锁:　pthread_mutex_t

锁创建

• 有两种方法创建互斥锁，静态方式和动态方式。

  • POSIX定义了一个宏PTHREAD_MUTEX_INITIALIZER来静态初始化互斥锁，方法如下：

     pthread_mutex_t mutex=PTHREAD_MUTEX_INITIALIZER;
    

    在LinuxThreads实现中，pthread_mutex_t是一个结构，而PTHREAD_MUTEX_INITIALIZER则是一个结构常量。

  • 动态方式是采用pthread_mutex_init()函数来初始化互斥锁，API定义如下：

     int pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mutexattr)
    

    其中mutexattr用于指定互斥锁属性（见下），如果为NULL则使用缺省属性。

    PTHREAD_MUTEX_TIMED_NP
    

    这是缺省值，也就是普通锁。当一个线程加锁以后，其余请求锁的线程将形成一个等待队列，并在解锁后按优先级获得锁。这种锁策略保证了资源分配的公平性。

    PTHREAD_MUTEX_RECURSIVE_NP
    

    嵌套锁，允许同一个线程对同一个锁成功获得多次，并通过多次unlock解锁。如果是不同线程请求，则在加锁线程解锁时重新竞争。

    PTHREAD_MUTEX_ERRORCHECK_NP
    

    检错锁，如果同一个线程请求同一个锁，则返回EDEADLK，否则与PTHREAD_MUTEX_TIMED_NP类型动作相同。这样就保证当不允许多次加锁时不会出现最简单情况下的死锁。

    PTHREAD_MUTEX_ADAPTIVE_NP
    

    适应锁，动作最简单的锁类型，仅等待解锁后重新竞争。

锁操作

• 锁操作主要包括加锁 pthread_mutex_lock()、解锁pthread_mutex_unlock()和测试加锁pthread_mutex_trylock()三个，不论哪种类型的锁，都不可能被两个不同的线程同时得到，而必须等待解锁。

• 对于普通锁和适应锁类型，解锁者可以是同进程内任何线程；而检错锁则必须由加锁者解锁才有效，否则返回EPERM；对于嵌套锁，文档和实现要求必须由加锁者解锁，但实验结果表明并没有这种限制，这个不同目前还没有得到解释

• 在同一进程中的线程，如果加锁后没有解锁，则任何其他线程都无法再获得锁

• int pthread_mutex_lock(pthread_mutex_t *mutex)
  
  int pthread_mutex_unlock(pthread_mutex_t *mutex)
  
  int pthread_mutex_trylock(pthread_mutex_t *mutex)
  

  pthread_mutex_trylock()语义与pthread_mutex_lock()类似，不同的是在锁已经被占据时返回EBUSY而不是挂起等待。

• pthread_mutex_destroy ()用于注销一个互斥锁，API定义如下：

  int pthread_mutex_destroy(pthread_mutex_t *mutex)
  

  销毁一个互斥锁即意味着释放它所占用的资源，且要求锁当前处于开放状态。由于在Linux中，互斥锁并不占用任何资源，因此LinuxThreads中的 pthread_mutex_destroy()除了检查锁状态以外（锁定状态则返回EBUSY）没有其他动作

  while (1) {
    pthread_mutex_lock(&mutex);
    // 先取出总数
    NSInteger count = self.ticketCount;
    if (count > 0) {
        self.ticketCount = count - 1;
        NSLog(@"%@卖了一张票，还剩下%zd张", [NSThread currentThread].name, self.ticketCount);
    } else {
        NSLog(@"票已经卖完了");
        pthread_mutex_destroy(&mutex);
        break;
    }
    pthread_mutex_unlock(&mutex);
    }
  

NSLock类

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

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

    while (1) {
    [myLock lock];
    // 先取出总数
    NSInteger count = self.ticketCount;
    if (count > 0) {
        self.ticketCount = count - 1;
        NSLog(@"%@卖了一张票，还剩下%zd张", [NSThread currentThread].name, self.ticketCount);
    } else {
        NSLog(@"票已经卖完了");
        break;
    }
    [myLock unlock];
    }
  

使用@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指令，你必须在你的代码中启用异常处理。了如果你不想让隐式的异常处理例程带来额外的开销，你应该考虑使用锁的类

  while (1) {
    @synchronized(object) {
        // 先取出总数
        NSInteger count = self.ticketCount;
        if (count > 0) {
            self.ticketCount = count - 1;
            NSLog(@"%@卖了一张票，还剩下%zd张", [NSThread currentThread].name, self.ticketCount);
        } else {
            NSLog(@"票已经卖完了");
            break;
        }
    }
  }
  

使用其他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);
  

• 在这种情况下，如果把代码进行一下改造

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

• 这段代码是一个典型的死锁情况。在我们的线程中，MyRecursiveFunction是递归调用的。所以每次进入这个方法时，都会去加一次锁，而从第二次开始，由于锁已经被使用了且没有解锁，所以它需要等待锁被解除，这样就导致了死锁，线程被阻塞住了。调试器中会输出如下信息：

  value = 5
  *** -[NSLock lock]: deadlock ( '(null)')   *** Break on _NSLockError() to debug.
  
  
  注意：因为一个递归锁不会被释放直到所有锁的调用平衡使用了解锁操作，所以你
  必须仔细权衡是否决定使用锁对性能的潜在影响。长时间持有一个锁将会导致其他
  线程阻塞直到递归完成。如果你可以重写你的代码来消除递归或消除使用一个递归
  锁，你可能会获得更好的性能。
  

NSCondition

while (1) {
    // 先取出总数

    NSInteger count = self.ticketCount;
    if (count > 0) {
        self.ticketCount = count - 1;
        NSLog(@"%@卖了一张票，还剩下%zd张", [NSThread currentThread].name, self.ticketCount);
        [conditionLock lock];
        [conditionLock signal];
        [conditionLock unlock];
    } else {
        NSLog(@"票已经卖完了");
        break;
    }
    [conditionLock lock];
    [conditionLock wait];
    [conditionLock unlock];
}

信号量 dispatch_semaphore

• 信号量机制主要是通过设置有限的资源数量来控制线程的最大并发数量以及阻塞线程实现线程同步等
• GCD中使用信号量需要用到三个函数：
  • dispatch_semaphore_create用来创建一个semaphore信号量并设置初始信号量的值；
  • dispatch_semaphore_signal发送一个信号让信号量增加1（对应PV操作的V操作）；
  • dispatch_semaphore_wait等待信号使信号量减1（对应PV操作的P操作）；

dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);
while (1) {
        dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
            // 先取出总数
            NSInteger count = self.ticketCount;
            if (count > 0) {
                self.ticketCount = count - 1;
                NSLog(@"%@卖了一张票，还剩下%zd张", [NSThread currentThread].name, self.ticketCount);
            } else {
                NSLog(@"票已经卖完了");
                break;
            }
        dispatch_semaphore_signal(semaphore);
    }