Programming in Occam-pi: A Tutorial

Programming in Occam-pi:A Tutorial

By: [email protected]

"Programming in Occam-pi: A Tutorial", Zain-ul-Abdin 2

Outline• Occam-pi basics

– Networks and communication– Types, channels, processes ...– Primitive Processes– Structured Processes– Examples: Integration, Matrix Multiplication

• Mobility– Mobile Semantics– Mobile Assignment– Mobile Communication– FORKing Processes– Example: Dynamic Process Creation


CSP

• CSP deals with processes, networks of processes and various forms of synchronisation / communication between processes.

• A network of processes is also a process - so CSP naturally accommodates layered network structures (networks of networks).


Occam-pi Introduction

• Named after Occam Razor ”If you have two equally likely solutions to a problem, choose the simplest”

• Combines the concepts of CSP with pi-calculus• Parallel processing language that simplifies the

description of systems• Allows composing simple components to build

complex systems Semantics [A+B] = Semantics [A] + Semantics [B]• Built in semantics for concurrency

– Processes– Channels (Unbuffered message passing)


Processes

• A process is a component that encapsulates some data structures and algorithms for manipulating that data.

• Both its data and algorithms are private. The outside world can neither see that data nor execute those algorithms! [It is not an object.]

• The algorithms are executed by the process in its own thread (or threads) of control.

• So, how does one process interact with another?

myProcess


Processes

• The simplest form of interaction is synchronised message-passing along channels.

• The simplest forms of channel are zero-buffered and point-to-point (i.e. wires).

myProcess


Synchronized Communication

• Output value down the channel out• This operation does not complete until the

process at the other end of the channel inputs the information

• Until that happens, the outputting process waits

out ! value


Synchronized Communication-cont’d• Input the next piece of information from channel

in into the variable x• This operation does not complete until the

process at the other end of the channel outputs the information

• Until that happens, the inputting process waits

in ? x


Synchronized Communication-cont’d• A may write on c at any time, but has to wait for a read.• B may read from c at any time, but has to wait for a

write.

cAA BB

c ! x

x

c ? y

y


Types

• Primitive types– INT, BYTE, BOOL– INT16, INT32, INT64– REAL32, REAL64

• Arrays types (indexed from 0)– [100]INT– [32][32][8]BYTE– [50]REAL64


Operators• +, -, *, /, \ PLUS, MINUS, TIMES

• +, -, *, /, \

• <, <=, >=, >

• =, <>

• /\(and), \/(or), >< (xor), >>(rshift),

<<(lshift)

• ~ (not)

INTxx, INTxx → INTxxBYTE, BYTE → BYTE

REALxx, REALxx → REALxxINTxx, INTxx → BOOLBYTE, BYTE → BOOLREALxx, REALxx → BOOL

*, * → BOOL

INTxx, INTxx → INTxx

BYTE, BYTE → BYTE

INTxx → INTxx

BYTE → BYTE

Precision must be matched

Types must match


Expressions

• No auto-coercion happens between types: if x is a REAL32 and i is an INT, then x + i is illegal ...

• Where necessary, explicit casting between types must be programmed: e.g. x + (REAL32 i) ...

• No precedence is defined between operators, we must use brackets: e.g. a + (b*c) ...

• The operators +, -, * and / trigger run-time errors if their results overflow.


Declarations

• All declarations end in a colon • A declaration cannot be used before it is

made ...• Declarations are aligned at the same level of

indentation ...• Variable declarations

• Channel declarations

INT a, b:

[max]INT c:

[max]BYTE d:

CHAN BYTE p:

[max<<2]CHAN INT q:


An Occam-pi Process

• Syntactically, an occam-pi process consists of:– an optional sequence of declarations (e.g. values,

variables, channels)– a single executable process

• All the declarations – and the executable – are aligned at the same level of indentation.

• The executable process is either primitive or structured.


Process Abstractions

PROC foo (VAL []BYTE s, VAL BOOL mode, INT result, CHAN INT in?,

out!, CHAN BYTE

pause?) ...:

foo(s, mode, result)

pause out

in


Primitive Processes

• Assignmenta := c[2] + b

• Input (synchronising)in ? a

• Output (synchronising)out ! a + (2*b)

• Null (do nothing)SKIP

• Timer (increments every millisec.) TIMER tim


Structured Processes-SEQ and PAR

SEQ

in ? sum

in ? x

sum := sum + x

out ! Sum

PAR

in0 ? a

in1 ? b

out ! a + b

c := a + (2*b)

Processes can run in any order, No data race hazards


Structured Processes-IF and WHILEIF x > 0 screen ! 'p‘ x < 0 screen ! 'n' TRUE screen ! 'z'

WHILE TRUE INT x: SEQ in ? x out ! 2*x


Structured Processes-PROC instance

PROC octople (CHAN INT in?, out!)

CHAN INT a, b:

PAR

double (in?, a!)

double (a?, b!)

double (b?, out!)

:


Example - Integrate

PROC integrate (CHAN INT in?, out!) INT total: SEQ total := 0 WHILE TRUE INT x: SEQ in ? x total := total + x out ! total:

• Sequential implementation


Example - Integrate

PROC integrate (CHAN INT in?, out!) CHAN INT a, b, c: PAR delta (a?, out!, b!) prefix (0, b?, c!) plus (in?, c?, a!):

• Parallel implementation


Example – Matrix Multiplication


Tool Set

• KROC- Kent Retargetable Occam Compiler

Mobility in occam-pi


Copy Semantics• Classical occam: data is copied from the workspace of

A into the workspace of B. Subsequent work by A on its x variable and B on its y variable causes no mutual interference.

cAA BB

c ! x

x

c ? y

y

SAFE but SLOW


Copy Assignment

• As assignment changes the state of its environment, which we can represent by a set of ordered pairs mapping variables into data values.

• In occam, because of its zero-tolerance of aliasing, assignment semantics is what we expect:

• [In all other languages with assignment, the semantics are much more complex - since the variable x0 may be aliased to other variables … and the values associated with those aliases will also have changed to v .]

{ <x , v >, <x , v >, … } x0 := x1 { <x , v >, <x , v >, … } 0 0 1 1 0 1 1 1


Reference Semantics• Java/JCSP: references to data (objects) are copied from

the workspace of A into B. Subsequent work by A on its x variable and B on its y variable causes mutual interference (race hazard).

cAA BB

c ! x

x

c ? y

y

UNSAFE but FAST


Reference Semantics

cAA BB

x y

c ! x c ? y

HEAP

before


Reference Semantics

cAA BB

x y

c ! x c ? y

HEAP

after


Movement Semantics

Consider copy and move operations on files …• copy duplicates the file, placing the copy in the

target directory under a (possibly) new name.• move moves the file to the target directory,

possibly renaming it:– the original file can no longer be found at the source

address;– it has moved.


Mobile Assignment

Mobile semantics differs in one crucial respect:

• The value of the variable at the source of the assignment has become undefined - its value has moved to the target variable.

• It must be noted: mobile semantics is strictly weaker than copy semantics.

{ <x , v >, <x , v >, … } x0 := x1 { <x , v >, <x , ?? >, … } 0 0 1 1 0 1 1


Mobile Communication• The semantics for assignment and communication are

directly related. In occam, communication is just a distributed form of assignment - a value computed in the sending process is assigned to a variable in the receiving one (after the two processes have synchronised).

• For example, if x0 and x1 were of type FOO, we have the semantic equivalence:

x0 := x1CHAN OF FOO c:PAR c ! x1 c ? x0

equals


Mobile data Syntax

• Occam-pi has a new keyword – a MOBILE qualifier for data types/variables• The MOBILE qualifier doesn’t change the semantics of

types as types. For example, MOBILE types are compatible with ordinary types in expressions.

• But it imposes the mobile semantics on assignment and communication between MOBILE variables.

• The MOBILE qualifier need not be burnt into the type declaration - it can be associated just with particular variables.

MOBILE INT x0, x1:


Mobile data – cont’d

• Mobiles are safe references

• Assignment and communication with reference semantics

• Only one process may hold a given mobile


Mobile Channel Type

• In occam programs, channels are fixed in place at compile time

• What if we want to reconnect the process network at runtime?

• A channel type is a bundle of one or more related channels: for example, the set of channels connecting a client and a server

• Note this has to be a CHAN TYPE, else you can’t put channels in it

• Channel direction specifiers are mandatory


Mobile Channel Bundles

• Defined as ‘client’ and ‘server’ ends of a “mobile channel-type”, e.g.:

• Directions specified in the type are server-relative– Channel ends inside channel type ends can be used

like regular channels

CHAN TYPE INT.IO

MOBILE RECORD

CHAN INT in?:

CHAN INT out!:

:

INT.IO! cli:

SEQ

cli[in] ! 42

cli[out] ? r

INT.IO? svr:

SEQ

svr[in] ? x

svr[out] ! x+1


Communicating Mobile Channels• The main use of mobile channel bundles is to support

the run-time reconfiguration of process networks• P and Q are now directly connected• Process networks may be arbitrarily reconfigured using

mobile channels– dynamic process creation makes this much more interesting

c ? a

d ? b

Generator

P

Q

c

d

a

b


Dynamic Process Creation

• N-replicated PAR, where the replicator count is a constant

• The creating process has to wait for them all to terminate before creating process has to wait for them all to terminate before it can do anything else.

VAL N IS 10:

SEQ

PAR i = 1 FOR N

...



• Asynchronous process invocation using FORK• Essentially a procedure instance that runs in parallel with

the invoking process• Parameter passing is strictly uni-directional and uses a

communication semantics• occam-pi introduces two new keywords – FORKING and

FORK• Inside a FORKING block, you can use FORK at any time

to spawn a new process• When the FORKING block exits, it’ll wait for all the

spawned processes to finish



PROC A () ... local state SEQ ...... FORKING SEQ ...... FORK P(n, svr, cli) ... ...:

VAL data is copied into a

FORKed processMOBILE data and channel-ends are

moved into a FORKed process


Client-Server Application

CSresponse

request

P


Client-Server Application

• Fault-tolerance by Replication

CSresponse

request

P

B S

Programming in Occam-pi: A Tutorial

Documents

Transcript of Programming in Occam-pi: A Tutorial