The options of IEEE Std 1003.1-2001 that are grouped together in this option group are: Asynchronous, Synchronized and Prioritized Input and Output, File Synchronization, Memory Mapped Files, Shared Memory Objects, Process and Range Memory Locking, Memory Protection, Semaphores, Timers, Realtime Signals Extension, Message Passing and Process Scheduling.

The options of the standard that are grouped together in the Advanced Realtime option group are: Advisory Information, Clock Selection, Process CPU-Time Clocks, Monotonic Clock, Timeouts, Typed Memory Objects, Spawn and Process Sporadic Server.

This option group includes the following options: Thread Priority Inheritance and Protection, and Thread Execution Scheduling.

The Advanced Realtime Threads option group requires the following POSIX options: Thread CPU-Time Clocks, Thread Sporadic Server, Spin Locks and Barriers.

This option group includes the following tracing facility options: Trace, Trace Event Filter, Trace Inherit and Trace Log.

The following figure shows the network subsystem:

There are four components:

• Input demultiplexing: Decides if a incoming packets are passed to higher layers or are directly forwarded to the network.

• Upper Layers: Processes packets and may also generate new traffic and pass it to the lower layers.

• Forwarding: This layer performs the selection of the output interface, the selection of the next hop, encapsulation, etc.

• Output Queueing or Traffic Control: This is the most important component and decides if packets are queued or dropped, decides in which order packets are sent, etc.

Once the traffic control releases a packet for sending, the network device driver sends it to the network.

The traffic control component consist of the following elements: queueing disciplines (qdisc), classes (within a queueing discipline), filters and policing

In this way, queueing discipline provides a method to enqueue a packet. A class is the place where packets are stored and processed in a specific way, afterwards, the qdisc selects the following packet for sending from classes. Filters are used by a qdisc to assign incoming packets to one of its classes. And finally, policing is used to ensure that incoming traffic does not exceed certain bounds.

The following picture illustrates an example of traffic control configuration:

This configuration consists of a queuing discipline with two delay priorities, as well as, two classes: the higher class contains a token bucket filter discipline that limits the traffic, while the lower class contains a FIFO qdisc. Therefore, while the higher class has packets for sending (rate < 1Mbps), the priority qdisc selects a packets from this class. The filter decides which packets are sent to the higher class. Once a priority qdisc selects the following packet for sending, the network driver sends it on the network.

In conclusion, the traffic control layer decides whether the packets are queued or dropped, in which order the packets are sent, and finally it may delay packet transmission. Moreover, the traffic control elements can be combined in a modular way to support Differentiated Service (DS), Integrated Service (RSVP), ATM and so on.

The following four sections describe the traffic control elements.

Each network interface has a queue discipline attached with it, which controls how packets are enqueued and treated.

A qdisc is a black box, which is able to enqueue packets and dequeue them using its own algorithm, for example, a CBQ qdisc uses a WRR (Weight Round Robin) scheduling to select the following packet for sending on the network.

Moreover, qdisc are divided into two categories:

• Classfull: Qdiscs that may have child qdiscs attached to them.

• Leafs: Qdiscs that have not child's.

The available classfull qdiscs are:

• PRIO a n-band strict priority scheduler,

• CBQ Class Based Queue,

• CSZ Clak-Scott-Zhang,

• ATM Asynchronous Transfer Model,

• DSMARK - DSCP a Diff-Serv Code Point marker and

• INGRESS

The available leafs qdiscs are:

• FIFO a simple FIFO (it is the default qdisc),

• TBF Token Bucket Filter,

• RED Random Early Detection,

• GRED Generalised Random Early Detection,

• TEQL Traffic Equaliser and

• SFQ Stochastic Fair Queue.

A class is attached to a qdisc. However, queueing disciplines and classes are intimately tied together; the presence of classes and their semantics are fundamental properties of the queueing discipline. There is only one available class. This is the CBQ class. Note that a CBQ may work as queue discipline or class.

Filters are used to classify packets based on certain properties of them (address IP ...). The supported filters are:

• rsvp (use RSVP protocol for classification),

• u32 (anything in the header may be used for classification),

• fw (use the firewall rules for classification),

• route (use routing table for classification decisions) and

• tcindex (use the DS field for classification).

Note that the u32 filter is the most advanced filter available and the tcindex filter is used in DiffServ (differentiation services).

The goal of policing is to ensure that traffic does not exceed certain bounds. There are four types of policing mechanisms: policing decisions by filter, refusal to enqueue a packet, dropping a packet from an inner queueing discipline and dropping a packet when en-queuing a new one.

i386, PPC, ARM (StrongARM/iPAQ).

Yes. It is available for i386 architectures.

There are three scheduling policies available: SCHED_FIFO, SCHED_SPORADIC SCHED_EDF. SCHED_FIFO is a fixed priority scheduling and threads with the same priority are scheduled in FIFO order. SCHED_SPORADIC an implementaion of the sporadic server used to run aperiodic activities. SCHED_EDF implements a dynamic priority scheduling policy the EDF ( Earliest Deadline First). Each thread has a fixed priority and a deadline. Threads are sorted by priority, but same priority threads are scheduled according to the EDF policy.

The system provides special system calls to implement periodic threads. pthread_make_periodic_np() and pthread_wait_np()

Minimum and maximum priority is 0 and 1000000 respectively. There is no limit in the number of running threads, but the scheduling cost is proportional to the number of threads. Current scheduler code is designed to handle efficiently a low number of threads (around 10).

It provides all the POSIX Thread termination facilities and also some extensions to remove termitate threads easier.

A thread can terminate itself by calling pthread_exit() function. pthread_join() suspend execution the execution of the calling thread until the target thread terminates. To implement this behavior, when a thread exits, the system do not delete the supporting data until other thread has joined. The system also provides the pthread_detach() function to indicate that the target thread will not be joined and the system support data can be reclaimed as soon as the thread exits.

A thread can request the cancellation (termination) of other thread: pthread_cancel(). The thread that receives the cancellation request, depending on the cancelability state, can do one o the following action:

• PTHREAD_CANCEL_DISABLE: The cancel request is ignored.

• PTHREAD_CANCEL_DEFERRED: The thread will be canceled but only at some safe points.

• PTHREAD_CANCEL_ASYNCHRONOUS:The thread is canceled immediately.

A thread can install cancellation cleanup handlers: pthread_cleanup_push() and pthread_cleanup_pop(). The cleanup handlers are called when the thread exits, is canceled or the handler is removed.

pthread_delete_np() function can be used to termintate inmediately a thread and can be used instead of the pair: pthread_cancel()/pthread_join()

Although RTLinux is designed to run in processors with MMU, all the application threads and the RTLinux kernel run in the same address space. There is no memory protection between threads and the kernel and also between threads themselves.

From the point of view of memory management, RTLinux is the guest operating system of the Linux Kernel. The Linux kernel has the whole control of the memory.

RTLinux do not provide dynamic memory allocation nor use it internally. The main argument is that dynamic memory allocation is not predictable if implemented efficiently. The Real-Time goal of predictability is usually achieved by preallocating most of the resources the threads will use at run time.

It is possible to allocate all the memory that each thread will require before the threads are created.

POSIX REALTIME semaphores are fully implemented: sem_init(), sem_destroy(), sem_getvalue(), sem_post(), sem_trywait() and sem_wait(). These are counting semaphores.

RTLinux supports the POSIX pthread_mutex_ family of functions: pthread_mutex_init(), pthread_mutex_destroy(), pthread_mutex_lock(), pthread_mutex_trylock() and pthread_mutex_unlock(). As well as all the supporting, pthread_mutexattr_... like, functions to handle mutex creation attributes.

The supported mutex types are:

• PTHREAD_MUTEX_NORMAL: The default POSIX mutex.

• PTHREAD_MUTEX_SPINLOCK_NP: Provides a interface to spin-locks used to synchronize the execution in multiprocessor systems.

The supported mutex protocols are:

• PTHREAD_PRIO_NONE:No priority control is performed on locking and unlocking.

• PTHREAD_PRIO_PROTECT: Immediate priority inheritance. The thread that locks the mutex inherits the priority ceiling of the semaphore, and returns to the original priority when the unlocks the mutex.

Mutex provide immediate priority inheritance.

There is no message queues available.

There is no mailboxes.

shared memory is provided with a non-POSIX interface called mbuff. Since all threads are executed in the kernel address space (rtlinux threads share by default all the memory), this sharing memory mechanism is used to communicate rtlinux threads and normal linux processes.

Both execution environments, RTLinux and Linux, have the same mbuff API.

Following the idea that not dynamic memory allocation can be requested during normal system execution, allocation and releasing functions can not be used from RTLinux threads, only at module loading or by linux processes.

RTLinux provide a single IPC called FIFO. It is First-In-First-Out queues that can be read from and written to by Linux processes and RTLinux threads. FIFOs are uni-directional - you can use a pair of FIFOs for bi-directional data exchange.

Time is measured in nano-seconds. Two different data structures are used to measure time: POSIX structure:

struct timespec {
   time_t tv_sec; /* seconds */
   long tv_nsec; /* nanoseconds */
};
	      

typedef long long hrtime_t; /* Nano seconds */

RTLinux use the highest resolution that the underlying hardware provides.

Currently supported clocks are:

• CLOCK_MONOTONIC: This POSIX clock runs at a steady rate, and is never adjusted or reset.

• CLOCK_REALTIME: This is the standard POSIX realtime clock. Currently, it is the same as CLOCK_MONOTONIC.

• CLOCK_RTL_SCHED: The clock that the scheduler uses for task scheduling, it is the best hardware clock.

The following clocks are architecture-dependent. They are not normally found in user programs.

• CLOCK_8254: Used on non-APIC x86 machines for scheduling. Its frequency is 1193180Hz.

• CLOCK_APIC: Used on SMP x86 machines and single processor equipped with local APIC. This clock ticks at the same frequency than the internal processor clock. If the processor is clocked at 1GHz or higher, then the this clock has a resolution smaller than 1 nano-second.

There is no user timers. There is only one timer handler per hardware timer, which is the associated with the interrupt handler. When the scheduler module is loaded, the scheduler takes the control of the timer and no other thread can use the timer.

The only timing facility that a thread can use being a periodic thread.

The internal structure of the source code is prepared to add new timer drivers easily. There is a struct rtl_clock similar to the device driver structure used to register UNIX device drivers.

RTLinux defines two types of interrupts: Soft and Hard Interrupts.

Hard Interrupts the one originated directly by the real hardware. There is very little system interference in the service of these interrupts, therefore the interrupt latency is almost only limited by the performance of the underlying hardware. Since these handlers are executed at the RTLinux level, it is not possible to call linux services. Interrupt handlers are installed and uninstalled with rtl_request_irq() and rtl_free_irq() functions.

Soft interrupts are normal Linux kernel interrupts, in the sense that the interrupt handlers are executed by the Linux kernel thread. The latency of this interrupts are the same than that of a normal linux, i.e., no realtime. On the other hand, is is possible to use all the facilities of the linux kernel. The following functions are used to manage this kind of interrupts: rtl_get_soft_irq() and rtl_free_soft_irq().

It is possible to generate interrupts from RTLinux to Linux with the function: rtl_global_pend_irq. Also, by using the POSIX signal mechanism is possible to send signals (which are received like soft interrupts) to the linux thread.

Since RTLinux threads are executed in kernel address space and processor mode, it is possible to use all the reserved processor instructions directly. To direct access io ports in ISA bus: rtl_inb, rtl_inb_p, and the outb counterparts. To access physical memory (devices located at the PCI bus) it is possible to use ioremap()[5] function at thread initialization and then access the device through the returned pointer.

Source level debugging using GDB directly from the same machine that is running the system. The debugging target system (RTLinux) and the host system (where GDB is running) are communicated with FIFOS.

It is possible to debug periodic threads (gdb command info threads) in the usual way: step by step, break points, inspect variable values, etc. Multiprocessor systems can be debugged. Also is possible to use graphical front-ends like: DDD, gvd, xxgdb, insight.

An optional tracer module can be included in the system. The tracer will register all the relevant system events and user-defined ones.

The builtin set of events includes RTLinux interrupt handlers entry and exit, scheduler entry and exit, spin-lock acquiring and freeing, context switches, interrupts disabling and enabling. It is possible to attach an arbitrary 32-bit value to each event record. The current value of instruction pointer is also logged with each event.

Events are grouped into classes. It is possible to select logging of events of any combination of different classes during runtime.

Events are logged in circular buffers located in shared memory, where a user-space program can collect and store in disk. This logging mechanism causes a minimal interference.

The development tools are the same than the used to develop the Linux kernel: GCC, binutils, make, etc.

It is possible to do cross development (host-target) and stand alone development, that is, use the same computer to compile and run/test the embedded system.

The main programming language is "C". But it is also possible to use C++.

Ted Baker reported a preliminary porting of the ADA language to the RTLinux system.

POSIX 1003.13/PSE51-compatible.

i386, MIPS, PPC, ARM, m68k-nommu.

Yes. It is available for i386 architectures.

There are two scheduling policies available: RT_SCHED_FIFO and RT_SCHED_RR.

Function rt_set_sched_policy(RT_TASK *task, int policy, int rr_quantum_ns) is used to set the priority and the round robin quantum.

The system provides special system calls to implement periodic threads: rt_task_make_periodic() and rt_task_wait_period()

Minimum and maximum priority is 0x3fffFfff and 0 respectively. Which is the opposite way as how POSIX define priorities, that is, in POSIX the higher the priority, the higher the priority.

The number of active tasks is only limited by the amount of memory available.

rt_task_init() and rt_task_delete functions are used to create and destroy tasks. If task task was waiting on a queue, i.e. semaphore, mailbox, etc, it is removed from such a queue and messaging tasks pending on its message queue are unblocked with an error return.

Although RTAI is designed to run in processors with MMU, all the application tasks and the RTAI kernel run in the same address space. There is no memory protection between tasks and the RTAI kernel and also between threads themselves.

From the point of view of memory management, RTAI is the guest operating system of the Linux Kernel. The Linux kernel has the whole control of the memory.

The module rt_mem_mgr provides the functions rt_malloc() rt_free().

Some amount of memory is pre-allocated then the module in inserted, and real time tasks can allocate and free memory from this pool while executing in RTAI environment.

Two different and incompatible semaphore facilities are implemented in RTAI: RTAI-SEMAPHORES, FIFO-SEMAPHORES.

• RTAI-SEMAPHORES: The following functions are available: rt_typed_sem_init(), rt_sem_init(), rt_sem_delete(), rt_sem_signal(), rt_sem_wait(), rt_sem_wait_if(), rt_sem_wait_until(), rt_sem_wait_timed().

  A semaphore of the kind can operate in one of the three following modes (types): CNT_SEM for counting semaphores, BIN_SEM for binary semaphores, RES_SEM for resource semaphores. Counting semaphores can register up to 0xFFFE events. Binary semaphores do not count signalled events, their count will never exceed 1 whatever number of events is signalled to them.Resource semaphores are special binary semaphores suitable for managing resources. The task that acquires a resource semaphore becomes its owner. The owner has its priority increased to that of any task blocking on a wait to the semaphore. Resource semaphores can be recursed.

• FIFO-SEMAPHORES: FIFO semaphore's API: rtf_sem_init(), rtf_sem_destroy(), rtf_sem_post(), rtf_sem_trywait(), rtf_sem_timed_wait().

  One of the first RTLinux and RTAI communication mechanism has an intrinsic synchronization capability, and that feature is the one used to implement this kind of semaphores. Also, current implementation of FIFO's is based of mailboxes.

RTAI supports the POSIX pthread_mutex_ family of functions in the POSIX compatibility module: pthread_mutex_init(), pthread_mutex_destroy(), pthread_mutex_lock(), pthread_mutex_trylock() and pthread_mutex_unlock(). As well as all the supporting, pthread_mutexattr_... like, functions to handle mutex creation attributes.

The supported mutex types are:

• PTHREAD_MUTEX_FAST_NP: The default POSIX mutex.

• PTHREAD_MUTEX_RECURSIVE_NP: This type of semaphore can be locked more then one time without causing a self task deadlock.

• PTHREAD_MUTEX_ERRORCHECK_NP: Detects and reports simple usage errors.

Jointly with the mutex the module also implements POSIX Conditional Variables.

Mutex provide immediate priority inheritance.

Provides four different (incompatible) intertask messages facilities:

• Message queues compatible with POSIX 1003.b queues. The functionality is provided by the POSIX compatibility module. The API is: mq_open(), mq_send(), etc.

• Small (4 bytes) synchronous messages. Messages can be priority ordered (determined by the compile time option MSG_PRIORD). Also there are timed sending and receiving primitives. The API is: rt_send(), rt_send_until(), rt_receive(), etc.

• Extended intertask messaging. Allows to use intertaks messages of any size. The API is: rt_sendx(), rt_sendx_until(), rt_receivex(), etc.

• Remote Procedure Calls (these RPC has no has nothing in common then the well know inter-host RPC, like Sun Microsystems™ RPC) do the same thing that synchronous messages but the tasks are coupled awaiting a reply from the receiver. RPCs operate like complementary, send and receive message pairs. The API is: rt_rpc(), rt_rpc_if(), rt_return(), etc.

RTAI provides mailboxes. Messages are ordered in FIFO order. Different size messages of are allowed. Multiple senders and receivers can read and write messages to the same mailbox.

There are several sending an receiving functions that provides a lot of flexibility (receiving functions are omitted of the following list for the sake of clarity):

• rt_mbx_send(): Blocking send of the whole message.

• rt_mbx_send_wp(): Send as many bytes as possible, without blocking the calling task.

• rt_mbx_send_if(): Send a message, only if the whole message can be passed without blocking the calling task.

• rt_mbx_send_until(), rt_mbx_send_timed: Send a message with timeout.

Shared memory is provided with a non-POSIX interface called shmem. Since all threads are executed in the kernel address space (rtlinux threads share by default all the memory), this sharing memory mechanism is used to communicate RTAI threads and normal linux processes.

Although the API is no the same, it is quiet similar to the SYSTEM V shared memory. The first time an area is requested, the system allocates a new chunk of memory; subsequent requests return the pointer to the already allocated memory.

RTAI fifos maintain full compatibility with those available in NMT_RTLinux. They are implemented on top of mailboxes.

Also provides a mechanism to create fifos by name.

Time is stored in a RTIME which is defined as:

struct timespec {
typedef long long RTIME;
};
	      

There is no user timers. There is only one timer handler per hardware timer, which is the associated with the interrupt handler. When the scheduler module is loaded, the scheduler takes the control of the timer and no other thread can use the timer.

The only timing facility that a thread can use being a periodic thread. And the delay functions: rt_busy_sleep(), rt_sleep() and rt_sleep_until(). Some functions use nanoseconds while other work with hardware ticks.

How time has to be used by the programmer is not well documented. The use of hardware ticks is very efficient, but produces different results when the same program runs on different hardware (for example, a i486 computer use the old 8254 clock while a Pentium has a builtin timer which provides a highest resolution clock).

The Watchdog module provide services to protect tasks (and the host Linux OS) against programming errors in RTAI applications. The watchdog can be programmed to perform several action on the occurrence of a task overrun.

RTAI defines two types of interrupts: Soft and Hard Interrupts.

Hard Interrupts the one originated directly by the real hardware. There is very little system interference in the service of these interrupts, therefore the interrupt latency is almost only limited by the performance of the underlying hardware. Since these handlers are executed at the RTAI level, it is not possible to call linux services. Interrupt handlers are installed and uninstalled with rt_request_global_irq() and rt_free_global_irq() functions.

It is possible to install interrupt handlers that will be executed as a normal Linux interrupt service routines. This is a powerful mechanism to execute code in Linux space, that can be triggered just sending a software interrupt from RTAI with the function rt_pend_linux_irq.

Since RTAI threads are executed in kernel address space and processor mode, it is possible to use all the reserved processor instructions directly. To direct access io ports in ISA bus: rtl_inb, rtl_inb_p, and the outb counterparts. To access physical memory (devices located at the PCI bus) it is possible to use ioremap()[6] function at thread initialization and then access the device through the returned pointer.

Source level debugging using Kgdb+Kmod which is a modified version of kgdb/gdbstubs which provides improved kernel module debug support including real-time modules. The target is debugged from a host by mean of serial cable which connects both machines.

An optional tracer module (Linux Trace Toolkit, LTT) can be included in the system. The tracer will register all the relevant system events and user-defined ones. LTT has also a graphical tool to visualize the logged events.

LTT provides developers with all of the information necessary to reconstruct a system's behavior over a certain period of time. Using LTT, one can graphically view the exact the dynamics of a system and find logical and temporal bugs of the system or the application.

The development tools are the same than the used to develop the Linux kernel: GCC, binutils, make, etc.

It is possible to do cross development (host-target) and stand alone development, that is, use the same computer to compile and run/test the embedded system.

The main programming language is "C". But it is also possible to use C++.

The original API do not adhere to any standard, but it has module which provides some compatibility with POSIX: mutex, conditional variables, message queues and POSIX threads.

The higest priority periodic task that protects the systems against tasks errors. Available policies:

• Nothing.

• Resynchronise the task's frame.

• Debug.

• Stretch the period of the offending task.

• Slip the offending task by forcibly suspending it for a percentage of its period.

• Suspend the offending task.

• Kill the offending task and remove all trace of it.

The Real-Time Workshop (RTW) is a tool that produces C-code or target specific code directly from a Simulink model for a variety of environnements, including real- time systems.

Motorola MC68xxx, MC683xx and ColdFire; Hitachi SH, Intel i386 and i960; MIPS; PowerPC; SPARC; AMD A29K; Hewlett-Packard PA-RISC .

Most of processors targets can be used in multiprocessor environment, but tasks do not migrate between CPUs. They are strictly bind to predefined CPU.

• Event-driven, priority-based, preemptive scheduling

• Optional rate monotonic scheduling

RTEMS do not provide any special API call to schedule peritodic threads.

• 255 executive kernel priority levels (1 the highest till 255 the lowest)

  POSIX API defines its own priority range from 1 to 254 (1 the lowest and 254 the highest)

• Maximal number of threads can be defined for each application and configurable maximum depends on amount of available memory.

Threads can be created dynamically.

Controlled thread deletion?. Yes

Not supported.

malloc() and free() functions - yes

Variable size memory chunks allocation? yes

Based on Region Manager concept.

POSIX binary, counting, with/without timeout, named/unnamed

Creation and destruction of unnamed semaphores: sem_init() and sem_destroy()

Opening/creation and closing of named semaphores: sem_open() and sem_close(). An unused named semaphore can be deleted by sem_unlink().

Function sem_wait() attempts to lock a semaphore, If the semaphore is unavailable (value is zero) blocks until the semaphore becomes available. There is nonblocking version sem_trywait() and version with timeout sem_timedwait().

Function sem_post() unlocks the semaphore and function sem_getvalue() enables to retrieve actual value of the semaphore.

Similar set of basic POSIX API functions exists as for semaphores. There are classic API functions as well.

Basic functions: pthread_mutex_init(), pthread_mutex_destroy(), pthread_mutex_lock(), pthread_mutex_trylock(), pthread_mutex_timedlock() and pthread_mutex_unlock().

Next functions are used to manipulate with mutex attributes: pthread_mutexattr_init(), pthread_mutexattr_destroy(), pthread_mutexattr_setprotocol(), pthread_mutexattr_getprotocol(), pthread_mutexattr_setprioceiling(), pthread_mutexattr_getprioceiling(), pthread_mutexattr_setpshared() and pthread_mutexattr_getpshared().

The following ordering protocols for waiting threads can be specified:

• PTHREAD_PRIO_NONE: blocking order FIFO.

• PTHREAD_PRIO_INHERIT: blocking order priority with the priority inheritance protocol in effect.

• PTHREAD_PRIO_PROTECT: blocking order priority with the priority ceiling protocol in effect.

Possible to activate priority inheritance or priority ceiling protocol.

RTEMS implements POSIX conditional variables in Condition Variable Manager.

The following functions are responsible of conditional variables creation, destruction and manipulation: pthread_cond_init(), pthread_cond_destroy(), pthread_cond_signal(), pthread_cond_broadcast(), pthread_cond_wait() and pthread_cond_timedwait().

The shared attribute can be defined and read by corresponding attribute functions.

FIFO or task priority wakeup order, LIFO urgent messages support, with timeout, fixed depth and max message size.

Message Passing Manager implements next POSIX functions: mq_open(), mq_close(), mq_unlink(), mq_send(), mq_receive(), mq_notify(), mq_setattr() and mq_getattr().

In development.

Implemented only for ITRON API.

No special directives.

Standard and POSIX signals with timeout. Signals are numbered from 1 to 32.

There are standard functions for sending of signal to process (whole application) kill() and sigqueue() with value and queuing capability. The thread specific version exists as well pthread_kill(). Signals can be masked on process sigprocmask() or thread basis pthread_sigmask().

There are defined standard functions for signal mask manipulation sigaddset(), sigdelset(), sigfillset(), sigismember() and sigemptyset(). Required reaction on unmasked pending signal or received signal is defined by function sigaction().

More functions for waiting, examination of pending signals and combined mask manipulation and waiting are defined pause(), sigpending(), sigsuspend(), sigwait(), sigwaitinfo() and sigtimedwait().

Alarm signal after specified number of seconds can be scheduled by alarm() function.

Native RTEMS API for 32 events.

An event flag is used by a task/thread (or ISR) to inform another task of the occurrence of a significant situation. Thirty-two event flags are associated with each task. A collection of one or more event flags is referred to as an event set. The data type rtems_event_set is used to manage event sets.

Tick timer resolution depends and can be set on BSP level.

Clock Manager provides functions for examining clock resolution clock_getres(), setting and getting real time clock_gettime() and clock_settime(). Execution delay functions sleep() and nanosleep(). Functions gettimeofday() and time() reads actual calendar time.

Next POSIX API functions are provided by Timer Manager. Per-process (application) timers can be created and deleted by functions timer_create() and timer_delete(). Timer expiration time can be set and examined by timer_settime() and timer_gettime(). Number of overrun counts can be check by function timer_getoverrun().

There are many other time related functions provided through different manages as well: alarm(), sleep(), nanosleep(), sigtimedwait(), pthread_cond_timedwait(), etc.

N/A

Interrupts are not converted to signals or other asynchronous events. They are handled by any C routine which was connected to the given interrupt vector. An interrupt handler can be established by any normal thread, kernel driver is not needed.

Functions to manage interrupt handlers are system specific and that is why only classic API is available.

Drivers are written as regular POSIX or RTEMS threads. Only ISR notification function is special case, which should transfer/invoke processing to regular threads.

• High performance port of FreeBSD TCP/IP stack

• UDP, TCP

• ICMP, DHCP, RARP

• TFTP

• RPC

• FTPD

• HTTPD

• CORBA

• RTEID/ORKID based Classic API.

• uITRON 3.0 API in development.

• ADA language API for RT systems.

• POSIX 1003.1b API including threads.

  The implementation status can be sketched by one section from reported compliance summary which shows next numbers for 362 POSIX 1003.1b functions defined by standard.

  • Implemented : 301

  • Unimplemented : 21

  • Unimplementable : 16

  • Partial : 2

  • Dummy : 19

  • Untested : 1

  Following is a list of the most important lacking functionalities of current version of RTEMS executive.

  • The current implementation of dup() is insufficient.

  • FIFOs mkfifo() are not currently implemented.

  • Asynchronous IO is not implemented.

  • The flockfile() family is not implemented

  • getc/putc unlocked family is not implemented

  • Shared Memory is not implemented

The QNX microkernel, known as Neutrino, is an implementation of the core POSIX together with the fundamental message passing services. The POSIX features that are not implemented in the microkernel are provided by optional processes and shared libraries.

Neutrino provides a few fundamental services:

• Thread services: Neutrino provides the POSIX thread creation primitives.

• Signal services: Neutrino provides the POSIX signal primitives.

• Message passing services: Neutrino handles the routing of all messages between all threads through the whole system.

• Synchronization services: Neutrino provides the POSIX thread synchronization primitives.

• Scheduling services: Neutrino schedules threads using the various POSIX realtime scheduling algorithms.

• Timers services: Neutrino provides the set of POSIX timer.

The process manager is capable of creating multiple POSIX processes (each of which may contain multiples POSIX threads). Its main areas of responsability include:

• Process management: It manages process creation, destruction, and process attributes such us user ID and group ID.

• Memory management: It manages memory protection, shared libraries, and POSIX shared memory primitives.

• Pathname management: It manages the pathname space (mountpoints).

When several threads run concurrently, as in typical realtime multitasking environments, the operating system must provide mechanisms to allow them to communicate with each other. This mechanism, called Interprocess Comunication, uses a message passing as its fundamental principle.

Message passing not only allows processes to pass data to each other, but also provides a mechanism to sinchronize the execution of several processes.

The processors families x86, ARM, MIPS, PowerPC and SH-4 are supported by QNX.

QNX is available for x86 (any Intel multi processor specification) and PowerPC (600 or 700 series) multi processor architectures.

QNX realizes the POSIX processes creation and destruction, basically, using these POSIX functions: spawn(), fork() and exec().

Moreover, QNX provides other non-POSIX functions. These primitives are: spawnl(), spawnle(), spawnlp(), spawnlpe(), spawnp(), spawnv(), spawnve(), spawnvp(), spawnvpe(), execlpe() and execvpe().

The QNX microkernel provides the following scheduling algorithms:

• FIFO scheduling:

• Round-Robin scheduling:

• Adaptive scheduling: A thread behaves as follows:

  • If the thread consumes its timeslice, its priority is reduced by 1. Note that it will only drop one level below its original priority.

  • If the threads blocks, it inmediately comes back to its original priority.

• Sporadic scheduling: Essentially, this algorithm allows a thread to service aperiodic events without exposing the hard deadlines of other threads or processes in the system.

QNX does not provide functions to implement directly periodic threads. Therefore, it is necessary to use timers calls to perform this functioning. Moreover, using timers, the following notification types may be used: signal, pulses and thread creation.

Each thread can have a range of priorities from 0 to 31 (the highest priority), independently of the scheduling policy. The special idle thread (in the process manager) has priority 0 and is always ready to run. Moreover, a thread have a real priority and a effective priority, and it is scheduled in accordance with its effective priority.

There is no limit thread creation in the same process, except the memory space, of course.

QNX provides a full-POSIX API for managing the thread creation and deletion. The following table shows these functions as well as the microkernel primitives used by these routines:

Neutrino offers complete memory protection for user applications and for operating system components (device drivers, filesystems, etc.).

Moreover, QNX reaches the complex POSIX process model in a protected environment using a MMU (Memory Management Unit) mechanism. This protection is useful both for development and for the runtime system.

In conclusion, QNX provides a microkernel architecture with full memory protection between each operating system components such as filesystem, TCP/IP, Qnet and so on. Therefore each process is a address space separated and protected against the rest of components.

QNX provides dynamically request memory allocation using the malloc(), realloc() or calloc() functions, and provides the free() function to release memory allocation.

QNX provides the full-POSIX semaphores calls. Therefore, both named and unamed semaphores are provided.

The following table list the primitives available on QNX for managing the semaphores, as well as, the microkernel calls used by these routines:

QNX provides the full POSIX mutexes calls where each of them, are associated with a microkernel call. The following table shows these routines:

The following mutex types are supported by QNX: PTHREAD_MUTEX_NORMAL,PTHREAD_MUTEX_ERRORCHECK, PTHREAD_MUTEX_RECURSIVE and PTHREAD_MUTEX_DEFAULT. Note that QNX supports the full POSIX mutex types.

Currently, there is only one POSIX mutex protocol available in QNX: the PTHREAD_PRIO_INHERIT protocol. Therefore, PTHREAD_PRIO_PROTECT protocol is not supported.

Finally, it is important to note how the classic priority inversion problem is solved: If a thread with a higher priority than the mutex owner tries to lock a mutex, then the effective priority of the current owner will be increased to that of the higher priority blocked thread waiting for mutex. The owner will returns to its real priority when it unlocks the mutex. This scheme is called priority inheritance.

This service consists of that the attribute of the mutex can be modified (using PTHREAD_MUTEX_RECURSIVE type) to allow a mutex to be recursively locked by the same thread. So, QNX provides this POSIX functioning.

As described earlier, the priority inversion control problem is solved using inmediate priority inheritance.

In the same way as semaphores and mutexes, QNX provides full POSIX condition variable functions as well as the microkernel calls that are used by these routines. These functions are: pthread_cond_init(), pthread_cond_destroy(), pthread_cond_wait(), pthread_cond_signal() and pthread_cond_broadcast().

QNX provides full POSIX reader/writers functions. Now these functions are listed: pthread_rwlock_rdlock(), pthread_rwlock_wrlock(), pthread_rwlock_unlock(), pthread_rwlock_tryrdlock(), pthread_rwlock_trywrlock().

It is important to note that Reader/writer locks are not implemented directly within the kernel and have not associated a microkernel call either, but are built from the mutex and condvar services provided by the kernel.

QNX provides full POSIX barriers functions. Those functions are: pthread_barrier_init(), pthread_barrier_wait(), pthread_barrier_destroy() and pthread_barrierattr_* family.

This type of synchronization consist of selecting the POSIX FIFO scheduling algorithm. In this way, we can guarantee that two threads of the same priority don't execute the critical section concurrently.

Note that this feature is not accomplished on SMP systems.

This synchronization mechanism allows to perform a short operation with the guarantee that the operation will performing atomically. The most important atomic operations that Neutrino provides are:

QNX provides the message passing mechanism as the main form of IPC in QNX and Neutrino. Although other forms are available, those options are built over its native IPC.

The following illustration shows the state changes in a send-receive transaction.

As shown in figure, a thread that does a MsgSend() to another thread or process will be blocked until the receiving thread does a MsgReceive(), processes the message, and executes a MsgReply(). If a thread executes a MsgReceive() without a previously sent message pending, it will block until another thread executes a MsgSend(). Therefore, while the send and receive operations are blocked and synchronous, MsgReply() and MsgError() don't block and furthermore, unlock the client from MsgSend().

The following table lists the message passing API provided by QNX:

Moreover, QNX provides other message passing functions and mechanism that are based on the API defined above. This mechanism are: Multipart Transfers, Channels and Pulses.

QNX support POSIX signals, realtime signals and traditional UNIX signals. Moreover, Neutrino provides eight special signals. Therefore, a total of 64 signals have been defined. The following table resumes these signals range:

To uses pipes in QNX, the pipe resource manager, called pipe must be loaded.

This POSIX comunication mechanism are available on QNX using the symbol | to create a pipe from shell and the pipe() or popen() functions to create a pipe from programs.

As well as pipes, for using FIFOs in QNX, the resource manager pipe must be loaded.

To manage FIFOs, QNX provides the following utilities: the mkfifo and rm command to create/delete FIFOs from shell, and the mkfifo(), remove() and unlink() functions to create/delete FIFOs from programs.

QNX provides a full POSIX message queue API. To use this synchronous mechanism in Neutrino, the message queue resouce manager called mqueue must be loaded.

There is a fundamental different between QNX messages and POSIX messages queue: while QNX messages block and copy data directly from the address spaces of the process sending to the address space of process receiving, POSIX message queue, on the other hand, do not block and may have pending messages queued.

In Neutrino microkernel, all mesages queues created will appear in the filename space under the directory /dev/mqueue.

Full POSIX shared memory is implemented in Neutrino via the process manager called procnto. The following functions are implemented as messages to procnto: shm_open(), close(), mmap(), mummap(), mprotect(), msync(), shm_ctl() and shm_unlink().

Neutrino provides the full set of POSIX clock functionality. Therefore, time may be measured in nanosecond, as well as, in second.

Moreover, QNX also provides several non POSIX clock functions: ClockAdjust() and ClockCycle().

The posible clock types are:

• CLOCK_MONOTONIC: This POSIX clock always increase at a constant rate and can not be adjusted.

• CLOCK_SOFTTIME: The same as CLOCK_REALTIME, but if the CPU is in powerdown mode, the clock stop running.

• CLOCK_REALTIME: A clock that mantains a ystem time.

It is importan to know that valid dates on a QNX system range from January 1970 to January 2554, and note that POSIX may be limited to the year 2038.

Neutrino provides the following interrupt handling API:

Using this API, a privileged thread (in user level) can call InterruptAttach() or InterruptAttachEvent(), passing a hardware interrupt number and the address of a function in the thread's address space to be called when the interrupt occurs. QNX allows multiple ISRs to be attached to each hardware interrupt number.

To access a PCI devices, QNX provides a well defined API. Some of these functions are: pci_map_irq() for mapping a interrupt pin to an IRQ, pci_find_device() to find the PCI device with a given ID and vendor ID, and so on.

In conclusion, QNX provides a lot of APIs to manage low level hardware features.

QNX provides an implementation of the TCP/IP stack (npm-tcpip) relatively light, modular and using the common BSD Socket API (this API is the standar API for TCP/IP programing in the UNIX world). This implemenattion provides an NFS server/client, multicasting, support for IPsec security, IPv6, and so on.

Qnet is the QNX native networking protocol that extends the operating system message passing interprocess comunication (IPC) transparently through a networks of microkernels.

To understand how this protocol works, consider the case of a simple network with two nodes; one of them contains the client process, and the other one contains the server process. The client process creates a connection to the server, using the ConnectAttach() function call and then sends its messages using the MsgSend() function call (this network case works in the same way that in the single node case).

It is important to note that the POSIX calls such as open(), read(), write(), etc can be used too.

The utility GBD can be used for debugging C and C++ programs.

When a program uses dynamic memory allocation, it is posible introduce memory leaks. Therefore, to determine whether the heap was corrupted, the malloc debug library is available in QNX. This library provides several checking by default: allocation memory, reallocating memory and releasing memory. Moreover, the mallopt() function allows optional checks: MALLOC_CKACCESS to detect buffer overruns and underruns as a result of string operations, MALLOC_FILLAREA to detect overruns as a result of user request size, MALLOC_CKCHAIN and MALLOC_VERIFY.

Furthermore, is important to note that when the library detects a problem, a message error is generated and the program is aborted. This behavior can be change specifying a handler that determines what is done when a warning o faltal error is detected.

Finally, this library provides the malloc_dump_unreferenced() function to trace and giving results. This function suspends all threads, performs the trace operation and prints messages of all memory leaks detected.

Other tracing mechanism utility called procnto-instr is provided by QNX. This module allows monitor the system execution in real time. Moreover, the TraceEvent() call can be used to generate custom events into the trace stream.

The propietary environment built by QNX Software Systems is called Photon MicroGUI.

QNX provides the Qcc and qcc compilers. They are based on the POSIX c86 utility. By default Qcc considers a C++ program while qcc considers a C program.

It is important to know that QNX provides a command that allows to built a scaled embedded systems. This utility is named mkifs.

It is possible to do cross development (host-target) and stand alone development, that is, use the same computer to compile and run/test the embedded system.

The main programming languages are C and C++.

Moreover, QNX provides the Visual Age Micro-Edition environment to develop programs written using the java languaje.

Finally, QNX provides a tool called the Photon Application Builder (abbreviated as PhAB or AppBuilder). It's a visual tool to develop user's interface. The code generated by this tool is C and C++.

POSIX 1003.1.

Motorola 68k/CPU32/ColdFire/PowerPC, Intel x86, Intel ARM/StrongARM, Hitachi SuperH, MIPS

Multiprocessor systems are supported with optional package VxMP.

There are only two scheduling policies available. Default is preemptive priority scheduling, it can be changed to Round-Robin scheduling. User can switch between these two polities during runtime.

There are no means to handle periodic threads. It is neccessary for an application to use standard timers.

There are 256 priority levels in range 0 - 255, 0 is the highest priority. Number of threads limited only by amount of available memory etc.

Threads can be created dynamically by calling TaskSpawn() function.

There is no any protection between user and system space and among different processes in basic VxWorks OS. All processes have unlimited access into whole memory space. Memory protection is available as optional package (VxVMI).

Full support using standard functions malloc(),calloc(),realloc() and free().

Binary, counting, mutex, with timeout.

Semphore creation and deletion is performed by calling semBCreate() (binary), semCCreate() (counting), semMCreate() (mutex) and semClose() functions.

Function semTake() attempts to take a semaphore. If the semaphore is not available, semTake() blocks until semaphore becomes available.Duration of blocking depends on parameter timeout which can be WAIT_FOREVER, WAIT_NOWAIT or any nonzero value which specifies timeout.When timeout is WAIT_NOWAIT, semTake() becomes nonblocking.

Mutex semaphore implements priority inheritance algorithm and provides means disabling task deletion while this task owns such semaphore. These features can be switched on during semaphore creation by parameters SEM_INVERSION_SAFE and SEM_DELETE_SAFE.

Possible with mutex semaphores.

Synchronous, prioritized messages, with timeout, fixed depth and max message size. Depth and maximal message length is specified durinq queue creation and it can't be changed later. Wind API provides functions msgQCreate() for queue creation, msgQSend() for sending a message and msgQRcvd() for receiving a message.

none

No special means because there are no memory protection between tasks. For multiprocessor systems optional package VxMP.

The wind kernel supports two types of signal interface: UNIX BSD-style signals and POSIX-compatible signals. The POSIX-compatible signal interface, in turn, includes both the fundamental signaling interface specified in the POSIX standard 1003.1, and the queued-signals extension from POSIX 1003.1b.

The signal facility provides a set of 31 distinct signals. A signal can be raised by calling kill(). A signal handler is bound to a particular signal with sigaction(). Signals are blocked for the duration of the signal handler. Tasks can block the occurrence of certain signals with sigprocmask(). If a signal is blocked when it is raised, its handler routine will be called when the signal becomes unblocked.

Configurable tick timer resolution, based on system clock. Limited by HW capabilities and kernel configuration, default system clock is 60Hz. As an example, on standard PC machine with Celeron 566MHz processor and kernel configured with TCP/IP stack, full debug support and asynchronous I/O support it is capable of up to cca 8kHz.

N/A

Interrupts are not converted to signals or other asynchronous events. They are handled by any C routine which was connected to given interrupt vector by function IntConnect. An interrupt can be handled by application thread, kernel driver is not needed. All interrupt handlers use one common special stack which is prepared by the system during the start-up.

When a task causes a hardware exception such as illegal instruction or bus error, the task is suspended and the rest of the system continues uninterrupted. However, when an ISR causes such an exception, there is no safe recourse for the system to handle the exception. The ISR has no context that can be suspended. Instead, VxWorks stores the description of the exception in a special location in low memory and executes a system restart.

A large variety of processors are supported. Among them the most important are :

• Motorola: PowerPC (PPC 601, 603, 604), PowerPC G3 (PPC 75x), PowerPC G4 (PPC 7400,7410,74xx) with Altivec Support, PowerPC IBM 405,440.

• Intel: x86(IA-32) Architecture (and compatible).

• MIPS

• Xscale

• ARM9

Conventional UNIX® protections exist between application threads of different processes. Threads of a process share the virtual address space of that process (excellent for IPC and I/O). Application threads execute in the address space of a conventional process, kernel threads execute in the kernel's address space.

LynxOS® exploits very well hardware MMU from the processor MMU, so that each process has it's own virtual memory space perfectly protected. This is important to guaranty QoS and to built robust systems. Moreover paged style MMU eliminates system wide memory fragmentation.

Kernel data structures are protected thanks to user/kernel mode as in Linux. User processes "trap" into the kernel to execute system calls. Kernel/user mode is supported directly by microprocessor privilege levels. User processes are limited in memory regions they can access and instructions they can execute. Kernel can acces all memory regions.

Kernel threads minimize the time spent in H/W context

malloc() and free() functions are available.

Provides POSIX semaphores (counting semaphores).

Standard POSIX mutexes and condition variables.

No priority inversion but specific inheritance mechanism called priority tracking (see driver section).

Simple inheritance, immediate ceiling, etc.

Priority inheritance is implemented via binary semaphores. When a high priority task wants a resource held by a lower priority task, the lower priority task's priority is boosted to that of the higher priority task until the resource is released. This mechanism is used in the LynxOS® kernel and is available to applications and drivers.

The default protocol attribute of pthread_mutextattrr_t is PTHREAD_PRIO_INHERIT so the prioceiling attribute is irrelevant.

yes

Synchronous or/and Asynchronous, prioritized messages, etc.

yes.

Them mmap() support for regular files and shared memory.

Users can configure ticks per second for real-time clocks. The define TICKSPERSEC in the /usr/include/conf.h file defaults to 100 ticks per second (which leads to 10ms between ticks).

Recommended minimum and maximum ticks per second are 20 (50 ms between ticks) and 500 (2ms between ticks).These numbers can vary depending on a systems hardware limitations.

It is possible to add hardware timers, they are handled by specific drivers interfaced with the POSIX timer.