Basic Rules of Real-time Applications

You can get real-time response when certain conditions are met. This section identifies these conditions and some of the more significant design errors.

Most of the potential problems described here can degrade the response time of the system. One of the potential problems can freeze a workstation. Other, more subtle, mistakes are priority inversion and system overload.

An Oracle Solaris real-time process has the following characteristics:

• Runs in the RT scheduling class, as described in Real-Time Scheduler

• Locks down all the memory in its process address space, as described in Memory Locking

• Is from a program in which all dynamic binding is completed early, as described in Shared Libraries

Real-time operations are described in this chapter in terms of single-threaded processes, but the description can also apply to multithreaded processes. For more information about multithreaded processes, see Multithreaded Programming Guide. To ensure real-time scheduling of a thread, the thread must be created as a bound thread. The thread's LWP must be run in the RT scheduling class. The locking of memory and early dynamic binding is effective for all threads in a process.

When a real-time process has the highest priority, the process acquires the processor within the specified dispatch latency period of becoming runnable. For more information, see Dispatch Latency. The process continues to run as long as it is the highest priority runnable process.

A real-time process can lose control and can also be unable to gain control of the processor because of other system events. These events include external events, such as interrupts, resource starvation, waiting on external events such as synchronous I/O, and preemption by a higher priority process.

Real-time scheduling does not apply to system initialization and termination services such as open() and close(). For more information, see the open(2) and close(2) man pages.