Health & Fitness

Communicating Processes, Safety and Dynamics: the New occam. occam. Dynamic occam. Motivation and Principles. Channel Ends and Direction Specifiers

Description
Communicatg Processes, Safety and Dynamics the New occam Peter Welch and Fred Barnes Computg Laboratory University of Kent at Canterbury {phw, kentac acuk IFIP WG 24, Dagstuhl,, Germany (14th
Published
of 15
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
Communicatg Processes, Safety and Dynamics the New occam Peter Welch and Fred Barnes Computg Laboratory University of Kent at Canterbury {phw, kentac acuk IFIP WG 24, Dagstuhl,, Germany (14th November, 2002) 12-Sep-03 Copyright PHWelch 1 occam 21 occam 3 CSP-M occam Communicatg Sequential Processes (CSP) occam-m transputers Handel-C JCSP (Java) CCS/pi-calculus mobile data, channel-ends and processes 12-Sep-03 Copyright PHWelch 2 Dynamic occam Introduction to Dynamic occam Motivation and Prciples Details Channel Ends and Direction Specifiers (and SHARED Channels) Dynamic Process Creation (FORK) Etended Rendezvous Process Priorities (32 levels now supported) Etensions (parallel recursion, nested PROTOCOL defitions, ) Eamples Dynamic Process Farms Interceptg Channel Communications Networked Channels RMoX and occweb Summary 12-Sep-03 Copyright PHWelch 3 Motivation and Prciples Motivation Classical occam embedded systems; hence pre-allocated memory (ie compile-time defed concurrency limits, array sizes and no recursion) It s long been time to move on Remove static constrats (but reta as a voluntary option for use hardware design and some embedded systems) Move towards general-purpose capability (because occam is too good to keep to ourselves ) Prciples for changes/etensions they must be useful and easy to use; they must be semantically sound and policed agast misuse; they must have very light implementation (nano-memory and warp speed); they must be aligned with the core language (no semantic, safety or performance disturbance) 12-Sep-03 Copyright PHWelch 4 Channel Ends and Direction Specifiers Channel Ends and Direction Specifiers out out y z tegrate + y + y + z y z tegrate + y + y + z PROC tegrate (CHAN INT?, out) An occam process may only use a channel parameter one-way (either for put or for output) That direction is specified (? or ), along with the structure of the messages carried this case, simple INTs The compiler checks that channel useage with the body of the PROC conforms to its declared direction 12-Sep-03 Copyright PHWelch 5 PROC tegrate (CHAN INT?, out) INITIAL INT total IS 0 INT serial? implementation total = total + out total 12-Sep-03 Copyright PHWelch 6 Channel Ends and Direction Specifiers Channel Ends and Direction Specifiers y z tegrate out + y + y + z y z c + 0 a b tegrate out + y + y + z PROC tegrate (CHAN INT?, out) parallel implementation PROC tegrate (CHAN INT?, out) CHAN INT a, b, c plus (?, c?, a) parallel delta (a?, out, b) prefi (0, b?, c) implementation 12-Sep-03 Copyright PHWelch 7 12-Sep-03 Copyright PHWelch 8 y z Java (JCSP) class IntegrateInt implements CSProcess { private fal ChannelInputInt ; private fal ChannelOutputInt out; } + 0 IntegrateInt public IntegrateInt (ChannelInputInt, ChannelOutputInt out) ) { this = ; thisout = out; } public void run () 12-Sep-03 Copyright PHWelch 9 out + y + y + z a out + y + y z c b + y + z 0 IntegrateInt public void run () { One2OneChannelInt a = ChannelcreateOne2OneInt (); One2OneChannelInt b = ChannelcreateOne2OneInt (); One2OneChannelInt c = ChannelcreateOne2OneInt (); Java new Parallel ( (JCSP) new CSProcess[] { new PlusInt (, c(), aout()), new Delta2Int (a(), out, bout()), new PrefiInt (0, b(), cout()) } )run (); } 12-Sep-03 Copyright PHWelch 10 Channel Ends and Direction Specifiers y z c + 0 a PROC tegrate (CHAN INT?, out) CHAN INT a, b, c plus (?, c?, a) delta (a?, out, b) prefi (0, b?, c) b tegrate out + y + y + z req buf? ret BUFMGR Channel types declare a bundle of channels that will always be kept together They are similar to the idea proposed for occam3, ecept that the ends of our bundles are mobile? req? buf ret? CHAN TYPE BUFMGR CHAN INT req? -- requested buffer size CHAN MOBILE []BYTE buf -- delivered array CHAN MOBILE []BYTE ret? -- returned array 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 12 req buf? ret BUFMGR? req? buf ret? req buf? ret BUFMGR? req? buf ret? CHAN TYPE BUFMGR CHAN INT req? -- requested buffer size CHAN MOBILE []BYTE buf -- delivered array CHAN MOBILE []BYTE ret? -- returned array CHAN TYPE BUFMGR CHAN INT req? -- requested buffer size CHAN MOBILE []BYTE buf -- delivered array CHAN MOBILE []BYTE ret? -- returned array and we also specify the directions of the component channels [channel bundles, like atomic channels, have two ends which we call, arbitrarily, the? (or ) end and the (or client ) end] 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 14 req buf? ret BUFMGR? req? buf ret? req buf? ret BUFMGR? req? buf ret? CHAN TYPE BUFMGR CHAN INT req? -- requested buffer size CHAN MOBILE []BYTE buf -- delivered array CHAN MOBILE []BYTE ret? -- returned array the formal declaration dicates these directions from the viewpot of the? end For these mobile channel types, variables are declared only for their ends Those ends are gog to be dependently mobile not the channel as a whole BUFMGR bufcli cli BUFMGR? bufsvr svr -- client -end variable -- -end variable They are allocated pairs dynamically bufcli cli, bufsvr = MOBILE BUFMGR 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 16 req buf? ret BUFMGR? req? buf ret? req buf? ret BUFMGR? req? buf ret? bufcli cli, bufsvr = MOBILE BUFMGR Those variables need to be given to separate parallel processes before it makes sense to use them eg MOBILE []BYTE b bufcli[req] cli[req 42 bufcli[buf]? b use b bufcli[ret] cli[ret b MOBILE []BYTE b INT s bufsvr[req]? s b = MOBILE [s]byte bufsvr[buf] b bufsvr[ret]? b 12-Sep-03 Copyright PHWelch 17 bufcli cli, bufsvr = MOBILE BUFMGR However, it s more fleible (and fun) to take advantage of their mobility Mobile channel-end variables may be assigned to each other and sent down channels strong typg rules apply, of course Recall, also, the basic rules of mobile assignment and communication once assigned or communicated from, the mobile variable becomes undefed It may not be used aga until re-allocated, assigned or communicated to 12-Sep-03 Copyright PHWelch 18 clichan (BUFMGR) svrchan (BUFMGR?) clichan (BUFMGR) BUFMGR? svrchan (BUFMGR?) client client CHAN BUFMGR clichan chan CHAN BUFMGR? svrchan chan (clichan svrchan chan) client (clichan?) (svrchan?) BUFMGR bufcli cli BUFMGR? bufsvr svr bufcli cli, bufsvr = MOBILE BUFMGR 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 20 clichan (BUFMGR) BUFMGR BUFMGR? svrchan (BUFMGR?) clichan (BUFMGR) svrchan (BUFMGR?) client client BUFMGR? BUFMGR bufcli cli BUFMGR? bufsvr svr bufcli cli, bufsvr = MOBILE BUFMGR clichan chan bufcli 12-Sep-03 Copyright PHWelch 21 BUFMGR bufcli cli BUFMGR? bufsvr svr bufcli cli, bufsvr = MOBILE BUFMGR clichan chan bufcli svrchan bufsvr -- bufcli and bufsvr are now undefed 12-Sep-03 Copyright PHWelch 22 clichan (BUFMGR) BUFMGR? svrchan (BUFMGR?) clichan (BUFMGR) BUFMGR BUFMGR? svrchan (BUFMGR?) client client PROC client (CHAN BUFMGR clichan?) BUFMGR cv PROC client (CHAN BUFMGR clichan?) BUFMGR cv clichan? cv 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 24 clichan (BUFMGR) BUFMGR BUFMGR? svrchan (BUFMGR?) clichan (BUFMGR) BUFMGR BUFMGR? svrchan (BUFMGR?) realclient realclient PROC client (CHAN BUFMGR clichan?) BUFMGR cv clichan? cv realclient (cv) PROC (CHAN BUFMGR? svrchan?) BUFMGR? sv 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 26 clichan (BUFMGR) svrchan (BUFMGR?) clichan (BUFMGR) svrchan (BUFMGR?) realclient BUFMGR? realclient BUFMGR? real PROC (CHAN BUFMGR? svrchan?) BUFMGR? sv svrchan? sv PROC (CHAN BUFMGR? svrchan?) BUFMGR? sv svrchan? sv real (sv) 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 28 clichan (BUFMGR) svrchan (BUFMGR?) clichan (BUFMGR) svrchan (BUFMGR?) realclient BUFMGR? real realclient (BUFMGR) real PROC realclient (BUFMGR call) PROC real (BUFMGR? serve) 12-Sep-03 Copyright PHWelch 29 PROC realclient (BUFMGR call) PROC real (BUFMGR? serve) 12-Sep-03 Copyright PHWelch 30 Shared Channel-Ends Shared Channel-Ends SHARED BUFMGR sbuf bufcli -- client -end variable BUFMGR? bufsvr svr -- -end variable sbuf bufcli, bufsvr = MOBILE BUFMGR i = 0 FOR nclients nclients may client2 (s sbufcli) be computed at (bufsvr) run-time 12-Sep-03 Copyright PHWelch 31 PROC client2 (SHARED BUFMGR sbuf bufcli) CLAIM sbuf bufcli sbuf bufcli MOBILE []BYTE b Only sbuf bufcli may not be channels may be sbuf bufcli[req] 42 used outside used with its sbuf bufcli[buf]? b of a CLAIM CLAIM block and use b sbuf bufcli[ret] b block no nested CLAIMs 12-Sep-03 Copyright PHWelch 32 Both Ends Shared Both Ends Shared SHARED BUFMGR sbuf bufcli -- client -end variable SHARED BUFMGR? sbuf bufsvr -- -end variable sbuf bufcli, sbuf bufsvr = MOBILE BUFMGR i = 0 FOR nclients nclients/s client2 (s sbufcli) may be computed i = 0 FOR ns at run-time 2 (s sbufsvr) 12-Sep-03 Copyright PHWelch 33 PROC 2 (SHARED BUFMGR? sbuf bufsvr) CLAIM sbuf bufsvr MOBILE []BYTE b sbuf bufsvr Other channels INT s may not be and nested client used outside CLAIMs may be sbuf bufsvr[req]? s used with a b = MOBILE [s]byte of a CLAIM CLAIM sbuf bufsvr[buf] b block block sbuf bufsvr[ret]? b 12-Sep-03 Copyright PHWelch 34 Both Ends Shared Both Ends Shared PROBLEM once a client and process have made their claims, they can do busess across the shared channel bundle Whilst this is happeng, all other client and processes are locked out from the communication resource SOLUTION use the shared channel structure just to enable clients and s to fd each other and pass between them a private channel structure Then, let go of the shared channel and transact busess over the private lks 12-Sep-03 Copyright PHWelch 35 CHAN TYPE CARRYBUFMGR CHAN BUFMGR? svr? Set up a similar network, but with the shared channel type beg CARRYBUFMGR (rather than BUFMGR) 12-Sep-03 Copyright PHWelch 36 Both Ends Shared Both Ends Shared CHAN TYPE CARRYBUFMGR CHAN BUFMGR? svr? A client process makes both ends of a non-shared BUFMGR channel and claims the shared channel When successful, it sends the -end of its BUFMGR down the shared channel This blocks until a process claims its end of the shared channel and puts that -end 12-Sep-03 Copyright PHWelch 37 CHAN TYPE CARRYBUFMGR CHAN BUFMGR? svr? Note that the client process, havg output the of its (unshared) BUFMGR channel, no longer has that -end and cannot use it or send it anywhere else Only that client has the client-end and only the receivg has the -end 12-Sep-03 Copyright PHWelch 38 Both Ends Shared CHAN TYPE CARRYBUFMGR CHAN BUFMGR? svr? Once that client and fish their busess, the should return the -end of the BUFMGR channel back to the client, who may then reuse it to send to someone else With a slightly modified defition of BUFMGR, its -end may be sent back down itself to the client 12-Sep-03 Copyright PHWelch 39 Dynamic Process Creation The construct creates processes dynamically, but the creatg process has to wait for them all to termate before it can do anythg else This is not always what we want Many processes need to be able to fork off new processes (whose memory will need to be allocated at run-time) and carry on concurrently with them Eamples clude web s and operatg systems But we are not operatg a free-for-all heap our new occam strict aliasg control is mataed even for dynamically allocated structures So, we must take care about memory referenced by long-lived forked processes 12-Sep-03 Copyright PHWelch 40 Dynamic Process Creation Dynamic Process Creation FORKING WHILE test FORK P (n, answer,, out) Can only FORK processes with a FORKING block All FORKed processes must termate before a FORKING block can termate FORKING VAL data are copied to a WHILE test FORKed process FORK P (n, answer,, out) Otherwise, it may have ceased to eist before the FORKed process termates MOBILE data and channel-ends are moved to a FORKed process Reference data must be SHARED and declared global to the FORKING block 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 42 Dynamic Process Creation (DCONN?) Dynamic Process Creation (DCONN?) tosw (CCONN) tosw (CCONN) fefarm fefarm feproc feproc feproc (DCONN) (DCONN) (DCONN) 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 44 Dynamic Process Creation PROC fefarm (CHAN DCONN??, SHARED CCONN tosw sw) DCONN? local FORKING INITIAL INT c IS 0? local FORK feproc (c, local, tosw sw) c = c + 1 Outle of the front-end process farm handlg comg connections to the dynamic version of the occam web PROC feproc (VAL INT n, DCONN?,, SHARED CCONN tosw sw) 12-Sep-03 Copyright PHWelch 45 A poolmanager is responsible for a pool of workers who queue up to request work packets from a farmer The poolmanager must ensure that at least midle workers are always waitg to request new packets Each worker must keep the poolmanager formed as to whether it is workg or idle The poolmanager matas a count of how many workers are idle and FORKs off new ones as the need arises Of course, this means the number of workers can never decrease it can only ever keep growg Limitg the number of idle workers to maidle is left as an eercise 12-Sep-03 Copyright PHWelch 46 farmer (WIN) CHAN TYPE WIN CHAN BOOL request? CHAN MOBILE []BYTE work poolmanager VAL INT midle IS SHARED WIN cli WIN? svr SHARED WOUT outcli WOUT? outsvr create any-1 channels harvester (WOUT) CHAN TYPE WOUT CHAN MOBILE []BYTE result? cli, svr = MOBILE WIN outcli, outsvr = MOBILE WOUT farmer (svr) poolmanager (midle, cli, outcli) harvester (outsvr) create network 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 48 PROC farmer (WIN? workers) MOBILE []BYTE packet manufacture work packet BOOL any workers[request]? any workers[work] packet farmer (WIN) farmer (WIN) poolmanager PROC harvester (WOUT? workers) MOBILE []BYTE packet workers[result]? packet consume result packet harvester (WOUT) harvester (WOUT) 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 50 farmer harvester (WIN) (WOUT) (SIGNAL) poolmanager CHAN TYPE SIGNAL CHAN INT count? -- workg (-1) or idle (+1) 12-Sep-03 Copyright PHWelch 51 PROC worker (SHARED WIN, SHARED WOUT out, SHARED SIGNAL signal) MOBILE []BYTE packet CLAIM [request] TRUE [work]? packet CLAIM signal signal[count] 1 -- say we are workg do the work CLAIM out out[result] packet -- hopefully, a modified one CLAIM signal signal[count] say we are idle 12-Sep-03 Copyright PHWelch 52 farmer harvester (WIN) (WOUT) (SIGNAL) poolmanager CHAN TYPE SIGNAL CHAN INT count? -- workg (-1) or idle (+1) 12-Sep-03 Copyright PHWelch 53 PROC poolmanager (VAL INT midle, SHARED WIN, SHARED WOUT out) SHARED SIGNAL signalcli SIGNAL? signalsvr signalcli, signalsvr = MOBILE SIGNAL create any-1 channel FORKING INITIAL INT nidle IS 0 (nidle midle) == FORK new workers INT n signalsvr[count]? n -- workg/idle (-1/+1) nidle = nidle + n 12-Sep-03 Copyright PHWelch 54 {{{ (nidle midle) == FORK new workers VAL INT needed IS midle nidle IF needed 0 i = 0 FOR needed FORK worker (, out, signalcli) nidle = midle TRUE SKIP }}} The dynamic management of process farms is one of the common design idioms used to support RMoX ( Raw Metal occam i ) - an eperimental operatg system for general and real-time embedded applications, built eclusively on this etended CSP model and programmed (almost and eventually) entirely occam 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 56?? rendezvous block The outputtg process is unaware of the etended nature of the rendezvous Etended Rendezvous This is a convenience and it s free wait for put but do not reschedule outputtg process reschedule outputtg process only after the rendezvous block has termated Etended Rendezvous They can be used as ALT guards guards ALT a? react?? rendezvous block react (optional and outside the rendezvous) tim? AFTER timeout react 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 58 Etended Rendezvous Here is an formal operational semantics Etended Rendezvous Not that it s implemented that way c 42 c c?? rendezvous block c 42 c c?? rendezvous block BOOL any c 42 cack? any = c cack c? rendezvous block cack TRUE No additional overheads for normal channel communication = Implementation is very lightweight (appro 30 cycles) no change outputtg process code; BOOL new occam any Virtual cmache (ovm) structions for?? c? Solves c a 42 long-standg semantic anomaly rendezvous of unhandled block tags cack variant? any protocols cack cack TRUE ((d apple) (d? CASE banana)) = STOP 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 60 Etended Rendezvous Taps Etended Rendezvous Taps recall CHAN TYPE CARRYBUFMGR CHAN BUFMGR? svr? A client process makes both ends of a non-shared BUFMGR channel and claims the shared channel When successful, it sends the -end of its BUFMGR down the shared channel This blocks until a process claims its end of the shared channel and puts that -end 12-Sep-03 Copyright PHWelch 61 recall CHAN TYPE CARRYBUFMGR CHAN BUFMGR? svr? Once that client and fish their busess, the should return the -end of the BUFMGR channel back to the client, who may then reuse it to send to someone else With a slightly modified defition of BUFMGR, its -end may be sent down itself back to the client 12-Sep-03 Copyright PHWelch 62 Etended Rendezvous Taps Etended Rendezvous Taps tap tap tercept tercept logger Note client and processes are unchanged logger Intercept the sent BUFMGR? and forward our own 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 64 Etended Rendezvous Taps Etended Rendezvous Taps tap tap tercept ltap tercept ltap logger FORK ltap process and plug loose ends logger client and processes cannot detect the taps 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 66 Etended Rendezvous Taps Etended Rendezvous Taps PROC tap (CARRYBUFMGR?, out, SHARED LOG log) FORKING BUFMGR? clientsvr, tapsvr BUFMGR tapcli tapcli, tapsvr = MOBILE BUFMGR [svr]?? clientsvr out[svr] tapsvr FORK ltap (clientsvr, tapcli, log) PROC ltap (BUFMGR?, BUFMGR out, SHARED LOG log) tap the req channel tap the buf channel tap the ret channel PROC ltap (BUFMGR?, BUFMGR out, SHARED LOG log) tap the req channel tap the buf channel tap the ret channel 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 68 Etended Rendezvous Taps Etended Rendezvous Taps PROC ltap (BUFMGR?, BUFMGR out, SHARED LOG log) {{{ tap the req channel BOOL b [req]?? b out[req] b CLAIM log log[report] request; b }}} tap the buf channel tap the ret channel PROC ltap (BUFMGR?, BUFMGR out, SHARED LOG log) tap the req channel tap the buf channel tap the ret channel 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 70 Etended Rendezvous Taps Etended Rendezvous Taps PROC ltap (BUFMGR?, BUFMGR out, SHARED LOG log) tap the req channel {{{ tap the buf channel MOBILE []BYTE b out[buf]?? b [buf] b CLAIM log log[report] supplied; SIZE b }}} tap the ret channel PROC ltap (BUFMGR?, BUFMGR out, SHARED LOG log) tap the req channel tap the buf channel tap the ret channel 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 72 Etended Rendezvous Taps Networked Channel Structures PROC ltap (BUFMGR?, BUFMGR out, SHARED LOG log) tap the req channel tap the buf channel {{{ tap the ret channel MOBILE []BYTE b [ret]?? b out[ret] CLONE b CLAIM log log[report] returned; b }}} CHAN TYPE CARRYBUFMGR CHAN BUFMGR? svr? Back to the origal design but this time, we want to stretch the shared (CARRYBUFMGR) channel over some communication network without changg the semantics of the system 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 74 Networked Channel Structures Networked Channel Structures t r t r NETWORK (TCP/IP, Firewire, 1355, ) NETWORK (TCP/IP, Firewire, 1355, ) Note client and processes are unchanged Note client and processes are unchanged 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 76 Networked Channel Structures Networked Channel Structures t r t r tp rp NETWORK (TCP/IP, Firewire, 1355, ) NETWORK (TCP/IP, Firewire, 1355, ) Note and client still and detect no change processes system are unchanged semantics and still detect no change system semantics 12-Sep-03 Copyright PHWelch Sep-03 Copyright PHWelch 78 Networked Channel Structures kroc//fooukcacuk To set this up, the KRoC programmer (designer) only constructs the named networ
Search
Similar documents
View more...
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks