Re: Is Parallel Programming Hard, And, If So, What Can You Do About It?

On 5/21/25 13:06, Lynn Wheeler wrote:
...

 I get roped into helping with a 370 16-CPU multiprocessor design. It was
going fine until somebody tells head of POK (high end 370 processors)
that it could be decades before POK's favorite son operating system (now
"MVS") had ("effective") 16-cpu support (POK doesn't ship a 16-CPU
system until after the turn of the century) ... and some of us are
invited to never visit POK again.
 

I got the impression that MVS's processor managment was really unweildy, the vary processor online stuff, and wasn't expected to happen more than
once after os boot.
When they put in support for multiple TOD clocks, they had to be kept in
sync.  If an out of sync condition was detected, checked when bit 31 of
the clock carried out (about once per second), an external interrupt
would be raised, and you synced them back up by putting the cpu's into
set clock spin loops.  In VMXA we would just signal processor them into
the sync logic.  In MVS, I think they had to vary the procssor back offline before they could do something like that.  Which meant every
time a processor came online from power off state, its TOD clock was
in an unset state, cause a TOD sync ext exception, all the online
processors would have varied offline, so the sync code could be run, and
then varied online again.  Repeat for every processor being brought
online from powered off state.  MVS couldn't deal with it so they had
the hardware folk put in a standalone clock chip to set the processor's
clock on power on (allegedly a Timex watch chip).
So without that chip, there would always be a TOD sync exeption at boot
time.  There was a Japanese data center that had the hardware console
on the opposite side of the data center instead of side by side with the
system console.  So when VMXA issued the operator message to press the
enable TOD set button on the hw console, the operator barely had time
to run over the side to press it.  You had 30 secs but vmxa messages
were asynchronous (and probably on the wrong side of that spin loop).
Had to futz with order of issuing that operator message.
Oh, and 370 arch stated that STCK would always be unique and monotonic
but that might not have been really true.  With enough clock drift, a
lot could happen in the 1 second between TOD sync checks.
Joe Seigh