1.4. Nucleus description

RTOS emulations are software modules which connect to the nucleus through the pod abstraction. The pod is responsible for the critical housekeeping chores, and the real-time scheduling of threads.

1.4.1. Multi-threading support

The nucleus provides thread object (xnthread) and pod (xnpod) abstractions which exhibit the following characteristics:

  • Threads are scheduled according to a 32bit integer priority value, using a preemptive algorithm. Priority ordering can be increasing or decreasing depending on the pod configuration.

  • A thread can be either waiting for initialization, forcibly suspended, pending on a resource, delayed for a count of ticks, ready-to-run or running.

  • Timed wait for a resource can be bounded by a per-thread watchdog.

  • The priority inheritance protocol is supported to prevent thread priority inversion when it is detected by a synchronization object.

  • A group of threads having the same base priority can undergo a round-robin scheduling, each of them being given an individual time quantum.

  • A support for sending signals to threads and running asynchronous service routines (ASR) to process them is built-in.

  • FPU support can be optionally enabled or disabled for any thread at creation time.

  • Each thread can enter a disjunctive wait on multiple resources.

1.4.2. Basic synchronization support

The nucleus provides a synchronization object abstraction (xnsynch) aimed at implementing the common behaviour of RTOS resources, which has the following characteristics:

  • Support for the priority inheritance protocol, in order to prevent priority inversion problems. The implementation is shared with the scheduler code.

  • Support for time-bounded wait and forcible deletion with waiters awakening.

1.4.3. Timer and clock management

The nucleus needs a time source to provide the time-related services to the upper interfaces. The timer hardware so that a user-defined routine is called according to a given frequency. On architectures that provide a oneshot-programmable time source, the system timer can operate either in aperiodic or periodic mode. Using the aperiodic mode still allows to run periodic nucleus timers over it: the underlying hardware will simply be reprogrammed after each tick by the timer manager using the appropriate interval value.

Each incoming clock tick is announced to the timer manager which fires in turn the timeout handlers of elapsed timers. The scheduler itself uses per-thread watchdogs to wake up threads undergoing a bounded time wait, while waiting for a resource availability or being delayed.

A special care has been taken to offer bounded worst-case time for starting, stopping and maintaining timers. The timer facility is based on the timer wheel algorithm[11] described by Adam M. Costello and George Varghese, which is implemented in the NetBSD operating system for instance.

1.4.4. Basic memory allocation

Xenomai's nucleus provides dynamic memory allocation support with real-time guarantee, based on McKusick's and Karels' proposal for a general purpose memory allocator[10]. Any number of memory heaps can be maintained dynamically by Xenomai, only limited by the actual amount of system memory.


Standard-compliant XHTMLStandard-compliant CSS 2