CS452 - Real-Time Programming - Spring 2012

Lecture 4 - Tasks & Kernels

Pubilc Service Annoucements

  1. Due date for assignment 0
  2. Some clean-up needed in course account, cleaned up course introduction.
  3. RTS/CTS
  4. News group: uw.cs.cs452.
  5. Course email account: cs452@cgl.uwaterloo.ca
  6. Documentation expected for assignment 0
  7. Partners

Kernel of a Real-time Operating System

Introduction

The base unit of a polling loop is

Think of action as the performance of a task, such as washing dishes. Think of condition as a signal from outside that tells you it's time to perform the task.

Actions are not independent of one another: washing dishes requires hot water, dish soap, etc., which are provided by other actions. Communication is needed.

Thus tasks need some support.

These basic needs are provided by the kernel of an operating system. The kernel we create in cs452 is a microkernel, because it provides these capabilities and nothing more.

We build the microkernel in four assignments

  1. task creation and scheduling
  2. inter-task communication
  3. an interrupt primitive
  4. complex servers

Microkernels

The real-time operating system we build consists of

  1. an uninterruptible microkernel, plus
  2. interruptible device-handling server tasks that run in user-space with permissions allowing them to access hardware.

What Does a Microkernel Provide?

Tasks

Communication

Communication has two aspects

  1. sharing information, requesting service
  2. synchronization

We use Send/Receive/Reply (SRR) to do both.

  1. Send blocks
  2. Receive blocks: is synchronous with the call to send
  3. Reply doesn't block: is synchronous with the return from send

Synchronization

  1. Between tasks
  2. With internal events
  3. With external events

Interrupts

Input from the outside world

  1. Provide the information you polled for
  2. ISR OS design, which is essentially a jump table, which separates testing from acting
    interrupt entry point:
        calculate action_entry_point;
        jump to act_entry_point;
    entry_point1:
        action1;
    entry_point2:
        action2;
    ...
    entry_pointn:
        actionn;

    These are the same actions you implemented in your polling loop,


Tasks

What is a task?

  1. A set of instructions
  2. Current state, which is changed by executing instructions, which includes

Two tasks can use the same set of instructions, but

The kernel keeps track of every task's state

The TD normally contains

  1. The task's stack pointer, which points to a private stack, in the memory of the task, containing

    all ready to be reloaded whenever the task next runs.

  2. Possibly the return value for when the task is next activated
  3. The task's parent
  4. The task's state
  5. Links to queues on which the task is located

Possible states of the task

  1. Active: running or about to run
  2. Ready: can run if scheduled
  3. Blocked: waiting for something to happen

Kernel Structure

The kernel is just a function like any other, but which runs forever.

kernel( ) {
  initialize( );  // includes starting the first user task
  FOREVER {
    request = getNextRequest( );
    handle( request );
  }
}

Where is the OS?


All the interesting stuff inside done by the kernel is hidden inside getNextRequest.

int getNextRequest( ) {
  return activate( schedule( ) ); //the active task doesn't change
}

What's inside activate( active )?

  1. transfer of control to the active task
  2. execution to completion of the active task
  3. transfer of control back to the kernel
  4. getting the request

The hard part to get right is `transfer of control'


Return to: