CS452 - Real-Time Programming - Fall 2009

Lecture 4 - Tasks, Kernel

Reminder


Kernel of a Real-time Operating System

Diagram

What Does the Kernel Provide

Tasks

Communication

Communication has two sides

  1. sharing information
  2. handshaking

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

Diagram

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
    entry_point1 :
        action1;
    entry_point2:
        action2;
    ...
    entry_pointn:
        actionn;

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


Kernel Structure

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

kernel( ) {
  initialize( );
  FOREVER {
    request = getNextRequest( );
    handle( request );
  }
}

Where is the OS?


Tasks

What is a task?

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

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 tasks, 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

Diagram


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

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

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'

How I Get Started Writing a Context Switch

1. Start with a program that calls a function

void func( ) {
  printf( "func: running\n" );
}

void main( ) {
  printf( "main: beginning\n" );
  func( );
  printf( "main: ending\n" );
}
  1. Compile and run it.
  2. Compile with the -S flag and look at the assembly code.

2. Find out how to put a PC into an interrupt vector

What is an interrupt vector?

  1. Add to the assembly code a line that puts the address of the first instruction of func( ) into the interrupt vector
  2. Compile the assembly code and run it.

3. Change to calling func() using a software interrupt

  1. Replace the instruction in main that calls func( ) to swi n
  2. Replace the bx or mov pc, lr instruction that ends func( ) with mov pc, lr.

4. You have just written a context switch, now you need to dress it up.

  1. Add stuff to main( ) so that it has context
  2. Save the context of main( ) on the stack as the first thing done inside func( )
  3. Restore the context of main( ) from the stack jas the last thing done before the instruction that ends func( ).

5. Add a return value from func( ) and pick it up in main( ).

To go beyond this we need to think about tasks more concretely


What we did here was to replace a function call with a software interrupt. Why bother?

  1. A software interrupt can leap tall barriers at a single bound
  2. A hardware interrupt is very similar to a software interrupt.

Return to: