Mutual exclusion protocols cannot be implemented in CCS-like languages Rob van Glabbeek & Peter H¨ ofner Data61, CSIRO, Sydney, Australia University of New South Wales, Sydney, Australia June 2017 Based on work presented in Walter Volger’s Festschrift in 2015.
A common belief (in the process algebra community): Any distributed system can be modelled in process-algebraic specification formalisms like CCS. My contribution today: This isn’t so.
Any distributed system can be modelled in process-algebraic specification formalisms like CCS. First some disclaimers. 1. Systems with features like time, probability, broadcast communication, etc., etc., cannot be modelled in CCS. For this purpose extensions are needed. This talk is not concerned with such features. 2. It is well-known that many operators (such as priority or the CSP parallel composition) cannot be expressed in CCS. This talk is not about expressing operators, but actual systems. 3. It was already known that certain process specifications cannot be rendered in CCS. The problem with the rendering of specifications, is that we may get either too liberal or too restrictive specifications, allowing more or fewer implementations. Here I do not address this problem. Instead I will present a specification of which no implementation can be rendered in CCS.
Any distributed system can be modelled in process-algebraic specification formalisms like CCS. Supporting evidence: 1. CCS is Turing powerful. Any computable partial function f : Σ ∗ → Σ ∗ over some finite alphabet Σ can be modelled by a CCS context P [ ], such that, for any input word w = a 1 a 2 . . . a n ∈ Σ ∗ , encoded as a CCS expression W := a 1 . a 2 . . . . . a n . z . 0 featuring an end-of-input marker z , the process P [ W ] computes forever without performing any visible actions if f ( w ) is undefined, and otherwise performs the sequence of visible actions f ( w ), followed by an end-of-output marker z . 2. Any labelled transition system (finite or infinite, computable or not) can be rendered as a CCS expression. Thus, when we show that a fair scheduler cannot be modelled in CCS, then it certainly cannot be modelled as a transition system.
This isn’t so. I will present a simple fair scheduler—one that in suitable variations occurs in many distributed systems—of which no implementation can be expressed in CCS unless CCS is enriched with a fairness assumption.
This isn’t so. I will present a simple fair scheduler—one that in suitable variations occurs in many distributed systems—of which no implementation can be expressed in CCS unless CCS is enriched with a fairness assumption. ◮ fair scheduler: a particular distributed system with specified input/output behaviour. ◮ fairness assumption: an assumption on system behaviour used when establishing properties of distributed systems.
This isn’t so. I will present a simple fair scheduler—one that in suitable variations occurs in many distributed systems—of which no implementation can be expressed in CCS unless CCS is enriched with a fairness assumption. ◮ fair scheduler: a particular distributed system with specified input/output behaviour. ◮ fairness assumption: an assumption on system behaviour used when establishing properties of distributed systems. A fair scheduler can easy be implemented using a mutual exclusion protocol. Thus, by reduction, if follows that mutex protocols cannot be rendered in CCS.
Fairness In the literature I found 5 meaningful types of fairness assumptions: 1. Progress 2. Justness 3. Weak Fairness 4. Strong Fairness 5. Full Fairness These form a hierarchy, thus creating 6 assumptional states.
Fu Ex SZ Pr SI SG SA ST SC WZ WC WA WT JC WI WG JA JI J J JT P
Fairness Shop with 2 customers. When in the shop, a customer is waiting expectantly to be served. Upon being served, the customer leaves the shop, but usually returns right away to buy something else. A customer may leave the shop anytime, and possibly return later. Failure of weak fairness: Customer A remains forever in the shop, ready to be served, but is never served, because the clerk is always busy serving customer B. Failure of strong fairness: Customer A occasionally leaves the shop, but always returns in the hope to get served. Yet, this never occurs, because the clerk is always busy serving customer B. Failure of progress: Customer A remains forever in the shop, ready to be served, but no-one is ever served. The clerk stares pathetically at the customer(s) without doing anything. Failure of justness: There are two counters with a clerk each. Customer A is the only customer at counter 1, yet never is served, while customer B is being served repeatedly at counter 2.
Fairness of synchronisations versus fairness of components I serves A I serves B • A leaves A enters B leaves B enters • • II serves A II serves B •
Fairness of synchronisations versus fairness of components I serves A I serves B • A leaves A enters B leaves B enters • • II serves A II serves B • Under strong fairness of synchronisations all 4 serve actions get a fair share.
Fairness of synchronisations versus fairness of components I serves A I serves B • A leaves A enters B leaves B enters • • II serves A II serves B • Under strong fairness of synchronisations all 4 serve actions get a fair share. Under strong fairness of components two diagonal serve action may be skipped. But not two adjacent ones.
Fairness of synchronisations versus fairness of components I serves A I serves B • A leaves A enters B leaves B enters • • II serves A II serves B • Under strong fairness of synchronisations all 4 serve actions get a fair share. Under strong fairness of components two diagonal serve action may be skipped. But not two adjacent ones. Under weak fairness of components server II may be always skipped. But not customer B.
Fairness of synchronisations versus fairness of components I serves A I serves B • A leaves A enters B leaves B enters • • II serves A II serves B • Under strong fairness of synchronisations all 4 serve actions get a fair share. Under strong fairness of components two diagonal serve action may be skipped. But not two adjacent ones. Under weak fairness of components server II may be always skipped. But not customer B. Under progress, all but one serve action could be skipped. But not all four.
Fairness of synchronisations versus fairness of components I serves A I serves B • A leaves A enters B leaves B enters • • II serves A II serves B • Under strong fairness of synchronisations all 4 serve actions get a fair share. Under strong fairness of components two diagonal serve action may be skipped. But not two adjacent ones. Under weak fairness of components server II may be always skipped. But not customer B. Under progress, all but one serve action could be skipped. But not all four. Under justness, any two serve action could be skipped. But not three.
Fairness in CCS Are the following CCS processes guaranteed to do the action b eventually? Assuming nothing progr. justness wk. f. str. fair. E with E def = a . E + b . 0. E ′ with E ′ def = a . a . E ′ + b . 0. b . 0 A | b . 0 with A def = a . A
Fairness in CCS Are the following CCS processes guaranteed to do the action b eventually? Assuming nothing progr. justness wk. f. str. fair. E with E def = a . E + b . 0. − − − � � E ′ with E ′ def = a . a . E ′ + b . 0. − − − − � b . 0 − � � � � A | b . 0 with A def = a . A − − � � �
Fairness in process algebra Strong or weak fairness can be ◮ indispensable for certain applications, such as a correctness proof of the alternating bit protocol. ◮ patently wrong when used where not appropriate. E with E def = a . E + b . 0.
Fairness in process algebra Strong or weak fairness can be ◮ indispensable for certain applications, such as a correctness proof of the alternating bit protocol. ◮ patently wrong when used where not appropriate. E with E def = a . E + b . 0. ◮ could be a spec. of a mobile phone ◮ b is a successful dialing attempt ◮ a is an unsuccessful dialing attempt. Fairness amounts to saying that if you try often enough, dialing will succeed. This is wishful thinking. The real world is not fair.
Fairness in process algebra Strong or weak fairness can be ◮ indispensable for certain applications, such as a correctness proof of the alternating bit protocol. ◮ patently wrong when used where not appropriate. E with E def = a . E + b . 0. ◮ could be a spec. of a mobile phone ◮ b is a successful dialing attempt ◮ a is an unsuccessful dialing attempt. Fairness amounts to saying that if you try often enough, dialing will succeed. This is wishful thinking. The real world is not fair. ◮ When assuming strong or weak fairness, we loose the ability to finitely specify a system like E above that does allow an infinite sequences of a s without a b .
This isn’t so. I will present a simple fair scheduler—one that in suitable variations occurs in many distributed systems—of which no implementation can be expressed in CCS. unless CCS is enriched with a fairness assumption. This argument holds for CCS ◮ without progress assumption; ◮ with progress; ◮ with (progress and) justness. but not for CCS with weak or strong fairness. For CCS with weak or strong fairness, other systems can no longer be finitely expressed.
Recommend
More recommend
