Specification of Reactive Hardware/Software Systems - Electronic ...

9.7 The Development of POOSL 297
Empty
Full(data)
def
def
ch?in(data) Full(data)
ch!out(data) Empty
This specification can directly be translated into POOSL by representing states Empty
and Full(data) by methods:
process class Buf
instance variables
communication channels ch
message interface ch?in(data) ch!out(data)
initial method call Empty
instance methods Empty ¡ data ¡ Full(data)
ch?in(data);Full(data) ch!out(data);Empty
To describe infinite, non-terminating behaviour, methods Empty and Full are defined
by mutual recursion. But can methods really be defined this way without causing any
problems? Unfortunately, the answer to this question is negative. Each time one method
calls on another one, the depth of the process stack is increased by one. Since no method
ever terminates, the stack will eventually grow beyond any bound. This problem has
earlier been detected in [Blo93] in which context-free grammars are applied to specify
the (infinite) behaviour of data communication protocols.
There exists a solution to this problem though. Suppose the buffer is currently executing
method Empty and is ready to execute method call Full(data). Since this method call
is not followed by any other statement (the call is tail recursive) and since method
Full as well as method Empty do not have any output parameters, the current local
variable environment is never needed anymore. Upon invocation of method Full this
environment can therefore be popped off the process stack. Similarly, if the buffer calls
on method Empty, the top of the stack can first be removed. In this way, the depth of the
stack will never exceed 1.
The general solution to the unbounded stack problem is formalised in terms of rule
(g’) of the labeled-transition system of Subsection 9.5.3. It states that if a method with
no output parameters is called from another method with no output parameters in a
tail-recursive way, the top of the process stack can first be removed.
9.7.5 Aborts and Interrupts
The abort and the interrupt statements are used to specify that a process should be willing
to accept some message at any instant.
Without the explicit use of the abort operator or the interrupt operator, aborts and
interrupts cannot be modelled naturally. Consider the following two statements:
(ch1?n1; ch2?n2; ch3?n3) abort ch?n