How both sync and async work with thread safe?

Question

In Swift, we can leverage DispatchQueue to prevent race condition. By using serial queue, all things are performed in order, from https://developer.apple.com/library/content/documentation/General/Conceptual/ConcurrencyProgrammingGuide/OperationQueues/OperationQueues.html

Serial queues (also known as private dispatch queues) execute one task at a time in the order in which they are added to the queue. The currently executing task runs on a distinct thread (which can vary from task to task) that is managed by the dispatch queue. Serial queues are often used to synchronize access to a specific resource.

But we can easily create deadlock How do I create a deadlock in Grand Central Dispatch? by perform a sync inside async

let serialQueue = DispatchQueue(label: "Cache.Storage.SerialQueue")
serialQueue.async {
  serialQueue.sync {
    print("perform some job")
  }

  print("this can't be reached")
}

The only way to prevent deadlock is to use 2 serial queues, each for sync and async function versions. But this can cause rare condition when writeSync and writeAsync happens at the same time.

I see in fs module that it supports both sync and async functions, like fs.writeFileSync(file, data[, options]) and fs.writeFile(file, data[, options], callback). By allowing both 2 versions, it means users can use them in any order they want? So they can easily create deadlock like what we did above?

So maybe fs has a clever way that we can apply to Swift? How do we support both sync and async in a thread safe manner?

Have a look into `DispatchSemaphore`s. The main purpose of `DispatchQueue`s have nothing to do with handling or preventing race conditions, that's what `DispatchSemaphore` was designed for. — Dávid Pásztor, Sep 19 '17 at 13:20
@DávidPásztor Actually, DispatchQueues are exactly the right tool for handling race conditions. They provide mutual exclusivity of all tasks they execute. If all your reads and writes to shared data go through a single dispatch queue, then you're guaranteed to never read midway through someone else's write, or write midway through someone else's read, etc. — Alexander, Sep 19 '17 at 14:02
@Alexander in that sense, you are right, if you only use a dedicated `DispatchQueue` for handling all data access/modification, they can be perfect for such task, I haven't though about this use case. — Dávid Pásztor, Sep 19 '17 at 14:10
@DávidPásztor That's exactly why they were invented. They abstract over `DispatchSemaphore` (they use it internally), so that you can never accidentally forget to acquire or release a lock — Alexander, Sep 19 '17 at 14:25

score 1 · Accepted Answer · answered Sep 19 '17 at 14:08

serialQueue.async {
    serialQueue.sync {
        print("perform some job")
    }
}

This deadlocks because this code queues a second task on the same dispatch queue and then waits for that second task to finish. The second task can't even start, however, because it is a serial queue and the first task is still executing (albeit blocked on an internal sempahore).

The way to avoid this kind of deadlock is to never do that. It's especially stupid when you consider that you can achieve the same effect with the following:

serialQueue.async {
    print("perform some job")
}

There are some use-cases for running synchronous tasks in a different queue to the one you are in e.g.

if the other queue is the main queue and you want to do some stuff in the UI before carrying on
as a means of synchronisation between tasks in different queues, for example if you want to make sure that all the current tasks in another queue have finished before carrying on.

however, there is never a reason to synchronously do something on the same queue, you might as well just do the something. Or to put it another way, if you just write statements one after the other, they are already executing synchronously on the same queue.

I see in fs module that it supports both sync and async functions, like fs.writeFileSync(file, data[, options]) and fs.writeFile(file, data[, options], callback). By allowing both 2 versions, it means users can use them in any order they want? So they can easily create deadlock like what we did above?

That depends on how the two APIs are implemented. The synchronous version of the call might just do the call without messing about on other threads. If it does grab another thread and then wait around until that other thread is finished, then yes there is a potential for deadlock if the node.js server runs out of threads.

How both sync and async work with thread safe?

1 Answers1