CS452 - Real-Time Programming - Fall 2008

Lecture 26 - Recent Hardware and Real-time Programs

Questions & Comments

Demos:
- comments
- next week

Hardware

First Generation

Big mainframe computers
Finite state machine controllers

Second Generation

Big mainframe computers
Mini-computers
Other tools, such as state charts
- real-time
- state machines with states that are Cartesian products
- focussed on small scale control
  - digital watches
  - traffic lights
- program was in ROM
  - called firmware
- cyclic execution

Third Generation

Multi-CPU servers
- more or less tightly coupled
- dominated by RPC and its relatives
Micro-computers
- many (most?) were used in real-time applications
  - point-of-sale systems
  - games
  - telephone switches
- supported by DOS (still in use!)
- much ad hoc intercommunication
  - as with mini-computers
Micro-controllers
- including DSPs

Fourth Generation

Multi-(multi-core CPUs) called servers
- communicate and synchronize using shared memory
  - using techniques from CS343
- 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 lack of multi-threading
- multi-core, cache, and shared memory don't play well together
Stream processors
- good for SIMD
- treat as co-processors

Ada Tasking

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

Ada was one such

Based on virtual processors
Each processor runs a task
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;

Main program is implicitly called as a task.

When it enters a program unit with tasks inside, it starts each of the tasks in the unit.
It 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.

Return to: