The first issue arising from trying to use the theory of designs to model programs in our context is the requirements imposed to achieve parallel behaviour: only processes that take the same amount of time can be put in parallel using the results from Section 2.3.9. We do not want to restrict ourselves to this type of parallel behaviour as most programming languages in our context do not pose any restrictions on how processes can be composed in parallel. In fact, it is common practice to have a never-terminating server process (like a driver for a hardware device) in parallel with other finite-length processes that act as its clients.
On the other hand, the fact that we intend to reason in a context where the time model is desi- gned to mimic synchronous behaviour and that most variables are shared, suggests our semantics should take advantage of the synchronous, shared-variable parallel environment from Definition 2.3.126. In this context, the second shortcoming of using the theory of designs as our reasoning fra- mework is that synchronisation is only meant to happen within parallel environments. Our context comprises languages where synchronisation permeates all constructs independently of them being executed in sequence or in parallel. Furthermore, our interest in the synchronisation action (de- noted as sync in the theory of designs) is not only based on its functionalities as the means of keeping all processes having consistent copies of the shared variables. We are also interested in
1Technically, the new healthiness conditions together with the design healthiness conditions H1 ◦ H2 form a Galois
the capabilities of this construct as the main (and only) way of controlling the way in which time is recorded in our model (i.e., the clock cycle counter). For example, the semantics of x:=
HCerequires
not only that all other processes to be notified of the new value for x but also to signal that a whole clock cycle has passed while performing this update.
An obvious solution to this problem is to assume the scope of the shared variables and the synchronous environment encompasses the whole program. In this way, assignments of the form x:=
HCe can always be described by the expression (x := e; sync). The problem arising within the
synchronous context is that law (xHC:=e)= (xHC:=e)# (x = e)
>
(3.1) no longer holds in the theory. This fact can be explained in the context of parallel programs. If we consider the program ((xHC:=e1)
k
HC(xHC:=e2)), it is not always true that it is equivalent to the program
((xHC:=e1# (x = e1) >) k
HC(xHC:=e2)). In particular, Law (3.1) should not hold as both assignments are
trying to update x and, in general, it is not clear which value will be produced after the merge takes place.
On the other hand, if x is not a shared variable across parallel processes, there is no reason for this law to not to hold. From the semantics perspective, if we try to prove Law (3.1) we can follow the reasoning below:
(x:= HCe)
= {Proposed semantics for Handel-C assignment} x:= e; sync
= {Definition 2.3.123 and law 2.3.11} c, x, x.outc:= c + 1, x.inc, e
From this point it is necessary to bind x.inc with the value of e if we are to prove that x = e after the assignment. If we recall from Definition 2.3.126, expressions in the shared context are subject to the additional condition that x.in = x.out0, hence if our program is of the form (shared x; (x:=
HCe); P) we can follow a reasoning path similar to the one presented above and reach
a situation where
((c, x, x.outc := c + 1, x.inc, e); P) ∧ x.in = x.out0
If we were able to obtain (c, x, x.outc:= c + 1, x.inc, e) ∧ x.in = x.out0from the above equation, we could actually prove Law (3.1). In order to achieve that, we need to be able to show that
((P; Q) ∧ x.in= x.out0)= (P ∧ x.in = x.out0); (Q ∧ x.in= x.out0) (3.2) Unfortunately, the result described in equation 3.2 does not hold for the general case as it requires additional restrictions on c, x.out and x.in that are not met in the theory of designs.
[Hoare and He 1998, Chapter 8]. This theory is expressive enough to cover all our needs, as it was originally devised to cope with non-deterministic behaviour and blocking communications. In fact, it can be regarded as covering a superset of the required features for our context. On the other hand, it is the ability to cope with refusals and waiting states makes the reactive theory too detailed for us and, thus, unnecessarily complex to reason with in our synchronous yet deterministic context.
The semantic domain we are looking for is a new theory that lies in between the design and the reactive processes theories. We follow the same approach used in the UTP to further restrict the design theory to a new theory where the missing properties from this section can be shown to hold2. The next section presents our main contribution in this direction: a new theory of synchronous processes with shared variables. The new theory addresses all the issues mentioned in this section, and provides a comprehensive set of algebraic laws that enable us to reason about synchronous parallel programs with shared variables.