Re: Serial, concurrent, parallel

On 1/14/2025 12:43 PM, Liz Tuddenham wrote:

Don Y <blockedofcourse@foo.invalid> wrote:
 

Can anyone suggest a simpler "real world" problem to promote these
"situations/scenarios"?

 Yes, good cooks do it all the time.:
 Put the kettle on to boil water because you can't do anything until you
have boiling water.  Work out what is going to take longest to cook
(potatoes) and put them on first.

But, that's only because you want all of those items to be ready at the
same time.  One could alternatively decide to prepare the desserts, first,
and throw them in the refrigerator so they are out of the way...

Cut up the meat and fry it while the
potatoes cook but as soon as it is in the frying pan, put a saucepan of
water on the hob to bring it to the boil.
 While the water is coming to the boil, start cutting up the green
vegetables.so they are ready when the water boils.  With 10 minutes to
go, put in the vegetables and, with luck, the whole meal will be ready
to serve at the same time.

But that's concurrency (from the cook's perspective).  It is analagous
to multitasking -- the COOK'S actions are serialized.
The parallelism happens because the appliances can "apply heat",
unattended.
And, there is no (practical) possibility of the frying of the meat
abending without the potatoes also suffering a similar "interruption".
[In my travel example, it is obvious that there are other "actors"
("processors") involved, beyond the equipment that assists them.]
Imagine, instead, someone (sous chef?) running out to BUY some potatoes
for the meal and:
- coming home empty handed ("they ran out of potatoes")
- not coming home promptly ("stuck in traffic")
- NEVER coming home ("ran away with the babysitter!"  :> )
In some of those cases, you can be "notified" of the "failure"
so you don't end up proceeding AS IF all is well and only discovering
the problem when you actually NEED the potatoes.
Or, imagine ORDERING a pizza, for delivery, and starting to prepare
a salad and sides while awaiting its delivery.  But, the order gets
misplaced or the driver gets waylaid.
I'm trying to show the value of dealing with these asynchronous
exceptions/notifications so you don't find yourself AT a wait-point
only to discover the thing you are waiting on is not coming. This
allows you to design more robust implementations.
I.e., if the pizza delivery guy texts you to say he was in a car
wreck, you can take action to acquire/make something in lieu of the
pizza (maybe even order another!) BEFORE the expect4ed delivery time
arrives and you find out the hard way that you're SoL.
Most folks who think serially would never imagine that "memory"
could suddenly disappear.  Or, that a file they had opened would
suddenly close itself.  Or, have entirely different contents than
those YOU had written (i.e., that's why we have locks!).

I had a friend who used to cook serially.  Her fried eggs had been
sitting cold and rubbery for 15 minutes by the time the bacon was ready.

Mashed potatoes are the classic test of good meal planning.

For a while she cooked for a lodger - on one occasion he sneaked out and
bought himself some fish and chips, ate them in his room and went to
bed.  She was very upset when she called him down for his evening meal
and found he wasn't hungry and had been asleep for over half an hour.

I tend to *eat* serially, rather than "around the plate".  Of course,
I'm often eating AT the stove while cooking something else to plate
(concurrent eating and cooking??  :> )
I used to use "changing a flat tire" to explain algorithms to
manglement.  It tends to fit the serial pattern of thought as
there are few REAL opportunities for concurrency (as changing
a flat tends to be a one-man operation).
Perhaps the actions of a pit crew would be a better analogy on
those lines?  But, again, all the actors are visible in such
scenarios; you never have to *wonder* if the vehicle was gassed
up as you can SEE the guy who's responsible for that task.
The travel example hides actors from direct observation -- yet
you know they are there, supposedly acting on your behalf.  (And,
will, hopefully, contact you if they encounter a problem doing so:
"We've had a fire in the building and we'll be closed for two
weeks while we make repairs.  We've taken the liberty of arranging
for you to stay at a nearby hotel -- at our expense -- to minimize
the inconvenience to you."   Or, "We've had a fire.  Find someplace
else to stay!"  The "old" alternative would be to show up and
find the building "closed for repairs" and have to process that
event LATE.