Tangential: the software documented in the books next to her were likely developed with a level of rigor that consumer software can only dream of, per the seminal article on similar matters: https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20...
During the Apollo 11 descent to the lunar surface, Buzz Aldarin pressed a button to display altitude and position during the landing sequence. As it turns out, this was the 8th task the Apollo 11 lander's guidance computer was asked to run, and it was only capable of running 7 tasks in real-time. Thanks to Hamilton and her team's priority scheduler, the guidance computer threw an alarm, killed the lowest priority task, and then resumed the execution of the other 7. If that hadn't been programmed to rescue itself like that, the computer would have crashed, and the Apollo 11 lander would not likely not have been the success that it was.
[1] https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#1201_...
Like it wouldn’t even be describable as a “rescue itself” if the response was simply “No. Too many jobs running. Please kill one to continue”
At a time when the contemporary computer systems that used asynchronous, priority-scheduled multitasking operating systems were things like IBM OS/360 mainframes and DEC PDP-6/PDP-10 minicomputers.
It was like having an Apple II in mid 1960s with double the word size.
You can look at the code here.
https://github.com/kororos/AvrX
Compiles down under 2k.
The thing is while actually doing that isn't crazy hard, they did that with hardly any existing examples to go by. And without modern tools.
Every 1970s videogame has some sort of scheduler that moves actors, draws the screen, and play sound. Depending on the computer, it might be very easy (some could interrupt when the VDP got to a specific spot) or require you to count cycles. If, for instance, your game is for an Apple II and you have background music, you need to hit the speaker at the frequency of the currently playing note WHILE you move things, do physics, and redraw the screen. And you need to count cycles, because there is no reliable counter you could use (I remember how awesome it'd be if I could write 0 to a memory location and read it later to know how many clock cycled passed, or one I could read to get which scan line of the image the video hardware was outputting).
The kind of example for man-rated I was expecting would be dealing with really nutty edge cases (perhaps like correctly operating under arbitrary bitflips) or the LISP recovery system from Deep Space 1.
Handling an expected error condition under normal operation is not, in my mind, a good example of man-rated robustness. It might be a good example of other things.
> Handling an expected error condition under normal operation
Nothing in the Apollo program was "normal operation" by any standard. The thing is the alarm elegantly - and correctly - handled a situation that should never have happened in the operation, that only happened because the simulators the procedures were developed against did not accurately account for the workload of having both docking and landing radars on at the same time (IIRC, this was the issue).
This kind of robustness in the face of unexpected misuse is required if you want to qualify your hardware as "man-rated".
I had read the setup as the 8th task being user error (you have 20 things to do, I can only run 7 at a time, and it’s an user error to submit the 8th task while the 7 are running)
A thing no other computer had ever done before, so, they had to come up with the idea in the first place - a brand new idea. But it was not only that - IIRC, the alarm happened when the OS (a tiny sliver of software not many computers even had at the time) skipped a less important task so it could run the more important ones before their configured deadlines.