Logic for Computer Science 13 Modelling processes Wouter Swierstra - - PowerPoint PPT Presentation

Logic for Computer Science

13 – Modelling processes

Wouter Swierstra

University of Utrecht 1

Last time

Games of no chance

2

This lecture

Processes

3

Mid-term Exam

The results have been emailed to you directly. I have appointments with students to go through the exams. I’ll try to email the final marks at the end of the week – these final marks will be a bit higher than the mark in the email.

4

5

Recap

In the lectures until now, we have learned about

• propositional logic;
• predicate logic;
• proofs;
• sets, functions and relations;
• inductive definitions and proofs by induction.

But our book is called ‘’Modelling Computing Systems” – these are all fairly ‘static’ mathematical structures. How do we model computing systems?

6

Recap

In the lectures until now, we have learned about

• propositional logic;
• predicate logic;
• proofs;
• sets, functions and relations;
• inductive definitions and proofs by induction.

But our book is called ‘’Modelling Computing Systems” – these are all fairly ‘static’ mathematical structures. How do we model computing systems?

6

Processes

Rather than start immediately with complicated computing systems – let’s begin by looking at some (familiar) examples drawn from the real world. Like a light switch…

7

Processes

Rather than start immediately with complicated computing systems – let’s begin by looking at some (familiar) examples drawn from the real world. Like a light switch…

7

Modelling a light switch

A light can be either on or off. There is a switch that can be used to the light on (if it is off); And turn the light off (if it is on). We might visualise this as follows: On Off

• n
• ff

We can see we have two different states our system is in (On or Off); and there are two different actions that transition between these two states (on and off).

8

Modelling a light switch

A light can be either on or off. There is a switch that can be used to the light on (if it is off); And turn the light off (if it is on). We might visualise this as follows: On Off

• n
• ff

We can see we have two different states our system is in (On or Off); and there are two different actions that transition between these two states (on and off).

8

Modelling a vending machine

1 coin tea coffee A simple vending machine that can dispense coffee or two for 1 euro can be modelled in this style. There are two possible states:

• 0 – no coin inserted;
• 1 – a coin has been inserted and a drink may be selected.

There can be more than one action between different states! (This machine doesn’t give change and only accepts 1 euro coins.)

9

Modelling a calculator

A pocket calculator is a much more complicated ‘machine’ with many more buttons:

• C/AC – resets the current calculation;
• the digits 1-9 extend the current number (or sometimes start a new number);
• the operations +,-,÷, and × finalize the current number being entered and start asking for a

new number. How can we ever start formally describing such a machine? This example shows that even something as simple as a pocket calculator has a great deal of ‘custom’ notation and natural language explanation. A bit like trying to define propositional logic, without knowing about inductive sets. Isn’t there a better notation? Or more general definition?

10

Modelling a calculator

A pocket calculator is a much more complicated ‘machine’ with many more buttons:

• C/AC – resets the current calculation;
• the digits 1-9 extend the current number (or sometimes start a new number);
• the operations +,-,÷, and × finalize the current number being entered and start asking for a

new number. How can we ever start formally describing such a machine? This example shows that even something as simple as a pocket calculator has a great deal of ‘custom’ notation and natural language explanation. A bit like trying to define propositional logic, without knowing about inductive sets. Isn’t there a better notation? Or more general definition?

10

Labelled transition systems

Each of these examples are instances of a labelled transition system – a simple way to model a computational process that can be in different states and shift between these states. More formally, a labelled transition system consists of:

• A set States – corresponding to all the possible states of the system (like On or 1);
• A set Actions – corresponding to the labels between states;
• A relation on States × Actions × States corresponding to the possible transitions from one

state to the next. We usually write s1

a

− → s2 when this relation includes (s1, a, s2)—or put

differently we can transition from state s1 to s2 by performing the action a.

11

Example: vending machine

1 coin tea coffee

• States: {0, 1}
• Actions: {coin, coffee, tea}
• Transitions: {(0, coin, 1), (1, coffee, 0), (1, tea, 0)}

12

Notation and short-hands

• We will write s1

a

− → s2 when we can transition from s1 to s2 by the action a.

• When we cannot transition from s1 to s2 with the action a, we sometimes write s1

a

− → / s2

• When there are no actions that transition from s1 to s2, we will write s1 →

/ s2.

• When there are no transitions from s to any other state, we will write s →

/

We can easily extend our transition relation to work over lists of actions, rather than a single

• action. This is useful to model a sequence of transition steps, rather than a single step, usually

written s

w s , where w

Action

• s

s – if there are no further actions to be taken, we stay at the state s.

• s

aw t if s a

s and s

w t for some state s – if we can take a single step from s to s along

a, and continue from s to t by the word w, we can transition from s to t by aw.

13

Notation and short-hands

• We will write s1

a

− → s2 when we can transition from s1 to s2 by the action a.

• When we cannot transition from s1 to s2 with the action a, we sometimes write s1

a

− → / s2

• When there are no actions that transition from s1 to s2, we will write s1 →

/ s2.

• When there are no transitions from s to any other state, we will write s →

/

We can easily extend our transition relation to work over lists of actions, rather than a single

• action. This is useful to model a sequence of transition steps, rather than a single step, usually

written s

w

− → s′, where w ∈ Action∗

• s ε

− → s – if there are no further actions to be taken, we stay at the state s.

• s

aw

− → t if s

a

− → s′ and s′

w

− → t for some state s′ – if we can take a single step from s to s′ along

a, and continue from s′ to t by the word w, we can transition from s to t by aw.

13

Wolf-goat-cabbage

A man needs to cross a river with a wolf, a goat, and a cabbage. His boat is only large enough to carry himself and one of his three possessions, so he must transport them one at a time. However, if he leaves the wolf and the goat together unattended, then the wolf will eat the goat; similarly, if he leaves the goat and the cabbage together unattended, the goat will eat the cabbage. How can the man get across safely with his possessions? Question How can we solve this puzzle? And more importantly, how can we model this problem as a labelled transition system?

14

Wolf-goat-cabbage: states

We want to model where the man, wolf, goat and cabbage are. Each can be on one side of the river, but not both at the same time. We can model this by taking P({M, W, G, C}) as our set of states. At a given state S, the elements of S have successfully crossed the river. Initially, no one has crossed the river – hence we are at the state ∅. The book uses a slightly different notation writing: MGC W When the man, goat and cabbage are on one side of the river, but the wolf has crossed.

15

Wolf-goat-cabbage: states

We want to model where the man, wolf, goat and cabbage are. Each can be on one side of the river, but not both at the same time. We can model this by taking P({M, W, G, C}) as our set of states. At a given state S, the elements of S have successfully crossed the river. Initially, no one has crossed the river – hence we are at the state ∅. The book uses a slightly different notation writing: MGC ≀≀≀ W When the man, goat and cabbage are on one side of the river, but the wolf has crossed.

15

Actions and transitions

There are four possible actions: {m, g, c, w} corresponding to crossing the river with the an empty boat (m), the goat (g), the cabbage (c), or the wolf (w). The transitions each move the man (and possibly one of his possessions) to the other side of the river. For example, MGC W

g C

MWG Finally, some states are ‘dangerous’ – when the wolf and goat are unattended on one side of the river or the goat and cabbage are unattended on one side of the river.

16

Actions and transitions

There are four possible actions: {m, g, c, w} corresponding to crossing the river with the an empty boat (m), the goat (g), the cabbage (c), or the wolf (w). The transitions each move the man (and possibly one of his possessions) to the other side of the river. For example, MGC ≀≀≀ W

g

− → C ≀≀≀ MWG

Finally, some states are ‘dangerous’ – when the wolf and goat are unattended on one side of the river or the goat and cabbage are unattended on one side of the river.

16

Actions and transitions

There are four possible actions: {m, g, c, w} corresponding to crossing the river with the an empty boat (m), the goat (g), the cabbage (c), or the wolf (w). The transitions each move the man (and possibly one of his possessions) to the other side of the river. For example, MGC ≀≀≀ W

g

− → C ≀≀≀ MWG

Finally, some states are ‘dangerous’ – when the wolf and goat are unattended on one side of the river or the goat and cabbage are unattended on one side of the river.

16

17

Example: Simple Stack Machine

We can also use labelled transition systems to model programming languages – such as the Simple Stack Machine language that you saw in the course on Computer Architecture and Networks.

• States: Int32∗ – a sequence of all the integer words on the stack;
• Actions: the set of all SSM instructions, such as {add, mul, ldc, lds, ...};
• Transitions: describe how each of the instructions modify the stack.

For example, the following relations capture the behaviour of some instructions:

{(n m w, add, (n + m) w) : n ∈ N, m ∈ N, w ∈ N⋆} ∪ {(n m w, mul, (n × m) w) : n ∈ N, m ∈ N, w ∈ N⋆} ∪ {(w, ldc n, n w) : n ∈ N, w ∈ N⋆} ∪ . . .

For all numbers n and m and words w.

18

Example: Simple Stack Machine

This captures some of the instructions of the SSM… But we can extend it easily enough to handle other commands.

• Extend the state to keep track of the current stackpointer, markpointer, or program counter;
• Add new instructions that manipulate these, or load/store with respect to the current

pointers;

• Extend the transition relation to explain how these instructions behave.

I’ll leave this an exercise for the reader… But the important observation is that we have the mathematical machinery to describe the meaning of this language precisely, unambiguously, and concisely – rather than the pages of natural language description in the lecture notes you read previously.

19

Example: Simple Stack Machine

This captures some of the instructions of the SSM… But we can extend it easily enough to handle other commands.

• Extend the state to keep track of the current stackpointer, markpointer, or program counter;
• Add new instructions that manipulate these, or load/store with respect to the current

pointers;

• Extend the transition relation to explain how these instructions behave.

I’ll leave this an exercise for the reader… But the important observation is that we have the mathematical machinery to describe the meaning of this language precisely, unambiguously, and concisely – rather than the pages of natural language description in the lecture notes you read previously.

19

A language for describing processes

One trend throughout this course has been that rather than do the same kind of examples over and over again, we try to find an abstraction that generalizes over recurring patterns. It turns out that we can find a language for describing these procesess. Just as we studied, say, propositional logic in terms of variables and logical operators rather than natural language – we’d like to have a systematic way for describing these processes. We will define a number of ‘atomic’ processes and operations for combining them.

20

The zero process

The zero process has one state, but no actions or transitions. We typically write 0 to denote this ‘empty’ process. Why is this useful? The number 0 also doesn’t count anything, yet we use it all the time!

21

The zero process

The zero process has one state, but no actions or transitions. We typically write 0 to denote this ‘empty’ process. Why is this useful? The number 0 also doesn’t count anything, yet we use it all the time!

21

The action prefix

a.E E a Whenever a is an action and E is some process expression, we write a.E to denote a new process with one transition going from a.E to E labelled with a.

22

Examples

Suppose we want to model a clock that ticks once, but then stops: tick.0 Or using a picture: tick.0 tick Question What about a clock that ticks three times?

23

Examples

A clock that ticks exactly three times and stops might look like: tick.tick.tick.0 Or using a picture: tick.0 tick.tick.0 tick.tick.tick.0 tick tick tick

24

Defining equations

We can define a given state by giving an equation, capturing the transitions from it. For example, we can define the process modelling the lamp (that can be switched on and off) using two equations: On def

= off.Off

Off def

= on.On

This yields the familiar example from earlier in the lecture: On Off

• n
• ff

Note that we ‘identify’ the states On with off.Off and Off with on.On in the diagram.

25

Choice

So far we can add new states (using definitions) and label one transition between states – but what if there are more than one transition possible? We introduce a choice operator, written +, to choose between two (or more) possible transitions. This choice operator is characterised as follows:

• If E

a

− → E′ then E + F

a

− → E′

• If F

a

− → F′ then E + F

a

− → F′

For example, we can define our vending machine that produces tea or coffee after payment as follows: Unpaid def

= coin.Paid

Paid def

= coffee.Unpaid + tea.Unpaid

26

Examples revisited

We can define both finite and infinite processes.

• A clock that ticks infinitely often can be defined as:

Clock def

= tick.Clock

• Or inductively define a finite process:

Clock0 def

= 0

Clockn+1 def

= tick.Clockn

27

Comparing processes

Suppose we have two process P1 and P2 expressions. When are they the same?

• Obviously when they are syntactically identical, they are the same.
• But what about comparing similar – yet different processes,
• for instance E and E

0.

• or E

F and F E

Shouldn’t these be the same too? Equality is one of the most subtle issues there is, once you start studying the foundations of logic.

28

Comparing processes

Suppose we have two process P1 and P2 expressions. When are they the same?

• Obviously when they are syntactically identical, they are the same.
• But what about comparing similar – yet different processes,
• for instance E and E

0.

• or E

F and F E

Shouldn’t these be the same too? Equality is one of the most subtle issues there is, once you start studying the foundations of logic.

28

Comparing processes

Suppose we have two process P1 and P2 expressions. When are they the same?

• Obviously when they are syntactically identical, they are the same.
• But what about comparing similar – yet different processes,
• for instance E and E + 0.
• or E + F and F + E

Shouldn’t these be the same too? Equality is one of the most subtle issues there is, once you start studying the foundations of logic.

28

Comparing processes

Suppose we have two process P1 and P2 expressions. When are they the same?

• Obviously when they are syntactically identical, they are the same.
• But what about comparing similar – yet different processes,
• for instance E and E + 0.
• or E + F and F + E

Shouldn’t these be the same too? Equality is one of the most subtle issues there is, once you start studying the foundations of logic.

28

Distinguishing between processes

Suppose we want to model a simple vending machine. Customers pay with two 10 cent coins and choose whether they want tea or coffee. We can model this with (at least) the following three processes: V1 def

=

10.10.(coffee.collect.V1 + tea.collect.V1) V2 def

=

10.(10.coffee.collect.V2 + 10.tea.collect.V2) V3 def

=

10.10.coffee.collect.V3 + 10.10.tea.collect.V3 Question Are these the same?

29

Distinguishing between processes

V1 def

=

10.10.(coffee.collect.V1 + tea.collect.V1) V2 def

=

10.(10.coffee.collect.V2 + 10.tea.collect.V2) Consider the following property: After inserting two coins, we can always choose to buy coffee. For which of the above machines does this hold? It holds for V1 but not V2! We can distinguish between the two different models of a vending machine.

30

Distinguishing between processes

V1 def

=

10.10.(coffee.collect.V1 + tea.collect.V1) V2 def

=

10.(10.coffee.collect.V2 + 10.tea.collect.V2) Consider the following property: After inserting two coins, we can always choose to buy coffee. For which of the above machines does this hold? It holds for V1 but not V2! We can distinguish between the two different models of a vending machine.

30

Equality between processes

So when are two terms written using our process algebra equal? Let’s start by looking at a simpler problem – when are two states equal? We say that two states E and F are equal, written E = F, when for actions a and states G we have that E

a

− → G if and only if F

a

− → G.

31

Example

Using this notion of equality, we can show that E + 0 = E. To prove this we need to show:

• if E

a

− → G then E + 0

a

− → G;

• and if E + 0

a

− → G then E

a

− → G.

The first statement is easy to prove – it follows directly from the definition of choice. To prove the second statement, suppose E + 0

a

− → G then we know that either E

a

− → G or 0

a

− → G.

But by definition of 0, the second case cannot hold. Hence we can conclude E

a

− → G.

32

Beyond this equality

Recall that we defined equality as follows: Equality We say that two states E and F are equal, written E = F, when for actions a and states G we have that E

a

− → G if and only if F

a

− → G.

But this is quite a strict notion of equality – both E and F must transition to the same G. There are examples where we have two transition systems that behave the same, but have very different states…

33

Bisimilarity

Instead of requiring transitions to go to the same state G, we can define a more flexible notion of equality. We say that two states E and F are equal, written E = F, when

• if E

a

− → E′ there is a transition F

a

− → F′ for some F′ such that E′ = F′;

• if F

a

− → F′ there is a transition E

a

− → E′ for some E′ such that F′ = E′.

If this holds, there is no set of commands that can distinguish the two processes and we say they are bisimilar. Using this weaker notion of equality, we can show for example that

• if E

F then E G F G;

• if E

F then a E a F.

34

Bisimilarity

Instead of requiring transitions to go to the same state G, we can define a more flexible notion of equality. We say that two states E and F are equal, written E = F, when

• if E

a

− → E′ there is a transition F

a

− → F′ for some F′ such that E′ = F′;

• if F

a

− → F′ there is a transition E

a

− → E′ for some E′ such that F′ = E′.

If this holds, there is no set of commands that can distinguish the two processes and we say they are bisimilar. Using this weaker notion of equality, we can show for example that

• if E = F then E + G = F + G;
• if E = F then a.E = a.F.

34

Induction?

If we study the definition of bisimilarity closely: Bisimilarity We say that two states E and F are equal, written E = F, when

• if E

a

− → E′ there is a transition F

a

− → F′ for some F′ such that E′ = F′;

• if F

a

− → F′ there is a transition E

a

− → E′ for some E′ such that F′ = E′.

We usually define relations inductively – something is constantly getting smaller. But what is getting smaller in this definition? To reason about such (potentially infinite) processes, we need (potentially infinite) proofs relating the states of two processes. This relies on more advanced techniques knows as coinduction…

35

Induction?

If we study the definition of bisimilarity closely: Bisimilarity We say that two states E and F are equal, written E = F, when

• if E

a

− → E′ there is a transition F

a

− → F′ for some F′ such that E′ = F′;

• if F

a

− → F′ there is a transition E

a

− → E′ for some E′ such that F′ = E′.

We usually define relations inductively – something is constantly getting smaller. But what is getting smaller in this definition? To reason about such (potentially infinite) processes, we need (potentially infinite) proofs relating the states of two processes. This relies on more advanced techniques knows as coinduction…

35

Why labelled transition systems?

These labelled transition systems form the basis for a powerful program verification technique known as model checking. This enables computers to automatically check that a program behaves in accordance with an abstract specification. Model checking is one of the most widely used verification techniques. You may encounter model checking in more detail in your MSc if you choose to follow courses such as Program semantics and verification.

36

Remainder of the book

• More thorough treatment on how to distinguish processes using the ‘games’ that Vedran

talked about.

• Logic for reasoning about processes – known as modal logic – extending propositional logic

with ‘may’ and ‘must’;

• Study of concurrent processes and algorithms
• Temporal logic – using notions of always and eventually to reason about processes’

behaviour There’s plenty of interesting material – but much of it is quite advanced for a first-year introduction to logic course. But it’s certainly worth reading once this course is over and you’ve taken courses on software verification, algorithms, and concurrency.

37

Remainder of this course

• We have seen how to define sets, functions and relations using induction. Can we use these

techniques to define a set of proofs?

• We have seen an inductive definition of a small imperative language. Can we give it

semantics? Can we develop a logic to reason about such programs? No longer use the book, ‘’Modelling Computing Systems”, but rather rely on hand-outs, last year’s reader and auxiliary material.

38

Material

• Modelling Computing Systems Chapter 11

39