Mutual exclusion protocols cannot be implemented in CCS-like - - PowerPoint PPT Presentation

Mutual exclusion protocols cannot be implemented in CCS-like languages

Rob van Glabbeek & Peter H¨

• fner

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 = a1a2 . . . an ∈ Σ∗, encoded as a CCS expression W := a1.a2. . . . .an.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
• r 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.

J

J JT P SA WA JA ST WT SI WI JI SZ WZ SC WC JC SG WG Fu Ex Pr

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

• ccurs, 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

A leaves

• A enters

I serves A II serves A B leaves

• B enters

I serves B II serves B

Fairness of synchronisations versus fairness of components

A leaves

• A enters

I serves A II serves A B leaves

• B enters

I serves B II serves B

• Under strong fairness of synchronisations all 4 serve actions get a fair share.

Fairness of synchronisations versus fairness of components

A leaves

• A enters

I serves A II serves A B leaves

• B enters

I serves B 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

A leaves

• A enters

I serves A II serves A B leaves

• B enters

I serves B 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

A leaves

• A enters

I serves A II serves A B leaves

• B enters

I serves B 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

A leaves

• A enters

I serves A II serves A B leaves

• B enters

I serves B 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 as 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.

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. Moreover, fair schedulers are typically used to implement fairness requirements (e.g. in operating systems). Hence it would be silly to presuppose fairness to ensure that they work correctly.

Specifications versus actual processes

Consider the specification G, expressed in CCS as A|B where A def = a.A and B def = b.B, with the added requirement that each run has infinitely many as as well as bs. When not assuming justness, this specification cannot be rendered in CCS. However, one of the implementations of this spec. is D def = a.b.D. This is a round-robin solution. It can be rendered in CCS. A real-life implementation of G is unlikely to capture the full generality of G. Therefore, we do not count G as an actual distributed system that cannot be rendered in CCS.

The fair scheduler

Our fair scheduler F

◮ can receive two kinds of requests r1 and r2, ◮ and is guaranteed to perform a task t1 or t2 in response.

Such schedulers occur in frequently in network routers and

• perating systems. E.g. the completely fair scheduler is the default

scheduler of the Linux kernel since v.2.6.23. Yet it cannot be rendered in CCS. In fact, no implementation of F, under the broadest definition of implementation that makes sense, can be rendered in CCS.

Specification of our fair scheduler

Our fair scheduler

◮ will always return to a state from where it will remain ready to

receive a request ri from the environment until it arrives (i = 1, 2);

◮ each action ri will be followed by ti (i = 1, 2); ◮ in each run there are no more occurrences of ti than of ri

(i = 1, 2);

◮ between each two occurrences of ti and tj an action e occurs.

Our proof

First we show that no fair scheduler can be specified in Petri nets.

This result, in slightly restricted forms, was obtained earlier by Kindler & Walter, and by Walter Vogler.

Then, we use a semantics from the literature that associates a Petri net with each CCS expression. We show that if a fair scheduler could be rendered in CCS, then its interpretation as a Petri net would also be a fair scheduler. Thus, fair schedulers cannot be rendered in CCS. The same argument applies to COSY, CSP, ACP, LOTOS, µCRL, the π-calculus, etc.

Mutual exclusion protocols

◮ Peterson’s and Dekker’s mutual exclusion protocols yield

instances of our fair scheduler.

Mutual exclusion protocols

◮ Peterson’s and Dekker’s mutual exclusion protocols yield

instances of our fair scheduler.

◮ Hence these protocols cannot be rendered correctly in CCS

without imposing a fairness assumption.

Mutual exclusion protocols

◮ Peterson’s and Dekker’s mutual exclusion protocols yield

instances of our fair scheduler.

◮ Hence these protocols cannot be rendered correctly in CCS

without imposing a fairness assumption.

◮ Yet, implementations of these algorithms in CCS (or similar)

• ccur frequently, and almost never assume fairness.

Mutual exclusion protocols

◮ Peterson’s and Dekker’s mutual exclusion protocols yield

instances of our fair scheduler.

◮ Hence these protocols cannot be rendered correctly in CCS

without imposing a fairness assumption.

◮ Yet, implementations of these algorithms in CCS (or similar)

• ccur frequently, and almost never assume fairness.

◮ All implementations found differ only in insignificant details.

Mutual exclusion protocols

◮ Peterson’s and Dekker’s mutual exclusion protocols yield

instances of our fair scheduler.

◮ Hence these protocols cannot be rendered correctly in CCS

without imposing a fairness assumption.

◮ Yet, implementations of these algorithms in CCS (or similar)

• ccur frequently, and almost never assume fairness.

◮ All implementations found differ only in insignificant details. ◮ Our result implies that this common rendering of

Dekker/Peterson cannot be correct.

Mutual exclusion protocols

◮ Peterson’s and Dekker’s mutual exclusion protocols yield

instances of our fair scheduler.

◮ Hence these protocols cannot be rendered correctly in CCS

without imposing a fairness assumption.

◮ Yet, implementations of these algorithms in CCS (or similar)

• ccur frequently, and almost never assume fairness.

◮ All implementations found differ only in insignificant details. ◮ Our result implies that this common rendering of

Dekker/Peterson cannot be correct.

◮ Most papers analyse safety properties only — those are fine.

Mutual exclusion protocols

◮ Peterson’s and Dekker’s mutual exclusion protocols yield

instances of our fair scheduler.

◮ Hence these protocols cannot be rendered correctly in CCS

without imposing a fairness assumption.

◮ Yet, implementations of these algorithms in CCS (or similar)

• ccur frequently, and almost never assume fairness.

◮ All implementations found differ only in insignificant details. ◮ Our result implies that this common rendering of

Dekker/Peterson cannot be correct.

◮ Most papers analyse safety properties only — those are fine. ◮ Three papers also prove liveness, and make essentially the

same mistake:

Mutual exclusion protocols

◮ Peterson’s and Dekker’s mutual exclusion protocols yield

instances of our fair scheduler.

◮ Hence these protocols cannot be rendered correctly in CCS

without imposing a fairness assumption.

◮ Yet, implementations of these algorithms in CCS (or similar)

• ccur frequently, and almost never assume fairness.

◮ All implementations found differ only in insignificant details. ◮ Our result implies that this common rendering of

Dekker/Peterson cannot be correct.

◮ Most papers analyse safety properties only — those are fine. ◮ Three papers also prove liveness, and make essentially the

same mistake:

◮ After leaving the noncritical section, a process indicates

interest in going to the critical section by setting a flag.

Mutual exclusion protocols

◮ Peterson’s and Dekker’s mutual exclusion protocols yield

instances of our fair scheduler.

◮ Hence these protocols cannot be rendered correctly in CCS

without imposing a fairness assumption.

◮ Yet, implementations of these algorithms in CCS (or similar)

• ccur frequently, and almost never assume fairness.

◮ All implementations found differ only in insignificant details. ◮ Our result implies that this common rendering of

Dekker/Peterson cannot be correct.

◮ Most papers analyse safety properties only — those are fine. ◮ Three papers also prove liveness, and make essentially the

same mistake:

◮ After leaving the noncritical section, a process indicates

interest in going to the critical section by setting a flag.

◮ The papers show that once this flag is set, the process is

guaranteed to reach the critical section.

Mutual exclusion protocols

◮ Peterson’s and Dekker’s mutual exclusion protocols yield

instances of our fair scheduler.

◮ Hence these protocols cannot be rendered correctly in CCS

without imposing a fairness assumption.

◮ Yet, implementations of these algorithms in CCS (or similar)

• ccur frequently, and almost never assume fairness.

◮ All implementations found differ only in insignificant details. ◮ Our result implies that this common rendering of

Dekker/Peterson cannot be correct.

◮ Most papers analyse safety properties only — those are fine. ◮ Three papers also prove liveness, and make essentially the

same mistake:

◮ After leaving the noncritical section, a process indicates

interest in going to the critical section by setting a flag.

◮ The papers show that once this flag is set, the process is

guaranteed to reach the critical section.

◮ Yet it does not follow that that a process with interest in going

to the critical section will succeed in doing this,

Mutual exclusion protocols

◮ Peterson’s and Dekker’s mutual exclusion protocols yield

instances of our fair scheduler.

◮ Hence these protocols cannot be rendered correctly in CCS

without imposing a fairness assumption.

◮ Yet, implementations of these algorithms in CCS (or similar)

• ccur frequently, and almost never assume fairness.

◮ All implementations found differ only in insignificant details. ◮ Our result implies that this common rendering of

Dekker/Peterson cannot be correct.

◮ Most papers analyse safety properties only — those are fine. ◮ Three papers also prove liveness, and make essentially the

same mistake:

◮ After leaving the noncritical section, a process indicates

interest in going to the critical section by setting a flag.

◮ The papers show that once this flag is set, the process is

guaranteed to reach the critical section.

◮ Yet it does not follow that that a process with interest in going

to the critical section will succeed in doing this,

◮ for the process may fail to set its flag.

Mutual exclusion protocols

One paper on Dekker’s protocol rendered in process algebra (by Corradini, Di Berardini & Vogler) formulates the issue with the flag

• correctly. They conclude that with “fairness of actions” (similar to
• ur justness) the protocol fails to have the required liveness
• property. With a forms of weak fairness, the protocol turns out to

be correct.

Pseudocode

Peterson formulated his mutual exclusion protocol correctly in pseudocode, without invoking a fairness assumption. It follows that such pseudocode cannot be transited correctly to CCS, or Petri nets.

Conclusion

To model fair schedulers, or mutual exclusion protocols, in process algebra, standard process algebras are insufficient. Some extension is needed. Many extensions are sufficient: e.g. broadcast communication, priorities, Petri nets with read arcs, CCS with signals.

Open Problem

Is there an extension of CCS in which (at some level of abstraction) “all” systems can be modelled” What does this question even mean? Find a minimal such extension.