
Stella Task Management
The Stella task managers provide timer services for handlers in addition to the more classical job scheduling facilities.
These are included in the task managers as the schedulers themselves include timer services (to handle requests such as "wait for data for no more than 2 seconds").
High precision timings (down to a few microseconds) are normally provided by using an external even handler linked to a hardware timer. For less stringent requirements, the task manager provides simple timer services.
The basic timer services manage intervals from milliseconds to days. They only manage time differences (e.g., 25 ms or 2 hours). They do not manage absolute time (e.g., 12:05:30 7th January 1998). If the system has a real-time clock, then higher level services can calculate a time difference to a future time and request a service after the required interval.
There are two main timer services for handlers.
- Periodic timer services are used to invoke a handler at regular intervals. This type of handler can be used for environment monitoring, servo control, or any other non-interrupt driven surveillance task.
- One-shot timer services are normally used for watchdogs, time-outs, automatic shutdowns or other delayed tasks. The delay can be reset externally or within the handler itself.
The handlers are invoked by a simulated interrupt. They are, therefore, not subject to scheduling delays and can reliably provide timings down to a millisecond.
In high efficiency versions of Stella, interrupt service routines (usually in the form of external event handlers) are subject to certain restrictions on the operating system functions that may be used. These restrictions also apply to timed handlers.
Stella schedulers provide three levels of scheduling services for handlers and one level of scheduling services for jobs.
Scheduled event handlers
Scheduled event handlers are invoked in response to an internal event. The event can come from any source. Very often, the source will be an external event handler, but it may be another scheduled event handler or a job.
Scheduled timed handlers
Scheduled event handlers can also be invoked by events generated by the timing services. These event handlers are scheduled one-shot handlers and scheduled periodic handlers.
There are several differences between scheduled event handlers and external event handlers.
- Scheduled event handlers execute within the same priority scheme as jobs and, in many reactive or interactive systems, can be used to build complete systems.
- The restrictions on the operating system calls that made be made by interrupt servers (and external event handlers) do not apply to scheduled event handlers.
- As they are executed within the job priority scheme, a low priority scheduled event handler cannot pre-empt a job (or another handler) with a higher absolute priority.
- As they are executed within the job priority scheme, scheduled event handlers do not provide the same guarantees of response time as external event handlers.
Embedded handlers
All the handlers described so far in this document execute in the "privileged" operating system mode. They are not associated with a particular job context. Embedded handlers, however, execute in application mode within the context of a particular job. This means that they are able to modify the job's data or properties directly.
An embedded handler has its own priority with respect to the job. This priority determines when the handler starts to execute after it has been invoked.
- A high priority embedded handler will interrupt the job to carry out its actions.
- A low priority handler will not interrupt the job. If the job is not waiting, the handler will not start to execute until the job makes an operating system call that will cause it to wait (e.g., "wait for input").
Job scheduler
The Stella schedulers are responsible for allocating processor time to jobs.
The distribution of the processor time depends on two characteristic priorities.
- The absolute priority dominates. The job with the highest absolute priority is the job that executes to the exclusion of all other jobs.
- The timesharing priority is used to determine the processor time taken by each of several competing jobs with the same absolute priority. The processor time is shared in proportion to their time-sharing priority.
Stella jobs are scheduled in a tree structure (which is often identical to the ownership tree) rather than the flat scheduling of systems not designed for multi task applications.
- The scheduling within a job tree is independent of the number and priorities of jobs outside that job tree.
- The scheduling between job trees is independent of the number and priorities of jobs within each job tree.
The POSIX scheme only provides two fixed levels (one for processes and one for tasks within a process) and two separate and incoherent sets of task management operating system calls. Stella provides an unlimited number of levels: all levels have the same task management operating systems interface.

With tree scheduling, the division of the processor time between job 1, tree 2 and tree 3 is independent of the number of jobs in tree 2 and tree 3 and of the priorities of these jobs. Moreover, the division of the processor time between tree 21 and tree 22 is independent of the number of jobs within these two (sub-)trees.
The use of a tree structure for scheduling not only simplifies the definition of job priorities within a multi-task application but also reduces the number of jobs at the top scheduler level. This has a direct impact on the choice of scheduling mechanism.
There are various Stella schedulers offering combinations of absolute priority scheduling and prioritised time-sharing. These schedulers offer different trade-offs between pre-emptive scheduling performance and range of facilities. A common feature of these schedulers is the use of a table mechanism (normally used in time-sharing systems only) even for "pure" pre_emptive schedulers.
Conventional real-time pre-emptive schedulers commonly use "head of queue" designs. This is an approach that boosts benchmark figures at the expense of real performance. It takes the cost of rescheduling from the dispatcher (which just needs to take the job from the front of the queue) and pushes it into the code that handles the release request (which needs to re-organise the queue).
If the scheduler is required to release the highest priority job in response to an interrupt, then the call to release that job will be in the server for that interrupt. Other interrupt servers may release other, lower priority, jobs. If all the interrupts occur simultaneously, then all the interrupt servers will be called before the scheduler can dispatch the highest priority job. Not only will there be n interrupt services before the highest priority job can start, there will also be n operating system calls to release a job. In these conditions, the time taken for the operating system call to release a job is, therefore, n times more important than the time taken to dispatch the job.
In principle, a table based scheduler requires only one instruction to mark the release of a job (set a flag). Most Stella schedulers adopt a compromise requiring two to four instructions.
Moreover, the simplicity of a table based scheduler makes it possible to create very efficient code: even under unrealistic benchmark conditions (single release call for a single task switch), the Stella P scheduler outperforms the market leader real-time operating system schedulers for up to 50 or more jobs.
The task manager provides services not just to applications programs, but also to other operating system modules.
There are six main groups of services.
- Creation and removal of tasks
Both handlers and jobs may be created or removed at any time. The entity manager is responsible for ensuring that the system is maintained in a safe state when a handler or job is removed. This may require the effective removal to be delayed.
- Suspending and releasing tasks
Suspend and release is a classical way of handling "wait for event" in jobs. Whether it is really useful in a system that provides direct event handling facilities remains to be seen. In the short term, it is required for "old-fashioned" applications.
- Setting job priorities
In general, the priority of handlers is determined on creation. Jobs, however, can have their priorities changed at any time.
- Job event management
Events can also be handled by jobs. A job's events are stored in the job's event vector. The job can examine its event vector at any time to check for pending events. Alternatively, a job can wait for one or more events to occur.
- Job environment management
A job's environment defines global and private defaults.
- Job intercepts
A job can define intercepts for various task management functions (break, terminate, etc.).
Back to table of contents.
Copyright (c) 1997 Tony Tebby.