ios - 为什么我们需要在另一个队列上使用 dispatch_sync() 而不是在 iOS GCD 中使用当前队列/线程

Question

我读到 dispatch_sync() 会阻塞当前线程并且不会返回它，直到一个人想要同步执行的任务在 dispatch_sync 的串行队列上完成() 需要继续努力。

所以基本上它会停止当前线程并执行它的任务。

如果是这样，为什么还要为这种任务设置另一个队列，为什么我们不能将任务放在当前线程上。

毕竟，执行任务无论如何都会阻塞当前线程。

既然 dispatch_sync() 不会打开另一个线程，那么为什么我们还要打开另一个队列来执行任务而不是在当前队列/线程上执行呢？

希望我在这里清楚地描述我的困惑。

我在这里比较在另一个队列上使用dispatch_sync()和直接使用当前线程/队列，所以我想知道在什么用例中，在另一个队列上使用 dispatch_sync() 会比仅使用当前队列更好。

这应该与线程安全和同步问题有关。

Answer 1

您想要这样做的原因可能有很多，但一个常见的用例是保护代码的关键部分。假设您有多个线程想要更​​新一个数组。数组不是线程安全的，因此这可能导致数组损坏。

通过对串行队列使用 dispatch_sync 并更新分派(dispatch) block 内的数组，您可以确保一次只有一个线程更新数组。您需要同步分派(dispatch)，因为您希望请求线程在继续之前等待数组更新。

例如，这里有一个简单的队列类，它使用串行调度队列来确保底层数组更新时的线程安全:

class Queue<T> {

    private var theQueue = [T]()

    private var dispatchQ = dispatch_queue_create("queueQueue", DISPATCH_QUEUE_SERIAL);

    func enqueue(object:T) {
        dispatch_sync(self.dispatchQ) {
            self.theQueue.append(object)
        }
    }

    func dequeue() -> T? {
        return self.dequeue(true)
    }

    func peek() -> T? {
        return self.dequeue(false)
    }

    private func dequeue(remove: Bool) -> T? {
        var returnObject: T?
        dispatch_sync(self.dispatchQ) {
            if !self.theQueue.isEmpty {
                returnObject = self.theQueue.first
                if (remove) {
                    self.theQueue.removeFirst()
                }
            }
        }

        return returnObject
    }

    func isEmpty() -> Bool {
        return self.theQueue.isEmpty
    }
}