4 ms·
>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?
by 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 agoSetting 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.
- mdwrigh2 8y agoWhile the kernel theoretically has the ability to preempt you, it's not supposed to when using a realtime priority thread. Per the RH realtime guide[[1]: """ SCHED_FIFO and SCHED_RR threads will run until one of the following events occurs: - The thread goes to sleep or begins waiting for an event - A higher-priority realtime thread becomes ready to run If one of these events does not occur, the threads will run indefinitely on that processor, and lower-priority threads will not be given a chance to run. This can result in system service threads failing to run, and operations such as memory swapping and filesystem data flushing not occurring as expected. """ SCHED_DEADLINE, which is newer and not mentioned in the guide, can provide a bit stronger guarantees because it can fail if it thinks the requirements you set aren't actually obtainable based on other system load (including high priority kernel tasks that might need to run, etc). [1]: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.3/html-single/Realtime_Reference_Guide/index.html#chap-Realtime_Reference_Guide-Priorities_and_policies https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...