Real-time response is guaranteed 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 The 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 detailed information about multithreaded processes, see the Multithreaded Programming Guide . To guarantee real-time scheduling of a thread, the thread must be created as a bound thread. Furthermore, 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 process is the highest priority real-time process, the process acquires the processor within the guaranteed dispatch latency period of becoming runnable. For more information, see Dispatch Latency. The process continues to run for as long as it remains the highest priority runnable process.
A real-time process can lose control of the processor because of other system events. A real-time process 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 generally does not apply to system initialization and termination services such as open(2) and close(2).