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
   • 25 August
     • Groups demoing on the 27th leave the lab at 13.00
   • 26 August
     • Code freeze at 9.00
     • Demos start at 9.30
       • 30 minutes in length
     • Demos end at 13.00, groups demoing on the 27th re-enter the lab
   • 27 August
     • Code freeze at 9.00
     • Demos start at 9.30
       • 30 minutes in length
     • Demos end at 13.00
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

• What does the program do when it detects a type mismatch?
• Well, it could send a more informative error message before it dies.

Statically

No,

• Structured programming depends critically on well-defined scope.
• While tasks are scoped internally, there is no inter-task scoping.
• In fact, we are happy to be free of scoping, because it allows us to try out a wider variety of program structures.

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

• translating other synchronization/communication semantics to and from CSP
• finding new methods for reasoning about CSP
• scaling everything to make CSP useful for production sized programs
• During that time many a chicken has left its tracks on the pages of formal methods journals and conference proceedings!

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'.)

• The claim was first made in the late 1970s/early 1980s.
• It was made again in the early 1990s, this time with the weight of Bell Labs behind it.
• And has been made yet again in the last few years, this time with the weight of Goggle behind it.

Primitives

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

1. read

   keyboard ? ch
   ch = <- keyboard

   • reads from an input channel called keyboard and assigns what it reads to the variable ch
   • the channel must have an associated type, and the type must match the type of the variable.
   • That is, the channel and the variable must be in the same scope.
   • read blocks until input is available on the channel
2. write

   keyboard ! duh
   keyboard <- duh

   • writes the value of the variable duh into the channel keyboard
   • blocks until the
   • Thus, a read/write pair guarantess that read in the reading process occurs simultaneously with or after the corresponding write in the writing process.

There is also a creation primitive

• occam -- PAR
  • no shared memory: costly
• Go -- go
  • shared memory: cheap

The communication primitives require something new, called a channel.

CHAN OF CHAR keyboard
keyboard chan char

• Each channel has a protocol that states the type that messages it handles must have.
• Knowing the name of a channel is essential for using it.
  • Applications control who can be on the other end of a channel, which is essential for security, by controlling who knows the name of the channel.

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

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

• An idea whose time has now come, again.
• Google

Problem is communication

• Big granularity (thick client: MS, Google)
  • minimizes communication
  • maximizes replicated data
  • The Google approach:
    • an opportunity nobody thought about
    • a problem nobody thought about.
• Small granularity
  • minimizes replicated data
  • maximizes communication
  • Your system, like threading solutions, relies on shared memory for communication
    • How would you handle caching?

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.

• Your kernel: communication based on memory that is universally accessible by the kernel, which is easy to program, hard to make secure.
• The transputer: communication based on switch mediated packets, which is hard to program, easy to make secure.

The transputer itself

• 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
  • can be, and usually was, taken over by the programmer.

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?

Google (data centre) hardware

Many single board (including disk) computers

• Communicate by high speed ethernet

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)
   • may be named, take arguments and return values
   • may be combined
2. CSP channels
3. time

Combining processes

1. sequential
2. conditional
   • if/then
   • selection by case
3. looping
   • without test/break
   • with test/break
4. parallel
   • initiated when the keyword PAR occurs.
5. alternation
   • guarded alternatives
   • if more than one guard is true then select at random
     • can be prioritized

Time

• timer returns time as channel input

  clock ? now

• AFTER can be used to combine times, because there is a total order based on time

  IF now AFTER yesterday THEN

• AFTER can make timer input blocking

  clock ? AFTER tomorrow

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

• all possible clients must be in the same scope in order to get static type checking
• with dynamic, structural type checking you only need to have the tasks written in languages having the same type system

BUT

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

Return to:

• Bill Cowan's lecture notes for CS452 in s12
• Bill Cowan's Spring 2012 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page