Whenever somebody does an analysis of coding standards like this (see also the JSF coding standards) they always lock in on how these rules are written to enforce "correctness", but they frequently gloss over an extremely important part of what it means to be correct in a complex control system like a jet fighter or a space craft, and that is deterministic execution.
"Correct" execution doesn't just mean error free, but it also means that code needs to execute deterministically both in terms of near-complete referential transparency as well as execution time. This is what is referred to as "real time computing" in CS, a term that has recently been made homonymous by UI/UX/front-end designers to describe responsiveness in high-latency systems like the web.
All of the inferences about how these rules aid static analyzers are good and correct, but a lot of these rules are also important to achieving deterministic execution time; memory management being the big one due to its complete lack of determinism both in computation result and computation time. Sticking code in a real-time OS doesn't really matter unless the code itself is also real-time kosher.
I don't bring this up to gripe, but only bring it up because it wasn't something I was familiar with until I started working on torque controlled walking robots a few years ago where the feedback loop has a real-time constraint, and it has since taken over my life and I find it to be a very fascinating aspect of computer science that almost nobody ever talks about. Achieving real-time deadlines in a program can be quite challenging and very often making something "faster" than its deadline is not even close to the same thing as making sure it always makes its deadline. It really changes the way you think about performance, execution time, program optimization, etc.
... referred to as "real time computing" in CS, a term that has recently been made homonymous by UI/UX/front-end designers to describe responsiveness ...
And to add to the confusion, the term "responsive" was co-opted to mean "adaptive layout".
So now it's perfectly possible to have this conversation:
- This site is not responsive.
- Sure it is, try resizing your browser.
- No, I mean that it takes too long to react to user input.
- Oh, you mean it should be real time?
- No, nothing even close to real time -- I'd be happy if something happened in less than 1 second when I click this button...
Right, 'real-time' vs. 'real-fast'. Control systems for electro-mechanical devices is the primary domain for this type of software. It is required for any motion control where missing a timing mark can cause an undesired physical event. Imagine a walking robot that missed a motor position adjustment during garbage collection. It might mean the robot itself is headed to the garbage ;-)
I always thought the traditional distinguishing terms here were "hard realtime" (e.g. control software) versus "soft realtime" (e.g. games). Are those not widely used any more?
They are used, but hard vs. soft realtime is tangential to the broader discussion here.
If we stick with the video game example, it has a real time goal: having frames displayed at the target framerate. The "soft" aspect comes from the fact it's tolerable for a game to fail some deadlines. It's certainly undesirable, but a few minutes of frame-y gameplay is not game-breaking.
Depending on the particular system, there will be tolerances of how frequently and in which ways a realtime deadline can be missed without constituting an overall failure of the system.
Hard, Firm, and Soft real-time are all classifications in real-time computing. They are measurements of how detrimental it is to the system if they miss a deadline. Control systems can still be soft real-time.
And those terms may be used not to refer to the system as a whole, but particular tasks within it. Hard constraints on tasks that can never miss a (often nanosecond resolution) time point, firm real-time that can't be missed but which can be delayed, soft real time that can be missed (but only a certain number or percentage of times, or can't be missed twice in a row, etc). Different systems and teams may use those categories differently. For example, the AGC alarms that nearly caused the Apollo 11 Eagle landing to abort were for tasks in the last category, so they were able to continue. There were other tasks on that same real-time system for which missing the timing would have required an abort (or triggered a lot of very loud noises followed by silence).
Correct. Real time doesn't mean "as fast as possible" in embedded systems. It can mean anything from "within a specified time after a given condition is met" to "it must happen at precisely this time, every time, after this condition is met" and a bunch of permutations between and outside those two.
The idea of deterministic jitter might be foreign to those who've never done real time embedded work. By this I mean the idea that, for example, a certain output or result is specified to happen at 100us +/- 1.2us from a condition being met. Here +/- 1.2us being the acceptable response jitter. Very often you find yourself using NOP's to balance both sides of a conditional in machine language in order to control jitter.
From experience I'd say that the exact definition of "real time" is project dependent. This definition is very different in, for example, a control panel processor vs. a 5 axis milling machine capable of rigid tapping.
I had my first exposure to this "deterministic" execution concept when I was writing the data collection part of a computer-based electrocardiogram interpretation service. the ECG cart hooked up to the patient at a hospital somewhere in the US would call our service located near Chicago. The front end would answer the phone and present three analog signals to the analog to digital converter which would sample each channel every 2 milliseconds, and write chunks of digitized samples to disk.
The trick was we noticed that the OS (RBM or Real-Time Batch Monitor from SDS, later Xerox) would mask all interrupts for short periods of time. This would delay the timer interrupt by an amount that would lead to an error in the voltage read (e.g., the rapid upward spike of the QRS wave) that would be significantly more than the quantization error.
Thus, with each release of the OS, I would have to track down the instructions that would mask the three classes of interrupts, and change the code so as not to mask the timer interrupt. This was, of course, delivered in a form of 80 column cards.
Not everyone gets to work on problems of this sort. To adapt the NASA list to JS seems a bit of a stretch.
Could you go into more detail on where I could learn more about this / where I could work on such types of systems? (outside of high frequency trading)?
I've started working on similar types of technology recently, but purely by wandering into it by accident.
I don't really know of any good general resources; they're often pegged to a specific programming language because the ways in which you have to achieve real-time compatibility differ depending on how the language and its runtime behave. We do all of our work in Java, which is definitely not a great candidate for real-time in most cases, so a lot of what I've learned about real-time programming has come from having to wrangle the JVM in to doing what we need it to do.
The fields that come to mind when I think of real-time outside of HFT, though, are control systems and digital signal processing (DSP). While DSP doesn't necessarily need to be real-time if you're doing it for analysis, doing DSP live definitely requires real-time programming knowledge since signals are often expressed in the time domain and any delay in computation of a discrete element will propagate in how the signal is interpreted. For example, if the signal you're processing is a sound signal (like music), and you are doing software-based DSP on the signal before it reaches the playback device, it better be real-time or any delay spikes will ruin the playback. This is why OS X is so popular with the music industry and especially DJ's; the Mach kernel has really good real-time support and a pretty good real-time software based DSP library for building apps.
We have some contacts at Aicas, and we've used both the original RTSJ in the past as well as evaluating Jamaica. Myself and a colleague recently attended JTRES and spoke to Dr. Hunt about where Aicas fell short for our specific use case, and in the very near term it won't be usable for us. We're looking in to re-evaluating it around summertime.
Most of these things I do on a regular basis, but #7 sounds rather stressing and code cluttering to me. Maybe these new Proxies of ES6 could ease that pain.
"Correct" execution doesn't just mean error free, but it also means that code needs to execute deterministically both in terms of near-complete referential transparency as well as execution time. This is what is referred to as "real time computing" in CS, a term that has recently been made homonymous by UI/UX/front-end designers to describe responsiveness in high-latency systems like the web.
All of the inferences about how these rules aid static analyzers are good and correct, but a lot of these rules are also important to achieving deterministic execution time; memory management being the big one due to its complete lack of determinism both in computation result and computation time. Sticking code in a real-time OS doesn't really matter unless the code itself is also real-time kosher.
I don't bring this up to gripe, but only bring it up because it wasn't something I was familiar with until I started working on torque controlled walking robots a few years ago where the feedback loop has a real-time constraint, and it has since taken over my life and I find it to be a very fascinating aspect of computer science that almost nobody ever talks about. Achieving real-time deadlines in a program can be quite challenging and very often making something "faster" than its deadline is not even close to the same thing as making sure it always makes its deadline. It really changes the way you think about performance, execution time, program optimization, etc.