Programming with POSIX® Threads

cry.

'You wo'n't make yourself a bit realler by crying,' Tweedledee remarked: 'there's nothing to cry about.'

— Lewis Carroll, Through the Looking-Glass

Once upon a time, realtime programming was considered an arcane and rare art. Realtime programmers were doing unusual things, outside of the programming mainstream, like controlling nuclear reactors or airplane navigational systems. But the POSIX. lb realtime extension defines realtime as 'the ability of the operating system to provide a required level of service in a bounded response time.' What applies to the operating system also applies to your application or library.

'Bounded' response time does not necessarily mean 'fast' response, but it does mean 'predictable' response. There must be some way to define a span of time during which a sequence of operations is guaranteed to complete. A system controlling a nuclear reactor has more strict response requirements than most programs you will write, and certainly the consequences of failing to meet the reactor's response requirements are more severe. But a lot of code you write will need to provide some 'required level of service' within some 'bounded response time.' Realtime programming just means that the software lives in the real world.

Realtime programming covers such a vast area that it is common to divide it into two separate categories. 'Hard realtime' is the traditional sort most people

think of. When your nuclear reactor will go critical if a fuel rod adjustment is delayed by a microsecond or your airplane will crash if the navigation system takes a half second to respond to a wind sheer, that's hard realtime. Hard realtime is unforgiving, because the required level of service and bounded response time are defined by physics or something equally unyielding. 'Soft realtime' means that you need to meet your schedule most of the time, but the consequences of failing to meet the schedule are not severe.

Many systems that interact with humans should be designed according to soft realtime principles. Although humans react slowly, in computer terms, they're sensitive to response time. Make your users wait too often while the screen redraws before accepting the next mouse click, and they'll be annoyed. Nobody likes a 'busy cursor' — most people expect response to be at least predictable, even when it cannot be fast.

Threads are useful for all types of realtime programming, because coding for predictable response is far easier when you can keep the operations separate. Your 'user input function' doesn't have to wait for your sort operation or for your screen update operation because it executes independently.

Achieving predictability requires a lot more than just separating operations into different threads, however. For one thing, you need to make sure that the thread you need to run 'soon' won't be left sitting on a run queue somewhere while another thread uses the processor. Most systems, by default, will try to distribute resources more or less fairly between threads. That's nice for a lot of things — but realtime isn't fair. Realtime means carefully giving precedence to the parts of the program that limit external response time.

5.5.1 POSIX realtime options

The POSIX standards are flexible, because they're designed to be useful in a wide range of environments. In particular, since traditional UNIX systems don't support any form of realtime scheduling control, all of the tools for controlling realtime response are optional. The fact that a given implementation of UNIX 'conforms to 1003.1c- 1995' does not mean you can write predictable realtime programs.

If the system defines _POSIX_THREAD_PRIORITY_SCHEDULING, it provides support for assigning realtime scheduling priorities to threads. The POSIX priority scheduling model is a little more complicated than the traditional UNIX priority model, but the principle is similar. Priority scheduling allows the programmer to give the system an idea of how important any two threads are, relative to each other. Whenever more than one thread is ready to execute, the system will choose the thread with the highest priority.

5.5.2 Scheduling policies and priorities

int sched_get_priority_max (int policy);

int sched_get_priority_min (int policy);

int pthread_attr_getinheritsched (

const pthread_attr_t *attr, int *inheritsched);

int pthread_attr_setinheritsched (

pthread_attr_t *attr, int inheritsched);

int pthread_attr_getschedparam (

constpthread_attr_t *attr,

struct sched_param *param);

int pthread_attr_setschedparam (

pthread_attr_t *attr,

const struct sched_param *param);

int pthread_attr_getschedpolicy (

const pthread_attr_t *attr, int *policy);

int pthread_attr_setschedpolicy (

pthread_attr_t *attr, int policy);

int pthread_getschedparam (pthread_t thread,

int *policy, struct sched_param *param);

int pthread_setschedparam (

pthread_t thread, int policy,

const struct sched_param *param);

A Pthreads system that supports _POSIX_THREAD_PRIORITY_SCHEDULING must provide a definition of the struct sched_param structure that includes at least the member sched_priority. The sched_priority member is the only scheduling parameter used by the standard Pthreads scheduling policies, SCHED_FIFO and SCHED_RR. The minimum and maximum priority values (sched_priority member) that are allowed for each scheduling policy can be determined by calling sched_get_priority_min or sched_get_priority_max, respectively, for the scheduling policy. Pthreads systems that support additional, nonstandard scheduling policies may include additional members.

The SCHED_FIFO (first in, first out) policy allows a thread to run until another thread with a higher priority becomes ready, or until it blocks voluntarily. When a thread with SCHED_FIFO scheduling policy becomes ready, it begins executing immediately unless a thread with equal or higher priority is already executing.

The SCHED_RR (round-robin) policy is much the same, except that if a thread with SCHED_RR policy executes for more than a fixed period of time (the timeslice interval) without blocking, and another thread with SCHED_RR or SCHED_FIFO policy and the same priority is ready, the running thread will be preempted so the ready thread can be executed.

When threads with SCHED_FIFO or SCHED_RR policy wait on a condition variable or wait to lock a mutex, they will be awakened in priority order. That is, if a low-priority SCHED_FIFO thread and a high-priority SCHED_FIFO thread are both waiting to lock the same mutex, the high-priority thread will always be unblocked first when the mutex is unlocked.

Pthreads defines the name of an additional scheduling policy, called SCHED_OTHER. Pthreads, however, says nothing at all regarding what this scheduling policy does. This is an illustration of an unofficial POSIX philosophy that