为什么我们不能在当前队列上使用 dispatch_sync？

Question

我遇到了一个场景，我有一个委托回调，它可能发生在主线程或另一个线程上，直到运行时我才知道是哪个（使用 StoreKit.framework）。

我还有需要在回调中更新的 UI 代码，这需要在函数执行之前发生，所以我最初的想法是有一个这样的函数：

-(void) someDelegateCallback:(id) sender
{
    dispatch_sync(dispatch_get_main_queue(), ^{
        // ui update code here
    });

    // code here that depends upon the UI getting updated
}

当它在后台线程上执行时，效果很好。但是，当在主线程上执行时，程序会陷入死锁。

仅这一点对我来说似乎很有趣，如果我正确阅读了 dispatch_sync 的文档，那么我希望它直接执行该块，而不用担心将其安排到运行循环中，如 here 所说：

作为一种优化，此函数在可能的情况下调用当前线程上的块。

但是，这没什么大不了的，它只是意味着更多的打字，这导致我采用这种方法：

-(void) someDelegateCallBack:(id) sender
{
    dispatch_block_t onMain = ^{
        // update UI code here
    };

    if (dispatch_get_current_queue() == dispatch_get_main_queue())
       onMain();
    else
       dispatch_sync(dispatch_get_main_queue(), onMain);
}

但是，这似乎有点倒退。这是 GCD 制作中的错误，还是我在文档中遗漏了什么？

Answer 1

dispatch_sync 做了两件事：

1. 排队一个块
2. 阻塞当前线程，直到该块完成运行

鉴于主线程是一个串行队列（这意味着它只使用一个线程），如果您在主队列上运行以下语句：

dispatch_sync(dispatch_get_main_queue(), ^(){/*...*/});

将发生以下事件：

1. dispatch_sync 将块放入主队列中。
2. dispatch_sync 阻塞主队列的线程，直到该块完成执行。
3. dispatch_sync 永远等待，因为该块应该运行的线程被阻塞了。

理解这个问题的关键是dispatch_sync 不执行块，它只是将它们排队。将在运行循环的未来迭代中执行。

以下做法：

if (queueA == dispatch_get_current_queue()){
    block();
} else {
    dispatch_sync(queueA, block);
}

非常好，但请注意，它不会保护您免受涉及队列层次结构的复杂场景的影响。在这种情况下，当前队列可能与您尝试发送块的先前阻塞队列不同。示例：

dispatch_sync(queueA, ^{
    dispatch_sync(queueB, ^{
        // dispatch_get_current_queue() is B, but A is blocked, 
        // so a dispatch_sync(A,b) will deadlock.
        dispatch_sync(queueA, ^{
            // some task
        });
    });
});

对于复杂的情况，在调度队列中读/写键值数据：

dispatch_queue_t workerQ = dispatch_queue_create("com.meh.sometask", NULL);
dispatch_queue_t funnelQ = dispatch_queue_create("com.meh.funnel", NULL);
dispatch_set_target_queue(workerQ,funnelQ);

static int kKey;
 
// saves string "funnel" in funnelQ
CFStringRef tag = CFSTR("funnel");
dispatch_queue_set_specific(funnelQ, 
                            &kKey,
                            (void*)tag,
                            (dispatch_function_t)CFRelease);

dispatch_sync(workerQ, ^{
    // is funnelQ in the hierarchy of workerQ?
    CFStringRef tag = dispatch_get_specific(&kKey);
    if (tag){
        dispatch_sync(funnelQ, ^{
            // some task
        });
    } else {
        // some task
    }
});

解释：

• 我创建了一个指向funnelQ 队列的workerQ 队列。在实际代码中，如果您有多个“工作”队列并且您想要一次恢复/暂停所有队列（通过恢复/更新它们的目标 funnelQ 队列来实现），这将非常有用。
• 我可能会在任何时间点汇集我的工作队列，所以要知道它们是否汇集，我用“漏斗”一词标记funnelQ。
• 在路上我dispatch_sync 到workerQ，无论出于何种原因，我想将dispatch_sync 到funnelQ，但避免将dispatch_sync 发送到当前队列，所以我检查标签并采取相应措施。因为 get 沿着层次结构向上走，所以不会在 workerQ 中找到该值，但会在 funnelQ 中找到它。这是一种找出层次结构中是否有任何队列是我们存储值的队列的方法。因此，为了防止 dispatch_sync 到当前队列。

如果您想知道读取/写入上下文数据的函数，有以下三个：

• dispatch_queue_set_specific：写入队列。
• dispatch_queue_get_specific：从队列中读取。
• dispatch_get_specific：从当前队列中读取的便捷函数。

键通过指针进行比较，并且从不取消引用。 setter 中的最后一个参数是释放键的析构函数。

如果您想知道“将一个队列指向另一个队列”，那就是这个意思。例如，我可以将队列 A 指向主队列，它会导致队列 A 中的所有块都在主队列中运行（通常是为了 UI 更新而这样做）。

Answer 2

我在the documentation (last chapter)找到这个：

不要从正在执行的任务中调用 dispatch_sync 函数 在您传递给函数调用的同一队列上。这样做会 使队列死锁。如果您需要分派到当前队列，请执行 所以异步使用 dispatch_async 函数。

另外，我点击了您提供的链接，并在 dispatch_sync 的描述中阅读了以下内容：

调用此函数并定位当前队列会导致死锁。

所以我认为这不是 GCD 的问题，我认为唯一明智的方法是您发现问题后发明的方法。

Answer 3

我知道你的困惑来自哪里：

作为优化，此函数调用当前块 尽可能线程。

小心，上面写着当前线程。

线程！=队列

队列不拥有线程，并且线程未绑定到队列。有线程，有队列。每当一个队列想要运行一个块时，它都需要一个线程，但这并不总是同一个线程。它只需要任何线程（可能每次都不同），当它完成运行块时（目前），同一个线程现在可以被不同的队列使用。

这句话讲的优化是关于线程，而不是队列。例如。假设您有两个串行队列，QueueA 和 QueueB，现在您执行以下操作：

dispatch_async(QueueA, ^{
    someFunctionA(...);
    dispatch_sync(QueueB, ^{
        someFunctionB(...);
    });
});

当QueueA 运行该块时，它将暂时拥有一个线程，任何线程。 someFunctionA(...) 将在该线程上执行。现在在进行同步调度时，QueueA 不能做任何其他事情，它必须等待调度完成。另一方面，QueueB 还需要一个线程来运行其块并执行someFunctionB(...)。所以要么QueueA 暂时挂起它的线程，而QueueB 使用其他线程来运行块，要么QueueA 将它的线程交给QueueB（毕竟在同步调度完成之前它无论如何都不需要它）而QueueB直接使用QueueA的当前线程。

不用说最后一个选项要快得多，因为不需要线程切换。而 this 就是这句话所说的优化。所以dispatch_sync() 到不同的队列可能并不总是导致线程切换（不同的队列，可能是同一个线程）。

但是dispatch_sync() 仍然不会发生在同一个队列上（同一个线程，是的，同一个队列，不是）。这是因为一个队列会在一个块之后执行一个块，当它当前执行一个块时，它不会执行另一个块，直到当前执行完成。所以它执行BlockA 和BlockA 在同一个队列上执行dispatch_sync() 或BlockB。只要队列还在运行BlockA，队列就不会运行BlockB，但在运行BlockB 之前，运行BlockA 不会继续。看到问题了吗？这是一个典型的僵局。

Answer 4

文档明确指出，传递当前队列会导致死锁。

现在他们没有说他们为什么要这样设计东西（除了它实际上需要额外的代码才能使它工作），但我怀疑这样做的原因是因为在这种特殊情况下，块将是“跳跃”队列，即在正常情况下，您的块在队列中的所有其他块都运行后结束运行，但在这种情况下它会在之前运行。

当您尝试使用 GCD 作为互斥机制时会出现此问题，这种特殊情况相当于使用递归互斥锁。我不想讨论使用 GCD 还是使用传统的互斥 API（例如 pthreads 互斥锁）更好，甚至使用递归互斥锁是否是个好主意。我会让其他人对此进行争论，但肯定有这个需求，尤其是当它是你正在处理的主队列时。

就个人而言，我认为如果 dispatch_sync 支持这一点或者如果有另一个函数提供了替代行为，它会更有用。我会敦促其他有此想法的人向 Apple 提交错误报告（正如我所做的那样，ID：12668073）。

你可以编写自己的函数来做同样的事情，但这有点小技巧：

// Like dispatch_sync but works on current queue
static inline void dispatch_synchronized (dispatch_queue_t queue,
                                          dispatch_block_t block)
{
  dispatch_queue_set_specific (queue, queue, (void *)1, NULL);
  if (dispatch_get_specific (queue))
    block ();
  else
    dispatch_sync (queue, block);
}

_{注意以前，我有一个使用 dispatch_get_current_queue() 的示例，但现在已被弃用。}

Answer 5

dispatch_async 和 dispatch_sync 都将它们的操作推送到所需的队列中。该动作不会立即发生；它发生在队列运行循环的某些未来迭代中。 dispatch_async 和 dispatch_sync 的区别在于 dispatch_sync 会阻塞当前队列，直到操作完成。

想想当你在当前队列上异步执行某事时会发生什么。同样，它不会立即发生。它将它放入一个 FIFO 队列中，并且它必须等到运行循环的当前迭代完成之后（并且可能还等待队列中的其他操作，然后再执行此新操作）。

现在您可能会问，在对当前队列异步执行操作时，为什么不总是直接调用函数，而不是等到未来某个时间。答案是两者之间有很大的不同。很多时候，您需要执行一个动作，但它需要在运行循环的当前迭代中由堆栈向上的函数执行任何副作用之后执行；或者你需要在运行循环中已经安排的一些动画动作之后执行你的动作，等等。这就是为什么很多时候你会看到代码[obj performSelector:selector withObject:foo afterDelay:0]（是的，它与[obj performSelector:selector withObject:foo]不同）。

正如我们之前所说，dispatch_sync 与dispatch_async 相同，只是它会阻塞直到操作完成。所以很明显为什么它会死锁 - 至少在运行循环的当前迭代完成之后，该块才能执行；但我们正在等待它完成后再继续。

理论上，当它是当前线程时，可以为dispatch_sync 创建一个特殊情况，立即执行它。 （performSelector:onThread:withObject:waitUntilDone: 存在这种特殊情况，当线程是当前线程并且waitUntilDone: 为 YES 时，它会立即执行它。）但是，我猜 Apple 决定最好在此处保持一致的行为，而不管队列如何。

Answer 6

从以下文档中找到。 https://developer.apple.com/library/ios/documentation/Performance/Reference/GCD_libdispatch_Ref/index.html#//apple_ref/c/func/dispatch_sync

与 dispatch_async 不同，“dispatch_sync”函数在块完成之前不会返回。调用此函数并以当前队列为目标会导致死锁。

与 dispatch_async 不同，不会对目标队列执行保留。因为对该函数的调用是同步的，所以它“借用”调用者的引用。此外，不会对块执行Block_copy。

作为一种优化，此函数在可能的情况下调用当前线程上的块。