并发队列上的 .barrier 是否应该立即激活？

Question

我不确定这在 xcode8 beta 5 中是否有问题。看看这段代码。你认为它应该先打印 "A" 还是先打印 "B"？

let q = DispatchQueue(label: "q", attributes: .concurrent)
q.async(flags: .barrier) {
  Thread.sleep(forTimeInterval: 0.25)
  print("A")
}
q.sync {
  print("B")
}

由于 .barrier，我认为它应该阻塞并发队列并打印 "A"、"B"，但它在最新的 xcode 测试版中没有。

错误？对.barrier的误解？你怎么看？

请注意：我知道如果我使用串行队列，这将按预期顺序打印——这是一个更大系统的一小部分，我需要孤立地理解这种行为。

Answer 1

这是 beta 6 中修复的错误。

在 beta 5 中，它不仅没有按照您预期的方式运行，而且 .onQueueAsBarrier 前提条件也失败了。问题似乎隐藏在 async 和 .barrier 选项中，因为如果你通过等效的 Objective-C API、dispatch_barrier_async 执行它，它工作正常，例如：

let q = DispatchQueue(label: "q", attributes: .concurrent)

BarrierExperiment.dispatchBarrierAsync(q) {
    dispatchPrecondition(condition: .onQueueAsBarrier(q))
    Thread.sleep(forTimeInterval: 0.25)
    print("A")
}

q.async() {
    print("B")
}

在哪里

@interface BarrierExperiment : NSObject

+ (void)dispatchBarrierAsync:(dispatch_queue_t)queue block:(void (^)())block;

@end

@implementation BarrierExperiment

+ (void)dispatchBarrierAsync:(dispatch_queue_t)queue block:(void (^)())block {
    dispatch_barrier_async(queue, block);
}

@end

并发队列上的 .barrier 是否应该立即激活？

Should a `.barrier` on a concurrent queue become active immediately?

grand-central-dispatch

swift

swift3

xcode8