ALPHABETIZED PARALLEL

2

Concurrency

When two processes are executed concurrently, they constitute a parallel combination. Each process executes independently, in accordance with its prescribed patterns of behaviour, but its range of possibilities will be influenced by the other process.

The way parallel CSP processes interact is intimately bound up with the view of events as synchronizations. Any event which appears in the interface of both processes must in-volve both processes whenever it occurs. This is the mechanism by which parallel processes interact—by synchronizing on events in the interface between them. Synchronization is sym-metric and instantaneous, and occurs only when both participants engage in it simultaneously, much like a handshake. For this reason it is often known as handshake synchronization. A single event occurs—the handshake—with a number of participants. Examples of handshake synchronizations include: the passing of a baton in a relay race; the delivery of a registered letter; the closure of a contract; becoming married; inserting a coin in a vending machine;

starting a phone conversation; sending an email message; adding a job to a printer queue.

a b b c

a b c

P^1kP²

P¹ P²

Fig. 2.1 Synchronization with buttons

b b

a c

b c

a

P^1kP²

P¹ P²

Fig. 2.2 Synchronization with wires

The interface of a process is the set of all the events that the process has the potential to engage in. If a process is considered as a black box, the interface consists of the names of all its buttons. If the process is viewed as a component with wires, then the interface provides a list of all the wires. In either case, it describes all of the events that the process is potentially able to perform. Since all external events are synchronizations between processes and their environment, the interface is the point at which a process and its environment influence each other.

A parallel combination of two processes P¹and P²whose interfaces are given as A

and B

respectively is described as P1A^kBP2

(pronounced ‘P1 parallel on A, B P2’). In this combination P1 can perform only events in A, P2 can perform only events in B, and they must simultaneously engage in events in the intersection of A and B. This is illustrated by Figures 2.1 and 2.2. It is conventional for the interface A of process P¹ to contain at least all of the events used in the definition of P¹. Similarly, B should contain all of the events appearing in P².

Parallel components of the combination P¹_A^k_BP²must also agree on termination, even though the^Xevent does not appear explicitly in the interface sets A and B. This means that a parallel combination does not terminate until all of its components are terminated.

There are two rules that define the possible transitions of a parallel combination. One rule describes the independent execution of each of the components, and the other describes the performance of a joint step. The set A^Xis defined to be A^[fXg.

P^{1 ?!} P⁰1

[

²

(

^A[fgnB

) ]

P¹_A^k_BP^{2 ?!} P⁰1A^kBP² P²_B^k_AP^{1 ?!} P²_B^k_AP⁰1

P^{1 ?!a} P⁰1

P2

a

?

!P⁰2

[

^a2AX\BX

]

P¹_A^k_BP^{2 ?!a} P⁰1A^kBP⁰2

The first transition rule states that each side can execute independently through per-forming events which are not in the common interface. The second transition rule states that if both components can perform an event a which appears in each of their interfaces, then the parallel combination can also perform it.

These rules also capture the fact that the interfaces of the components do not change as the processes execute: they remain fixed throughout the life of the parallel combination.

Example 2.1

The parallel combination

(

^a!P1

)

^fa^gkfa^;b^g

(

^a!P2jb!P3

)

can perform an a transition initially, and reach P¹ fa^gkfa^;b^g P², or else it can perform a b transition initially to reach

(

^a!P1

)

^fa^gkfa^;b^gP³.

However, the same processes combined in a different way

(

^a!P1

)

^fa^;b^gkfa^;b^g

(

^a!P2jb!P3

)

can perform only a initially, since the presence of b in both interfaces means that both components are required to co-operate on its occurrence; and the left-hand process is not able

initially to perform b. ²

Example 2.2

A race between two competitors should have a single start event which both of the participants synchronize on. However, each competitor will independently finish, so two events finish¹ and finish²are used to describe these separate events. Participant

1

^will

be described as start^!finish^{1 !}STOP, and participant

2

similarly. The race can then be described as

RACE

=

start^!finish^1!STOPfstart^;finish1 g

k

fstart^;finish2

gstart^!finish^2!STOP The fact that each finish event occurs in only one interface set captures the fact that the

competitors can finish independently of each other. ²

Example 2.3

On entering a restaurant, the cloakroom attendant might help the customer off or on with her coat, as captured by the events coat^:off and coat^:on respectively, storing and retrieving coats as appropriate. This activity might be described by the following process description:

ATT

=

^{coat:off!store!ATT}

2

retrieve^!coat^:on^!ATT with an interface described as

ATT

=

^{fcoat:off;coat:on;store;retrieveg}

The dining behaviour of the customer is as follows:

CUST

=

^{enter!coat:off !eat!coat:on!CUST}

CUST

=

^{fcoat:off;coat:on;enter;eatg}

In the parallel combination ATT

ATT

k

CUST CUST

the events enter and eat are performed solely by CUST; the events coat^:on and coat^:off are synchronizations between CUST and ATT; and the events store and retrieve are entirely under the control of ATT—the attendant is left to deal with the coat appropriately. ²

Example 2.4

A pay and display parking permit machine accepts cash, and issues tickets and change. A designer might decide to implement these functions using two separate processes:

TICKET

=

^{cash!ticket!TICKET}

CHANGE

=

^{cash!change!CHANGE}

The machine is then captured as the parallel combination of these two components:

MACHINE

=

^TICKETfcash^;ticket^gkfcash^;change^gCHANGE

in CALCg c CALCf out

Fig. 2.3 A pipeline of two calculations

The two components both participate in the cash event, but they exercise independent control

over the ticket and change events. ²

Example 2.5

A process to calculate and output f

(

^g

(

^x

))

from input x may be constructed from two processes which calculate f and g.

CALCg

=

ⁱⁿ

?

^x

:

^Z!c

!

^g

(

^x

)

^!CALCg

CALCf

=

^c

?

^y

:

^Z!out

!

^f

(

^y

)

^!CALCf

The composition of f and g may be calculated by the parallel combination of CALCg and CALCf. The output of CALCg is connected to the input of CALCf, resulting in a pipeline of two processes which together compute f

(

^g

(

^x

))

from input x. This is described by

CALC_{g in}

:Z[c^:Zkc^:Z[out^:ZCALCf

which is illustrated in Figure 2.3. ²

A parallel combination of processes is itself a process, with an alphabet and a range of possible executions. Synchronization on an event a by two concurrent components results in a single occurrence of that event, and there can be no information contained in the occurrence of a as to the number of participants. A further process may be run in parallel with the existing combination, also synchronizing on a. This approach to parallel composition results in a mechanism for multi-way synchronization. No matter how many parallel components a system contains, all those with an event a in their alphabet are required to participate in every occurrence of it.

Example 2.6

A team of furniture removers contains a number of people with responsibilities for moving different kinds of furniture. Pianos require several people to lift them, so the event lift piano will be in the alphabet of several members of the team, and they must all synchronize on this event for it to occur. The event lift piano will occur only once, no matter how many participants it has. This event is a multi-way synchronization—it can occur only when all its participants are ready. There is also the possibility of adding further participants by extending the system: if a new person is added to the team with piano-lifting among their responsibilities,

then they will also participate in the event lift piano. ²

A parallel component of a system constrains the occurrence of all events in its alphabet, since the co-operation of that component is required for the performance of such events. The

event lift piano can be prevented from occurring by any team member who is not ready to perform it. This means that any constraint on the occurrence of events can be introduced through the addition of a parallel component which enforces that constraint. Introduction of constraints may be carried out at the specification level, where different facets of desired behaviour are captured by different process descriptions which are then combined in parallel.

It may also be carried out at the design level, where responsibility for enforcing different constraints is assigned to different processes.

Example 2.7

A number of shopping opportunities are described by the process SHOPPING.

An item may be selected by the customer; the customer might pay; or the customer might leave, in which case the other possibilities are lost until the shop is re-entered.

SHOPPING

=

^{select!SHOPPING}

2pay^!SHOPPING

2leave^!enter^!SHOPPING

There are a number of restrictions that the shop places on the free performance of events as described by SHOPPING. One is concerned with ensuring that goods are paid for; and another requires goods to be selected before payment.

Security ensures that selected goods are paid for by the time the customer leaves the shop:

SECURITY

=

^select!WATCH

2pay^!SECURITY

2leave^!SECURITY WATCH

=

^select!WATCH

2pay^!SECURITY

This process is concerned with tracking the occurrence of events select and pay and restricting the possibility of the event leave under the appropriate circumstances. The event enter is not part of its alphabet.

The shop operating under this constraint is described by SECURE SHOP

=

(

^{enter!SHOPPING}

)

^fenter^;leave^;select^;pay^gkfleave^;select^;pay^gSECURITY

The cash tills impose another constraint: that payment is possible only after some item has been selected. The initial situation is captured by BROWSING, whose alphabet is

fpay^;select^g. Before any item has been selected, payment is not possible. Once an item has been selected, then payment is possible, though further items may also be selected.

BROWSING

=

^select!TILL

TILL

=

^select!TILL

2pay^!BROWSING

The alphabet of this process does not contain either enter or leave, since it is concerned only with the relationship between the events select and pay.

The shop as a whole, integrating this last constraint, is described by SHOP

=

SECURE SHOPfenter^;leave^;select^;pay^gkfselect^;pay^gBROWSING

Each parallel component restricts the behaviour of the whole to some degree. The process enter^!SHOPPING restricts all occurrences of select and pay to between enter and leave;

the process SECURITY restricts occurrences of leave; and the process BROWSING restricts occurrences of pay. All three processes are concerned with the events pay and select, and so all three processes participate in those events—each occurrence is a multi-way synchronization.

Since these events are all part of the alphabet of SHOP, and hence available for further synchronization, they may be further constrained by additional parallel components. ² The default interface for a process P is its alphabet

(

^P

)

: those events mentioned in the process description. If the required interface in a process description is precisely this set, then it need not be mentioned explicitly. In the case of P¹ (P1

) k

(P2

) P²the alphabets may be dropped and P^1kP²written instead. The process SHOP described above could be rewritten as

SHOP

= ((

^{enter!SHOPPING}

)

^kSECURITY

)

^kBROWSING

since the interface sets given in for each component process are precisely their alphabets. The definition of the alphabet operator

(

^P

)

is given in Figures 3.7 and 3.8 on Pages 75 and 75.

Deadlock

The introduction of concurrency brings with it the possibility of deadlock, which is not possible for purely sequential programs. In a concurrent system the execution of one process might inhibit or temporarily suspend the execution of another. There are a number of situations in which this might arise, such as resource sharing, or awaiting communication. It is thus possible that every process in a concurrent system is waiting for some other process. Since no process is actively executing, each process will remain blocked, forever waiting for some other process to make progress. This unfortunate phenomenon is called deadlock: each process

individually would be able to continue execution if it were in a different environment, but all are prevented from doing so. Incompatible states between parallel components often arise as a result of unforeseen and unexpected sequences of interactions.

The combined state of all the deadlocked components is known as the deadlock state.

From the point of view of an execution, a sequence of transitions has resulted in a deadlocked process if the final process description of the sequence has no possible transitions. In this sense, the process STOP can be considered as a deadlocked process: no further progress can be made, although the execution has not completed normally.

Example 2.8

Two children share an paint box and an easel. Whenever they wish to paint, they first search for the easel and the box until both are found. After they have finished painting, they drop the box and then the easel.

ISABELLA

=

^{isabella:get:box!isabella:get:easel!isabella:paint!}

isabella^:drop^:box^!isabella^:drop^:easel^!ISABELLA

2isabella^:get^:easel^!isabella^:get^:box^!isabella^:paint^! isabella^:drop^:box^!isabella^:drop^:easel^!ISABELLA KATE

=

^{kate:get:box!kate:get:easel!kate:paint!}

kate^:drop^:box^!kate^:drop^:easel^!KATE

2kate^:get^:easel^!kate^:get^:box^!kate^:paint^! kate^:drop^:box^!kate^:drop^:easel^!KATE The easel and the box can each be held only by one child at a time:

EASEL

=

^{isabella:get:easel!isabella:drop:easel!EASEL}

2

kate^:get^:easel^!kate^:drop^:easel^!EASEL BOX

=

^{isabella:get:box!isabella:drop:box!BOX}

2

kate^:get^:box^!kate^:drop^:box^!BOX

The combination of the children and the painting equipment is described as PAINTING

=

^{ISABELLAkKATEkBOXkEASEL}

The arrangement works well on the whole, but occasionally both children decide at about the same time to paint. If this happens, then there is a danger that one of them will find the easel, and the other will find the box, after which neither of them can make any further progress (see Exercise 2.3). The two items could be released, but their owners are not ready to release them:

they are each waiting for the other item to become available first, a classic deadlock situation.

In this case the system could be made deadlock-free by insisting that the items are acquired in a particular order: the box first, and then the easel. Restricting the possibilities on the children, to only the first branch of the choice in each case, results in an overall improvement

to the system. ²

Example 2.9

A team of two furniture movers is required to move a number of pianos and tables, and each piece of furniture requires two people to lift it. Each remover independently makes his own decision as to which piece of furniture to lift first—this is an internal choice, since in each case it is a decision made by the furniture remover.

PETE

=

^{lift piano!PETE}

ulift table^!PETE DAVE

=

^{lift piano!DAVE}

ulift table^!DAVE TEAM

=

^DAVEkPETE

If each remover makes the same choice, then they are able to co-operate and synchronize on lifting the item. However, if their choices differ, then the result is deadlock.

DAVE comprises part of PETE’s environment, and so both PETE and his environment have control over the way the choice is resolved. Since it is not possible for two independent parties both to exercise complete and independent control over resolution of a choice, the result might be deadlock.

If PETE instead offered an external choice PETE⁰

=

^{lift piano!PETE0}

2lift table^!PETE⁰

then he gives up control over the choice and instead is prepared to go along with the decision of the environment. Since there is now only one agent making the choice, the resulting team

PETE^0kDAVE will no longer deadlock. ²

Indexed alphabetized parallel

The binary parallel composition operator may be generalized to model situations where there are a number of concurrent interacting components. If I is a finite set of indexes such that Pi

and Aiare defined for each i²I, then the following system may be defined:

k

i²I A_i Pi

This describes a combination of components where each Pihas interface Ai

. Any event a must be performed in a multi-way synchronization by all those processes Pi which have a²Ai: all parties interested in a particular event must be involved in all of its occurrences.

The indexed parallel composition may be defined using successive applications of the binary parallel operator. If I contains only two indexes i1and i2, then the indexed parallel is equivalent to the binary form:

k

i^2fi1

;i2 g

A_i Pi

=

^Pi1 Ai1 kAi2

Pi2

An inductive definition is provided for the case where the set I has more than two elements, defining the case with n

+ 1

elements in terms of the definition for n elements. The interface of^ki

2I

Ai Pi is the union of all the individual interfaces:

S

i²IAi. The addition of one more component Pj(j⁶²I) with interface Ajresults in the parallel composition^ki2I[fjg

A_i Pi.

k

i²I^[fj^g

A_i Pi

= (

^ki_A²_i^IPi

)

^[i²IA_i^kA_j Pj

It transpires that the binary parallel operator is associative, in the sense that the combination P¹_A^k_B[C

(

^P2B^kCP³

)

has the same executions as

(

^P1A^kBP²

)

A^[B^kCP³, and commutative:

P¹_A^k_BP²has the same executions as P²_B^k_AP¹. These two facts mean that the same process will result whichever order the processes are added to the parallel combination. As in the binary case, the interface sets Aimay be dropped from the process description, in which case the alphabet of each process is taken as its default interface. The resulting combination is written^ki

2I

Pi.

Example 2.10

A group of people are all required to be present for a meeting to be quorate.

If NAMES is the set of all the people’s names, then the alphabet and behaviour of a particular person may be described as follows:

An

=

^{fenter:n;leave:n;meetingg}

PERSONn

=

^{enter:n!PRESENTn}

PRESENTn

=

^{leave:n!PERSONn}

2meeting^!PRESENTn

The situation is then described as

GROUP

=

^kn_A²_n^NAMESPERSONn

The event meeting is in the alphabet of all the components, so it can occur when they are all able to perform it. This can only be when enter^:n has occurred for all n²NAMES without a

P⁰ P¹ P² Pn^?1

c⁰ c¹ c² c³ cn^?1 cn

Fig. 2.4 A chain of buffers

subsequent leave^:n. All the events of the form enter^:n and leave^:n appear in the alphabet of only one process, PERSONn, so their occurrence is entirely under the control of that process.

2

Example 2.11

A chain of processes which act simply as buffers, passing on an item of data, is given in Figure 2.4. There are n such components, indexed by the set^f

0

^;:::;n?

1

^g.

For every i between

0

^{and n?}

1

, the buffer Pi and its interface Ai are given by the following definition,

Ai

=

^ci:Z[ci+1:Z

Pi

=

^ci

?

^x

:

^Z!ci+1

!

^x!Pi

The chain of buffers is then defined as CHAIN

=

^ki_A^2f0:::_i ^n?1gPi

Each occurrence ci^:m of a message passing along the chain involves exactly two participants, Pi^?1and Pi, apart from the two end channels c0and cn which in each case involve only one

component. ²

Example 2.12

A network which sorts a set of n

+ 1

numbers into ascending order may be constructed from cells each of which sort two numbers at a time, as in Figure 2.5. Here the set of numbers is input along v0;0and the h0;ifor

0

^6i<n. The numbers appear in ascending order along the vj^;n⁺¹

(0

^6j6n

)

^.

Each cell Ci^;jinputs a number on its left and a number from above, outputs the smaller of these below, and the larger to its right. For internal cells, these are inputs to neighbouring cells; and for the cells in the bottom row, they are the outputs of the array.

For i^<j the Ci^;jare defined as follows:

Ci^;j

=

^hi;j

?

^x!vi;j

?

^y!vi;j+1

!min

^fx;yg!hi+1;j

!max

^fx;yg!Ci;j

Cells on the diagonal of the array are defined slightly differently, reflecting their different connections:

Ci^;i

=

^hi;i

?

^x!vi;i

?

^y!vi;i+1

!min

^{fx;yg!vi+1;i+1}

!max

^fx;yg!Ci;i

No documento The CSP Approach (páginas 46-59)