This takes approximately 2,7 seconds to finish, quite a latency to collect some data. In this example, every RestTemplate call blocks the thread it is running on until the call returns some data and then hands over the thread to the next RestTemplate call. It works like this because RestTemplate, by nature, is a synchronous, blocking operation. If you want to know how blocking and non-blocking operations work, there is a detailed explanation here.
After learning this, Tracey decides that she can make use of some of the idle threads on her system to make multiple blocking calls at the same time. It is good to clear out a misconception here: this is called parallelism, not concurrency.
GOTCHA: Parallelism and concurrency are not the same thing
Even if this is not a coroutine specific topic, there is a common misconception regarding parallelism and concurrency. These terms are often used interchangeably, but they represent distinct concepts.
Let’s take a brief journey into the realms of sequential blocking, concurrency, and parallelism by imagining a bustling office scenario, where a diligent clerk is actively assisting clients.
Sequential/Blocking (No Concurrency or Parallelism):
In our imaginary office, this behavior would be seen as the clerk helping one client at a time. While the first client fills in the form, the clerk waits and doesn’t serve any other client.
A single-threaded program works in a sequential/blocking manner, where tasks are executed one after another without any concurrent or parallel execution.
Parallelism:
This involves the clerk calling in a colleague to help. Now, both clients are being served simultaneously by different clerks. Each clerk works independently on their assigned task, leading to true parallel execution.
In a multi-process or multi-threaded program, tasks are genuinely executed simultaneously on multiple processors or cores. For example, two RestTemplate calls can be made at the same time, but they will use and block different threads, not sharing their resources.