CS452 - Real-Time Programming - Spring 2011

Lecture 30 - Communicating Sequential Processes (CSP)

Pubilic Service Announcement

Milestone 2
Projects

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 different 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
etc.

For programmers the claim has been and is made that CSP provides a superior method for structuring MPTT systems.

The claim was first made in the 1980s
And has been made 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, they are

read
```
keyboard ? ch
```
- reads 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
write
```
keyboard ! duh
```
- write the value of the variable duh to the channel keyboard
- write does not block
- Thus, a read/write pair guarantess that read in the reading process occurs simultaneously with or after write in the writing process.

The communication primitives require something new, called a channel.

Each channel has a protocol that states the type that messages it handles must have.

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?

Communication requires either

a common bus, star topology
- system bus,
- LAN
passing messages along
- emphasizes the switches
- 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 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
CSP channels
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
  - can be prioritized

Time

timer returns time as channel input
```
clock ? now
```
AFTER can be used to combine times
```
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: