CS452 - Real-Time Programming - Winter 2015

Lecture 4 - Tasks & Kernels

Public Service Annoucements

  1. Marking of a0.
  2. Due date for kernel 1: 26 January, 2015

Kernel of a Real-time Operating System


In the next few weeks we will build, from scratch, a micro-kernel. The micro-kernel supervises the execution of tasks, which are the elements of our systems. (A task is a function with no arguments and no return value.)

The base unit of a polling loop is

This looks more than you think like the operating systems to which you are accustomed. The actions you used in assignment zero responded to hardware events detected by execution of a condition. Walking before we try to run we respond to hardware events in part 3 of the kernel.

The code that implements an action needs support. It must

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. the interrupt primitive
  4. complex servers


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

What Does a Microkernel Provide?


A program is conceived as a collection of co-operating tasks. Tasks provide applications with modularity. Task structure as a method of program organization will be discussed about the time you are finishing the OS.

Tasks consist of

Why are tasks important?


Communication has two aspects

  1. sharing information and
  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

Sharing data

Data is usually shared in the form of a struct, which requires a common name space of types, but removes parsing and formating.

Send does transfers both ways at once. Receive and Reply transfer one way each.


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


In the polling loop you polled a register

Almost every test failed, which wastes CPU. Even worse, it increases the response time, the time from when the event occurs until the first instruction of user code responding to it occurs.

You can get rid of the polling tests if you program the hardware to send the CPU a signal when the condition for which you are waiting occurs. Such a signal is called an exception and the CPU goes into a privileged state when the interrupt occurs.

The kernel responds to the exception by reading volatile data and readying the task that is waiting on the interrupt. This task is essentially the action that was conditioned on the event in the polling loop.


What is a task?

  1. A set of instructions
  2. The current state, which is changed by executing instructions. The state of a task includes 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.

void kernel( ) {
  TD* = active;
  initialize( );  // includes starting the first user task
    handle( getNextRequest( ) );

Where is the OS?

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

int getNextRequest( ) {
  return activate( active = schedule( ) ); //the active task changes only here

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' which we call a context switch

The Hardware/Software Provided in the Undergraduate Environment

Software provided and maintained by CSCF


Specific documentation from Technologic

System on Chip (SoC)

EP9302, designed and manufactured by Cirrus semiconductor


Byte addressable, word size 32 bits

Hardware configuration created by RedBoot

Separate instruction and data caches

`COM' ports

Connected to two UARTs implemented on the SoC

Reset switch


Specific documentation from Cirrus

System on chip

ARM 920T core

Specific documentation from ARM, which covers

Return to: