Towards Races in Linear Logic

Process calculi based in logic, such as $\pi$DILL and CP, provide a foundation for deadlock-free concurrent programming, but exclude non-determinism and races. HCP is a reformulation of CP which addresses a fundamental shortcoming: the fundamental operator for parallel composition from the $\pi$-calculus does not correspond to any rule of linear logic, and therefore not to any term construct in CP. We introduce non-deterministic HCP, which extends HCP with a novel account of non-determinism. Our approach draws on bounded linear logic to provide a strongly-typed account of standard process calculus expressions of non-determinism. We show that our extension is expressive enough to capture many uses of non-determinism in untyped calculi, such as non-deterministic choice, while preserving HCP's meta-theoretic properties, including deadlock freedom.


Introduction
Consider the following scenario: Ami and Boé are working from home one morning when they each get a craving for a slice of cake. Being denizens of the web, they quickly find the nearest store which does home deliveries. Unfortunately for them, they both order their cake at the same store, which has only one slice left. After that, all it can deliver is disappointment. This is an example of a race condition. We can model this scenario in the π-calculus, where , and are processes modelling Ami, Boé and the store, and and are channels giving access to a slice of cake and disappointment, respectively. This process has two possible outcomes: either Ami gets the cake, and Boé gets disappointment, or vice versa. (x(y). x(z).
x . ) =⇒ introduced by Kokke, Montesi, and Peressotti [KMP18]. Delayed actions are not an essential part of HCP, but significantly complicate the theory. Therefore, we base our work on the variant without delayed actions. For typographical simplicity, we will refer to the system without delayed actions as HCP, instead of HCP − . Should we need to refer to the system with delayed actions, we will use DHCP.

Non-determinism, Logic, and Session Types
Recent work extended πDILL and CP with operators for non-deterministic behaviour [ALM16,Cai14,CP17]. These extensions all implement an operator known as non-deterministic local choice. (This operator is written as P + Q, but should not be confused with input-guarded choice from the π-calculus [MPW92].) Non-deterministic local choice can be summarised by the following typing and reduction rules: P Γ Q Γ P + Q Γ P + Q =⇒ P P + Q =⇒ Q Local choice introduces non-determinism explicitly, by listing all possible choices. This is unlike the π-calculus, where non-determinism arises due to multiple processes communicating on shared channels. We can easily implement local choice in the π-calculus, using a nullary communication: (x .0 x().P x().Q) =⇒ (P x().Q) or (x().P Q) In this implementation, the process x .0 will "unlock" either P or Q, leaving the other process deadlocked. Or we could use input-guarded choice: (x .0 (x().P + x().Q)) However, there are many non-deterministic processes in the π-calculus that are awkward to encode using non-deterministic local choice. Let us recall our example: (x .
x(z). ) =⇒ This non-deterministic interaction involves communication. If we wanted to write down a process which exhibited the same behaviour using non-deterministic local choice, we would have to write the following process: (x .y .
x(z). y(w). ) =⇒ In essence, instead of modelling a non-deterministic interaction, we are enumerating the resulting deterministic interactions. This means non-deterministic local choice cannot model non-determinism in the way the π-calculus does. Enumerating all possible outcomes becomes worse the more processes are involved in an interaction. Imagine the following scenario: Three customers, Ami, Boé, and Cat, have a craving for cake. Should cake be sold out, however, well... a doughnut will do. They prepare to order their goods via an online store. Unfortunately, they all decide to use the same shockingly under-stocked store, which has only one slice of cake, and a single doughnut. After that, all it can deliver is disappointment. We can model this scenario in the π-calculus, where , , , and are four processes modelling Ami, Boé, Cat, and the store, and , , and are three channels giving access to a slice of cake, a so-so doughnut, and disappointment, respectively. (x .
x(w). ) =⇒ With the addition of one process, modelling Cat, we have increased the number of possible outcomes enormously! In general, the number of outcomes for these types of scenarios is n!, where n is the number of processes. This means that if we wish to translate any non-deterministic process to one using non-deterministic local choice, we can expect a factorial growth in the size of the term.

Hypersequent Classical Processes
In this section, we introduce HCP [KMP18], the basis for our calculus HCP ND . The term language for HCP is a variant of the π-calculus [MPW92]. In HCP, processes (P , Q, R) communicate using names (x, y, z, . . . ). Each name is one of the two endpoints of a bidirectional communication channel [Vas12]. A channel is formed by connecting two endpoints using name restriction. This is in contrast to sections 1 and 2, where we used names to represent channels.
P , Q, R ::= x↔y link | 0 terminated process | (νxx )P name restriction, "cut" The variables x, y, z, u, v, and w range over channel endpoints. Occasionally, we use a, b, and c to range over free endpoints, i.e., those which are not connected to another endpoint. The construct x↔y links two endpoints [San96,Bor98], forwarding messages received on x to y and vice versa. The construct (νxx )P creates a new channel by connecting endpoints x and x . By convention, we name dual endpoints using primes, e.g., x and x . However, the primes are merely a naming convention, and do not denote co-names, e.g., x and x are not inherently dual, only under a ν-binder (νxx ). The construct P Q and composes two processes. In x(y).P and x[y].P , round brackets denote input, square brackets denote output. We use bound output [San96], meaning that both input and output bind a new name. Terms in HCP are identified up to structural congruence.
Definition 3.2 (Structural congruence). The structural congruence ≡ is the congruence closure over terms which satisfies the following additional axioms: Channels in HCP are typed using a session type system which is a conservative extension of linear logic.

Definition 3.3 (Types).
A, B, C :: Duality plays a crucial role in both linear logic and session types. In HCP, the two endpoints of a channel are assigned dual types. This ensures that, for instance, whenever a process sends across a channel, the process on the other end of that channel is waiting to receive. Each type A has a dual, written A ⊥ . Duality (· ⊥ ) is an involutive function on types.
Environments associate channels with types. Names in environments must be unique, and environments Γ and ∆ can only be combined (Γ, ∆) if cn(Γ) ∩ cn(∆) = ∅, where cn(Γ) denotes the set of channel names in Γ.
Definition 3.5 (Environments). Γ, ∆, Θ ::= x 1 : A 1 . . . x n : A n HCP registers parallelism using hyper-environments. A hyper-environment is a multiset of environments. While names within environments must be unique, names may be shared between multiple environments in a hyper-environment. We write G H to combine two hyper-environments.  Definition 3.7 (Typing judgements). A typing judgement P Γ 1 . . . Γ n denotes that the process P consists of n independent, but potentially entangled processes, each of which communicates according to its own protocol Γ i . Typing judgements can be constructed using the inference rules below.

Structural rules
Ax x↔y x : A, y : Alternative syntax. In (1), the only well-typed continuation P is the terminated process 0. We could use an alternative formulation of the rule, which combines (1) and H-Mix 0 . However, as H-Mix 0 is used on its own, and not just in combination with (1), we chose the present formulation to avoid having multiple different representations of the terminated process in the language.
Reductions relate processes with their reduced forms.
Definition 3.8 (Reduction). Reductions are described by the smallest relation =⇒ on process terms closed under the rules below: We define unbound output in terms of bound output and link [LM15]: 3.1. Example. HCP uses hyper-sequents to structure communication, and it is this structure which rules out deadlocked interactions. Let us go back to our example of a deadlocked interaction from section 1. If we want to type this interaction in HCP, we run into a problem: to connect x and y, and z and w, such that we get a deadlock, we need to construct the following term: ). However, there is no typing derivation for this term. We can construct a typing derivation down to the sequent below, but we cannot introduce both name restrictions: the Cut rule eliminates a hypersequent separator, which ensures that it only ever connects two independent processes, but the sequent below only has one.
Proof. By induction on the derivation of P ≡ Q.
Theorem 3.10 (Preservation). If P G and P =⇒ Q, then Q G.
Proof. By induction on the derivation of P =⇒ Q.
Definition 3.11 (Actions). A process P acts on x whenever x is free in the outermost term constructor of P , e.g., x[y].P acts on x but not on y, and x↔y acts on both x and y. A process P is an action if it acts on some channel x.
Definition 3.12 (Canonical forms). A process P is in canonical form if such that: no process P i is a cut or a mix; no process P i is a link acting on a bound channel x i or x i ; and no two processes P i and P j are acting on dual endpoints x i and x i of the same channel.
Lemma 3.13. If a well-typed process P is in canonical form, then it is blocked on an external communication, i.e., P ≡ (νx 1 x 1 ) . . . (νx n x n )(P 1 | · · · | P n+m+1 ) such that at least one process P i acts on a free name.
Proof. We have P ≡ (νx 1 x 1 ) . . . (νx n x n )(P 1 . . . P n+m+1 ), such that no P i is a cut or a link acting on a bound channel, and no two processes P i and P j are acting on the endpoints of the same channel. The prefix of cuts and mixes introduces n channels. Each application of cut requires an application of mix, so the prefix introduces n + m + 1 processes. Therefore, at least m + 1 of the processes P i must be acting on a free channel, i.e., blocked on an external communication.
Theorem 3.14 (Progress). If P G, then either P is in canonical form, or there exists a process Q such that P =⇒ Q. Proof. We consider the maximum prefix of cuts and mixes of P such that and no P i is a cut. If any process P i is a link, we reduce by (↔). If any two processes P i and P j are acting on dual endpoints x i and x i of the same channel, we rewrite by ≡ and reduce by the appropriate β-rule. Otherwise, P is in canonical form.
Theorem 3.15 (Termination). If P G, then there are no infinite =⇒-reduction sequences.
Proof. Every reduction reduces a single cut to zero, one or two cuts. However, each of these cuts is smaller, measured in the size of the cut formula. Furthermore, each instance of the structural congruence preserves the size of the cut. Therefore, there cannot be an infinite =⇒-reduction sequence.
3.3. Erratum for HCP. The typing rules for HCP presented here are more restrictive than those in earlier publications [KMP18]. Progress does not hold for the earlier version. For instance, the following process is stuck, yet typeable: The earlier typing rules failed to guarantee a crucial property: each typing environment should correspond to one top-level action. The rules presented in this paper fixes the problem by disallowing hyper-environments in logical rules.
The move from channel names to endpoint names is not essential to the fix, but significantly streamlines the presentation. Otherwise, the type system must guarantee that each channel name occurs at most twice in the hypersequent, and if twice, then with dual types. Using endpoint names, it is sufficient to require that all names be distinct.

Shared Channels and Non-determinism
In this section, we will discuss our main contribution: an extension of HCP which allows for races while still excluding deadlocks. We have seen in section 3.1 how HCP excludes deadlocks, but how exactly does HCP exclude races? Let us return to our example in π-calculus from section 1, to the interaction between Ami, Boé and the store.
x(z). ) =⇒ z}) Races occur when more than two processes attempt to communicate simultaneously over the same channel. However, the Cut rule of HCP requires that exactly two processes communicate over each channel: G Γ, ∆ We could attempt to write down a protocol for our example, stating that the store has a pair of channels x, y : with which it communicates with Ami and Boé, taking to be the type of interactions in which cake may be obtained, i.e. of both and , and state that the store communicates with Ami and Boé over a channel of type . However, this only models interactions such as the following: Γ, ∆, Θ In this interaction, Ami will get whatever the store decides to send on x, and Boé will get whatever the store decides to send on y. This means that this interactions gives the choice of who receives what to the store. This is not an accurate model of our original example, where the choice of who receives the cake is non-deterministic and depends on factors outside of any of the participants' control! Modelling racy behaviour, such as that in our example, is essential to describing the interactions that take place in realistic concurrent systems. We would like to extend HCP to allow such races in a way which mirrors the way in which the π-calculus handles non-determinism. Let us return to our example: (x .
x(z). ) In this interaction, we see that the channel x is only used as a way to connect the various clients, Ami and Boé, to the store. The real communication, sending the slice of cake and disappointment, takes places on the channels , , y and z. Inspired by this, we add two new constructs to the term language of HCP for sending and receiving on a shared channel. These actions are marked with a to distinguish them from ordinary sending and receiving. As before, round brackets denote input, square brackets denote output. Note that x[y].P , much like x[y].P , is a bound output: both client creation and server interaction bind a new name. The structural congruence, which identifies certain terms, is the same as theorem 3.2.
In any non-deadlock interaction between a server and some clients, there must be exactly as many clients as there are server interactions. Therefore, we add two new dual types for client pools and servers, which track how many clients or server interactions they represent. The types ! n A and ? n A ⊥ are dual. (The subscripts must be identical, i.e., ! n A is not dual to ? m A ⊥ if n = m.) Duality remains an involutive function.
We have to add typing rules to associate our new client and server interactions with their types. The definition for environments will remain unchanged, but we will extend the definition for the typing judgement. To determine the new typing rules, we essentially answer the question "What typing constructs do we need to complete the following proof?" x (w). x (w ). ) Γ, ∆, Θ The constructs x[y].P and x(y).P introduce a single client or server action, respectivelyhence, channels of type ! 1 and ? 1 . However, when we cut, we want to cut on both interactions simultaneously. We need rules for the contraction of shared channel names.

Clients and Pooling.
A client pool represents a number of independent processes, each wanting to interact with the same server. Examples of such a pool include Ami and Boé from our example, customers for online stores in general, and any number of processes which interact with a single, centralised server.
We introduce two new rules: one to construct clients, and one to pool them together. The first rule, (! 1 ), interacts over a channel as a client. It does this by receiving a channel y over a shared channel x. The channel y is the channel across which the actual interaction will eventually take place. The second rule, Cont ! , allows us to contract shared channel names with the same type. When used together with H-Mix, this allows us to pool clients together. P Γ, y : x : ! m+n A Using these rules, we can derive the left-hand side of our proof by marking Ami and Boé as clients, and pooling them together.

Servers and Sequencing.
Dual to a pool of n clients in parallel is a server with n actions in sequence. Our interpretation of a server is a process which offers some number of interdependent interactions of the same type. Examples include the store from our example, which gives out slices of cake and disappointment, online stores in general, and any central server which interacts with some number of client processes. We introduce two new rules to construct servers. The first rule, (? 1 ), marks a interaction over some channel as a server interaction. It does this by sending a channel y over a shared channel x. The channel y is the channel across which the actual interaction will take place. The second rule, Cont ? , allows us to merge two (possibly interleaved) sequences of server interactions. This allows us to construct a server which has multiple interactions of the same type, across the same shared channel. ? m+n A Using these rules, we can derive the right-hand side of our proof, by marking each of the store's interactions as server interactions, and then contracting them. Θ, w : , w : (? 1 ) y (w ). Θ, z : , y : ? 1 (? 1 ) y(w). y (w ). Θ, y : ? 1 , y : ? 1 Cont ? y(w). x(w ). Θ, y : ? 2 Thus, we complete the typing derivation of our example.
Definition 4.3 (Typing judgements). We extend theorem 3.7 as follows: Running Clients and Servers. Finally, we need to extend the reduction rules to allow for the reduction of client and server processes. The reduction rule we add is a variant of E-Send.
Definition 4.4 (Reduction). We extend theorem 3.8 as follows: The difference between E-Request and E-Send is that the former allows reduction to happen in the presence of an unrelated process R, which is passed along unchanged. This is necessary, as there may be other clients waiting to interact with the server on the shared channel x, which cannot be moved out of scope of the name restriction (νx). When there is no unrelated process R, i.e., when there is only a single client, we can rewrite by SC-ParNil before and after applying E-Request.
So where does the non-determinism in HCP ND come from? Let us say we have a term of the following form: x (y 1 ). . . . x (y n ).Q) As parallel composition is commutative and associative, we can rewrite this term to pair any client in the pool with the server before applying E-Request. Thus, like in the π-calculus, the non-determinism is introduced by the structural congruence. Does this mean that, for an arbitrary client pool P in (νxy)(P y(w).Q), every client in that pool is competing for the server interaction on x? Not necessarily, as some portion of the clients can be blocked on an external communication. If we reduce this term, then only the clients x[z 1 ].P 1 . . . x[z n ].P n will be assigned server interactions, and we end up with the following canonical form: This matches our intuition and the behaviour of the π-calculus. For instance, we can now encode our example, where Ami and Boé both send a request for cake to the store, and the store sends back either a cake or nothing: The encoding presented above is slightly more complex than necessary: after the store receives a request as x 1 , it could simply perform the cake interaction over that channel, and similarly for x 2 . However, we include these actions for clarity.
Alternative syntax. If we choose to reuse the terms x[y].P and x(y).P for shared channels, we could replace E-Send with E-Request, using the latter rule for both cases.
Lemma 4.5 (Preservation for ≡). If P ≡ Q and P G, then Q G.
Proof. By induction on the derivation of P ≡ Q.
Theorem 4.6 (Preservation). If P G and P =⇒ Q, then Q G.
Proof. By induction on the derivation of P =⇒ Q.
Definition 4.7 (Actions). A process P acts on x whenever x is free in the outermost term constructor of P , e.g., x(y).P acts on x but not on y, and x↔y acts on both x and y. A process P is an action if it acts on some channel x.
Definition 4.8 (Canonical forms). A process P is in canonical form if P ≡ (νx 1 x 1 ) . . . (νx n x n )(P 1 | · · · | P n+m+1 ), such that: no process P i is a cut or a mix; no process P i is a link acting on a bound channel x i or x i ; and no two processes P i and P j are acting on dual endpoints x i and x i of the same channel.
Lemma 4.9. If a well-typed process P is in canonical form, then it is blocked on an external communication, i.e., P ≡ (νx 1 x 1 ) . . . (νx n x n )(P 1 | · · · | P n+m+1 ) such that at least one process P i acts on a free name.
Proof. We have P ≡ (νx 1 x 1 ) . . . (νx n x n )(P 1 . . . P n+m+1 ), such that no P i is a cut or a link acting on a bound channel, and no two processes P i and P j are acting on the same bound channel with dual actions. The prefix of cuts and mixes introduces n channels. Each application of cut requires an application of mix, so the prefix introduces n + m + 1 processes. Each application of Cont ! requires an application of mix, so there are at most m clients acting on the same bound channel. Therefore, at least one of the processes P i must be acting on a free channel, i.e., blocked on an external communication. Theorem 4.10 (Progress). If P G, then either P is in canonical form, or there exists a process Q such that P =⇒ Q.
Proof. We consider the maximum prefix of cuts and mixes of P such that P ≡ (νx 1 x 1 ) . . . (νx n x n )(P 1 . . . P n+m+1 ), and no P i is a cut. If any process P i is a link, we reduce by (↔). If any two processes P i and P j are acting dual endpoints x i and x i of the same channel, we rewrite by ≡ and reduce by the appropriate β-rule. Otherwise, P is in canonical form. Proof. Every reduction reduces a single cut to zero, one or two cuts. However, each of these cuts is smaller, measured in the size of the cut formula. Furthermore, each instance of the structural congruence preserves the size of the cut. Therefore, there cannot be an infinite =⇒-reduction sequence.
4.5. HCP ND and Non-deterministic Local Choice. In section 2, we discussed the non-deterministic local choice operator, which is used in several extensions of πDILL and CP [ALM16,Cai14,CP17]. This operator is admissible in HCP ND . We can derive the non-deterministic choice P + Q by constructing the following term: Each makes a choice: the first sends inl, and the second sends inr. • On the right-hand side, we have a server with both P and Q. This server has two channels on which a choice is offered, y and z . The choice on y selects between P and Q. The choice on z does not affect the outcome of the process at all. Instead, it is discarded. When these clients and the server are put together, the choices offered by the server will be non-deterministically lined up with the clients which make choices, and either P or Q will run.
While there is a certain amount of overhead involved in this encoding, it scales linearly in terms of the number of processes. The reverse-encoding the non-determinism present in HCP ND using non-deterministic local choice-scales exponentially, see, e.g., the examples in section 2.

Cuts with Leftovers
So far, our account of a non-determinism in client/server interactions only allows for interactions between equal numbers of clients and server interactions. A natural question is whether or not we can deal with the scenario in which there are more client than server interactions or vice versa, i.e., whether or not the following rules are derivable: Γ, ! n+m A ∆, ? n A ⊥ Γ, ∆, ! m A Γ, ! n A ∆, ? n+m A ⊥ Γ, ∆, ? m A ⊥ These rules are derivable using a link. For instance, we can derive the rule for the case in which there are more clients than servers as follows: Γ, ∆, w : ! m A

Relation to Manifest Sharing
In section 2, we mentioned related work which extends πDILL and CP with non-deterministic local choice [ALM16,Cai14,CP17], and contrasted these approaches with ours. In this section, we will contrast our work with the more recent work on manifest sharing [BP17].
Manifest sharing extends the session-typed language SILL with two connectives, ↑ S L A and ↓ S L A, which represent the places in a protocol where a shared resource is aquired and released, respectively. In the resulting language, SILL S , we can define a type for, e.g., shared queues (using the notation for types introduced in this paper): The type queue A types a shared channel which, after we aqcuire exclusive access, gives us the choice between enqueuing a value (A ⊥ ) and releasing the queue, or dequeuing a value if there is any (A ⊕ ⊥) and releasing the queue.
The language SILL S is much more expressive than HCP ND , as it has support for both shared channels and recursion. In fact, Balzer, Pfenning, and Toninho [BPT18] show that SILL S is expressive enough to embed the untyped asynchronous π-calculus. This expressiveness comes with a cost, as SILL S processes are not guaranteed to be deadlock free, though recent work addresses this issue [BTP19].
Despite the difference in expressiveness, there are some similarities between HCP ND and SILL S . In the former, shared channels represent (length-indexed) streams of interactions of the same type. In the latter, it is necessary for type preservation that shared channels are always released at the same type at which they were acquired, meaning that shared channels also represent (possibly infinite) streams of interactions of the same type. In fact, in HCP ND , the type for queues (with n interactions) can be written as ! n (A ⊥ (A ⊕ ⊥)).
One key difference between HCP ND and SILL S is that in SILL S a server must finish interacting with one client before interacting with another, whereas in HCP ND the server may interact with multiple clients simultaneously.

Discussion and Future Work
We presented HCP ND , an extension of HCP which permits non-deterministic communication without losing the strong connection to logic. We gave proofs for preservation, progress, and termination for the term reduction system of HCP ND . We showed that we can define non-deterministic local choice in HCP ND . Our formalism so far has only captured servers that provide for a fixed number of clients. More realistically, we would want to define servers that provide for arbitrary numbers of clients. This poses two problems: how would we define arbitrarily-interacting stateful processes, and how would we extend the typing discipline of HCP ND to account for them without losing its static guarantees.
One approach to defining server processes would be to combine HCP ND with structural recursion and corecursion, following the µCP extension of Lindley and Morris [LM16]. Their approach can express processes which produce streams of A channels. Such a process would expose a channel with the co-recursive type νX.A (1 ⊕ X). Given such a process, it is possible to produce a channel of type A A · · · A for any number of As, allowing us to satisfy the type ? n A for an arbitrary n.
We would also need to extend the typing discipline to capture arbitrary use of shared channels. One approach would be to introduce resource variables and quantification. Following this approach, in addition to having types ? n A and ! n A for concrete n, we would also have types ? x A and ! x A for resource variables x. These variables would be introduced by quantifiers ∀xA and ∃xA. Defining terms corresponding to ∀xA, and its relationship with structured recursion, presents an interesting area of further work.
Our account of HCP did not include the exponentials ?A and !A. The type !A denotes arbitrarily many independent instances of A, while the type ?A denotes a concrete (if unspecified) number of potentially-dependent instances of A. Existing interpretations of linear logic as session types have taken !A to denote A-servers, while ?A denotes A-clients. However, the analogy is imperfect: while we expect servers to provide arbitrarily many instances of their behaviour, we also expect those instances to be interdependent.
With quantification over resource variables, we can give precise accounts of both CP's exponentials and idealised servers and clients. CP exponentials could be embedded into this framework using the definitions !A ::= ∀n! n A and ?A ::= ∃n? n A. We would also have types that precisely matched our intuitions for server and client behavior: an A server is of type ∀n? n A, as it serves an unbounded number of requests with the requests being interdependent, while a collection of A clients is of type ∃n! n A, as we have a specific number of clients with each client being independent.