Question on objc_sync_enter/exit replacement in Swift

Question

My Swift code uses objc_sync_enter & objc_sync_exit methods to implement @synchronized primitive (available in Objective-C) in Swift. However, this answer claims it is an outdated as well as inappropriate way to implement synchronised access in Swift. While the reasons for the same are not provided, I would like to know modern ways of implementing critical sections in Swift where a number of variables are accessed in a block, but the same variables are written infrequently (such as when UI orientation or app settings change).

Answer 1

You asked:

I would like to know modern ways of implementing critical sections in Swift where a number of variables are accessed in a block

The modern way is to use actors. See The Swift Programming Guide: Concurrency: Actors:

actor TemperatureLogger {
    let label: String
    var measurements: [Int]
    private(set) var max: Int

    init(label: String, measurement: Int) {
        self.label = label
        self.measurements = [measurement]
        self.max = measurement
    }

    ...

    func update(with measurement: Int) {
        measurements.append(measurement)
        if measurement > max {
            max = measurement
        }
    }
}

Also see WWDC 2022 video Eliminate data races using Swift Concurrency or 2021’s Protect mutable state with Swift actors.

---

In codebases where you have not yet adopted Swift concurrency (e.g., async-await) you could use a GCD serial queue:

class TemperatureLogger {
    let label: String

    private var _measurements: [Int]                           // private backing variable
    var measurements: [Int] { synchronized { _measurements } } // synchronized computed var to return value

    private var _max: Int                                      // private backing variable
    var max: Int { synchronized { _max } }                     // synchronized computed var to return value

    init(label: String, measurement: Int) {
        self.label = label
        self._measurements = [measurement]
        self._max = measurement
    }

    func update(with measurement: Int) {
        synchronized {
            _measurements.append(measurement)
            if measurement > _max {
                _max = measurement
            }
        }
    }

    private let queue = DispatchQueue(label: "TemperatureLogger")

    private func synchronized<T>(block: () throws -> T) rethrows -> T {
        try queue.sync {
            try block()
        }
    }
}

Serial queues are a simple, yet robust, synchronization mechanism. Just make sure you perform all interactions (both reads and writes) through this queue. Specifically, do not expose the private backing variable, but rather only provide mechanisms (such as computed variable, update methods, etc.) that ensure the state is properly synchronized.

Now, no discussion of GCD synchronization mechanisms can pass without a nod to the “reader-writer” pattern (in which one uses concurrent GCD queue, performing writes asynchronously with a barrier and performing reads synchronously without a barrier). While this is intuitively appealing, it actually offers only a modest performance improvement but introduces all sorts of complicating factors, especially in thread-explosion scenarios. Rather than the reader-writer pattern, if performance were really critical, one might use a lock, which ends up being even more performant:

private let lock = NSLock()

private func synchronized<T>(block: () throws -> T) rethrows -> T {
    lock.lock()
    defer { lock.unlock() }
    return try block()
}

But in the vast majority of cases, this would be premature optimization. Only fall back to low-level mechanisms, such as locks, where performance is paramount. And be especially careful if contemplating unfair locks from Swift.

See https://stackoverflow.com/a/73314198/1271826 and the links contained therein for a discussion of a variety of synchronization mechanisms.

But in short, actors are the modern solution, GCD are the robust, older solution, and locks are useful in edge-cases where performance is critical, but must be used carefully. But objc_sync_enter and objc_sync_exit are of little-to-no practical use anymore.

---

You go on to say:

... where a number of variables are accessed in a block, but the same variables are written infrequently (such as when UI orientation or app settings change).

If it is simply for UI updates, a common technique is merely to dispatch these blocks to the main queue. This works because (a) all UI updates must happen on the main thread, anyway; and (b) the main queue is a serial queue.

In short, especially when for UI updates, dispatching related model and UI updates the main queue is a quick-and-dirty synchronization mechanism.