Aquarius TheGirl Aquarius TheGirl - 16 days ago 6
Linux Question

What code should NOT be written as a real time one?

In Xenomai's API of Posix skin, I find the following:


POSIX skin.

Clocks and timers services.

Condition variables services.

Interruptions management services.

Message queues services.

Mutex services.

Semaphores services.

Shared memory services.

Signals services.

Threads management services.

Thread cancellation.

Threads scheduling services.

Thread creation attributes.

Thread-specific data.


I can't see anything regarding the file handling and socket programming, so I am guessing that perhaps file handling and sockets are not to be dealt in the real time? Is the guess wrong?

Please guide.

Answer

Xenomai and its origin, RTAI, both take control of your scheduler, handling the linux kernel itself as a non-real-time thread.

They have provided many services, most of which as you can see is related to threads and synchornization that do NOT call Linux API (in kernel space) or system calls (in user space). As you know, real-time is all about "guaranteeing deadline" and calling Linux violates it (because Linux doesn't guarantee anything).

Since drivers are also important in real-time systems, they have implemented the real-time driver model, or RTDM that helps both implementing and using device drivers in a real-time context.

File handling in kernel is strongly frowned upon. If you are talking about user-space real-time applications, then you can have access to any drivers that is implemented in RTDM. If you don't find one for file handling or sockets, then no you can't use them. Note that even a printf uses Linux system calls and is forbidden.

Note that if you do use them, nothing breaks, you just lose your real-time-ness! I personally do use files for logging, but only call them in case of an error that means real-time is already ruined anyway.

I don't know about Xenomai, but at least in RTAI, if you call a Linux system call, then you get a warning like "RTAI: LXRT changed mode: syscall ..." in your kernel logs.

Comments