But yes, when it is meant rigorously, you can definitely schedule a thing to run on exactly at particular times, preempting whatever lower priority thing was running before.
In my last embedded project that meant we had thing that got called every 64 microseconds -- and it was our job to ensure it finished in time for the next tick and also left enough CPU for all the other threads.
Then, for the realtime program to run correctly, it would involve as well an understanding of all other processes/programs that are running at potentially the same time (e.g. "competitors" and "collaborators") and/or with the same or higher priorities, etc.., right?
Therefore, candidate summarized definition:
realtime (HW?/)OSs allow you to execute SW which will run with no interruption, as long as no other SW having the same or higher level of priority interferes?
Does it sound right?
Cool (yes, I was wondering about the complexity :) ) Thank you!
Yes, and the best way to understand things is to keep them simple.
For example you can haveone real time thread which gets absolute priority and meets hard deadlines while everything else runs whenever the OS can find time for it. Then your only two rules are (1) don't let the real-time thread starve the others completely, and (2) don't rely on timing from anything except the real-time thread.
> OSs allow you to execute SW which will run with no interruption, as long as no other SW having the same or higher level of priority interferes?
Yep. Any OS meeting that definition is real-time. Probably you could get away with a looser definition, but getting it right would be a rabbit-hole.