CS452 - Real-Time Programming - Fall 2008

Lecture 29 - Real-time Kernels

Questions & Comments

1. Projects

Ada Tasking

In the 1970s we started looking for successors to C/Unix-like environments.

Ada was one such

• Based on virtual processors: a la IBM TSS
• Each processor runs a task
  • a common method of doing multi-tasking among scientists and engineers.
• Coordinated by the Ada-runtime

Over-all structure

• specification and body
• code gathered, as functions, into packages that share common environments (like ADTs)

Create

task T is
    ....   // public face of task
end T; 
task body T is
    ....   // any code at all
end T;

Tasks are created by the declaration of a task variable

X: T;

• X: T;
• The task is `activated' (we would call it readied) when the begin following the declaration is executed.
• The task name is a constant used for calling entries. (See below.)
• The task inherits the context in which it is declared

Main program is implicitly called as a task.

• A task becomes active when the program unit that declares begins execution.
• Execution leaves the unit only when every task has terminated (synchronization)

Send-Receive-Reply

Tasks can include

1. Entries in their specifications

   task T is
       entry E( <in & out parameters> );
   end T;

2. Accept statements that implement the entries

   accept E( <formal parameters> ) do
      ...  //code to be executed
   end E;

3. Calls to entries in other tasks

   T.E( <actual parameters> );
       

Accept blocks until the call to the entry occurs.

The call blocks until the accept is executed.

Relationship to S/R/R

• Because the caller blocks it cannot be blcked on more than one call at a time.
• More than one task can call a single entry.
  • Multiple callers are queued until the accept code has been completely executed.
• accept is Receive
• call is Send
• end of accept code is Reply

How do You Write a Server

Presumably

loop
    accept Send( request ) do
        // process request
        // fill in return parameters
    end Send;
end loop;

What's wrong here?

• Hint. Is it possible to defer the Reply?

Here is one of the work-arounds.

• the select statement

loop
    select
        SendNotifier( data ) do
            // update internal state
        end SendNotifier;
    or
        SendClient( request ) do
            // fulfil request
        end SendClient;
    end select;
end loop

How does this still fall short?

Is it possible to write a server in a programming language with nested scoping?

Time

Pretty easy. Two time primitives

• delay until <clock time>
• delay <time interval>

You can build delay from delay until, but not vice versa.

Interrupts

An interrupt handler is a parameterless procedure, that can be attached (either statically, at compile time, or dynamically, at run-time) to the occurrence of an interrupt.

Standard programming model

1. handler run in response to interrupt
2. handler acquires volatile data
3. in handler there is a rendezvous (call to an entry) to a task that will continue processing

BUT,

`The Ada programming language defines the semantics of interrupt handling as part of the tasking mechanism, making it possible to construct implementation-independent interrupt handlers. However, for the Ada mechanism to be effective, an implementation must provide support not specified by the Ada standard, such as for initializing hardware interrupting devices, handling unexpected interrupts and optimizing for real-time performance constraints. This paper analyses some of the constraints that efficient interrupt support places on an implementation. It develops a model for the interaction between interrupt hardware and Ada tasks and describes optimizations for Ada interrupt handlers. Implementation issues, including task priorities and task termination for interrupt handlers, are discussed in detail.' Real-time interrupt handling in Ada Jørgen Born Rasmussen, Bill Appelbe, Software Practice and Experience.

Comments

Interrupts are unsatisfactory

• people who have to use Ada write special purpose libraries
  • e.g. Chelini
    • note performance
    • note primitive communication (wait = accept)

Servers are not much used

• task structure is relatively ad hoc

QNX, Cogent, vxWorks, Green Hills, etc.

Systems for developing and controlling real-time programs.

1. Applications are collections of co-operating tasks.
2. OS an API to a collection of library routines

   Including

   • task creation
   • inter-task communication and synchronization
   • control of scheduling
   • interrupt service routines
3. Posix-compatability seems to be essential
   • task model a superset of pthreads
   • all the Posix communication and synchronization primitives are available
     • message queues are closest to SRR message passing
     • send blocks when queue is full
     • receive blocks when queue is empty
     • message queues are not used for synchronization

Message Passing

Comes in two flavours

1. with Reply (aka the one you know)
   • QNX, Cogent, etc
2. without Reply
   • use channels (a la occam) When send and receive block, this is CSP (communicating sequential processes)
   • Send/Receive is a one-way message using a channel known to sender and receiver
     • also, put/get
     • a second send/receive replies
   • Send may block (synchronous) or not (asynchronous)
     • CSP blocks
     • message queues do not block

vxWorks

Creation

1. spawn
2. initialize
3. activate

Synchronization

• POSIX semaphors
• Events
  • send (non-blocking)
  • receive (blocking with time-out)

Communication

• message queues
  • create
  • open
  • send
  • receive

Interrupts

Return to:

• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page