Comment by da_chicken
16 hours ago
The term she coined for it was "man-rated". Meaning that it had been tested rigorously enough to be trusted to keep humans alive.
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.
That story is easy to understand and thus catchy, but it is not true. The cause of those 1201 and 1202 alarms is a lot more complex, but well worth taking the time to understand if you are into the topic. Wikipedia offers a short description [1] to get you started.
[1] https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#1201_...
That does not seem like particularly notable example of foresight & robustness, given that it’s such a low number of maximum tasks, and such a fundamental & frequently used element of its operation.
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 that time running that many concurrent tasks on such anemic hardware was a small miracle. This wasn't your average linux kernel.
> “No. Too many jobs running. Please kill one to continue”
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.
It is infinitely harder to be first. Once it is known that viable path exists, the task becomes a lot easier
You’re forgetting this had never been done before.
The Apollo Guidance Computer had 4KB of RAM and 16KB of ROM. Can you write a scheduler that would execute 8 programs related to landing on the moon in 4KB?
An asynchronous scheduler with task priority, interrupts, and real-time response. That goes on a spaceship with less than 70 Watts of power available for the computer. That weighed about 70 pounds. When there has never been that sort of a multi-tasking computer controlled avionics before.
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.
2 replies →
Yes.
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).
And it ran at 0.043 MIPS. Each task would get maybe 5000 instructions per second, minus scheduler overhead.
I mean, the implementation can be incomprehensibly impressive, but as an example of “man-rated” — being sufficiently robust — rejecting the request would be sufficient and I suspect this was an obvious place to have some kind of handling for. If there were no handler of any kind in this position, it’d be unforgivable in modern, far less robust software.
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.
2 replies →