next up previous contents
Next: Interrupt Handling Up: Scheduler API Previous: Scheduler API   Contents

Tasks and Processes

Any computer system, be it Real Time or not, usually consists of a number of tasks or processes. Each task is designated to carry out some logically independent component of the application. Splitting an application in this manner improves the overall throughput of the system by achieving parallelism between the various components of the system.

For example consider a typical Mpeg streaming application. An application like that might be split into three threads, one for carrying out the I/O, another for Mpeg decoding and the last for displaying. Splitting the application in this manner helps in achieving parallelism between the networking hardware (for I/O), the CPU (for decoding) & the video controller (for displaying).

One very important distinction between a Real Time System and a typical non Real System,(like a PC system) is, in the nature of tasks or processes in them. A tasks in a typical Real Time System are much more deterministic. Prior knowledge is often avaliable about one or more of the following task attributes.

  1. The Number of tasks
  2. Nature - Periodic, Aperiodic, Periodicity
  3. Deadlines
  4. Execution Times
  5. Resource Requirements
In this regard typical non Real Time Systems, like a PC system are much more non deterministic. The number and nature of tasks in those systems are very much dependent on the environment like the number of users currently logged in, etc.

Because of this differnece between a Real Time System and a normal PC system, the scheduling algorithms used in them are expectedly quite different. Operating System (like Linux), for the latter type of systems are written keeping this in mind. The scheduling algorithms used in such systems are designed to reduce the average response time of processes.

On the other hand Operating Systems for Real Time Systems use entirely different sceduling algorithms. Here the aim is usually not reducing the average response times of processes, but to have better throughput and to garuntee job deadlines.

There is also a wide difference between different Real Time systems, in regards to their scheduling requirements. For example while Round Robin scheduling is suitable for a Real Time network switch , it's not at all suitable for precedence constrained jobs. Hence a Real Time OS should have the feature where the application developer can choose which scheduling algorithm to use for that particular application.

Most of the currently used RTOS although have this feature of pluggable scheduler, they support only a limited number of scheduling algorithms(at most 2 or 3).

We have proposed & developed a framework where the scheduler is not a part of the kernel but a part of the application. This allows the application developer to write his own customized scheduler, most suitable for the particular application, and hence optimize on scheduling overheads.

The kernel interacts with the scheduler through a set of functions. Broadly it works as follows. Whenever a new thread is created the kernel calls a scheduler function passing as argument the newly created thread. The scheduler is expected incorporate the new thread into it's own data structure. Subsequent scheduling of the thread & of all other threads in the system is for the scheduler to decide. At each context switch time (on a timer interrupt) the kernel calls a scheduler function to find out which thread to schedule next.

We have demonstrated our approach through two example scheduler, one a simple fifo scheduler and another a edf scheduler with deadline detection.


next up previous contents
Next: Interrupt Handling Up: Scheduler API Previous: Scheduler API   Contents
Soumyadeb Mitra 2002-08-07