The Static Real-Time CORBA 1.0 Scheduling Service is an implementation of the Scheduling Service that is standardized in the Real-Time CORBA 1.0 specification. The Scheduling Service uses a configuration file of parameters generated from an offline tool, such as RapidRMA from TriPacific Software, to set parameters in a Real-Time CORBA 1.0 ORB. The Scheduling Service sets RT CORBA 1.0 parameters such as client CORBA (global) fixed priority, and Real-Time ORB primitives such as a Server Declared Priority Model and Threadpools to ensure that scheduling parameters be set properly in all parts of the CORBA system.
Per the RTCORBA 1.0 standard, the Scheduling Service is comprised of two local objects, ClientSchedulers which reside on each client node, and ServerSchedulers, which reside on servers that accept remote method calls. These two objects shield application developers from the complexities of real time scheduling by encapsulating the necessary RT primitives to perform real time scheduling.
The Scheduling Service makes use of the scheduling information available at design time that is supplied to both the ClientScheduler and the ServerScheduler through a configuration file. Application developers need only to model their system and supply model information such as priority via the config to the SchedulingService object constructors to achieve Real-Time distributed scheduling.
The ClientScheduler, responsible for scheduling activity on the client nodes, contains a map from activity names to CORBA priorities. Application developers wishing to assign execute a particular activity need only to construct a ClientScheduler for the client and then call schedule_activity() prior to activity execution, passing in the name of the activity. The ClientScheduler object then maps the activity name to the associated CORBA priority and sets thread execution to a linearly mapped local OS priority.
The ServerScheduler object, which resides on the server, is responsible for scheduling server activity from remote client requests. The ServerScheduler uses the Server Declared Priority model, threadpools, and interceptors to efficiently and transparently schedule remote execution. In order to appropriately schedule server execution, application developers need only create a ServerScheduler object, then register each object via the schedule_object method, which maps CORBA objects with names (strings) used to reference those objects.
When a client sends a method request, the CORBA priority at which the client thread is running is sent along via a client interceptor to the server. Threads in the server's threadpool run at RTCORBA::maxPriority, so the ServerScheduler's Interceptor immediately intercepts client requests. It then maps the references object to a resource priority ceiling for that object, specified in the configuration file, and uses Multiprocessor Priority Ceiling Protocol to determine the appropriate elevated priority for the thread to execute. If the object is free, the Server Scheduler first locks the object and then sets the processing thread to run at the appropriate elevated priority. If the object is currently locked by another thread, the request is placed in a waiting queue and execution is blocked until the object is freed from use by all higher priority requests in the queue. When execution is complete, the thread priority is returned to RTCORBA::maxPriority so that it may accept the next incoming client request. The released implementation is for the TAO CORBA system and is available as open source in the TAO code repository.
The Scheduling Service can be downloaded independently of TAO here.
