>>Real-time programs tend to avoid syscalls, etc. which cause a context switch so it is indeed possible to run a realtime program indefinitely without the OS stepping in.
I guess that context switches would have to happen if e.g. 2 realtime programs, with the same priority etc..., would run concurrently on the same CPU - or would "the running program" (the one that managed to start first) be allowed by the OS(/HW?) to take total ownership of the CPU until it finishes running?
That "until it finishes running" bit is why you can't tackle realtime at just the kernel level or just within the process. You need to also consider the whole system—ensuring that the services you're trying to run as realtime processes actually fit within your hardware's performance envelope. If you have processes that need to be pinned to a CPU core and have exclusive use of that core, then you need to ensure that you don't try to run more of those on the system than you have CPU cores available to dedicate. If you're timesharing cores between multiple processes, you need to know that the processes sharing cores have timing requirements that can be satisfied by your available resources. The human in charge of the overall system design needs to be figuring out things like how many time slices per second each realtime process needs and how many microseconds of CPU time it needs in each time slice to complete its work.
I guess that context switches would have to happen if e.g. 2 realtime programs, with the same priority etc..., would run concurrently on the same CPU - or would "the running program" (the one that managed to start first) be allowed by the OS(/HW?) to take total ownership of the CPU until it finishes running?