rdos wrote:
Not necessarily. Many modern hardware devices can operate in realtime and still send interrupts to the target operating system. A good example is a USB controller, a network card or an AHCI disc controller.
None of those are operations which usually have real-time constraints, not even soft ones. Online constraints, yes, but not real-time ones in a technical sense.
Generally speaking, RT is only going to apply to something where there is an output control signal being sent, rather than an input data signal being received. If the input is necessary for the system to decide how to proceed with a later RT operation, then yes, processing it may have a real time constraint, but even then that isn't necessarily the case. Even if it is, from the POV of the operating system, the constraint usually applies to the process (driver, application, etc.) which is creating the control output, rather than the input itself.
Also, a control output is only real-time if the operation must be performed within a fixed time window of no earlier than
t and no later than
t' to avoid unrecoverable failure of the operation itself - the lower time boundary is just as important as the upper one when discussing RT (even if it is defined as '0 nanoseconds', it is still a lower boundary), as is the requirement that a failure leads to some irrevocable outcome (which could be anything from a paper jam to a power plant meltdown, so long as it is something which cannot be ignored or undone).
Of those examples, only the USB controller is likely to have an RT requirement, when operating peripherals such as mice where timing is a factor, be even there the usual goal is 'fast as possible response' rather than 'response within a fixed time window' - the online timing is handled in software after the signal is received, rather than as part of the signal capture, so the operation itself is not, strictly speaking, an RT one, or even an online one.
Also, a slow response for such a device (or slow processing of the input signal by the driver or application, or even an outright failure to receive the signal) usually won't cause an outright failure - e.g., it may cause you to miss a shot in
CS:GO or
Fortnite (assuming you're a video gamer, I have no idea if you are or not), but honestly there are many other causes within games like that themselves which are far more likely to have that effect, and more to the point, such a stutter won't usually cause the game to abort or crash. The game as a whole will still proceed, even if you lose the match because of that stutter.
More important for our discussion, though, is the fact that the time-critical aspects of the actual peripherals (if they have any) are mostly handled in the hardware or firmware of the devices themselves, rather than as part of the driver in the OS. A number of things which historically were considered soft real-time because they were handled in software on the parent system (e.g., the timing of a printer's write head, or of a floppy drive's read/write head on systems such as the Apple II) were long since moved into dedicated hardware, and even before that, many of them didn't really have a hard real-time constraint - for example, if a disk's R/W head overshot, the driver would usually be able to detect this and adjust it before committing to a read or write operation.
This means that your later example of AD sampling really isn't RT either, unless you are doing the conversion online without any sort of buffering. Again, that is likely to be part of the sampling hardware. Even if you are sampling online ('in real time' in the colloquial sense), it is unlikely that it has a real-time constraint in the software development sense - I'm not sure that a stutter would be considered an irrevocable failure, unless you are performing live for an audience, or if it causes a recording of a unique event to be unusable.
And that's sort of the crux of this issue: most things which are online are not, in fact, real time in the technical sense. Yes, things such as video compositing
should be done within a time constraint, but the operation won't
fail irrevocably if it isn't. It won't cause a line of text to be misprinted in a software-driven printer (which, as I said earlier, was a classic example of a 'soft real-time' constraint in the 1970s and 1980s - a guarantee of 'best effort' performance was acceptable even if it caused paper and ink to be wasted), cause a paper jam (a slightly less soft RT constraint for the same sort of system), knock a bottle over and force an assembly line to halt ('firm' real-time - it is mission critical, and the timing restraint is a hard one, but it is unlikely to be life-threatening unless someone seriously messes up elsewhere), or cause an aileron to get stuck resulting in a plane crash (a genuine hard real-time constraint, where failure leads to significant real world consequences).
In other words, it doesn't sound as if you are talking about an HRT constraint in the first place. While you, of all of us, are more likely to run into an HRT constraint given the real-world applications which RDOS is used for, AFAICT none of the actual deployed installations to date have run operations with such a constraint (IIRC, they include things such as POS systems for gas/petrol stations, but don't control the fuel pumps themselves). So, unless your real application is something different from those you've mentioned, I'm not sure if this really is HRT.
As a rule of thumb, if it isn't controlling physical equipment, it isn't HRT.
(As an aside, I keep reading that as 'hormone replacement therapy', which says a lot about where my head is these days, but that isn't really relevant to this discussion.)