Should ".barrier" in the parallel queue be activated immediately?

Question

I'm not sure if this broke in xcode8 beta 5. Look at this code. Do you think he should first type “A,” or “B”?

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

Due to .barrier I think it should block the parallel queue and print "A", "B", but it is not in the latest beta version of xcode.

Bug? Misunderstanding .barrier? What do you think?

note: I know that this will print in the expected order, if I use the next queue - this is a tiny part of a much larger system, and I need to understand this behavior in isolation.

Answer 1

This was a bug fixed in beta 6.

In beta 5, it not only behaves as you expected, but also with the condition .onQueueAsBarrier . The problem would be similar to async with the .barrier option, because if you execute it using the equivalent Objective-C API, dispatch_barrier_async , it works fine, for example:

 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") } 

Where

 @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