In an RTOS can a process be prempted when running in kernel space

Question

I understand that a process can't be preempted when running in kernel space. If that's true, in an RTOS how is responsiveness guaranteed (If a system call takes more time to execute) ? Can a do a context switch for a process even when it is running in kernel space ?

Answer 1

Whether a process can be preempted or not depends on the design of process states. On linux you have UNITERUPTIBLE_SLEEP where the process sleep still a certain service it had requested for is completed. (Ex read) . It may so happen that the service never got completed and the process never got a signal and was infinitely sleeping (holding on to system resources).

In case of an RTOS, this approach is not justified as the resources(Ex memory) is scarce. So, a process can never be in UNITERUPTILBE STATE. Hence the OS can send a signal to the process sleeping/waiting for some service, prematurely. So the OS has a greater control on process allowing it control system resources as well.

As pointed by @Levente Kurusa, the OS can send a signal to the process after an interval, making it either yeild control to the OS,( time sliced execution which ensure good response time) or kill it if it was waiting for a service for long time.

Answer 2

In a RTOS, each process has a minimum time to run, and the system calls are documented and implemented in a way that ensures the worst case, the maximum time it takes to complete. That is, when you call for example, open(), the RTOS's system call documentation has a worst time field. If the call doesn't complete in, say 100ms, then it will fail. Application development for RTOS is really different from developing for a general OS. You have to take in account each call's time and such. For example, on QnX you have to tell the OS the maximum response time. If your process doesn't complete in that frame, it will be terminated.
Note: QnX is a RTOS for x86.

Answer 3

RTOS architectures vary considerably so it is not possible to make a general statement. The concept of kernel space itself may not even be relevant to a particular RTOS depending on its design and the platform it runs on. Targets without an MMU for example cannot really implement the concept, though some targets have privileged execution modes for interrupts or supervisor which may be used by a kernel, but that is not the same thing, and only involves switching of stacks and register sets and access to certain instructions rather than management memory and I/O spaces.

Many RTOS are simply scheduling kernels that provide no more than task scheduling, timers, synchronisation and IPC and are provided as statically liked libraries so that the final application is monolithic. Most often all threads share a single memory space and the concept of a "process" rather than a "lightweight" thread as the task model is not implemented. If there is a concept of "kernel space", then typically only the OS scheduler itself will run in that mode, and all tasks, threads, or processes run outside that "space".

An OS that does make extensive use of MMU and uses a "process" model is QNX which uses a microkernel architecture so that only a very small part of the system responsible for scheduling runs in "kernel space", much of the OS and all user processes run outside of that.

Invariably in an RTOS however, interrupts are either never disabled or disabled for the minimum possible time, and the scheduler itself is entirely deterministic.

To get a better understanding of RTOS concepts take a look at this online course from Jack Ganssle.