CS452 - Real-Time Programming - Spring 2009
Lecture 30 - History : Transputer, Occam
Hardware for Real-Time
First Generation
Second Generation
The Transputer: a Second Generation Offshoot
Use many co-operating, medium capability microCPUs to do a big job.
- An idea whose time has now come.
- Google
Problem is communication
- Big granularity (thick client: MS, Google)
- minimizes communication
- maximizes replicated data
- The Google approach: a problem nobody thought about.
- Small granularity
- minimizes replicated data
- maximizes communication
- Your system, like threading solutions, relies on shared memory for
communication
- The return of the FORTRAN common block
- How would you handle caching?
Comminication requires either
- a common bus, star topology
- passing messages along
What about real-time?
- lots of timer (countup) hardware
- interaction of countdown and countup to make your clock server
- Instances of timers are not guaranteed to be synchronized
- How could two timers be synchronized?
The transputer was an early, now vanished, example of the latter
- CPU, memory, switch on one chip
- chips connected in an array
- presumably a run-time system decides where tasks will go in order to
- maximize CPU throughput
- minimize communication overhead
Occam 2
Basic idea
- processes (tasks)
- may be named, take arguments and return values
- may be combined
- channels
- Concept is
- input - channel ? value
- output - channel ! value
- need a protocol (for type safety)
- must be named
- time
Combining processes
- sequential
- conditional
- if/then
- selection by case
- looping
- without test/break
- with test/break
- parallel
- initiated when the keyword PAR occurs.
- alternation
- guarded alternatives
- if more than one guard is true then select at random
Channels
- input
channel ? variable
- variable type must match protocol
- real-world hardware acknowledged by the anarchic protocol
- blocks when channel is empty
- output
channel ! value // the value of a variable or the result of an procedure
- variable type must match protocol
- blocks until an input process accepts the data
- input & output provide synchronization
- similar to sockets except for output blocking
- variant protocols are possible
- These require typed input
Time
The Result
You can write a type-safe server, BUT
- all possible clients must be known at compile time.
Program structure is more static than is allowed in your system.
This might be a good thing.
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
- Micro-controllers
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
- 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.
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
`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
Return to: