5 ms·

Thx >>The point of a realtime OS is not to make your programs run in real-time, but to make it possible for your programs to run in real-time. So basically, if

Thx >>The point of a realtime OS is not to make your programs run in real-time, but to make it possible for your programs to run in real-time. So basically, if I program something and somehow set it to be "realtime" then I can be sure that it won't be suspended before it finishes whatever it is doing? Such a condition cannot be kept indefinitely - soon or later there will be activities that will need the OS' attention (therefore my program will have to be suspended), no? (If yes then I have problems understanding the threshold...).

alfalfasprout 8y ago
This varies. On a multicore CPU it's possible that processes will actually be pinned to a core and those processes will have exclusive access to the CPU core (i.e nothing else will be scheduled on it). 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. It's tricky though because even things like dynamic memory allocation can have non-realtime behavior.
- zepearl 8y ago
  >>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?
  - wtallis 8y ago
    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.
- kllrnohj 8y ago
  > Real-time programs tend to avoid syscalls, etc. which cause a context switch That's not why they avoid syscalls. If you are running on a real time schedule there won't be a context switch in response to a syscall. They may, however, get blocked on kernel mutexes. So syscalls are avoided for the same reason user-space mutexes are avoided - being real-time doesn't help if you're blocked on a mutex.
- shaklee3 8y ago
  At least in Linux, there are still os threads that will run on pinned, isolated CPUs. There's work being done to allow only the user thread to run, but last I checked it wasn't complete.
gizmo686 8y ago
>So basically, if I program something and somehow set it to be "realtime" then I can be sure that it won't be suspended before it finishes whatever it is doing? Not necessarily. The OS will provide guarantees about how when the program will be suspended and for how long. The strength of those guarantees will vary between systems, and it is a fuzzy line to decide at what point you have a realtime system. One example of this is cheap smartphones. Most phones contain a separate baseband processor to control the phone's radio. Because of how critical timing is to radios, these processors will typically run some sort of realtime system. However, modern processors are powerful enough to run both the baseband code, and Android on the same processor. The difficulty in doing so is that Android is very much not a realtime system, so trying to run the radio software as, say, a Linux kernel driver would be impossible. The solution is to run both Android and the baseband under a realtime hypervisor. The hypervisor would then guarantee, for example, that every millisecond it will switch to the baseband code. The baseband still gets suspended while Android is running, but because it knows exactly how long it will be suspended and how long it has to do its work while it is not suspended, it is possible for it to do its timing critical job. You could view this as the baseband having a lot of short-lived "jobs" that it finishes each time before loosing control. Another way to think about it (that is typically more realistic) is that the baseband has 1 longrunning job that involves a fair bit of waiting; and it can be suspended while it is waiting. Depending on your architecture, you might have the baseband coorporativly suspend itself, or have the hypervisor preemptively suspend it (with well defined timings that the baseband was designed to work with)
- kllrnohj 8y ago
  > The difficulty in doing so is that Android is very much not a realtime system, so trying to run the radio software as, say, a Linux kernel driver would be impossible. Not entirely true. Although Linux is not typically real-time you can achieve this by using SCHED_FIFO or SCHED_DEADLINE for a given process/thread. Android in fact does this for things like audio or display composition.
  - ertjaet 8y ago
    Setting a Linux process to a "realtime" priority (using SCHED_FIFO, etc.) will put above all non-RT /userspace/ processes. But doing that still means that the kernel can preempt you, if it decides to.

alfalfasprout 8y ago

This varies. On a multicore CPU it's possible that processes will actually be pinned to a core and those processes will have exclusive access to the CPU core (i.e nothing else will be scheduled on it). 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. It's tricky though because even things like dynamic memory allocation can have non-realtime behavior.

zepearl 8y ago
>>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?
- wtallis 8y ago
  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.
kllrnohj 8y ago
> Real-time programs tend to avoid syscalls, etc. which cause a context switch That's not why they avoid syscalls. If you are running on a real time schedule there won't be a context switch in response to a syscall. They may, however, get blocked on kernel mutexes. So syscalls are avoided for the same reason user-space mutexes are avoided - being real-time doesn't help if you're blocked on a mutex.
shaklee3 8y ago
At least in Linux, there are still os threads that will run on pinned, isolated CPUs. There's work being done to allow only the user thread to run, but last I checked it wasn't complete.

gizmo686 8y ago

>So basically, if I program something and somehow set it to be "realtime" then I can be sure that it won't be suspended before it finishes whatever it is doing? Not necessarily. The OS will provide guarantees about how when the program will be suspended and for how long. The strength of those guarantees will vary between systems, and it is a fuzzy line to decide at what point you have a realtime system. One example of this is cheap smartphones. Most phones contain a separate baseband processor to control the phone's radio. Because of how critical timing is to radios, these processors will typically run some sort of realtime system. However, modern processors are powerful enough to run both the baseband code, and Android on the same processor. The difficulty in doing so is that Android is very much not a realtime system, so trying to run the radio software as, say, a Linux kernel driver would be impossible. The solution is to run both Android and the baseband under a realtime hypervisor. The hypervisor would then guarantee, for example, that every millisecond it will switch to the baseband code. The baseband still gets suspended while Android is running, but because it knows exactly how long it will be suspended and how long it has to do its work while it is not suspended, it is possible for it to do its timing critical job. You could view this as the baseband having a lot of short-lived "jobs" that it finishes each time before loosing control. Another way to think about it (that is typically more realistic) is that the baseband has 1 longrunning job that involves a fair bit of waiting; and it can be suspended while it is waiting. Depending on your architecture, you might have the baseband coorporativly suspend itself, or have the hypervisor preemptively suspend it (with well defined timings that the baseband was designed to work with)

kllrnohj 8y ago
> The difficulty in doing so is that Android is very much not a realtime system, so trying to run the radio software as, say, a Linux kernel driver would be impossible. Not entirely true. Although Linux is not typically real-time you can achieve this by using SCHED_FIFO or SCHED_DEADLINE for a given process/thread. Android in fact does this for things like audio or display composition.
- ertjaet 8y ago
  Setting a Linux process to a "realtime" priority (using SCHED_FIFO, etc.) will put above all non-RT /userspace/ processes. But doing that still means that the kernel can preempt you, if it decides to.