1 / 41

On the expressive power of synchronization primitives in the π -calculus

Explore the expressive capabilities of synchronization primitives in the π-calculus, including mixed choice scenarios, asynchronous and probabilistic variations, and their impact on distributed implementations. Learn about the π hierarchy and encoding strategies, operational semantics, and features enhancing expressive power.

marjoryr
Download Presentation

On the expressive power of synchronization primitives in the π -calculus

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. On the expressive power of synchronization primitives in the π-calculus Catuscia Palamidessi, INRIA Saclay, France BASICS'09, Shanghai

  2. Focus on the -calculus • Contents • The -calculus with mixed choice () • Expressive power of the -calculus and problems with its fully distributed implementation • The asynchronous -calculus (a) • The π hierarchy • Towards a randomized fully distributed implementation of  • The probabilistic asynchronous -calculus (pa) • Encoding  into pa using a generalized dining cryptographers algorithm BASICS'09, Shanghai

  3. The p-calculus • Proposed by [Milner, Parrow, Walker ‘92]as a formal language to reason about concurrent systems • Concurrent: several processes running in parallel • Asynchronous cooperation: every process proceeds at its own speed • Synchronous communication: handshaking, input and output prefix • Mixed guarded choice: input and output guards like in CSP and CCS. The implementation of guarded choice is aka the binary interaction problem • Dynamic generation of communication channels • Scope extrusion: a channel name can be communicated and its scope extended to include the recipient Q z z x y R P z BASICS'09, Shanghai

  4. p: the p-calculus with mixed choice Syntax g ::= x(y) | x^y | t prefixes (input, output, silent) P ::= Si gi . Pimixed guarded choice | P | P parallel | (x) P new name | recA Precursion | Aprocedure name BASICS'09, Shanghai

  5. Operational semantics • Transition system P -a Q • Rules ChoiceSi gi . Pi –giPi P-x^yP’ Open ___________________ (y) P -x^(y)P’ BASICS'09, Shanghai

  6. Operational semantics • Rules (continued) P -x(y) P’Q-x^zQ’ Com ________________________ P | Q -t P’ [z/y]|Q’ P -x(y) P’Q-x^(z)Q’ Close _________________________ P | Q -t (z) (P’ [z/y] |Q’) P -g P’ Par _________________ f(Q), b(g) disjoint Q | P -gQ | P BASICS'09, Shanghai

  7. Features which make p very expressive- and cause difficulty in its distributed implementation • (Mixed) Guarded choice • Symmetric solution to certain distributed problems involving distributed agreement • Link mobility • Network reconfiguration • It allows expressing HO (e.g. l calculus) in a natural way • In combination with guarded choice, it allows solving more distributed problems than those solvable by guarded choice alone BASICS'09, Shanghai

  8. y P Q x The expressive power of p • Example of distributed agreement: The leader election problem in a symmetric network Two symmetric processes must elect one of them as the leader • In a finite amount of time • The two processes must agree x.Pwins+ y^.Ploses| y.Qwins+ x^.Qloses Ploses| Qwins Pwins| Qloses BASICS'09, Shanghai

  9. Example of a network where the leader election problem cannot be solved by guarded choice alone For the following network there is no (fully distributed and symmetric) solution in CCS, or in CSP BASICS'09, Shanghai

  10. A solution to the leader election problem in p winner looser winner winner looser looser BASICS'09, Shanghai

  11. Approaches to the implementation of guarded choice in literature • [Parrow and Sjodin 92], [Knabe 93], [Tsai and Bagrodia 94]: asymmetric solution based on introducing an order on processes • Other asymmetric solutions based on differentiating the initial state • Plenty of centralized solutions • [Joung and Smolka 98] proposed a randomized solution to the multiway interaction problem, but it works only under an assumption of partial synchrony among processes • In this talk we propose an implementation fully distributed, symmetric, and using no synchronous hypotheses. BASICS'09, Shanghai

  12. State of the art in p • Formalisms able to express distributed agreement are difficult to implement in a distributed fashion • For this reason, the field has evolved towards variants of p which retain mobility, but have no guarded choice • One example of such variant is the asynchronousp calculus proposed by [Honda-Tokoro’91, Boudol, ’92] (Asynchronous = Asynchronous communication) BASICS'09, Shanghai

  13. pa : the Asynchonous pVersion of [Amadio, Castellani, Sangiorgi ’97] Syntax g ::= x(y) | t prefixes P ::= Si gi . Piinput guarded choice | x^youtput action | P | P parallel | (x) P new name | recA Precursion | Aprocedure name BASICS'09, Shanghai

  14. Characteristics of pa • Asynchronous communication: • we can’t write a continuation after an output, i.e. no x^y.P, but only x^y | P • soPwill proceed without waitingfor the actual delivery of the message • Input-guarded choice: only input prefixes are allowed in a choice. Note: the originalasynchronous p-calculus did not contain a choice construct.However the version presented here was shown by [Nestmann and Pierce, ’96] to be equivalent to the originalasynchronous p-calculus • It can be implemented in a fully distributed fashion (see for instance Odersky’s group’s project PiLib) BASICS'09, Shanghai

  15. The π hierarchy • We can relate the various sublanguages of π by using encodings • Preserving certain observable properties of runs. Here we will consider as observable properties the presence/absence of certain actions. • Existence of such encoding represented by BASICS'09, Shanghai

  16. The π hierarchy mixed choice Value-passing CCS Internal mobility Separate choice Input guarded choice output prefix asynchronous BASICS'09, Shanghai

  17. The π hierarchy mixed choice Palamidessi Value-passing CCS Internal mobility Separate choice Input guarded choice output prefix Nestmann asynchronous BASICS'09, Shanghai

  18. Separation result 1 • It is not possible to encode mixed-choice π into separate-choice π • Homomorphically wrt |: • Preserving 2 distinct observable actions • This result is based on a sort of confluence property, which holds for the separate-choice π and not for the separate-choice π • The proof proceeds by showing that the separate-choice π cannot solve the leader election problem for 2 nodes BASICS'09, Shanghai

  19. Separation result 2 • It is not possible to encode mixed-choice π into value-passing ccs or π with internal mobil. • Homomorphically wrt |: • Without introducing extra channels • Preserving 2 distinct observable actions • The proof proceeds by showing that the separate-choice π cannot solve the leader election problem for certain kinds of graphs BASICS'09, Shanghai

  20. p [[ ]] probabilistic asynchronous p << >> distributed machine Towards a fully distributed implementation of p • The results of previous pages show that a fully distributed implementation of p must necessarily be randomized • A two-steps approach: Advantages: the correctness proof is easier since [[ ]] (which is the difficult part of the implementation) is between two similar languages BASICS'09, Shanghai

  21. ppa: the Probabilistic Asynchonous p Syntax g ::= x(y) | t prefixes P ::= Sipigi . Pi pr. inp. guard. choiceSi pi = 1 | x^youtputaction | P | Pparallel | (x) Pnewname | recA Precursion | Aprocedurename BASICS'09, Shanghai

  22. 1/2 1/3 1/2 1/3 1/3 1/2 1/3 1/2 1/3 1/3 2/3 2/3 1/3 1/3 1/2 1/3 1/3 1/2 1/3 2/3 1/3 The operational semantics of ppa • Based on the Probabilistic Automata of Segala and Lynch • Distinction between • nondeterministic behavior (choice of the scheduler)and • probabilistic behavior (choice of the process) Scheduling Policy: The scheduler chooses the group of transitions Execution: The process choosesprobabilistically the transition within the group BASICS'09, Shanghai

  23. The operational semantics of ppa • Representation of a group of transition P { --gi-> piPi } i • Rules Choice Si pi gi . Pi {--gi-> piPi }i P{--gi-> piPi }i Par ____________________ Q | P {--gi-> piQ | Pi }i BASICS'09, Shanghai

  24. The operational semantics of ppa P{--xi(yi)-> piPi }i Q{--x^z-> 1 Q’}i Com ____________________________________ P | Q {--t-> piPi[z/yi]|Q’ }xi=x U { --xi(yi)-> pi Pi |Q }xi=/=x P{--xi(yi)-> piPi }i Res ___________________ qi renormalized (x) P { --xi(yi)-> qi (x) Pi }xi =/= x BASICS'09, Shanghai

  25. Implementation of ppa • Compilation in a DM << >> : ppa DM • Distributed << P | Q >> = << P >>.start() | << Q >>.start(); • Compositional << P op Q >> = << P >> jop << Q >> for all op • Channels are buffers with test-and-set (synchronized) methods for input and output. The input-guarded choice selects probabilistically one of the channels with available data BASICS'09, Shanghai

  26. Encoding p into ppa • [[ ]] : pppa • Fully distributed [[ P | Q ]] = [[ P ]] | [[ Q ]] • Preserves the communication structure [[ P s ]] = [[ P ]] s • Compositional [[ P op Q ]] = Cop [ [[ P ]] , [[ Q ]] ] • Correct wrt a notion of probabilistic testing semantics P must O iff [[ P ]] must [[ O ]] with prob 1 BASICS'09, Shanghai

  27. f Pi P R f Ri Qi R’i Q S f Si f Encoding p into ppa • Idea (from an idea of Uwe Nestmann): • Every mixed choice is translated into a parallel comp. of processes corresponding to the branches, plus a lock f • The input processes compete for acquiring both its own lock and the lock of the partner • The input process which succeeds first, establishes the communication. The other alternatives are discarded The problem is reduced to a dining philosophers problem: each lock is a fork, each input process is a philosopher, and enters a competition to get his adjacent forks. The winners of the competition can synchronize, which corresponds to eating in the DP. There can be more than one winner Generalized DP: each fork can be adjacent to more than two Philosophers BASICS'09, Shanghai

  28. Dining Philosophers: classic case Each fork is shared by exactly two philosophers BASICS'09, Shanghai

  29. Dining Philosophers: generalized case • Each fork can be shared by more than two philosophers BASICS'09, Shanghai

  30. Intended properties of solution • Deadlock freedom (aka progress): if there is a hungry philosopher, a philosopher will eventually eat • Starvation freedom: every hungry philosopher will eventually eat (but we won’t consider this property here) • Robustness wrt a large class of schedulers: A scheduler decides who does the next move , not necessarily in cooperation with the program, maybe even against it • Fully distributed: no centralized control or memory • Symmetric: • All philosophers run the same code and are in the same initial state • The same holds for the forks BASICS'09, Shanghai

  31. The Dining Philosophers - a brief history • Problem proposed by Edsger Dijkstra in 1965 (actually the popular formulation is due to Tony Hoare) • Many solutions had been proposed for the DP, but none of them satisfied all requirements • In 1981, Lehmann and Rabin proved that • There was no “deterministic” solution satisfying all requirements • They proposed a randomized solution and proved that it satisfies all requirement. Progress is satisfied in the probabilistic sense, I.e. there is probability 1 that a philosopherwill eventually eat. • Meanwhile, Francez and Rodeh had come out in 1980 with solution to the DC written in CSP • The controversy was solved by Lehmann and Rabin who proved that CSP (with guarded choice) is not implementable in a distributed fashion (deterministically). BASICS'09, Shanghai

  32. The algorithm of Lehmann and Rabin • think; • choose probabilistically first_fork in {left,right}; • if not taken(first_fork) then take(first_fork) else goto 3; • if not taken(second_fork) then take(second_fork); else { release(first_fork); goto 2 } • eat; • release(second_fork); • release(first_fork); • goto 1 BASICS'09, Shanghai

  33. Problems • Wrt to our encoding goal, the algorithm of Lehmann and Rabin has two problems: • It only works for the classical case (not for the generalized one) • It works only for fairschedulers BASICS'09, Shanghai

  34. Conditions on the graph • Theorem:The algorithm of Lehmann and Rabin is deadlock-free if and only if all cycles are pairwise disconnected • There are essentially three ways in which two cycles can be connected: BASICS'09, Shanghai

  35. Proof of the theorem • If part) Each cycle can be considered separately. On each of them the classic algorithm is deadlock-free. Some additional care must be taken for the arcs that are not part of the cycle. • Only if part) By analysis of the three possible cases. Actually they are all similar. We illustrate the first case committed taken BASICS'09, Shanghai

  36. Proof of the theorem • The initial situation has probability p > 0 • The scheduler forces the processes to loop • Hence the system has a deadlock (livelock) with probability p • Note that this scheduler is not fair. However we can define even a fair scheduler which induces an infinite loop with probability > 0. The idea is to have a scheduler that “gives up” after n attempts when the process keep choosing the “wrong” fork, but that increases (by f) its “stubborness” at every round. • With a suitable choice of n and f we have that the probability of a loop is p/4 BASICS'09, Shanghai

  37. Solution for the Generalized DP • As we have seen, the algorithm of Lehmann and Rabin does not work on general graphs • However, it is easy to modify the algorithm so that it works in general • The idea is to reduce the problem to the pairwise disconnetted cycles case: • Each fork is initially associated with one token. Each philosopher needs to acquire a token in order to participate to the competition. After this initial phase, the algorithm is the same as the Lehman & Rabin’s • Theorem: The competing philosophers determine a graph in which all cycles are pairwise disconnected Proof: By case analysis. To have a situation with two connected cycles we would need a node with two tokens. BASICS'09, Shanghai

  38. Generalized philosophers • The other problem we had to face: the solution of Lehmann and Rabin works only for fair schedulers, while ppa does not provide any guarantee of fairness • Fortunately, it turns out that the fairness is required only in order to avoid a busy-waiting livelock at instruction 3. If we replace busy-waiting with suspension, then the algorithm works for any scheduler • This result was achieved independently also by [Duflot, Fribourg, Picarronny 02]. BASICS'09, Shanghai

  39. The algorithm of Lehmann and RabinModified so to avoid the need for fairness The algorithm of Lehmann and Rabin • think; • choose probabilistically first_fork in {left,right}; • if not taken(first_fork) then take(first_fork) else wait; • if not taken(second_fork) then take(second_fork); else { release(first_fork); goto 2 } • eat; • release(second_fork); • release(first_fork); • goto 1 • (second_fork); • release(first_fork); • goto 1 think; • choose probabilistically first_fork in {left,right}; • if not taken(first_fork) then take(first_fork) else goto 3; • if not taken(second_fork) then take(second_fork); else { release(first_fork); goto 2 } • Eat; • release BASICS'09, Shanghai

  40. The encoding • [[ (x) P ]] = (x) [[ P ]] • [[P | Q ]] = [[ P ]] | [[ Q ]] • [[ ∑ gi.Pi ]] = the translation we have just seen • Theorem: For every P, [[P]] and P are testing-equivalent. Namely for every test T, inf (Prob (succ, [[ P ]] | [[T ]] ) = inf (Prob (succ , P | T)) sup (Prob (succ, [[ P ]] | [[T ]] ) = sup (Prob (succ , P | T)) BASICS'09, Shanghai

  41. Conclusion • We have provided an encoding of the p calculus into a probabilistic version of its asynchronous fragment • fully distributed • compositional • correct wrt a notion of testing semantics • Advantages: • high-level solutions to distributed algorithms • Easier to prove correct (no reasoning about randomization required) BASICS'09, Shanghai

More Related