Are system calls ever realtime-safe?
 

We are maintaining and developing a 1kHz control system for a robot. This system needs to be hard realtime. To achieve this, we are running our software under an RT-PREEMPT kernel.

However, I have heard that system calls are never realtime-safe in Linux -- in other words, there are no system calls guaranteed to never take a large amount of time. This doesn't make sense to me -- how could, say, clock_gettime() ever take a large amount of time if our thread has the highest realtime priority (and is the only thread at this priority)?

We are aware that many system calls -- such as networking, file IO, and malloc() -- generally aren't realtime safe. I am asking about the system calls that seem vital to basic operation of a program.

Are system calls ever realtime safe? If not, why?

Note: I have already asked this on StackOverflow, but have not gotten any satisfactorily confident or explanitory answers.

Thank you for any help.

The Linux kernel does not guarantee that a process which is engaged in a system call will receive control within a specified time. It also does not guarantee that the fact that any process is engaged in a system call will not deprive some other process (or system activity) from being scheduled within a specified time.

Linux is not ... by design is not ... a RTOS.

I believe that you can either design a real-time operating system or a general-purpose one. These are fundamentally-conflicting design choices such that you cannot simultaneously, meaningfully have both.

That is unfortunate. I guess we'll have to live with the knowledge that our system could possibly miss a deadline (fortunately, our system is resilient against the occasional missed deadline... but we'd prefer hard realtime) -- much of our system depends on Linux-only libraries and toolkits.

I'm fairly sure that RT-PREEMPT, however, guarantees that a high-priority realtime task will preempt any lower-priority thread within some (unspecified but small) amount of time, regardless of that thread's execution state.

I agree with this to an extent... but by changing some of those design choices it seems like RT-PREEMPT reverses most of the determinism-inhibiting effects of Linux's focus as a general-purpose OS.

Thank you for answering.

Linux does have certain features which tilt toward the needs of "timing is really important" situations ... but please recognize that even these are sometimes pretty intrusive. When you start using features like RT-PREEMPT, other processes (upon which your task might also very much depend) can get starved.

Probably the best thing you can do is to equip your machine with the fastest CPU hardware you can afford, then make sure that the machine has nothing else to do with its time than to control your robot. Then, as you did, plan your setup to be resilient against the occasional missed deadline.

We're well aware of what we depend on (for this reason). Frankly, if our code approaches 100% processor usage, we'd prefer to starve other processes (even our own non-realtime tasks) before we miss a cycle.

We're actually using cpu groups to free up a core soley for our tasks. All other tasks go to another core on the system. In other words, we're already doing exactly what you're suggesting.

One thing I don't think I've asked as clearly as I should have is why?

Do you (or anyone else) have any idea why no system calls are realtime-safe?

Thank you for your responses.