Operational Semantics of Process Monitors
Abstract
is a specification language for runtime monitors that can directly express concurrency in a bottomup manner that composes the system from simpler, interacting components. It includes constructs to explicitly flag failures to the monitor, which unlike deadlocks and livelocks in conventional process algebras, propagate globally and aborts the whole system’s execution. Although has a trace semantics along with an implementation demonstrating acceptable performance, it lacks an operational semantics. An operational semantics is not only more accessible than trace semantics but also indispensable for ensuring the correctness of the implementation. Furthermore, a process algebra like admits multiple denotational semantics appropriate for different purposes, and an operational semantics is the basis for justifying such semantics’ integrity and relevance. In this paper, we develop an SOSstyle operational semantics for , which properly accounts for explicit failures and will serve as a basis for further study of its properties, its optimization, and its use in runtime verification.
Keywords:
Operational Semantics, Concurrency, Runtime Monitoring, Communicating Sequential Processes1 Introduction
Specificationbased runtime monitoring [5] checks a program’s execution trace against a formal specification. Often more rigorous than testing due to the presence of a formal specification, this technique is also computationally much cheaper than formal verification methods like model checking, as it only needs to look at concrete program runs with instrumentation. [10] is a language based on Hoare’s Communicating Sequential Processes [6] for developing the formal specification. Unlike many other languages in this niche, can directly express concurrency. Moreover, it builds up the specification in a bottomup manner by composing smaller, interacting components, helping to model complex behavior.
’s main appeal as a specification language, compared to plain CSP, is a FAIL construct that signals a global failure, aborting all processes in the model at once. This construct can be used like assert(false) in C or Java, allowing to code invariants that mark some states as (shouldbe) unreachable. By contrast, deadlocks and livelocks, the conventional notions of failure in CSP, affect only the deadlocked or livelocked process(es). These failures are thus very difficult to propagate into a failure for the entire system, as desired for assertion failures. However, the semantics of how FAIL propagates throughout the model requires special treatment. Because the propagation preempts all other activities, normal execution rules must apply only when FAIL is not currently propagating. This is a negative constraint, which is generally problematic [4].
While earlier work [10] demonstrated a trace semantics and a reasonably efficient implementation for , an operational semantics has been lacking. Developing an operational semantics is highly desirable for several reasons. Firstly, though a trace semantics more naturally defines the set of behaviors (i.e. traces) that comply with a specification, an operational semantics more directly defines the implementation. Secondly, process algebras admit multiple denotational semantics capturing different aspects of operationally defined behavior [3]. Investigating the full spectrum of such semantics requires an operational semantics. Finally, an operational semantics provides a more accessible presentation of the semantics than denotational semantics.
1.1 Contributions
2 Syntax and Trace Semantics of
Event  

Event Variable  
Term  
Event Set  where is computable 
Event Set Param 
This section reviews the syntax and trace semantics of . Figure 1 presents the syntax. A term represents a process, which is an entity that successively emits events drawn from an alphabet . Terms are built from the following constructs, with the indicated meanings. For a thorougher explanation, see [10].

The stuck term STOP does not emit anything.

The failing term FAIL aborts all processes.

Prefix chooses and emits an event , then executes .

Choice executes or , whichever manages to emit something first.

Parallel composition executes and in parallel. Their events are interleaved arbitrarily, except events in are synchronized.
An event set can be specified by any computable function parametrized by the ’s bound by surrounding prefix operators.
In this short paper, we omit recursion and the terminating action in the interest of conciseness. This paper’s focus is on analyzing FAIL, and complicates the presentation substantially without adding anything of conceptual significance. Recursion seems to be similar, though it is still under investigation.
Trace  

Trace Set  
Trace Set Operations  
(1) (2)  
Trace Semantics  
Figure 2 presents the trace semantics. A trace is a (possibly empty) sequence of events, and is the set of all traces. The concatenation of traces and is written . A trace set is any prefixclosed set of traces, which can be empty, unlike in conventional process algebras. The trace semantics of assigns to each term a trace set , which is intuitively the set of traces can emit.
The semantic map uses some operations on trace sets. If is a trace set, prepends to all members of and adjoins , while discards all traces in that do not start with and drops the leading from all remaining traces. The operator is defined by eqs. 2 and 1. Though significantly simplified, these equations are equivalent to the ones found in [10] modulo the absence of . In [10], this operator was defined “coinductively”, which was correct but misleading. Formally, by the KnasterTarski Theorem, the defining equations (1) and (2) have a greatest solution in the complete lattice of total binary functions on TraceSets ordered by pointwise inclusion, which was taken to be . However, if and are any two solutions of these equations, then for any and , every trace in is also in , by straightforward induction on the trace’s length. Thus, the solution is unique, and is this unique solution.
3 Operational Semantics
Action  

Doomed Term  
Viable Term  
Operational Semantics  
This section presents the operational semantics. The semantics is given in Figure 3, which defines internal transitions between terms. Some transitions do not emit events but instead emit the silent action . A visible transition happens when internally transitions to in zero or more steps, and the non actions it emits along the way forms .
The main challenge in this semantics is capturing the propagation of FAIL. For example, in , the must not be allowed to keep emitting events, for then could do so indefinitely, withholding the propagation of FAIL. Instead, FAIL should kill all processes including , transitioning the whole term to FAIL. To achieve this effect, the usual rule that allows the left operand to transition must apply only when the right operand is not failing. This constraint is tricky to capture because it is a negative constraint.
In our semantics, the constraint is captured by the viability annotation . This annotation restricts the range of the metavariable to exclude doomed terms, i.e. terms for which transitioning to FAIL has become inevitable and are now propagating FAIL within themselves. These annotations are placed so that when a term is doomed, rules that propagate FAIL become the only applicable ones, thus forcing the propagation to take place.
Proposition 1
A doomed process always transitions to FAIL while emitting nothing but .
Proof
implies , where denotes term size, by induction on . Thus, a doomed term can only transition, and only finitely many times, while staying doomed. Another induction shows , so a doomed term keeps transitioning until it reaches FAIL.
4 Correspondence Between the Semantics
This section establishes a correspondence between the two semantics: a process’ denotation is precisely the set of traces it can emit, up to but not including any transitions that doom the process. This means that the monitor comparing a system to can declare a failure as soon as the system’s trace strays out of .
Theorem 4.1
.
A special case of this theorem is particularly illuminating: the doomed set is precisely the set of terms with empty trace sets, corresponding to the fact that doomed terms silently transition to FAIL.
Proposition 2
.
Proof
Induction on .
Furthermore, trace sets faithfully follow nonsilent transitions, in that the traces which follow an event in are precisely the traces of terms that follow after a sequence of transitions that emit .
Lemma 2
.
Proof
Induction on the size of , where event sets do not count toward size, e.g. . This way, , so when , the inductive hypothesis applies to , despite it not being a subterm. Several lemmas are needed along the way, two of which are of particular note. Take for example with and . Inductive hypotheses give . Then, continuity (Lemma 1) lets us commute the and , equating this to . Then, a lemma characterizing those with equates this to .
Theorem 4.1 is a straightforward consequence of these facts.
Proof (of Theorem 4.1)
We show by induction on . For the base case, by Proposition 2. If , then , and if , then can only transition inside Doomed as noted in the proof of Proposition 1. For the inductive step, breaks down as , and . By Lemma 2, this is equivalent to having and for some , which by inductive hypothesis is equivalent to .
5 Related Works
The main issue with semantics is the propagation of FAIL, which entails the negative constraint that normal computation rules apply only if FAILpropagation rules do not. Negative premises of the form come quite naturally as a means for codifying such constraints, but negative premises are generally quite problematic. A transition relation satisfying negative rules may be notexistent, or nonunique, with no obvious guiding principle (such as minimality) in choosing the “right” one. Some formats do guarantee welldefinedness, such as GSOS with the witnessing constraint [2] and ntyft/ntyxt [4]. But even then, negative rules tend to betray desirable properties such as compositionality of some forms of bisimulation [1].
Our approach exploits the fact that we only have a very specific negative constraint – the absence of doomed subprocesses – and encodes it with a restriction on the range of metavariables in transition rules. With trick, we manage to avoid negative premises altogether, essentially turning the system into a positive one. This approach is very commonly employed, e.g. in reduction rules for the callbyvalue calculus [7], where the argument in a function application should be evaluated only if the function expression cannot be evaluated any further.
We identify FAILinduced failures by transitions into FAIL, but an alternative approach would be to have FAIL emit a special event , just as termination is signalled by . Though we have not pursued this idea in detail, the central concern there will be to give higher priority than all other events. Prioritized transition also involves a negative constraint but is known to be quite wellbehaved, being translatable to plain CSP [9]. At the moment, it is not clear if FAIL propagation can be translated to the prioritizedtransition primitive in [9].
6 Conclusion
We gave an operational semantics for that adequately captures the behavior of FAIL, the global failure operator, with positive operational rules. This semantics induces the previously defined trace semantics. As noted in the introduction, this development enables studies of other types of denotational semantics, while informing the implementation. An interesting direction of future work is to see if FAIL can be specified by priorities, and if that approach yields betterbehaved semantics.
Acknowledgment
The authors would like to thank Yoshinao Isobe for comments on an earlier draft of this paper and stimulating discussions.
References
 [1] Bloom, B.: Structural operational semantics for weak bisimulations. Theoretical Computer Science 146(1), 25–68 (1995)
 [2] Bloom, B., Istrail, S., Meyer, A.R.: Bisimulation can’t be traced. Journal of the ACM 42(1), 232–268 (1995)
 [3] van Glabbeek, R.J.: The linear time  branching time spectrum I. The semantics of concrete, sequential processes, chap. 1, pp. 3–100. Elsevier (2001)
 [4] Groote, J.F.: Transition system specifications with negative premises. Theoretical Computer Science 118(2), 263 – 299 (1993)
 [5] Havelund, K., Reger, G.: Specification of parametric monitors, pp. 151–189. Springer Fachmedien Wiesbaden, Wiesbaden (2015)
 [6] Hoare, C.A.R.: Communicating Sequential Processes. PrenticeHall, Inc., Upper Saddle River, NJ, USA (1985)
 [7] Mitchell, J.C.: Foundations for Programming Languages. MIT Press (1996)
 [8] Plotkin, G.D.: A structural approach to operational semantics. The Journal of Logic and Algebraic Programming 60, 17–139 (2004)
 [9] Roscoe, A.: The expressiveness of CSP with priority. Electronic Notes in Theoretical Computer Science 319, 387 – 401 (2015)
 [10] Yamagata, Y., Artho, C., Hagiya, M., Inoue, J., Ma, L., Tanabe, Y., Yamamoto, M.: Runtime Monitoring for Concurrent Systems, pp. 386–403. Springer International Publishing, Cham (2016)