Before working on my PhD dissertation, I was under the impression that real-time meant real fast. In my mind, the term real-time was associated with programs that dealt with real world phenomena and therefore had to respond quickly to their inputs in order to be of any use.
My pre-PhD background was pattern recognition and artificial intelligence, so I wasn’t aware of the exact meaning of real-time. My misconception of the term real-time was reinforced by the literature I read. Almost all the material I read that referred to real-time used it to mean “real fast”.
My PhD research cured me of this misconception, but I have discovered that this misunderstanding of the term seems to be more pervasive than I imagined. I have seen several grad students use the term to imply “real fast”. I have heard things like “my algorithm does its job in so and so milliseconds, so it is real-time”.
I hope that this blog post will contribute to the eradication of this misconception. So, what exactly does the term real-time mean? The term real-time simply means a system that can provide predictable timeliness assurances. Lets examine that sentence a bit. What does “timeliness assurances” mean?
We all know the meaning of “assurances”, so lets turn our attention to the meaning of timeliness. In order to explain what timeliness means, we need to understand that the correctness of a real-time process depends on both its output and the time at which it produces this output. Traditional correctness is associated with output only — if a process produces the correct output, given a certain input, then it is correct. Not so for real-time processes.
There are two types of real-time systems, “hard” real-time systems and “soft” real-time systems. In both types of systems, a time limit, usually referred to as a deadline, is associated with a process. All processes in a “hard” real-time system must produce their output before their associated deadline.
For “soft” real-time systems, some processes may miss their deadline — therefore the goal becomes meeting the deadline of a certain subset of processes to optimize some application-specific criteria. Thus, a “hard” real-time system is correct only if all its processes meet their deadline, while a “soft” real-time system is correct only if its application-specific criteria is successfully optimized.
“Timeliness assurances” refers to the ability of a system to provide assurances that it will meet its timing requirements — i.e., it is an assurance that a real-time system is correct (note that the definition of correctness, as described in the paragraph above, depends on the type of real-time system we are considering).
At this point, some readers may be thinking, “OK, if we design a really fast system, all deadlines will be met, so real-time does in fact mean real fast”. Unfortunately, this is not the case. Even if you have an extremely fast machine, and your programs are optimized to execute as quickly as possible, scheduling the processes on your system in the wrong order can result in missed deadlines. It’s not the speed of the system that matters, but the scheduling algorithm used. The situation is even more apparent for “soft” real-time systems; after all, how is speed going to ensure that an application-specific criteria is optimized?
So real-time does not mean real fast at all, speed is orthogonal to the concept of real-time. It’s not the speed of the system that matters, but rather how the system schedules its processes. The scheduling algorithm used should be able to guarantee, given certain assumptions about the system, that all deadlines are met or that a certain application-specific criteria will be optimized.
The situation becomes more complicated when process dependencies exist — synchronization primitives, such as locks, need to be aware of the timeliness requirements of the system so that they do not work against the scheduling algorithm which is doing its best to meet these requirements.
So, to summarize, I don’t care how fast your program is, if you are going to run the program on a platform that is not dedicated to your program and you do not have control over the scheduling algorithm used, you cannot claim that it is a real-time system.
Of course, if your program is the only one on the system, which is common for those doing hardware implementation of algorithms, you can claim that it is real-time if its execution time is faster than the input it processes.
Since there are no other processes on your system, your program will execute as soon as its input arrives — there is no scheduling decision here, there are no choices between programs. So if the input you process arrives every n time units, and your program can process this input in m time units, you have a rudimentary real-time system if n>m.
Note that by “no other processes are on your system”, I really mean that no other processes are on your system — this includes operating system processes that execute in the background. If they exist, they will compete with your program for CPU time and all bets are off.
Therefore, if you have written your program to execute on standard Windows or Linux kernels, you do NOT have a real-time system no matter how fast your program is. I don’t care if it executes in a femtosecond, it’s not a real-time system because your program is going to compete with other processes, including processes belonging to the operating system, and unless this competition is managed by a scheduler that can provide timeliness assurances, any claim of “real-timeness” is invalid.