CS452 - Real-Time Programming - Spring 2009

Lecture 31 - History : Ada

Emb

First Generation

Assembly language on big computers

all computers were big
polling loops and

Second Generation

Transputer, Occam

Third Generation

Ada: A Third Generation Offshoot

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
- a la IBM TSS
  - first: virtual card decks
  - later virtual machines, the minidisk
- now an idea that has come to life
- examples: vmWare, Qemu, Parallels
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

Entries in their specifications

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

Accept statements that implement the entries

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

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 blocked 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.

Problems

How would you attach interrupts to hardware that varies from execution to execution?

task body Int is
    loop
        accept Interrupt do
            // manipulate device
            SendServer( error, data )
        end Interrupt
     end loop
end Int

Where and how do interrupts get turned on?
How does the device get initialized?

Notice how device-specific the above code is.

`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.

Fourth Generation

Multi-(multi-core CPUs) called servers
- communicate and synchronize using shared memory
  - using techniques from CS343
  or using RPC
  - using techniques from CS454
- multi-core, cache, and shared memory don't play well together
- performance limited by threading
  - explicit support for threading, e.g. register windows (Sun) increases performance hugely
  - communication still costly
Multi-core microprocessors
- performance strongly hampered by difficulty of multi-threading
- multi-core, cache, and shared memory don't play well together
Stream processors
- good for SIMD

Return to: