Stella Jobs and Handlers

 

Stella distinguishes two types of task: jobs and handlers.

Stella jobs

A Stella job is a particular form of free-running task that has its own full context (registers, memory and priority). A job executes under control of the scheduler, sharing processor time with other jobs in accordance with its priority. The distinguishing characteristic of a job is its "permanent context". Although jobs can, of course, be created and removed, the execution of a job appears (to that job) to be a continuous process. If a job is interrupted or has to wait for an event, then when it continues, it does so from the next instruction with its context unchanged. This is the classic form of task that is usually used for applications and, in some operating systems, for device drivers or even the operating system modules themselves.

In Stella, jobs can be co-operative or independent and co-operative jobs can share resources flexibly, safely and efficiently. Regardless of the relationship between the jobs, Stella provides a uniform operating system interface. Stella does not suffer from the incoherence that is implicit in the arbitrary actor / task group / process / thread structure of systems derived from UNIX.

Stella handlers

A Stella handler is a task, with a very lightweight context, that is neither permanent nor continuous. It is launched in response to an external event, a timer or some other transient phenomenon. When it has finished its operation, usually within a few tens of instructions, it simply exits without saving any part of its context. The code and the working data remain, but the task itself has gone. Unlike a job, which still has a presence even when it is inactive, such a task is transient.

Conventional programming environments are based on the idea that the permanent task is the natural form of program. The architypical permanent program is rather short lived and was created at the end of the 1960s:

main () { printf "Hello World!\n"; }

The "Hello World" program does not interact at all with its environment. On the other hand, a simple program that takes keystrokes from the keyboard, processes them and then prints them out can be considered as a typical example of a "reactive" program.

If a reactive program is implemented as permanent program, it must be expressed as a loop. It is more natural, however, to express it as a transient task responding to an event.

For the permanent task the "wait" is a very heavyweight operating system call. Even with for "market leader" real time operating systems it takes several hundred instructions. The start and exit overheads for a transient task are at least an order of magnitude smaller.

Some systems have very limited facilities for managing handlers (UNIX, for example, provides irregular facilities for handlers for "signals"). Other systems provide simulated event handling using a permanent task (Microsoft Windows, for example). Few, if any, other systems, however, have a comprehensive range of facilities approaching that of Stella.

Classical operating systems do not allow such a general use of the handler concept. The example given above may well require data to be stored between two successive operations or to be transferred between two different contexts. In a classical operating system permanent data storage must be associated with permanent tasks.

Stella, however is not subject to such arbitrary restrictions. In a Stella system, therefore, handlers are used not only for servicing interrupts, but for any transient or repetitive task.

It is, of course, possible to use handlers exclusively to build complete complex applications. This is an approach that is well suited to event based systems (for example menu and graphics based applications or real-time control systems).

Management of jobs and handlers

Stella provides two different modules for handling external event handlers (interrupt servers) and other types of task.

The Stella external event managers and the Stella task managers are designed to work together. Many lightweight embedded systems, however, will not need a task manager while some system designers may prefer to stick to "good old-fashioned" vectored interrupt handling instead of using the external event manager. The external event management and the task management are, therefore, kept separate.

The indirect external event handlers managed by the external event manager are invoked by either direct external event handlers or by other indirect external event handlers. This allows handlers to be divided into a high priority "immediate response" section and lower priority, lengthy operations that do not interfere with the immediate response.

Each level of task management services is designed to meet a different set of constraints.

External event manager   Guaranteed responses down to microseconds1 for small tasks. The tasks are scheduled to meet deadline or repetition rate constraints.
Timed handlers Non guaranteed timings down to milliseconds for small tasks2.
Scheduled handlers Non guaranteed responses on a human time-scale for small or medium tasks (execution times up to tens of milliseconds).
Jobs Conventional applications programs, number crunching, etc.


1  The minimum guaranteed response time depends less on "raw" processor speed than conventional benchmark figures show. "High speed" processors depend on both caches and pipelines to achieve their rated performance. Neither caches nor pipelines are much help under worst case conditions as neither will hold useful data.
2  The timings are as reliable as any conventional real time system (and more reliable than most).
 

  Back to table of contents.


Copyright (c) 1997 Tony Tebby.