11.14一天一坑之——NSCondition加锁的时机

代码
原文

今天遇到的问题是使用NSCondition加条件锁的时候，没有了解清楚condition加锁的时机，造成了短暂的死锁。

下面的代码是一个标准的死锁案例：

    NSCondition *condition = [[NSCondition alloc] init];
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        [condition lock];
        NSLog(@"wait for products");
        [condition waitUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];
        if (_products > 0) {
            _products -= 1;
            NSLog(@"consume a product");
        }
        else {
            NSLog(@"�timeout");
        }
        [condition unlock];
    });

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        [condition lock];
        [NSThread sleepForTimeInterval:3];
        _products += 1;
        NSLog(@"produce a product");
        [condition signal];
        [condition unlock];
    });

这里在两个不同的线程进行产品的生产与消费，开始产品量为0，消费线程进入等待，等待时间为1s，1s后有可用产品则消费，否则超时；生产线程模拟耗时操作3s后产出第一个产品后，发送信号，解锁等待。

我们期待的结果应该是超时，因为等待1s后仍然没有产品可用，然而代码却不按套路出牌…

这里耗时操作的模拟是3s，如果真实的耗时操作时间很长，那么消费线程则会陷入无限等待中。

正确的代码只需要修改一行，在生产线程中将加锁[condition lock]与模拟耗时操作[NSThread sleepForTimeInterval:3]两行进行交换即可。原因在于condition的wait操作是一个先解锁后加锁的过程，在调用wait时会立即解锁，等待时间结束后再重新加锁，这样既保证了等待时可以由其他线程进行加锁，又保证了等待结束后的操作满足线程安全，而重新加锁的前提是此时没有其他线程对该condition加锁，但是我在生产线程中一开始就加了锁，那么消费线程在1s的等待时间结束后想要加锁时，生产线程仍然没有释放锁，因此造成了死锁。两行互换后，消费线程重新加锁时，生产线程的模拟耗时操作还没有结束，也未对condition进行加锁，这里的死锁打开了，也可以按照我们的需求进行了。

正确的代码如下：

    NSCondition *condition = [[NSCondition alloc] init];
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        [condition lock];
        NSLog(@"wait for products");
        [condition waitUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];
        if (_products > 0) {
            _products -= 1;
            NSLog(@"consume a product");
        }
        else {
            NSLog(@"�timeout");
        }
        [condition unlock];
    });

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        [NSThread sleepForTimeInterval:3];
        [condition lock];
        _products += 1;
        NSLog(@"produce a product");
        [condition signal];
        [condition unlock];
    });

结论
应该只针对竞争资源进行加锁，不应该包括其他逻辑代码。