What is the difference between synchronous and asynchronous?

I am confusing sequential queing with synchronous threading. I've studied this before, but it's not sticking. What does it mean to be synchronous or asynchronous as far as threading or DispatchQueue or OperationQueue? Anyone care to explain this to me? I would really appreciate it. I'm having trouble finding information on it. Last time I used Ray Wenderlich, but my subscription ran out.

Accepted Reply

I think you are mixing up terminology. Although one could talk about certain synchronous behaviours with respect to threads, I don't think you are doing that. Also, I think you are asking about "serial" queues, not "sequential" queues. A queue is, by definition, "sequential".


The two types of queues are:

Serial - One dispatched block runs at a time.

Concurrent - All dispatched blocks (may) run at the same time.


A queue is a higher-level data struture than a thread. They make concurrency easier to conceptualize. And generally you want to talk about "concurrency" rather than "threading". Concurrency talks about the order in which operations run. Concurrency may, or may not, be implemented with threads. Concurrency may also be implemented with separate processes, among other things. Threads refers to one specific type of hacked-up single-process concurrency.

Replies

I think you are mixing up terminology. Although one could talk about certain synchronous behaviours with respect to threads, I don't think you are doing that. Also, I think you are asking about "serial" queues, not "sequential" queues. A queue is, by definition, "sequential".


The two types of queues are:

Serial - One dispatched block runs at a time.

Concurrent - All dispatched blocks (may) run at the same time.


A queue is a higher-level data struture than a thread. They make concurrency easier to conceptualize. And generally you want to talk about "concurrency" rather than "threading". Concurrency talks about the order in which operations run. Concurrency may, or may not, be implemented with threads. Concurrency may also be implemented with separate processes, among other things. Threads refers to one specific type of hacked-up single-process concurrency.

So where does synchronous and asynchronous fit it? What are the differences between those two things?

Synchronous = Waiting for your girlfriend to try on clothes in a department store while holding her coat and handbag.


Asynchronous = Going to a sports bar and having a drink before returning to pick her up when she has finished shopping. Not synchronous.

Synchronous means execution is blocked while waiting for a response.


Asynchronous means execution continues immediately, and the response is delivered at some future time by a delegate callback, by executing a block/closure or whatever.


Operation queues are often used to make synchronous things asynchronous. You queue up a bunch of operations that are synchronous themselves (make blocking I/O calls, do expensive computations etc.) followed by one that handles the results. All the operations are queued up with no delay and the thread/process that queued them up is immediately free to do other things. The operations are executed later (maybe same thread, maybe different thread, maybe different process... that’s an implementation detail you might or might not care about). Some time in the future, the last operation that reports the results is run.

Simplified...


Synchronous: Waits for the task done

Asynchonous: Does not wait for the task done


Where to use...


Synchronous: UI update, modifying thread-unsafe data structure

Asynchonous: When calling a task which may take long and/or unpredictable time


Actual codes may not seem so simple...

DispatchQueue.main.async {
    tableView.reload()
}

The closure will be executed in the main queue synchronously, but the caller does not wait it to be done.

> What are the differences


series vs. parallel execution.


Synchronous basically means that you can only execute one thing at a time. Asynchronous means that you can execute multiple things at a time and you don't have to finish executing the current thing in order to move on to next one.

ShinehahGnolaum wrote:


So where does synchronous and asynchronous fit it? What are the differences between those two things?

I assume this is in reference to the GCD "dispatch_sync" and "dispatch_async" functions. Unfortunately, this is just poor function naming on Apple's part. It leads to a lot of confusion.


Synchronous means multiple things happening at the same time. Ergo, "dispatch_sync" means exactly the opposite of what it should mean. 🙂


Asynchronous is not quite the opposite of that, at least in a computing concept. I think Apple must have created "dispatch_async" first and then somebody decided to use "dispatch_sync" for something that was the opposite. But that only boxed them into a semantic mess.


In a computing context, asynchronous is closer to the concept of "event-driven". Obviously, event-driven means something that happens in response to an event. But the key part of this is that both event-driven and asynchronous refer to operations that happen on some undefined schedule that you, the programmer, do not control. You don't know when the user is going to click a mouse button, when a hardware interrupt is going to fire, or when your asychronously dispatched block is going to execute. Therefore, think of asynchonous as meaning "you don't know when".


Synchonrous is then the opposite of that - "you know exactly when". When you dispatch a block synchronously, you know it is going to execute right then and there.


It is important that you don't equate "asynchronous" with "concurrent". They are not the same. When you are running code, you will often notice that code that is written after "dispatch_async" actually executes before the block inside the "dispatch_async" function call. That is an illusion. It could happen before, at the same time, or 5 minutes later. You don't know when the code in the asynchronous block is going to execute.


But with dispatch_sync, the code will execute in the order specified by the code. I am going to have to take issue with one of the previous replies. You almost never want to do UI updates via dispatch_sync. UI updates should only happen on the main thread, which just happens to be a serial queue. Normally you perform a dispatch_async on the main thread and then let your background thread run. You can also call dispatch_async on the main thread from the main thread. Don't try that with dispatch_sync or you'll deadlock.


There is no such thing as a "thread-unsafe data strucure" because there are only "data structures" and none of them are ever thread safe. A dispatch_sync function is useful, along with a serial queue, for ensuring that only one threat at a time has access to a data structure. If you do happen to have some object that is advertised as "thread safe", it is only because someone else has done the work with "dispatch_sync" or an equivalent to ensure that you can safely access it from multiple threads. If you aren't careful with dispatch_sync, you could have deadlock, which is bad.