0

From: https://mail.rtai.org/pipermail/rtai/2012-April/024968.html

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.

Aquarius_Girl
  • 21,790
  • 65
  • 230
  • 411

1 Answers1

0

First of all, what do you mean by the control gets shifted to user space? If your task is in kernel space, it can never get shifted to user-space. If it is in user space, well it's already there!

In RTAI, you have hard real-time tasks, soft real-time tasks and the Linux kernel. A task is either scheduled by RTAI or the Linux kernel. RTAI ensures real-time behavior, so stuff like deadlines and periods etc go with RTAI. Linux however does not understand any of these, nor does it care.

Now, as long as your code works with RTAI, everything is fine. If you call anything that needs to be done by the Linux kernel, you lose real-time because the Linux kernel is scheduled as a non real-time process by RTAI. So rule of thumb is, whatever passes through Linux is bad.

If you receive a signal from Linux, there is a part of this process handled by the Linux kernel, not to mention the signal handler runs in Linux context and interrupts are disabled. This means you are completely out of your real-time environment without RTAI having any control of the situation. Hence the jeopardy of real-time.

Shahbaz
  • 46,337
  • 19
  • 116
  • 182