CS452 - Real-Time Programming - Fall 2011

Lecture 32 - Communicating Sequential Processes (CSP)

Public Service Annoucements

1. Final demo: Tuesday, 6 December, 2011; Wednesday, 7 December, 2011
   • Demo I starts at 10.00 on Tuesday
   • Demo I ends at 13.00 on Tuesday, say 14.00 because we often run overtime.
   • Demo II starts at 10.00 on Wednesday
   • Demo II groups have 20 hours of exclusive track use from end of Demo I to the start of Demo II
   • Therefore, Demo I groups should have 20 hours of exclusive track use.
   • From 14.00 on Monday to 10.00 on Tuesday only groups showing their demos during Demo I may use the trains lab.
2. Final exam: 10.30, Friday, 9 December, 2011 to 13.30, Saturday, 10 December, 2011.

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
   • write does not block
   • Thus, a read/write pair guarantess that read in the reading process occurs simultaneously with or after the corresponding write in the writing process.

The communication primitives require something new, called a channel.

CHAN OF CHAR keyboard
keyboard chan char

• A channel is a first in/first out silo.
• 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 Transputer

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:
    • 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
    • The return of the FORTRAN common block
    • How would you handle caching?

Communication requires either

• a common bus, star topology
  • system bus (= shared memory)
  • LAN
• a common channel, over which users pass messages in real-time
  • wasteful of bandwidth
  • analogue telephony
• passing messages along
  • emphasizes the switches (bridges) that connect common buses
  • really more like a hybrid, which is classified differently based on the level of abstraction.

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 a real-time system based on plentiful small granularity communication. Your kernel is another example.

• Your kernel: communication based on shared memory, 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.

Transputer hardware

• 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

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 wekens synchronization, which might not be what you want.

Return to:

• Bill Cowan's Fall 2011 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page