CS452 - Real-Time Programming - Spring 2012

Lecture 32 - Communicating Sequential Processes (CSP)

Public Service Annoucements

  1. Final exam date: 9.00 August 7 to 11.30 August 9
  2. Final demos: 26 August & 27 August
  3. Noticed at the Milestone 2 demos
    1. Conservative reservations did best
      • They make corner cases not exist
      • But they inhibit performance: we saw system lock-up with two trains.
    2. My impression:
      • every group had something close to staggering
      • a few groups had robust implementations, not necessarily complete
    3. One robust implementation had many terminal-controllable parameters
    4. Only one group -- of the ones we asked -- had a small idle task execution time fraction, ~ 50%, and they were having performance problems.
    5. Following, first on a big loop, then on a small one, is a good test of reservations.
      • We liked ones that adjusted to go at the best speed.
      • This is a symptom of being ables to run more trains without lock-up

Can Message Passing be Made Type Safe?

Dynamically

Yes, even including type extension and polymorphism, but

Statically

No,

CSP

To formal methods people CSP is a calculus for reasoning about the correctness of multi-process/threaded/tasking (MPTT) systems. Active research has been ongoing for forty years with several goals

For programmers the claim has been and is made that CSP provides a superior method for structuring MPTT systems. (`Superior' in the sense of `easier to design, implement and understand'.)

Primitives

In CSP there are two communication primitives. In the notation of occam 2/Go, they are

  1. read
    keyboard ? ch
    ch = <- keyboard
  2. write
    keyboard ! duh
    keyboard <- duh

There is also a creation primitive

The communication primitives require something new, called a channel.

CHAN OF CHAR keyboard
keyboard chan char

The Grandfather -- the Transputer -- and the Grandson -- Go

Use many co-operating, medium capability microCPUs to do a big job.

Problem is communication

Transputer hardware

The transputer was an early, now vanished, example of a real-time system based on plentiful small granularity communication. Your kernel is another example.

The transputer itself

What about real-time?

Google (data centre) hardware

Many single board (including disk) computers

Software

Farmer with clients & worker

Occam2

FOREVER
  ALT
    from.client ? request && workerfree
      SEQ
        workerfree = false
        to.worker ! request
    from.worker ? result
      SEQ
        workerfree = true
        to.client ! result

Go

FOREVER {
    select {
    case request <- from.client && workerfree
        workerfree = false
        request.data -> to.worker
    case result <- from.worker
        result -> request.chan
    {
}
case result <- from.worker

Timing out

Occam2

PAR
  SEQ
    sleep( delay )
    timeout ! true
  ALT
    in.data ? data
      // respond to data
    timeout ? now
      // data timed out

Go

timeout := make( chan bool )
go func( ) {
  time.Sleep( delay )
  timeout <- true
}( )
select {
case <- ch:
  // data available
case <- timeout:
  // read timed out
}

Basic idea

  1. processes (tasks)
  2. CSP channels
  3. time

Combining processes

  1. sequential
  2. conditional
  3. looping
  4. parallel
  5. alternation

Time

Can you Build a Server with Type-Checking?

Outer
Scope
|
| CHAN OF REQUEST request
|
| Server 
| Scope
| |
| | REQUEST sreq
| | CHAN OF REPLY srep
| |
| | request ? sreq
| | srep := sreq.reply
| |
| | srep ! sresult
| |
| |
| |
| Client
| Scope
| |
| | REQUEST creq
| | CHAN OF REPLY crep
| |
| | creq.reply := crep
| | request ! creq
| |
| | crep ? cresult
| |
 

The Result

You can write a type-safe server, BUT

BUT

with this structure excessive code in the client weakens synchronization, which might not be what you want.


Return to: