Re: Serial, concurrent, parallel

On 1/16/2025 3:14 AM, Martin Brown wrote:

On 14/01/2025 18:10, Don Y wrote:

I am surprised (disturbed?) at the problems people seem to have
sorting these things out in their thought processes.  I don't
*believe* people think strictly "serially" but I am beginning to
question that belief as I witness smart/capable people stuck in
that mindset!

 Most people do think in a very linear fashion so I'm not too surprised at your finding. Good realtime programmers are as rare as hen's teeth.

When you think of a circuit diagram, do you "track" an electron through
the wiring?  Don't you conceptualize "this block does this WHILE this
other block is doing that"?
People seem to tolerate the notion of an ISR running WHILE their code
is running.  They don't seem to think of it as "my code is running and
THEN an interrupt comes along and does...".
Yet, when they think of multitasking (and beyond), they seem to
intentionally serialize the actors' actions.  Why the difference
in mindsets?

I've been finding problems with their implementations that
would not be present if they TRULY "thought in parallel".  Things
that should be obvious seem to slip right past them.  This came
to a head when I asked a colleague to explain multitasking:
>
   "Well, FIRST, the processor does... and THEN..."
>
   "Ah, 'THEN'!  So, you are thinking about multitasking as the
   SERIALIZATION of multiple tasks instead of the CONCURRENT
   execution of them!  So, when your code is run in true parallel
   form (multiple cores, multiple processors), all of those hidden
   assumptions that you've baked into your design fall apart because
   they are no longer implicitly serialized!

 There are major shrink wrap programs out there that have these bugs.
 Excel 2007 as first released on a multi core machine and programmed via VBA the charting package would quite happily try to plot data points *before* the axis scales had been established. This did not end well and broke a lot of previously stable working commercial code.

Well, that's sad.  But, is similar to what I am seeing in my colleagues'
efforts.
It's like folks "suddenly" working in a preemptive RTOS and being surprised
that the instruction on line N+1 doesn't happen right after the one on line N.
E.g., setting up <something> before you've set up the control structures
that it uses and then being surprised when it starts running "undirected"!

It could be "solved" by the addition of suitable small delays here and there to prevent the race condition triggering. Heavy users went back to XL2003 which I recall was a particularly good vintage.

Dunno.  I've not used a spreadsheet since Quattro.  Never really saw the
appeal (if I need some set of values calculated, I'll just write a bit of
code to do it unambiguously -- instead of wondering what quirks the
spreadsheet imposes).  Especially as so many people seem to use spreadsheets
in lieu of (real) databases.  :<

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

 For things to get interesting you need at least 4 threads with some of them depending on synchronisation with the others. Building a house or putting up one of those insert tab A into slot B tents might do it.
 A house without foundations will obviously fall down and putting the roof on before plastering and fitting out the interior is essential.

Yes, but the foundation won't get poured if the cement factory is "closed".
Or, the trucks won't be able to deliver it if there is a road closure along
the route.
Or...
Any of these things can affect that dependency.  And, many of them can be
signaled BEFORE the actual "need" (deadline) arises!

A variant of this cartoon might also get people's attention:
 https://www.businessballs.com/amusement-stress-relief/tree-swing-cartoon-pictures-early-versions/

One of the issues that they seem to have universal problems with is the fact
that another (parallel) actor may "go away" while it is working on their
behalf or BEFORE it has been tasked with some activity of theirs.  My RTOS
notifies all clients of objects when those objects (or the servers backing
them) disappear (a task declares all of its dependencies to be sure it HAS
them as well as is ENTITLED to them before starting).  The thinking being
that a client would want to take remedial action BEFORE the "need" for the
object manifests.
I've set default exception handlers to kill off any task whose dependencies
disappear (seems like a logical approach) with the thinking that a task
that *can* handle such a disappearance will register a different/better
exception handler.
I.e., there are no "failing to test the return value of malloc" scenarios.
My system is designed to dynamically adapt to the resources available
so it willingly sheds tasks that it deems "less important" in any given
situation (there are upwards of 50K tasks in a system; powering down
a node -- or, losing it in some other way -- easily kills off several
hundred!).
A well-designed task knows this and checkpoints itself so it can pick
up where it left off when resources are again plentiful enough to support
it's resurrection ("Lazarus service").  As any object on which you rely
is backed by SOME task, SOMEwhere, you should be prepared for those objects
to "disappear" at any time.  If you know one has gone, you can adapt to
that "loss" -- even if it means checkpointing just prior to the point where
you access it (so you can resume at that point and benefit from all of your
efforts-to-date, later).  Similarly, if you are DONE using an object,
you should release your dependency on it so you WON'T be notified of
its demise.
I don't see how to "remind" them of this short of deliberately throwing ALL of
those exceptions early in the task's lifecycle -- to ensure they are handled
"as desired" (instead of being surprised by their "random" occurrences,
later!)
The travel analogy works because one can imagine WANTING to be notified
(by the airline, hotel, etc.) that your reservation has been changed
or canceled BEFORE you actually expect to "use" it.  Then, you can
take a different approach to the "problem" instead of being stuck in
an airport or hotel lobby and abending, there!