Migraing Proocols In Muli-Threaded Message-Passing Sysems Ausin Anderson Universiy of Souhampon ama08r@ecs.soon.ac.uk Julian Rahke Universiy of Souhampon jr2@ecs.soon.ac.uk Absrac Dynamic sofware updae is a echnique by which a running program can be updaed wih new code and daa wihou inerruping is execuion. Ofen we will wan o preserve properies of programs across updae boundaries. Preserving simple yping across updae boundaries for single-hreaded programs is well sudied. There are oher higher-level properies we may wish o preserve, paricularly for muli-hreaded programs. Session yping is used o guaranee ha a se of parallel hreads communicae according o a given proocol. Hence we invesigae preserving correc communicaions behaviour of a se of parallel hreads correcly across updae boundaries which change he running proocol. We presen a procedure for updaing muliple hreads o cleanly migrae a sysem from one proocol o anoher. Caegories and Subjec Descripors D.1.2 [Programming Techniques]: Auomaic Programming - program modificaion, program ransformaion; D.1.3 [Programming Techniques]: Concurren Programming - muli-hreaded programming; D.2.7 [Sofware Engineering]: Disribuion, Mainenance, and Enhancemen; D.3.1 [Programming Languages]: Formal Definiions and Theory General Terms Languages, Typing Keywords Dynamic Sofware Updae, Muli-Pary Session Types, Disribued-Proocols 1. Inroducion Dynamic sofware updae is a echnique by which a running program can be updaed wih new code and daa wihou inerruping is execuion [13]. Generally here are various behaviours which are considered safe or unsafe, in a given siuaion. We can use safey properies o guaranee ha we do no perform any unsafe acions. Simple ype safey is an obvious example of such a propery and preserving simple ype safey for updaes o single hreaded programs is well sudied [8, 13]. In a muli-hreaded sysem here are more complex behaviours and hence more complex safey properies which canno be reasoned abou using simple ype safey alone. The inabiliy o provide safey for muli-hreaded sysems is a significan resricion of he analyses for single-hreaded sysems. Permission o make digial or hard copies of all or par of his work for personal or classroom use is graned wihou fee provided ha copies are no made or disribued for profi or commercial advanage and ha copies bear his noice and he full ciaion on he firs page. To copy oherwise, o republish, o pos on servers or o redisribue o liss, requires prior specific permission and/or a fee. HoSWUp 09, Ocober 25, 2009, Orlando, Florida, USA. Copyrigh 2009 ACM ISBN 978-1-60558-723-3/09/10... $10.00 Muli-hreaded session yping is a ype discipline used o ensure ha a se of parallel hreads communicae according o a specific proocol [3]. In our earlier work we presen a mechanism o updae individual hreads in a muli-hreaded sysem such ha he updaed hread will coninue o communicae according o he correc proocol afer he updae as before he updae [2]. We refer o his propery as updae safey. In ha work we presen a saic analysis which we use o guaranee (and prove) subjec reducion and fideliy and lineariy safey properies. The mos imporan safey propery is ha of fideliy, which saes ha for each possible communicaion acion for he code we have a corresponding possible sep in he proocol. In ha work an updaed hread coninues wih he same proocol and hence he updae is invisible o he oher hreads. We refer o such an updae as an inernal updae. Our conribuion in ha work is o permi inernal updaes o hreads which can change he funcion bodies of named funcions. We also exend he session yping discipline by permiing non-ail-recursive funcion calls. Migraing a muli-hreaded sysem from one proocol o anoher requires ha we updae muliple hreads; we clearly canno change he communicaions behaviour of a hread running one end of a proocol wihou changing he oher end. We refer o such updaes as sysem updaes. We refer o he updaes o individual hreads as hread updaes. A sysem updae includes muliple hread updaes. Hence we also discuss sysem updaes in he conex of muliple updaes, as a sysem updae will updae muliple hreads. If we use a mehodology of applying he hread updaes from a given sysem updae separaely, migraing each hread independenly from he old proocol o he new, we can produce errors. We presen an example error which can occur from such a mehodology. Hence in order o cleanly migrae from he old proocol o he new we mus provide some coordinaion of he applicaions of he updaes o individual hreads. Our conribuion in his paper is a coordinaion procedure which should rule ou errors of he form we demonsrae. We rely on our saic analysis which guaranees subjec reducion and preservaion of fideliy and lineariy. We do no presen his analysis; i is essenially he analysis we presened in our prior work [2]. Using our coordinaion procedure we should be able o safely migrae a mulihreaded sysem from one communicaions proocol o anoher. The res of he paper is srucured as follows. In Secion 2 we describe our language and global session ypes which we use o describe proocols. In Secion 3 we presen wo examples o moivae he problem and demonsrae he ype of error we wish o rule ou. In Secion 4 we describe our proposed soluion, which includes a disribued proocol o deermine when each hread should apply an updae. In Secion 5 we presen relaed work. In Secion 6 we conclude and presen fuure work.
2. Language and Types Our language is a firs order, call-by-value, funcional programming language wih named funcions. We provide communicaions primiives which reques and accep saring a session, send and receive values, and selec and accep selecion of services (a pah for he proocol o ake ou of several opions). These primiives are based on hose presened in he session yping lieraure [3]. We also provide le expressions and if expressions. Sequenial composiion e 1; e 2 is considered synacic sugar for le x = e 1 in e 2 where x is free in e 2. Finally we also include he updae command. The updae which is applied is no specified in he code; if i were i would no be a dynamic updae. The updae command is an updae poin which applies, if i can, any updae which is relevan o he hread in which i is execued. If here are no relevan updaes hen we simply perform skip. An updae is provided a run ime by an ou-of-band communicaions mechanism. In our sysem we do no communicae beween hreads, bu beween roles. A role can only be held by a single hread a any one ime, bu a role can be ransferred from one hread o anoher, permiing us o describe some high level communicaions behaviours (higher order session yping). We provide he definiive descripion of a communicaions proocol ha a group of roles follow using global session ypes. We define global session ypes, ranged over by G, in he folowing grammar: G ::= p p : U Send a value of ype U where p / p p p : {l i : G i} Send a label in {l i} where p / p G.G Sequenial composiion µ.g Recursion Recursion variable The ype p p : U denoes ha role p will send a value of ype U o roles p (a se of roles which does no include p). The ype p p : {l i : G i} denoes ha role p will send a label l i o roles p. Afer sending label l i he session will coninue wih session ype G i. This permis us o permi he proocol o proceed using one of several specified sub-proocols. The ype G 1.G 2 denoes sequenial composiion; he global session will firs perform G 1 hen G 2. The ype µ.g denoes recursion, on recursive variable. As proocols can include more han wo roles muli-pary communicaions can be represened by a single global session ype. We refer o global session ypes and proocols inerchangeably. The proocol could be inferred from he code, bu we require he programmer o explicily sae he global session ype for each session. Our global session ypes are based on hose in he lieraure [3, 9] We use a global queue for handling messages. When a hread is sending a value i will append he message on o he end of he queue. When a hread is receiving a value i will search hrough he queue from he fron, removing he firs message for he role on which he hread is receiving. This provides asynchronous communicaion where a receiving hread can block o wai for a message o be pu on he queue, bu sending hreads do no block waiing for a receiving hread o be ready. Along wih our session yping sysem presened in our proper work [2] his permis us o guaranee he order in which messages will be received and hence he ypes of he values being received. Informally his ype sysem guaranees ha for each send here is a complemenary receive (i.e. for hree sends which send, in order, an ineger hen a boolean hen an ineger hen here will be hree receives, expecing exacly hose ypes in ha order). P 1 P 2 P 1 = i, d 1 P 2 = j, d 2 d 1 = fun f(x) = e 1 in main e 2 e 1 = send(x, p 2, 1) ; send(x, p 2, 2) ; receive(x, p 2) ; f(x) e 2 = le x = reques(s, {p 1, p 2}, p 1) in f(x ) d 2 = fun g(y) = e 3 in main e 4 e 3 = le z 1 = receive(y, p 1) in le z 2 = receive(y, p 1) in send(y, p 2, z 1 + z 2) ; g(y) e 4 = le y = accep(s, p 2) in g(y ) Figure 1. Code which implemens simple mah server 3. Problem Exposiion and Examples In Secion 3.1 we presen a simple mahs server, based on an example presened in he lieraure [6]. We use his example o illusrae he ype of error which we wan o preven. In Secion 3.2 we presen a producer-consumer relaionship, and an updae o is proocol. We illusrae how we do no need hreads o block and synchronise emporally, which would cause overhead when hreads are waiing for ohers. Insead we can coordinae he updaes wih respec o fulfilling communicaions responsibiliies wihin a proocol, specifically ha each hread performs he same number of runs hrough he old proocol before migraing o he new proocol. 3.1 Mahs Server Example We presen a mahs server where a clien sends wo inegers o a server and he server reurns heir sum. The proocol for his mahs server is: G A = µ. p 2 p 1 : INT. G 1 = G 2 = p 1 p 2 : INT p 2 p 1 : INT Here p 1 is he clien and p 2 is he server: p 1 sends p 2 wo inegers and p 2 reurns a hird, heir sum. This proocol coninues recursively. We define a sysem which implemens his proocol in Figure 1. We define wo program hreads, P 1 and P 2, which have hread idenifiers i and j and bodies d 1 and d 2 respecively. Thread body d 1 defines a recursive funcion f, iniiaes a session s, and passes he channel which i obains by he session iniiaion o he funcion f. Funcion f is defined so ha, using he channel passed o i as argumen x, i sends wo inegers, receives back a hird ineger, and hen recursively calls iself passing iself he channel as is parameer. Thread body d 2 defines a funcion g, acceps he session being iniiaed, and calls funcion g wih he channel i obains. Funcion g performs he complemenary acions o hose of f, which are wo receives and a send, and hen recursively calls iself. Consider a siuaion where we wan o migrae o a new proocol which permis p 2 o, afer having received he wo inegers, eiher signal a success and reurn he resul or signal an error and reurn nohing, and hen in boh cases o coninue recursively. The case of reurning an error and no resul could be used o deal wih excepions in he server, for example in he case of overflow. We can describe his proocol as follows: G B = µ. G 1. p 2 p 1 : {resul : G 2., error : }
This exends he previous proocol, as we are sending an addiional message, he label which denoes success or error, o he hree values we were sending in G A. We define a sysem which implemens his new proocol in Figure 2. This is a modificaion of he code presened in Figure 1, where we have simply replaced he bodies of funcions f and g wih e 5 and e 7 respecively. Here he selec consruc permis one hread o decide how he session will coninue, eiher by signalling a resul and sending an ineger o i and a recursive call, or by signalling an error and a recursive call. For he purposes of his example we choose o signal an error if he firs argumen is negaive. In our sysem we do no subsiue he funcion body for funcion calls a he poin when we define he funcion (which is fun f(x) = e in d). Insead we provide a heap for each hread which binds he funcion name o he funcion body. Thereafer each ime we encouner a funcion call in ha hread we replace i wih he funcion body, wih he argumens o he funcion call subsiued for he relevan parameer variables. In order o migrae from a sysem implemening he firs proocol o a sysem implemening he second all we need o do is replace he funcion bodies of f and g. Since we sore he bodies in he heap, we can simply modify he mapping, and he nex ime he funcion is called hen he new implemenaion will be used. This does no replace he inlined code of a funcion which is running a he ime of an updae. To safely perform such an updae we canno updae he wo hreads independenly; we mus perform some coordinaion of when updaes occur. We argue his requiremen informally below. Consider he sysem P 1 P 2 defined in Figure 1, and an updae which changes he funcion bodies of f and g from e 1 and e 3 o e 5 and e 7 respecively. To describe he ype of error ha can occur we firs mus describe he concep of compleing runs of a proocol for a given role. If a global session ype (proocol) is a loop a op level (e.g. G A and G B) hen we consider performing he communicaion acions of he body of he loop as performing one run of ha proocol. Differen roles will perform differen communicaion acions o perform one run of he proocol: in G A role p will perform wo sends and a receive and role q will perform wo receives and a send. Jus as roles and hreads are separae, runs of a proocol are separae from code conrol flow: a hread may inernally perform wo ieraions of is main loop o perform one run of he proocol. The noion of a role is specified in he session ype iself; o implemen his we may need o annoae he code. We sar P 1 P 2, and we evaluae he hreads unil boh have compleed one run of he proocol, resuling in he hreads: i, f(k 1) j, g(k 2) where k 1 and k 2 are he channels which he hreads are using o communicae. Since each hread has compleed one run of he proocol, a his poin wo inegers have been sen from P 1 o P 2, a hird has been sen in response, and all hese values have been received. We can hen evaluae one sep resuling in he hreads: i, e 1{k 1/x} j, g(k 2) which performs he funcion call f in P 1. If a his poin we perform he updae and hen coninue o evaluae he funcion call o g in P 2 hen we will have: i, e 1{k 1/x} j, e 7{k 2/y} Wih his configuraion, he expressions e 1 and e 7 will aemp o communicae. This, however, will lead o an error since, as we saed earlier, e 7 performs more communicaions acions han e 5, and hence when e 1 is waiing o receive an ineger as he resul, e 7 will be aemping o send a label o indicae how i wans o coninue he session. Hence we need o perform some form of coordinaion on when we perform updaes, o ensure ha such errors do no occur. P 3 P 4 P 3 = i, d 3 P 4 = j, d 4 d 3 = fun f(x) = e 5 in main e 2 e 5 = send(x, p 2, 1) ; send(x, p 2, 2) ; e 6 e 6 = case(x, p, {resul : receive(x, p 2), error : ()}) ; f(x) e 2 = le x = reques(s, {p 1, p 2}, p 1) in f(x ) d 4 = fun g(y) = e 7 in main e 4 e 7 = le z 1 = receive(y, p 1) in le z 2 = receive(y, p 1) in e 8 e 8 = (if z 1 < 0 hen selec(y, p 1, error) else selec(y, p 1, resul) ; send(y, p 2, z 1 + z 2)) ; g(y) e 4 = le y = accep(s, p 2) in g(y ) Figure 2. Code which implemens more complex mah server 3.2 Producer-Consumer Example In he mahs server example he wo hreads will only be one run removed from each oher, due o he fac ha each has o wai o receive from he oher. Proocols do no always have such a ighly coupled relaionship. Consider a producer-consumer sysem, defined by he proocol: G C = µ. p p p c : BOOL. where on each run of he proocol he producer sends he consumer wo inegers and a boolean. In his siuaion he producer could, a imes, be producing much faser han he consumer is consuming. Consider he siuaion where he producer has seamed ahead and performed five runs of he proocol, whils he consumer has only performed he proocol once. For he producer one run of he proocol consiss of sending wo inegers and a boolean, and hence in his scenario i has performed fifeen sends. For he receiver one run of he proocol consiss of hree receives, and hence in his scenario i has performed hree receives. Hence he consumer has an addiional welve values siing in he queue waiing o be received. A his poin he producer could perform an updae and migrae o a new proocol: G D = µ. p p p c : BOOL. where i only sends one ineger and a boolean. I could hen go ahead and produce under he new proocol. However, he consumer could no updae a his poin - i sill has four runs worh of messages waiing for i in he queue. Hence i mus perform he remaining four runs of he proocol, so ha i ends up having performed he correc complemenary acions o he producer (specifically he same number of receives, wih he same ypes, in he same order, as he producer has performed sends). Afer having performed hese acions he consumer can perform he updae and migrae o he new proocol.
4. Proposed Soluion We use sysem updaes o migrae a sysem from one proocol o anoher. A sysem updae includes muliple hread updaes which updae hreads which are involved in he old proocol. Our saic analysis, essenially ha presened in our previous work [2], is sufficien o guaranee ha afer a hread has been updaed wih a well yped updae hen he hread will perform communicaions acions according o he new proocol. Hence we can guaranee correcness of migraing individual hreads o a new proocol. Though he individual hreads can be guaraneed o cleanly migrae o he new proocol, if he hread updaes are applied a he wrong imes hen we can cause errors. We demonsrae such an error in he evaluaion of he mahs server example in Secion 3.1. Inuiively, he error highlighed in he example is ha one hread has begun anoher run of he old global proocol, whils he oher has migraed o he new global proocol. Hence hreads may receive values which hey are no expecing or may never be sen he values hey are expecing. This violaes he fideliy safey propery discussed in Secion 1 as he proocol would be performing communicaion acions for which here are no corresponding communicaion in he proocol. In order o rule ou such errors we need o ensure ha all hreads which are involved in a session migrae o he new session afer having compleed he same number of runs of he old proocol. Afer he above saic analysis has been used o guaranee ha each hread will individually behave correcly, safey becomes a runime coordinaion problem. This coordinaion does no require performing any dynamic yping or analyses, and simply is conrolling when hread updaes are applied. A sysem updae, whose hread updaes are all correc, can always be applied; he runime coordinaion will never rejec i. In order o aid reasoning abou runs of a proocol we keep a coun of how many runs have been compleed by each role in ha proocol. This coun, which we refer o as run numbers, denoes how many runs hrough a proocol have been performed by ha role in he proocol. We have o incremen he run number of a role every ime he hread sars a new run of he global session of which ha role is a par. We are no couning loops in he conrol flow of hreads bu simply keeping rack of he communicaion acions ha have been preformed by a role. Each hread can ake par in muliple sessions, including muliple insances of a proocol, and hence each hread can have muliple roles. We augmen each hread wih a mapping from roles o run numbers. One possible coordinaion approach is he naive sop-he-world mehod, which is he following. Afer an updae has been inroduced o he sysem we define some run number n which is greaer han he curren run number associaed wih any of he roles involved in he session being updaed. We hen block each hread afer i has compleed n runs. When all hreads have blocked hen we updae he code of all of he hreads simulaneously and safely proceed wih he new proocol. Whils his approach would be safe i requires us o block hreads o he exen ha we are almos sopping he program and resaring. This is a odds wih dynamic sofware updae, one of whose primary aims is o provide updaes wihou having o shu down sysems. Insead we can make use of he fac ha we use a queueing archiecure for message passing. The example in Secion 3.2 demonsraes how one hread can safely migrae o he new proocol before anoher. This is as any messages i sends as par of he new proocol will be pu a he back of he queue, and any receives i aemps o do as par of he new proocol will require i o wai for he sender o be using he new proocol. Hence he hreads can migrae o he new proocol separaely, wihou requiring synchronising. The poin a which each hread can migrae is coordinaed as follows. Each hread has an associaed mapping from channels s.p which ha hread is using o run numbers n i (as discussed above). The channel s.p includes he name of he session s and he role p. The mapping is defined as he parial funcion runnumber(p). The mapping for hread i is annoaed as runnumber(p) i. We define he updae run number o be: n = max(runnumber(s.p) i) i I + 1 where I is he se of hread idenifiers of he hreads which are being updaed and s is he name of he proocol we are updaing. Inuiively he updae run number is he number of runs hrough he old proocol a hread mus complee afer which i mus migrae o he new proocol. Hence afer a hread has compleed proocol run n i applies he updae and migraes o he new proocol. We se he updae run number o he maximum run number plus one. To explain his consider again he evaluaion of he mah server in Secion 3.1: i, f(k 1) j, g(k 2) i, e 1{k 1/x} j, g(k 2) Whils hese hreads have boh compleed he same number of runs of he proocol, hread i has looped and sared he code which will perform he nex run of he old proocol. If he nex evaluaion sep is applying he updae hen we can coninue o evaluae o: i, e 1{k 1/x} j, e 7{k 2/y} and hence have wo differen versions of he proocol aemping o inerac. Since a recursive funcion call is concepually an inernal acion we do no wan o reason abou i. Insead we assume ha, a he poin of generaing he updae run number, he hread wih he greaes run number could have sared he nex run. Hence we se he updae run number o one more han he greaes run number. Once each individual hread has compleed n runs of he old proocol i can safely perform he updae and migrae o he new proocol. Due o he queueing archiecure any messages sen afer his migrae will be placed a he back of he queue, and hence oher hreads which have no ye performed he updae should receive exacly he righ number and ype of messages in heir remaining runs of he old proocol. We canno define he updae run number a compile ime as we do no know when he updae will be provided o he sysem. However, as he runime coordinaion is concerned only wih when, no if, we will apply an updae hen we reain a purely saic analysis. One implemenaion issue o noe is ha in order o calculae he updae run number we require a snapsho of he mappings from channels o run numbers for all he hreads involved in a proocol being updaed. This will necessiae a lock on he hreads involved in he proocol, bu only for he shor amoun of ime required o calculae he updae run number as above. Such a lock is a small operaion in comparison o he naive approach which requires locking each hread once i has compleed n runs unil all hreads have reached compleed n runs. 5. Relaed Work In early work on session yping [9] presens an asynchronous mulipary session ype sysem which includes a limied form of delegaion and a progress propery o guaranee ha a well yped session will no deadlock, in and of iself. The work in [3] builds on [9] o provide full, ransparen, delegaion as well as a progress guaranee ha differen well yped sessions will no inerfere wih each oher and cause deadlock. Mos work on session ypes use π calculus syle calculi. Some work uses a λ calculus formulaion [6, 7] which we used in our analysis o guaranee updae safey [2]. All known previous work on session yping resrics funcion calls o ail calls
in order o simplify he yping. In our updae safey analysis we remove his resricion by making of ype and effec sysems [12]. There are several exising formal analyses for DSU. Early work includes [4] which presens a firs-order, simply-yped, call-byvalue lambda calculus, wih he addiion of a module sysem and an updae primiive. An updae can change he code of a module, bu no is ype signaure. The programmer can inroduce new versions of modules. There is no limi on how many versions of a module he sysem can have loaded, and code can make explici which module versions i is willing o use. The updae sysem guaranees ype safey of code using differen module versions. Following his work [13] presens a C like language, including sae, poiners and records (which can be use o implemen srucures) and faciliies o dynamically updae code. The granulariy of updae in his paper is a funcion; hence he programmer can change he funcion body (and ype signaure) of any funcion and he sysem will ensure ha he updaed code is sill ype safe. This sysem also permis updaes o modify an absrac daa ype and hence he daa iems of he ype being modified mus also be modified so ha hey conform o he new ype. Hence in his sysem when modifying an absrac daa ype he programmer mus include a funcion o ransform values from he old ype o he new ype. The work in [11] consiss of a similar DSU sysem o [13], bu insead of specifying updae poins hey address he issue of when updaes should occur using ransacional echniques from daabase research. In heir language he programmer can delineae regions of code inside which she does no wish an updae o he code o (visibly) occur. This work is exended o MDSU in a recen paper where one can infer hese regions and use a check in proocol o only perform he updae when all hreads are ready o perform i [10]. Experimenal resuls of he delay beween updaes being inroduced and when a suiable updae poin occurs and discussion abou he balance beween safey and imeliness are also presened. Objec updaing is approached in several papers [1, 5] which presen a sysem which permis objecs o be updaed in arbirary ways a differen imes. Hence i is possible o inerac wih an older or newer version of an objec inerface. To deal wih his he auhors use simulaion objecs and shadow mehods o indicae he effec of older or newer mehods on he curren objec. The auhors provide an implemenaion and informal safey properies. 6. Conclusions and Fuure Work We presened an example error which can occur when applying hread updaes in an uncoordinaed manner. We presened a soluion which provides he relevan coordinaion as o when o apply each updae o each hread. This soluion does no require any hread o block and wai for ohers o be ready o perform he updae, and hence minimises overhead in he disribued updae procedure. This approach does no appear, however, o be applicable o he shared sae paradigm unless read and wrie queues were used for shared sae access. As fuure work we plan o develop he echnical deails of he proposed updae procedure. This will involve developing mechanisms for hreads o signal ha hey have finished an run of a loop, examining how inernal updae commands inerac wih he updae procedure, developing a ype sysem o analyse such sysems, and proving ype safey, lineariy and fideliy properies similar o hose in in our previous work [2]. [2] Ausin Anderson and Julian Rahke. Safe dynamic sofware updae for muli-hreaded message-passing sysems (draf), 2009. hp://eprins.ecs.soon.ac.uk/18041/. [3] Lorenzo Beini, Mario Coppo, Loris D Anoni, Marco De Luca, Mariangiola Dezani-Ciancaglini, and Nobuko Yoshida. Global progress in dynamically merged mulipary sessions. Technical repor, 2008. hp://www.doc.ic.ac.uk/~yoshida/paper/ global_progress.pdf. [4] G. Bierman, M. Hicks, P. Sewell, and G. Soyle. Formalizing dynamic sofware updaing. In Proceedings of he 2nd Inernaional Workshop on Unanicipaed Sofware Evoluion. Warsaw, Poland, 2003. [5] Rasekhar Boyapai, Barbara Liskov, Liuba Shrira, Chuang-Hue Moh, and Seven Richman. Lazy modular upgrades in persisen objec sores. In In Objec-Oriened Programming, Sysems, Languages, and Applicaions (OOPSLA, pages 403 417, 2003. [6] Simon Gay, V. T. Vasconcelos, and Anonio Ravara. Session ypes for iner-process communicaion. Technical Repor 133, Deparmen of Compuing, Universiy of Glasgow, 2003. [7] Simon Gay and Vasco T. Vasconcelos. Asynchronous funcional session ypes. Technical Repor 2007 251, Deparmen of Compuing, Universiy of Glasgow, May 2007. [8] Michael Hicks and Sco Neles. Dynamic sofware updaing. ACM Trans. Program. Lang. Sys., 27(6):1049 1096, 2005. [9] Kohei Honda, Nobuko Yoshida, and Marco Carbone. Mulipary asynchronous session ypes. SIGPLAN No., 43(1):273 284, January 2008. [10] Iulian Neamiu and Michael Hicks. Safe and imely updaes o muli-hreaded programs. SIGPLAN No., 44(6):13 24, 2009. [11] Iulian Neamiu, Michael Hicks, Jeffrey S. Foser, and Polyvios Praikakis. Conexual effecs for version-consisen dynamic sofware updaing and safe concurren programming. SIGPLAN No., 43(1):37 49, 2008. [12] Flemming Nielson and Hanne Riis Nielson. Type and effec sysems. In Correc Sysem Design, Recen Insigh and Advances, (o Hans Langmaack on he occasion of his reiremen from his professorship a he Universiy of Kiel), pages 114 136, London, UK, 1999. Springer- Verlag. [13] Gareh Soyle, Michael Hicks, Gavin Bierman, Peer Sewell, and Iulian Neamiu. Muais muandis: Safe and predicable dynamic sofware updaing. In Proceedings of he 32 nd ACM SIGPLAN- SIGACT symposium on Principles of Programming Languages (POPL), pages 183 194, 2005. References [1] Sameer Ajmani, Barbara Liskov, Liuba Shrira, and Google Inc. Modular sofware upgrades for disribued sysems. In In Proceedings of he 20h European Conference on Objec-Oriened Programming, pages 452 476, 2006.