— 3 min read
The opposite of love is not hate, it's indifference. The opposite of art is not ugliness, it's indifference. The opposite of faith is not heresy, it's indifference. And the opposite of life is not death, it's indifference.
- Elie Wiesel (1928-2016), Romanian-born American writer.
One thing I've noticed people don't get right when they start in software development is the concept of synchronous & asynchronous operations.
Neither did I, back in the day. In fact, I needed to stop for a day to go deep on it so I can have the right picture. It's ironic, such a simple concept yet so hard to grasp.
I'll share my interpretation with you and - hopefully - it'll be simpler to undertand.
According to Wikipedia:
Synchronization refers to the idea that multiple processes are to join up or handshake at a certain point, in order to reach an agreement or commit to a certain sequence of action.
There was a time where machines are very limited and could just run one task at time. Nowadays we have rocket power computation in our hands. Your phone now is capable to process way more information than ever. The Industry is constantly increasing the CPU power in mobile devices (as well as adding more cores, better architecture, etc).
Even with all this power, there are tasks that still need to happen in a synchronised fashion. Although you can dispatch tasks to happen at the same time, there will be a point in time they have to convey on the resource access. As in, what thread will touch the data first.
The bottomline is - synchronisation (in this context) is about one thing happening (or being executed) at time, after the previous one and before the next one.
The catch is - when a synchronous task is dispatched, it also means this task will be executed now, at the same time the task was dispatched, and will wait for the task to be completed to progress to the next task, thus blocking the thread/process control. (bear this in mind to the next section).
There's a misunderstanding about the opposite of synchronization. People seem to believe that the opposite of doing one thing is doing several, at time.
That's what Concurrency means. Asynchronous operations don't necessarily happen at the same time. You can have a serial queue processing tasks asynchronously, for instance.
As per definition:
[...] Asynchronous describes the relationship between two or more events/objects that do interact within the same system but do not occur at predetermined intervals and do not necessarily rely on each other's existence to function. They are not coordinated with each other, meaning they could occur simultaneously or not because they have their own separate agenda.
What performing a task asynchronously essentially means is that that task is independent and will not block execution.
In other words, the system will compute that you want to perform this task, but it will not wait for it to finish. This way it's thread (and consequentially the other tasks that are about to come) can follow its natural flow.
This is a powerful feature for "non-blocking" systems, such as web frameworks (Nodejs, Swift NIO, etc).
"But wait Rici, if not now, so when does it is executed?" you might ask. Well, it'll be executed later. That means not at the same time it was dispatched, and the control will be returned to the system so the next task can be executed.
So when does later occur? Well, you define. It depends to where you're sending your operation to be executed. In iOS, what the system does is to send this taks to the end of the queue.
So let's suppose you have 10 tasks to execute in a serial queue and the 5th is asynchronous (dispatched in the same queue). It will be pushed to be executed after the so defined 10th task.
I hope that this help you to have a clear picture. At the end of the day, it doesn't really matter when it will be executed, but if it will block the other operations execution or not.
Thanks for reading, see you next time.