How to make an async Swift function "@synchronized"?

Question

I'd like to create an async function which itself using async calls. I also want to ensure that only one call is actively processed in any moment. So I want an async @synchronized function.

How to do that? Wrapping the function's body inside the dispatchQueue.sync {} does not work as it expects synchronised code. Also it seems that DispatchQueue in general is not designed to have async code blocks / tasks to execute.

This code communicates with hardware, so async in nature, that's why I want an async interface for my library. (I don't want to block the app while the stages of communication happen.) But certain operations can't be executed parallel on the hardware, so I have to go through synchronisation so the certain operations won't happen at the same time.

The most obvious way that comes to mind is `OperationQueue` (https://developer.apple.com/documentation/foundation/operationqueue). You will submit all calls as `Operation`s to the `OperationQueue`, which will have `maxConcurrentOperationCount = 1`, and that will ensure that only one operation in the queue is executed at any point. It means of course that operation should be removed from queue not when it starts, but when it receives the response (but all operations can wait in the queue). — timbre timbre, May 22 '22 at 17:17
Another option is to adopt the "Chain-of-responsibility" pattern (sort of, not exactly, but close), where a request will know to start the next request upon its own completion. — timbre timbre, May 22 '22 at 17:22
We would generally reach for actors and `await` the prior task. The challenge is that actors are reentrant, so you need a synchronous tasks that awaits the prior task and starts the next asynchronous task. See `SerialTasks` implementation in https://stackoverflow.com/a/70586879/1271826. — Rob, May 23 '22 at 16:37
Thanks, Rob it really seems that your solution on the linked question solves my problem as well. Now I have to think whether I want to learn about actors to fully understand your code or revert back to synchronised code (on a background thread) with callbacks which seem to make it simpler. — Tamas, May 23 '22 at 17:32

Rob · Accepted Answer · 2023-05-12T20:00:32.563

My original answer (in which I suggest awaiting the prior task) is below. It is a simple pattern that works well, but is unstructured concurrency (complicating cancelation workflows).

Nowadays, I would use an AsyncSequence, e.g., an AsyncStream. See WWDC 2021 video Meet AsyncSequence. Or, for queue-like behavior (where we set up the queue initially and later append items to it), more often than not, I reach for AsyncChannel from the Swift Async Algorithms package. See WWDC 2022 video Meet Swift Async Algorithms.

E.g., I can create an AsyncChannel for URLs that I want to download:

let urls = AsyncChannel<URL>()

Now that I have a channel, I can set up a task to process them serially with a for-await-in loop:

func processUrls() async {
    for await url in urls {
        await download(url)
    }
}

And, when I later want to add something to that channel to be processed, I can send to that channel:

func append(_ url: URL) async {
    await urls.send(url)
}

You can have every Task await the prior one. And you can use actor make sure that you are only running one at a time. The trick is, because of actor reentrancy, you have to put that "await prior Task" logic in a synchronous method.

E.g., you can do:

actor Experiment {
    private var previousTask: Task<Void, Error>?

    func startSomethingAsynchronous() {
        previousTask = Task { [previousTask] in
            let _ = await previousTask?.result
            try await self.doSomethingAsynchronous()
        }
    }

    private func doSomethingAsynchronous() async throws {
        let id = OSSignpostID(log: log)
        os_signpost(.begin, log: log, name: "Task", signpostID: id, "Start")
        try await Task.sleep(nanoseconds: 2 * NSEC_PER_SEC)
        os_signpost(.end, log: log, name: "Task", signpostID: id, "End")
    }
}

Now I am using os_signpost so I can watch this serial behavior from Xcode Instruments. Anyway, you could start three tasks like so:

import os.log

private let log = OSLog(subsystem: "Experiment", category: .pointsOfInterest)

class ViewController: NSViewController {

    let experiment = Experiment()

    func startExperiment() {
        for _ in 0 ..< 3 {
            Task { await experiment.startSomethingAsynchronous() }
        }
        os_signpost(.event, log: log, name: "Done starting tasks")
    }

    ... 
}

And Instruments can visually demonstrate the sequential behavior (where the ⓢ shows us where the submitting of all the tasks finished), but you can see the sequential execution of the tasks on the timeline:

I actually like to abstract this serial behavior into its own type:

actor SerialTasks<Success> {
    private var previousTask: Task<Success, Error>?

    func add(block: @Sendable @escaping () async throws -> Success) {
        previousTask = Task { [previousTask] in
            let _ = await previousTask?.result
            return try await block()
        }
    }
}

And then the asynchronous function for which you need this serial behavior would use the above, e.g.:

class Experiment {
    let serialTasks = SerialTasks<Void>()

    func startSomethingAsynchronous() async {
        await serialTasks.add {
            try await self.doSomethingAsynchronous()
        }
    }

    private func doSomethingAsynchronous() async throws {
        let id = OSSignpostID(log: log)
        os_signpost(.begin, log: log, name: "Task", signpostID: id, "Start")
        try await Task.sleep(nanoseconds: 2 * NSEC_PER_SEC)
        os_signpost(.end, log: log, name: "Task", signpostID: id, "End")
    }
}

For anyone not familiar how a swift `actor` works, I have found this very useful: https://swiftbysundell.com/articles/swift-actors/ — Tamas, May 24 '22 at 07:37
FWIW, I increasingly use asynchronous sequences (esp [`AsyncChannel`](https://github.com/apple/swift-async-algorithms/blob/main/Sources/AsyncAlgorithms/AsyncAlgorithms.docc/Guides/Channel.md)) to get both serial and constrained actor reentrancy behaviors. E.g., see the download managers in the latter part of [this answer](https://stackoverflow.com/a/73072799/1271826). — Rob, Mar 08 '23 at 21:35

score -1 · Answer 2 · answered Aug 30 '22 at 10:58

The accepted answer does indeed make tasks run serially but it does not wait for a task to be finished and does not propagate errors. I use the following alternative to support the catching of errors.

actor SerialTaskQueue<T> {
    private let dispatchQueue: DispatchQueue

    init(label: String) {
        dispatchQueue = DispatchQueue(label: label)
    }
    
    @discardableResult
    func add(block: @Sendable @escaping () async throws -> T) async throws -> T {
        try await withCheckedThrowingContinuation { continuation in
            dispatchQueue.sync {
                let semaphore = DispatchSemaphore(value: 0)

                Task {
                    defer {
                        semaphore.signal()
                    }

                    do {
                        let result = try await block()

                        continuation.resume(returning: result)
                    } catch {
                        continuation.resume(throwing: error)
                    }
                }

                semaphore.wait()
            }
        }
    }
}

Can you share an example where you see the accepted answer is not working? — Harsh, Oct 06 '22 at 00:04
Apple explicitly warns against using things like semaphores together with Swift concurrency. — Helam, Mar 28 '23 at 16:32

How to make an async Swift function "@synchronized"?

2 Answers2