That's pretty much what the author said:
> Real time doesn’t mean instantaneous, or even as fast as possible, it means there’s a clear deadline in the system that the process must complete by a certain amount of time. That deadline need not be milliseconds. It can be weeks. In hard real time systems the system is verified in such a fashion that we can assume it’s impossible for the deadline to be violated. If the deadline is slipped the system is broken.
From what I got, the author's complaint is that most people who talk about "real-time" don't actually define, let alone guarantee such a threshold. Without it, the term becomes a marketing buzzword.
The actual definition is even more strict, implying a system cannot break the deadline because the time cost is completely deterministic and when you start a process you can already know the exact point in time the process finishes. That would rule out using any operations that have a nondeterministic time cost, such as dynamic scheduling or network requests.
> Because, brace yourselves, “real time” refers to process prioritization not response time.
She latter back pedals and does define it correctly.
One of the common features of analog is no storage of data, simply passing it on at the speed it comes in.
Once you start buffering or storing the data that's when artificial delays can be introduced that can be so much different than analog that you perceptibly lose an element of continuity.
Electronically, to retard analog signals very much there were integrated circuits like delay lines, where the incoming signal was passed from silicon cell to cell an excessive number of times simply to achieve a desired latency from the output pins.
This is almost the equivalent of a FIFO buffer so often used in handling digital signals.
That 1/100th of a second cycle time and the guarantees associated with it are what make it a real-time system (a hard real-time system, in this example).
The OS that runs the ECU (engine control, sometimes other such safety systems), sometimes things like brakes, is an rtos because delays can cause death.
But the OS running your driver systems, music player, WiFi, climate control, etc is a non real-time OS, more like android, and that’s reflected in the delays you can sometimes see.
Compare Digital founder Ken Olsen's use of the term in his oral history, "The original computing was based on the way people had done computations before. You'd collect all the data, bring it together, process it and send the answers back. The idea of processing it, real time, took a long time to develop. In the world of commercial processing, it's just in the last few years that batch processing has started to disappear. The replacement for it is now called transactional processing, where if you make a transaction with a bank, it is instantly taken care of." (https://www.computerhistory.org/collections/catalog/10263035...)
There are many applications to this, each coming with their own set of implications. E.g., if you want a smoothly running interactive program on an early PDP computer, you want to have program paths of about equal runtime duration. Which may mean in turn that you would want opt out of no-operation paths as late as possible, by this stabilizing run-time, rather than as early as possible. (E.g., we perform calculations anyway, but apply the result only under a certain condition.) Or, if it is about complex processes, where it may mean that we will fulfil a contract in a guaranteed span of time to facilitate cooperations of any kind (e.g, what Olsen calls transactional processing or matching sampling rates with digital computers as a replacement for analog lab computers). Or it may be bound to a particular domain, where stale data isn't of any use (e.g., compare Whirlwind's origin in a digital flight simulator.) Or it may be just about a system being able to respond to input at all.
"words mean what I say they mean, not what you say they mean." -- mathgladiator
