OS Platforms for RTSJ
Version One
Peter Dibble and En-Kuang Lung
May 2005
This document is not intended to be a specification for operating systems that support the RTSJ. Some of the OS attributes here are nearly critical, many of them improve the quality of the RTSJ implementation (or any other real-time application) running on them, and some of them just make the RTSJ implementors? job easier.
At one level an RTSJ implementation can be written for any OS, or it can run on the bare hardware. ?All you do is just? use the OS as a boot loader, and when the JVM runs have it take over all scheduling-related activities—unless the OS is remarkably modular this would mean replacing much of the operating system.
A less-demanding version of the above approach has already been used for regular JVMs. When thread support from the OS does not match the requirements of the JVM, implementers have routinely used thread support implemented entirely in library code. RTSJ's requirements extend into many system calls, so it would require much more than a threading library.
Practically speaking, the RTSJ requires the following from its underlying OS:
? At least 28 carefully-scheduled FIFO priority levels closely corresponding to POSIX FIFO scheduling. This is a fairly detailed description of scheduling behavior.
? The application assigned thread priority must be fixed throughout the application lifetime. The threads? relative OS priority should not be adjusted dynamically by the OS.
? At least one priority lower than the 28 real-time priorities, and preferably at least 10 such priorities to use for regular Java priorities
? Additional FIFO priority levels beyond the minimum of 28 that are exposed to the application are probably required for the JVM implementation.
? Priority inheritance (POSIX Prio-Protect) support for mutex locks in the JVM
? Priority inheritance must be used for all locks that are held by the OS for an unbounded time, and preferably for any lock that can be held for more than a few instructions. (Which implies that the OS has to use mutex locks whenever they are appropriate .)
OS queues should be FIFO within priority. Priority queues are not commonly used away from the scheduler because they are less efficient that LIFO queues, and this characteristic is hard to test, but it can make a difference in response time in a heavily-loaded system.
The RTSJ cost enforcement option needs OS support. The support might be just flexible enough to insert cost monitoring code in the dispatcher, but a more likely form of support would be an accessible per-thread consumed CPU time value and the ability to construct timers based on consumed CPU time.
If the application wants processing groups, it would be nice to see support for this in the OS.
The ATC facility of the RTSJ does not like to see control go into the operating system and get stuck in there for an unbounded time. Picture a file-open request that blocks waiting for a removable disk to be mounted. If the waiting thread gets an AIE, it could wait in that call for hours before control gets back to where the JVM can do something.
If the OS permits such calls to be interrupted, e.g. by a signal, the JVM can recover control and deliver good responsiveness.
This turns out to be hard for an OS to do. Thinking about which system calls can wait for unbounded time, then arranging escape paths for when the call is aborted adds a lot of complexity.
People would like to use RTSJ's raw memory interface to write device drivers. This has turned out to be harder than anticipated.
On an X86, some devices are in I/O space. Ordinary memory mapping does not see the space that is accessed by the processor via in and out instructions.
The X86 and other processors often put I/O devices on the PCI bus. Devices on the PCI bus are accessible with ordinary load and store operations, but the PCI address space cannot simply be mapped into a process' address space with a mmap system call.
For applications that want direct access to I/O devices, RTSJ would like an easy way to map that device into its address space.
The RTSJ doesn't have any specific requirement for timer resolution, but at worst the resolution of the real-time clock should be comparable with timing jitter. For most systems, that means that it should be possible to set timers and read the clock with resolution finer than 100 microseconds.
It is often impractical or difficult to run RTSJ as root or from a super user account. It would be much easier logistically to be able to run RTSJ from either a standard user account or a user account with added access rights.
In order to get the most responsive RTSJ application behavior, it is often desirable to disable processor interrupt when it is possible to do so. SMP platforms offer the opportunity to disable processor interrupts on a processor or a processor group while directing interrupts to the remaining processors.
The OS should permit RTSJ threads to reach the full range of priorities including the capability for real-time threads to preempt interrupt handlers.
This requires the operating system to execute as much interrupt service as possible in schedulable entities.
Priority ceiling is an RTSJ option, and it can probably be supported in the RTSJ implementation without OS support, but it would be good to have.