Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
What will happen is that when a true real time RTAI task is signalled by Linux you'll loose real time for an undefined time period.
POSIX API in general is not supported by the RTAI.
So, when a POSIX real time signal is sent to the RTAI's real time task, the control gets shifted to user space? But I think since the POSIX signals too are the real time ones and they can be written in the kernel module (?) .. so how can it be said that it'll result in the soft real time?
I am not very sure of the reasons for the quote, please explain the point that I am missing.
AnishaKaul wrote:But POSIX man page says there are special "real time" signals. Aren't they real time too?
Posix 'realtime' signals have some properties that normal signals don't have
The real-time signals have a number of properties that differentiate them from other signals and make them suitable for application-defined purposes:
- Multiple instances of a real-time signal can be sent to a process and all will be delivered.
- Real-time signals can be accompanied by an integer or pointer value (see sigqueue[2]).
- Real-time signals are guaranteed to be delivered in the order of their priority.
Well, if you mean "deadlines are not strict" by soft real time, then yes.
There're two kinds of real time schedulers, but it's a design choice which one you prefer:
- non-strict: most process does not use all of their timeslices. A delay in deadline (one process is not ready for it's deadline) acceptable, because other smaller timeslices compensate. (this kind of rt used for streaming, video cutting softwares etc.)
- strict: no process allowed to overcome it's deadline. Programs designed in special way, and usually all process loaded at boot, and you cannot start processes dynamically. (mostly used in critical infrastructures and automated factories, like nuclear plants)
Linux is capable of the former. Note that implementing the latter is extremely difficult, because you have to know how long a process will run. For a typical desktop (with varying number of processes over time), no way to know that. It's usually helped by special scheduler hardware (but necessarily), like in Omron PLCs.
