I watched this years WWDC GCD talk lately and I think there is a code snippet something is wrong with. It is about making a property thread-safe using DispatchQueues.
class MyObject {
private var internalState: Int
private let internalQueue: DispatchQueue // Serial or Concurrent?
var state: Int {
get {
return internalQueue.sync { internalState }
}
set (newState) {
internalQueue.sync { internalState = newState }
}
}
}
They use a DispatchQueue to lock a property. But i think this snippet is not valid, because the internalQueue could be concurrent. So if we call the setter from two different DispatchQueues/Threads if that internal queue is not serial, it could also lead to threading problems right? Because in my understanding sync just holds the invoking thread and continues if the task is complete. What do you think about this snippet? Am I wrong?
I'd like just to show another approach that makes you able to read concurrently, but block everything while writing by using a dispatch barrier.
class MyObject {
private var internalState: Int
private let internalQueue = DispatchQueue(label: "reader-writer", attributes: .concurrent)
var state: Int {
get {
return internalQueue.sync { internalState }
}
set (newState) {
internalQueue.async(flags: .barrier) { internalState = newState }
}
}
}
With that approach, reads can occur concurrently on the queue, but writes are executed exclusively, due to the barrier.
This is just a Swift 3 conversion of an approach explained in the book Effective Objective C 2.0, written by Matt Galloway.
But i think this snippet is not valid, because the internalQueue could be concurrent
But it isn't concurrent. Dispatch queues that you create are serial by default. That is the point of the technique (and the example).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With