Mechanized Theory of Event Structures: A Case of Parallel Register Machine

—The true concurrency models, and event structures, in particular, have been introduced in the 1980s as an alternative to operational interleaving semantics of concurrency, and nowadays they are regaining popularity. Event structures represent the causal dependency and conﬂict between the individual atomic actions of the system directly. This property leads to a more compact and concise representation of semantics. In this work-in-progress report, we present a theory of event structures mechanised in the C OQ proof assistant and demonstrate how it can be applied to deﬁne certiﬁed executable semantics of a simple parallel register machine with shared memory.


I. INTRODUCTION
Event structures is a mathematical formalism introduced by Winskel [1] as a semantic domain of concurrent programs.In recent years there has been renewed interest in event structures, with the applications of the theory ranging from relaxed memory models [2]- [4] to model-based mutation testing [5].
The main advantage of event structures compared to traditional interleaving semantics is that they give a more compact and concise representation of programs' behaviours.For example, consider the following code snippet of a simple parallel program.
x := 1 x := 2 x := 3 Fig. 1 Under the interleaving semantics, it has 3! = 6 traces with each trace consisting of 4 events, as depicted in fig. 1. Events themselves represent atomic side-effects produced by instruction executions.In our case, an event is either a write of a value a to a shared variable x denoted as W(x, a), or a read of a value a from a shared variable x denoted as R(x, a).
The same information can be encoded in a single event structure containing 6 events in total (see fig. 2).In the event structure, there are two types of edges between the events.The grey arrows e 1 →e 2 represent the causality relation, a partial order reflecting the causal relationship between the atomic events of computation.The red edges e 1 e 2 represent the conflict relation which is a symmetric and irreflexive relation encoding mutually exclusive events.Each particular trace can be extracted from the event structure as a linearisation of some configuration, that is a causally-closed and conflict-free subset of events, which additionally should satisfy the constraint that each read is preceded by a matching write.
Fig. 2 The programming languages theory and formal semantics research communities are moving to increase the usage of proof assistants like COQ [6], AGDA [7], ISABELLE/HOL [8], AREND [9], and others, to complement theoretical studies with their mechanisation, as this process increases the reliability and reproducibility of scientific results.Yet, to the best of our knowledge, there is little work on mechanisation of the theory of event structures.The present report aims to close the gap.
We have chosen COQ as the proof assistant because it's a mature formal proof management tool with a rich ecosystem of libraries, plugins, documentation, and existing applications including the certification of properties of programming languages: the verified C compiler CompCert [10], the Verified Software Toolchain [11] for verification of C programs, and the Iris framework [12] for concurrent separation logic, to name a few.
Our end goal is to develop a COQ library containing a comprehensive set of common definitions, lemmas, and tactics that would allow researchers to utilise the theory of event structures for the needs of their domain.
In this work-in-progress report, we sketch the common design principles behind our library and give a concrete example of its usage by developing a formal mechanised semantics of a simple register machine with shared memory.
Our library together with the examples of its usage is available online at https://github.com/event-structures/event-struct.

II. RELATED WORK
Event structures were introduced by Winskel to study the semantics of the calculus of communicating systems [1], [13].Several modifications of event structures [14], [15] were later proposed to tackle similar problems.
More recently, event structures were applied in the context of relaxed memory models [2]- [4], [16].Among this line of work, we are aware of only one paper [16] that was accompanied by a mechanisation in a proof assistant.The authors formalised the WEAKESTMO [4] memory model in COQ.However, this memory model uses a custom variant of event structures, that does not obey the axioms of any conventional class of event structures [13]- [15].This fact makes it harder to reuse and adapt it to other applications of the theory.

III. BACKGROUND
There exist several modifications of event structures.Currently, we have implemented only the prime event structures [1] in our library.We give some background on this class of event structures below.
Definition 3.1: A prime event structure (PES) is a triple (E, , #), where ) is a partial order; for every e ∈ E its causality prefix e := {e : e e} is finite, i.e., every event is caused by a finite set of events.
• # is a conflict relation on E such that: -# is irreflexive and symmetric; it satisfies the hereditary condition: That is, if two events are in conflict, then all their causal successors are necessarily in conflict.A single prime event structure can encode multiple runs of a program.Each individual run can be extracted as a configuration.In other words, configurations are used to model a history of computation up to a certain point.

IV. OVERVIEW OF OUR LIBRARY
In this section, we sketch the design principles of our library.We build our mechanisation on top of the MATHCOMP [17] library which is an extensive and coherent repository of formalized mathematical theories, whose implementation is based on the SSREFLECT [18] extension of the COQ system.By using MATHCOMP, we draw on the large corpus of already formalised algorithms and mathematical results: its core modules feature support for a range of useful data structures, e.g.numbers, sequences, finite graphs, and also interfaces: types with decidable equality, subtypes, finite types, and so on.
We also use the small-scale reflection methodology [18], [19], a key ingredient of SSREFLECT.
The small-scale reflection approach is based on the pervasive use of symbolic representations intermixed with logical ones within the confines of the same proof goal, as opposed to large-scale reflection which does not allow such mixing.Symbolic representations are connected to the corresponding logical ones via user-defined reflect predicates.The symbolic representation can be manipulated by the computational engine of the language, allowing the user to automate low-level routine proof management by using various decision and simplification procedures.Whenever the user needs to guide the proof they can switch to the logical representation and perform some proof steps manually.
To achieve better automation and e.g.get proof irrelevance for free, one is encouraged to use decision procedures whenever possible.For example, in the context of our library, we encode the binary relations of the event structures as decidable bool-valued relations, i.e., , # : E → E → bool, as opposed to propositional relations of type E → E → Prop.
Encoding computable relations in COQ, especially their (computable) transitive closures, can be quite challenging since COQ is a total language and its termination checker only understands termination patterns going slightly beyond simple structural recursion.To make it easier, we employ the EQUATIONS function definition plugin [20] which provides both notations for writing programs by dependent patternmatching and good support for well-founded recursion.
In fact, binary relations are omnipresent in our formalization.This quickly manifested in a substantial amount of proof overhead and we seeked for tools to automate our proofs.Since binary relations form a Kleene Algebra with Tests (KAT) [21], we have chosen to use the RELATION-ALGEBRA1 [22] package which provides a number of tactics to solve goals using decision procedures for a number of theories, such as partially ordered monoids, lattices, residuated Kleene allegories and KATs.
We also favour the computational encoding of semantics.Similar to the recent related works on mechanisation of operational semantics [23]- [25], we encode the semantics as monadic interpreters.This allows us to extract [26] the semantics as a functional program and run it.We believe that the possibility to run the semantics is a very useful feature, as it allows to debug the formal semantics and helps to develop better intuition about it.
To facilitate computable semantics, we define a subclass of finitely supported event structures as a finite sequence of events combined with a finitely supported function which enhances events with additional information, such as their labels, causality predecessors, etc. Encoding finitely supported functions is not a trivial endeavor in a proof assistant and for this task we use the FINMAP 2 library which is an extension of MATHCOMP providing finite sets and finite maps on types with a choice operator (rather than on finite types).
Finally, to encode the algebraic hierarchy of various classes of event structures we use yet another feature of MATH-COMP -packed classes [27], which is a design pattern providing multiple inheritance, maximal sharing of notations and theories, and automated structure inference.

V. CASE STUDY
In this section, we provide a case study demonstrating an application of our mechanised theory of event structures.We show how it can be used to encode the semantics of a parallel register machine equipped with shared memory.

A. Register Machine
For our case study, we use a simple idealised model of a register machine, which consists of a finite sequence of instructions, an instruction pointer, and an infinite set of registers.The syntax of the machine's language is shown in fig. 3 We first present the semantics of a single-threaded program.Under this semantics, memory access instructions do not operate on shared memory but rather produce a label denoting the side-effect of the operation (see fig. 4).This encoding The semantics is given in the form of a labelled transition system:3 P s l − → s , where P is a program, l is a label, s and s are states of the machine.The state of the machine itself consists of an instruction pointer i and a map from registers to their values σ, as shown in fig. 5.The rules of the semantics are standard (see fig. 6).

B. Event Structure of Register Machine
In this section we present operational semantics which constructs a prime event structure encoding a set of possible behaviours of the register machine.
The event structure is constructed incrementally in a stepby-step fashion by adding a single event on each step.In order to generate a new event on each step, we require that events behave as identifiers.
Definition 5.1: We say that a set E together with strict partial order ≺ form an identifier set if: • there exists a distinguished initial identifier e 0 ∈ E; • there exists a function fresh : E → E which generates a new fresh identifier, s.t.
∀e ∈ E. e ≺ fresh(e) We will encode the event structure as a tuple E, lab, f po , f rf and explain below the meaning of each component, and how they form a prime event structure together.
The first component E is a sequence of events e 1 . . .e n in reverse order w.r.t the order in which events get added to the structure.The second component is a labelling function lab : E → Lab, assigning a label to each event.
Next, following the theory of axiomatic weak memory models [28], we define the causality relation of the register machine's event structure as the reflexive transitive closure of the union of two relations -program order and reads-from, denoted as po and rf correspondingly.
Fig. 6: Semantics of register machine The program order relation tracks precedence of events within a single thread.The reads-from relation captures the flow of values from write events to read events, and ensures that values do not appear out of thin air [28], [29].
In order to construct po and rf incrementally we represent them via their inverse covering functions f po and f rf .
Definition 5.2 (Covering): Let be a partial order.Then is covering relation w.r.t.whenever x y is true if and only if x < y and there is no z s.t.x < z and z < y.A (nondeterministic) function f from A to the set of finite subsets of A is a covering function if its corresponding relation, i.e., We use the inverse covering function because it is more convenient in our setting.Indeed, the semantics adds a new event at each step.Then it is convenient to require that, in addition, the small-step relation is provided with the po and rf predecessors of a new event.
We define the conflict relation in two steps.First, we define the primitive conflict relation ∼ # which is generated by the f po function.The two events are considered to be in primitive conflict if they are not equal and have a common po predecessor.For this definition to work properly, we also need to assume that each thread has a special initial event labelled by a distinguished thread start label TS.We also need a way to reconcile the event structure with the states of the machine's threads.To do so, we use a function Σ : E → ThrdState which maps an event to a thread state obtained as the result of the execution of the event's sideeffect.Let us consider an example.Given the program below, our semantics builds the corresponding event structure as shown in fig. 7. Our construction of event structures allows to encode a wide class of so-called po∪rf acyclic relaxed memory models [28].For example, a predicate corresponding to sequential consistency [30] requires that the causality order can be extended to a total order on all events of the configuration, such that for each read event the last preceding write event to the same location has the same value as the read.

VI. FUTURE WORK
There are several directions for future work.First, we plan to apply our library to a wider range of problems.We are going to develop a mechanised semantics of some long-established languages used to model concurrency, in particular, the calculus of communicating systems (CCS) [31] and π-calculus [32].We also plan to continue our work on expressing various relaxed models of shared memory [28], [33], [34] in terms of event structures.
Second, we want to cover other classes of event structures in our library, in particular, bundle [14], flow [15], and stable [1], [13] event structures.We plan to use them to develop mechanised denotational semantics of concurrent languages and relaxed shared memory models [35].
Finally, we plan to mechanise in COQ classical results that connect various classes of event structures [15], [36].It would allow us to easily establish the connection between operational and denotational semantics of concurrent languages.

Fig. 3 :
Fig. 3: Syntax of the register machine