当所有正在运行的任务都在等待时，GCD死锁，不启动挂起的任务

Question

我有一个递归函数，可以在并发队列上调度新任务。我想限制同时调度的任务的数量，所以我使用了一个信号量，这样每个任务都会等待它，直到旧线程结束并发出信号。

然而，我发现当运行线程达到最大数量（64个）时，队列会陷入死锁，并且它们都开始等待信号量。然后GCD不会启动新任务，即使它有很多挂起的队列。

我做错了什么？这是我的代码：

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification 
{
    dispatch_semaphore_t sem = dispatch_semaphore_create(10);

    dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^
               {
                   [self recurWithSemaphore:sem];
               });
}

- (void)recurWithSemaphore:(dispatch_semaphore_t)sem
{
    // do some lengthy work here...

    // at this point we're done all but scheduling new tasks so let new tasks be created
    dispatch_semaphore_signal(sem);

    for (NSUInteger i = 0; i < 100; ++i)
    {
        // don't schedule new tasks until we have enough semaphore
        dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);

        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^
                   {
                       [self recurWithSemaphore:sem];
                   });
    }
}

Answer 1

使用信号量控制对有限资源的访问时的典型模式是

>

创建非零值信号量；

对于每项任务：

>

完成后，“信号”信号量（使其可用于另一项任务）。

所以，假设你想启动1000000个任务，在任何给定时间只有4个并发任务，你可以这样做：

dispatch_semaphore_t semaphore = dispatch_semaphore_create(4);

dispatch_queue_t queue = ... // some concurrent queue, either global or your own

dispatch_async(queue, ^{
    for (long index = 0; index < 1000000; index++) {
        dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
        dispatch_async(queue, ^{
            [self performSomeActionWithIndex:index completion:^{
                dispatch_semaphore_signal(semaphore);
            }];
        });
    }
});

显然，如果您要动态添加更多的任务来执行，您可以将其从for循环更改为而循环，检查一些同步的源，但想法是相同的。

然而，关键的观察结果是，我并没有让performSomeActionWithIndex本身递归地创建任务本身（因为这样你就进入了原始问题的死锁状态，任务停止了，因为它们无法启动新任务）。

现在，我不知道你的问题是否可以重构成这种模式，但是如果可以，这可能是一个选择。

顺便说一句，为了完整起见，我想指出控制并发度的典型解决方案是使用操作队列而不是调度队列，在这种情况下，可以指定maxConcurrentOperationCount。

正如你正确指出的，这会影响记忆。在我的测试中，每个计划的操作至少占用500字节（在现实世界的场景中可能会更多），因此，如果要计划的任务确实超过5000-10000个，那么操作队列可能很快就会变得不切实际。正如您所建议的，未来的读者应该参考《并发编程指南：并发和应用程序设计》中的性能含义部分。

我知道在你的情况下，这不是一个可行的方法，但我提到它只是为了未来读者的利益。我通常建议在需要控制并发程度时使用操作队列。如果你处理的任务太多，以至于不能合理地将它们安排在一个操作队列中，我只会跳到上面概述的方法。