In a mind-blowing twist, in computer science
concurrent and
simultaneous aren't synonyms.
Concurrency denotes access to a shared resource
within a time frame. And there are different approaches to achieving this.
To illustrate the difference lets imagine we're making breakfast,
and we want eggs and toast with a glass of fresh orange juice.
In Sequence
If we did it in a
linear way
we might take 2 minutes to cook scrambled eggs; once they're ready
we would pop bread in the toaster, wait another two minutes, and spend
an extra 30 seconds spreading butter on our toast at the end. Finally we'd move on
to the juicer and spend one minute pressing oranges. Total preparation
time 5m:30s
Eggs are cold by then!
With multitasking
To solve the cold eggs problem we can use a multitasking approach instead of waiting for each part to complete in turn.
If we cook
multithreaded style,
we may crack the eggs open on a pan, then turn to the toaster and put the bread in. We then go back and forth between the juicer and our eggs,
making sure eggs don't stick to the bottom of the pan, and squeezing oranges.
One minute in we
get our juice. Two minutes in, eggs are ready and bread pops out. We
spend the same 30 seconds as before applying golden buttery goodness.
In
reality all that context switching between juicer, pan, and toaster
isn't instant, so let's add 30 seconds more to account for the time it takes to move from one to another. Total
preparation time 3m:00s! We saved a whole two minutes over the
linear method.
If we did it
in parallel, we'd
ask somebody (let's say a couple of friends) to help out. We could cook
the eggs ourselves, while one of them does the toast and the other prepares the
juice. Total time goes down to 2m:30s, which was the time of
the slowest task.
This distinction becomes important to understand when choosing a multiprocessing model, as each offer advantages and tradeoffs.
