Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
Is there any gotcha's programming RealTime C++ applications (user space and linux drivers) on RT linux kernel compare to a std linux kernel?
The Linux RT patch applies changes to kernel scheduler, semaphores, muteces, etc, and I'm wondering if these changes are transparent to the developer? or would one need to take special care in writing such application?
Depends - if you actually develope kernel space drivers that use mutexes and semaphores you should give the patches a quick review. As developer that is your responsibility, no answer on a website will solve that issue.
If you are mainly developing userspace software, these changes do not affect you, as you only wrangle with the kernel interfaces, which are supposed to be stable.
Keep in mind that userspace applications are usually not recommended for strong real time requirements.
Due to the fact that most major distributions supply a RT kernel I conclude: No, nothing special beyond the RT fun is required - general keep in mind things: https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application
I've no experience of programming RT applications with C++: I used Ada; also, Erlang may fit. (There is also RT Java, but I have no experience of it.)
In principle, using C++ shouldn't be a problem, given the tools for IPC (as you mentioned), and for multiprogramming: fork, etc. Explicit memory management will be error-prone until you master it.
RT Linux is an extension to ordinary Linux. (That is common for many RTOSs - they are extensions to non-RT, but time-sharing, OSs.)
In order for the RT tasks to coexist with the non-RT processes, the RTOS takes certain measures: for example, it locks the tasks in memory, or it assigns them higher priorities than the processes. The purpose is to make sure that no non-RT process will ever block a RT task (thus possibly leading to it failing to meet its deadline - and the whole point of RTSs is to prevent this from ever happening).
In the case of RT Linux, it will assign the Linux kernel the lowest priority.
RT Linux is below the Linux kernel, just above the hardware. But the Linux kernel will be oblivious to this: it will perceive the hardware and RT Linux as one (i.e., as hardware). Nonetheless, all hardware interrupts will be intercepted by the RT Linux kernel, and some (those relating to RT tasks) will be dealt with by the RTOS (the rest will be passed on to the ordinary Linux kernel to deal with).
RT Linux uses RT scheduling algorithms that ensure "predictable" behaviour (in the RT lingo), that is, that all tasks meet their deadlines. This differs from Linux, which can't make any such guarantees. Also, RT Linux does not support virtual memory, as this (swapping back and forth) would lead to much longer (unbounded) context switches, and thus unpredictable delay times. (In fact, all RT Linux tasks have full access to the hardware.)
