posix.tex

rtai-3.1-test3的源代码(Real-Time Application Interface )

\item When migrating tasks from the RTAI execution domain to the Linux
domain, a time-critical transition must occur, during which RTAI
delegates the control of this task to the Linux scheduler. This phase
must be fast and perfectly synchronized, to guarantee a safe
reentrancy into the Linux kernel code. Additionally, since the only
safe transition point is the Linux rescheduling procedure, the delay
incurred to reach the next rescheduling point inside any preemptible
portion of the Linux kernel must be bounded and as short as possible.

\end{itemize}

Transitions from RTAI to Linux are obtained by sending a
virtual ADEOS interrupt from the RTAI domain to the Linux
domain. The interrupt handler into the Linux kernel wakes up
the process as requested.

If the Linux kernel code was last preempted by RTAI outside
of a critical section, a Linux rescheduling takes place
immediately on the return path of the virtual
interrupt. Otherwise, the preemptible kernel will ensure that
a rescheduling takes place as soon as the critical section is
exited. With the additional benefit of the low latency patch,
those sections are kept as short as possible, enforcing
lock-breaking preemption points as needed.

% ----------------------------------------------------------------------------

\section{Practical Assumptions, Limits and Guarantees}

The new scheme has some practical assumptions and limits: 

\begin{itemize}

\item A vast majority of RTAI-based applications in user-space would rely
on POSIX services mainly for thread synchronization and hi-resolution
timing. Thread synchronization services would only pay the additional
cost of RTAI/Linux migrations - needed to re-enter the Linux kernel
from a RTAI task for performing the system call - when the access to
some resource is effectively contended by more than a single POSIX
thread. Provided this cost is at most a handful of microseconds, it is
assumed that the advantages of RTAI-enabling the Linux system calls
instead of rewriting specific APIs outweight this single drawback,
especially since most of the Linux syscalls issued for synchronization
by the native POSIX layer tend to put the caller to sleep. In any
case, very time-critical services could still be substituted with a
mere RTAI add-on if needed.

\item "In the POSIX interface we trust". IOW, it is assumed that the
standard POSIX interface used to program the real-time applications is
efficient as far as thread concurrency is concerned. As a consequence
of this, and aside of the kernel time consumed in executing syscalls
for its threads, rewriting another dedicated RTAI-specific interface
should not be significantly more efficient performance-wise.

\item "In the Linux kernel we trust". IOW, the syscalls internally used by
the standard POSIX interface for common operations are assumed to be
efficiently written and would not charge unacceptable CPU cost to any
application which currently targets user-space real-time support. The
preemptible and low latency kernel patches are expected to provide for
limited and bounded \_scheduling\_ latencies inside the Linux kernel.

\item Running a RTAI task into the Linux domain with an effective
real-time priority must not impact on the preemptability inside the
RTAI domain. The following assertions remain true at any point in
time:

        \begin{itemize}
        
        \item Adeos's pipelined interrupt model ensures that any unmasked
        interrupt is immediately dispatched to the RTAI domain if
        unstalled, regardless of the currently running domain (RTAI,
        shielding domain or Linux).

        \item Interrupt shielding ensures that Linux targeted interrupts
        are not propagated to the Linux handlers when a real-time
        task executes into the Linux kernel.

        \end{itemize}

\item The Linux kernel provides for a \texttt{SCHED\_FIFO} scheduling policy
enforcing static real-time priorities among the tasks it
controls. This is especially important as Linux's scheduling decisions
must not break the RTAI priority hierarchy when real-time tasks are
operating into the Linux domain.

\end{itemize}

RTAI/fusion will be adapted for running on the Linux 2.6 kernel in
the future, but as of now, please put on your 2.4 glasses when reading
this document.

% ----------------------------------------------------------------------------

\section{Implementation}

\subsection{Current Implementation}

RTAI/fusion is built upon the implementation of a mutable priority
scheme for the Linux placeholder task. As a remainder, this
pseudo-task currently represents all the non real-time Linux tasks,
and acts as a common fallback schedulable object to pick when no
real-time RTAI tasks are ready to run.

The test code is built upon the Xenomai nucleus. Xenomai provides the
scheduling of kernel-based and user-space threads, using a technology
derived from LXRT, and incorporating the implementation details listed
below (see 7). This nucleus includes a real-time, FIFO-based, static
priority scheduler.

Like LXRT, the Xenomai scheduler defines a Linux placeholder called
the "root" thread which gets scheduled as a fallback option when no
other Xenomai threads are runnable into the RTAI domain. This causes
the RTAI domain to suspend itself Adeos-wise, yielding control to the
next domain down the pipeline.

Each Xenomai thread capable of executing in user-space has one
kernel-based TCB called a "shadow", along with its standard
Linux-controlled task structure. Real-time scheduling of shadow
threads is done using those TCBs, but the register state is
exclusively saved into the Linux task structures by both Linux and
Xenomai schedulers during context switching. In Xenomai's terminology,
a shadow thread is the real-time control block of a Linux task also
schedulable by Xenomai. Both schedulers control the task in a mutually
exclusive manner.

The priority of the root thread is mutable, and can be changed
dynamically to reflect the position of the Linux kernel activity
within the real-time priority hierarchy.

A Linux-controlled gatekeeper task is in charge of resuming a Xenomai
thread migrating from Linux to the RTAI domain. This thread is the
equivalent of LXRT's kthread\_b() helper task.

Mutable priority works like this:

In a system defining T1(prio=1,domain=RTAI), T2(prio=2,domain=RTAI),
and ROOT(prio=0,domain=Linux), we would have the following transition:

\begin{code}
T2 runs in domain RTAI...
   T2 migrates to the Linux domain (for executing a syscall)
       ROOT inherits priority(T2)
                T2 executes the syscall on behalf of ROOT
                (at this point, interrupts are no more propagated to
                the Linux kernel)
   T2 migrates back to the RTAI domain (after the syscall completes)
        T2 resumes into the RTAI domain
        ROOT priority is lowered back (to 0 if no other real-time
        threads are runnable into the Linux domain, or inherited from the
        next real-time thread to execute in this domain). As soon as the
        root thread recovers its base priority (0), the interrupt flow is
        restarted toward the Linux kernel.
T2 suspends...
T1 resumes...
\end{code}

As shown, T2 migration would not cause the preemption of the root
thread by T1 despite its lower initial priority, since ROOT's priority
would not allow it after it has been dynamically raised.

In practice, T2 would not be forced to exit the Linux domain right
after the syscall completes, but only when it issues a RTAI
syscall. The migration back to RTAI has been described for
illustration purposes.

Obviously, ROOT never migrates to RTAI, and is always runnable.

% ----------------------------------------------------------------------------

\subsection{Implementation details with regard to priority mutation}

When informed by Adeos that a new Linux task is about to be switched
in (ADEOS\_SCHEDULE\_HEAD event), we check in the event handler whether
a shadow thread is paired with the incoming task.  In such a case, the
root thread priority is raised to the priority of the shadow,
otherwise, this priority is set to the "idle" priority level
(i.e. non-realtime priority).

In the RTAI code controlling the migration of the current thread
from RTAI to the Linux domain, the priority of the root thread is
inherited from the migrating thread.

In the RTAI code controlling the migration from the current Xenomai
thread from Linux to the RTAI domain, the priority of the gatekeeper
thread is inherited from the migrating thread.

\section{Hardware/Software pre-requisites}

The experimental RTAI/fusion subsystem currently runs on the following
configuration:

\begin{itemize}

\item Linux 2.4.21/ia32
\item ADEOS combo patch (Adeos + Kpreempt + Lolat)
\item Xenomai nucleus from the RTAI vesuvio branch.

\end{itemize}

A simple demo is available for download here:

\centerline{http://savannah.gnu.org/download/xenomai/fusion/}

% ----------------------------------------------------------------------------

\section{Programming with POSIX API}
\subsection{Threads}
\subsection{...}
\subsection{API Reference}

\section{Interprocess Communication}
\subsection{Overview}
\subsection{Mutexes}
\subsection{Conditional Variables}
\subsection{Queues}
\subsection{API Reference}