WP1 - RTOS State of the Art Analysis: Deliverable D1.1 - RTOS Analysis
Prev	Chapter 9. RTAI	Next

Inter-Process communication

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.

Priority inversion control

Mutex provide immediate priority inheritance.

Messages queues

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

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.

Prev	Home	Next
Memory management	Up	Time and timers