Then it did something that would be amazing in this era, much less 1969: [snip description of reboot]
That’s not really amazing. It’s par for the course for modern microcontrollers, of the sort that litter the innards of modern cars and tractors and such. They usually keep their programs in NOR Flash memory, so they don’t need to be read from a hard drive on start-up, and don’t need to keep much state in volatile memory. And they are usually designed to be able to start up in the blink of an eye. There are fairly cheap microcontrollers with better specs than the Apollo Guidance Computer, and they’re common in applications that need reliable embedded software. It’s a safe bet that the private space industry uses quite a lot of them. And the job prioritization is typical for any system designed to be hard realtime.
Even in big computers like the one on your desk, failing really quickly and well can help with reliability. There’s a school of thought in server design which says that servers should consist of large numbers of isolated parts, which crash if anything goes wrong, and can be rebooted very quickly. This is how most web sites stay up despite bugs, random crashes, and server failures.
I think what is interesting is not the reboot but the fact that it every task was prioritized and unimportant ones were inherently discarded. I do not think this is a feature typical to embedded programming.
That’s actually a very common realtime scheduling algorithm: execute the highest-priority task ready to run at any time, and discard the lower-priority tasks if you don’t have time for them. It’s popular because of situations exactly like the one the Apollo Guidance Computer ran into.
That’s not really amazing. It’s par for the course for modern microcontrollers, of the sort that litter the innards of modern cars and tractors and such. They usually keep their programs in NOR Flash memory, so they don’t need to be read from a hard drive on start-up, and don’t need to keep much state in volatile memory. And they are usually designed to be able to start up in the blink of an eye. There are fairly cheap microcontrollers with better specs than the Apollo Guidance Computer, and they’re common in applications that need reliable embedded software. It’s a safe bet that the private space industry uses quite a lot of them. And the job prioritization is typical for any system designed to be hard realtime.
Even in big computers like the one on your desk, failing really quickly and well can help with reliability. There’s a school of thought in server design which says that servers should consist of large numbers of isolated parts, which crash if anything goes wrong, and can be rebooted very quickly. This is how most web sites stay up despite bugs, random crashes, and server failures.
I think what is interesting is not the reboot but the fact that it every task was prioritized and unimportant ones were inherently discarded. I do not think this is a feature typical to embedded programming.
That’s actually a very common realtime scheduling algorithm: execute the highest-priority task ready to run at any time, and discard the lower-priority tasks if you don’t have time for them. It’s popular because of situations exactly like the one the Apollo Guidance Computer ran into.