Last week I had a intense discussion on „interrupt driven“, „automotive grade“ and other ferry tails.
Let us start with the OS thing. At a minimum it is a while loop performing well defined „management“ task e.g., keeping a controller happy and consuming registers. Sounds a bit like a company. For doing so, let us consider our while loop has 5 jobs to perform. One is calling code which we not developed. We this job „the spooky one“. What’s of this job never returns? As expected our while loop will never continue – „you only had one job“. Our whole system stuck. To avoid those situations, we register a callback function which will be called time to time. Let’s call this a software interrupt. The thing which allowed us to keep the hardware controller happy was a hardware interrupt. So the interrupt will (maybe hardware triggered) call our handling and house keeping function, allowing us to „kill“ the „spooky job“. By doing so, our system is not longer deterministic and might not (hard) real-time. Not deterministic because between the well defined order of our 5 jobs another house keeping function is executed, changing the whole system state. Might not cause any issue, but from a „academic“ perspective it is not deterministic. What about real-time? If it not disrupt „defined“ our sampling grid … „well“ it can be hard real-time.
Side clause: A usual CPU has multiple cores. Each core allow to do calculations. Due to that, the afore mentioned thoughts are one level of each core.
Based on these considerations a usual GPOS can‘t be either deterministic (but still be good enough) not real-time. Also the preemptive („Unterbrechbarkeit“) extension of Linux „just“ not stop running „task“ (the scheduler thing) whiteout being aligned – well defined execution positions.
What about performance. Real-time not mean really fast. It just says it happens in the defined/ expected timing. It e.f., will delay superior tasks to keep the current timing „expectations“.