Let no act be done at haphazard, nor otherwise
than according to the finished rules that govern its kind.

-- Marcus Aurelius Antonius

Chapter 7

Interaction Resolvers

For effective MRM, the effects of dependent concurrent interactions must be resolved in accordance with model requirements. Often, concurrent interactions may have dependent effects, for example, precluding or enhancing the effects of one another. Traditionally, the effects of concurrent interactions have been resolved by serialization, in which the interactions are ordered arbitrarily. However, serialization is often inappropriate because it isolates even those interactions whose effects must be applied concurrently. Other policies, such as combining or ignoring some or all interactions, do not isolate the interactions and may be more suitable for resolving dependent effects.

In Chapter 5, we presented Multiple Representation Entities (MREs). An Interaction Resolver (IR) is a component of an MRE that encodes policies for resolving the effects of concurrent interactions. Since specifying policies for all possible concurrent interactions can be complex, we present a taxonomy consisting of classes of interactions. We assume that designers of multi-models understand the semantics of interactions in their application well enough to classify interactions and formulate policies for resolving concurrent instances of classes of interactions. We present example policies for resolving classes of concurrent interactions. Our taxonomy enables a designer to choose appropriate policies for resolving concurrent interactions.

We describe interactions in §7.1. In §7.2, we discuss serialization and its alternatives. In §7.3, we motivate the need for policies other than serialization. In §7.4, we explore the problem of dependent concurrent interactions by means of an abstract application. We start with a simple system, add one dependency among its components, and study the effect of single, and subsequently, multiple interactions. We show how resolving the effects of concurrent interactions can be a complex design issue. In §7.5, we present a taxonomy to classify interactions based on intrinsic characteristics of interactions we encountered often in models. These characteristics lead naturally to policies for classes of interactions. We present example policies in §7.5. We describe the operation of an Interaction Resolver for an example MRE in §7.6.

7.1 Interactions

Entities communicate with one another or influence one another by means of interactions. As described in §3.2, an entity changes its own or another entity's behaviour by means of an interaction. Interactions are a fundamental part of any useful model because they connect the model to its environment. We regard a communication between any two entities as an interaction.

Interactions are ubiquitous -- they may be physical occurrences such as movement, a temperature increase or an explosion, or some sort of communication, such as a television broadcast, a dissertation submission or an order received from a superior. Examples of interactions are database transactions and operations [Eswa76]; processor interrupts; cache operations [Henn96]; reads and writes to shared memory in parallel processing systems; operations, events and actions in object-oriented and process modelling [Rum91] [Shlaer92] [Alhir98]; method invocations and function calls in object-oriented systems; messages in distributed processing systems and logical time systems [Lam78]; accesses to a blackboard [Erman80]; and exceptions in programming languages [Good75]. We include all of these interactions as well as changes an entity makes to its own state in our definition of interactions. Since we are concerned only with the effects of interactions, we consider specific techniques for implementing interactions to be irrelevant to our work.

A model that permits concurrent interactions requires a policy to resolve any dependencies among interactions and a mechanism to implement the policy. The traditional policy for resolving the effects of concurrent interactions is serialization.

7.2 Serialization

Serialization , the traditional policy for resolving the effects of concurrent interactions, involves applying those effects in sequential order, i.e., one after another. Serialization is a valid policy for resolving the effects of concurrent interactions in many domains, for example, databases. Consider the clients and server in the system in Figure 37. Transactions from a client to the server are interactions, indicated by arrows. If only one client interacts with the server at any given time, the server returns to a valid state trivially at the end of each interaction. If multiple clients interact with the server concurrently, ensuring that the server returns to a valid state is non-trivial.

Consider two interactions, I and J , independently issued to Server by Client1 and Client2 respectively. I and J each consists of operations, i.e., reads and writes, to variables a and b , denoted by R( a ) , R( b ) , W( a ) and W( b ) .

I : R( a )W( a )R( b )

J : R( b )W( b )W( a )
Server's state will be as if Client1 issued I to Server and when I completed, Client2 issued J to Server, or the other way around. Each client may not be aware of the other's presence since the system guarantees that its behaviour will be as if each client is the only client interacting with the server. This property of the system's behaviour, called isolation , is one of the ACID properties for database transactions [Haer83].

The actual order in which operations occur on Server is called a schedule . In a serial schedule , interactions are ordered one after another [Papa86]. A serial schedule ensures that clients interact with the server in isolation. Z 1 and Z 2 below are serial schedules for I and J . For clarity, we underline I 's operations in every schedule.

Z 1: R( a )W( a )R( b )R( b )W( b )W( a )

Z 2: R( b )W( b )W( a )R( a )W( a )R( b )

When I and J occur concurrently, the system must control how these interactions change Server. Since I and J are concurrent, their operations may interleave. A possible interleaved schedule for I and J is Z 3 below1. Z 3 is not a serial schedule because I and J are not ordered one after another.

Z 3: R( a )R( b )W( a )W( b )W( a )R( b )
A schedule is serializable if it is equivalent to a serial schedule for some definition of equivalence [Eswa76]. If Z 3 is equivalent to Z 1 or Z 2, Z 3 is a serializable schedule. Serialization is a policy that resolves concurrence by permitting only serializable schedules, i.e., by ordering or interleaving concurrent interactions appropriately. Concurrency control mechanisms, such as locking and time-stamp ordering are used to implement serialization.

Serialization has been chosen as a policy for resolving interactions in database systems because it satisfies clients' expectations of isolation yet permits concurrence [Papa86] [Bern87]. Isolation assumes that client interactions are not predicated on one another, i.e., they are independent of one another. Serialization isolates client interactions.

Some researchers have recognised that serialization can be too strict for many concurrent interactions. In advanced databases, serialization can reduce concurrence significantly. Accordingly, researchers have proposed alternative policies that relax or extend serialization yet maintain isolation. These policies utilize varying levels of semantic information about transactions in order to increase concurrence yet maintain database consistency. Semantic information has been utilized for scheduling long and short transactions [Brahma90]; extending and relaxing serialization [Barg91]; applying counter-transactions [Garcia83]; commuting interpreted operations on abstract data types [Weihl88]; aborting conflicting transactions [Barg91]; and recovering database states [Badri92]2. In general, serialization is considered correct but too strict, and alternative criteria relax or extend serialization in order to permit increased concurrence [Bern81] [Lynch83] [Munson96] [Korth88] [Thom98]. Moreover, isolation of transactions is considered a desirable property of database systems. Next, we discuss situations where isolation may be undesirable.

7.3 Abandoning Isolation

For some applications, the system must not isolate concurrent interactions since they may be dependent on one another. Serialization and alternative policies that relax or extend serialization isolate interactions. Therefore, they cannot be correct policies for resolving the effects of dependent concurrent interactions. Correct policies for these interactions must provide alternatives for isolating the interactions.

In the following examples, not isolating concurrent interactions, i.e., abandoning isolation, enables resolving their dependent effects correctly. Consider entities E1 and E2 that concurrently write to an attribute v with the interactions E1. W ( v , ...) and E2. W ( v , ...). The ellipses denote other interaction parameters. A sequential order for these interactions could be E1. W ( v , ...) followed by E2. W ( v , ...) or E2. W ( v , ...) followed by E1. W ( v , ...).

In a model of a billiards table, E1 and E2 could be ball entities and v could be the velocity of a ball. The two interactions could be E1. W ( v , δ v 1) and E2. W ( v , δ v 2), where δ v 1 is a change in v caused by E1 and δ v 2 is a change in v caused by E2. The correct policy to resolve these two interactions is to change v by the vector addition of δ v 1 and δ v 2. Serializing these interactions may be incorrect for a number of reasons as discussed below. Let ⊕ denote vector addition. v 1, v 2 and v 3 are three possible outcomes of adding δ v 1 and δ v 2 to the original value v 0 of the velocity v .

v 1 = ( v 0 ⊕ δ v 1) ⊕ δ v 2

v 2 = ( v 0 ⊕ δ v 2) ⊕ δ v 1

v 3 = v 0 ⊕ (δ v 1 ⊕ δ v 2)
The parentheses show the order in which the interactions take effect. v 1 and v 2 are computed by serializing the two interactions. In contrast, v 3 is computed by combining the two interactions before applying them to v . Mathematically, v 1 = v 2 = v 3. However, when executing a model, the results of these orderings can differ. For example, δ v 1 and δ v 2 may be so small that adding them to v 0 individually does not change the velocity v . However, δ v 1 and δ v 2 combined may be sufficient to change v . In such a case, v 1 = v 2 ≠ v 3. This thresholding anomaly may occur because of low precision in the representation of v . Another instance of thresholding could be that δ v 1 and δ v 2 can overcome the inertia of the entity with velocity v when combined, but not individually. As another example, suppose an entity E3 continuously plots the trajectory of the ball with velocity v . If v changes to v 1 or v 2, E3 will plot two changes, whereas if v changes to v 3, E3 will plot only one change. This example is an instance of temporal inconsistency. v 1 and v 2 are computed by serialization, whereas v 3 is computed by combination. For this model, combination is a more meaningful policy than serialization.

In a model of an autonomous agent, E1 could be a planner that pre-determines the steps to fulfill the agent's goal, E2 could be a perception-action (PA) system that observes and acts on the agent's environment, and v could be the visibility of an obstacle. The two interactions could be E1. W ( v , yes ) and E2. W ( v , no ), implying that the planner reports that the obstacle can be seen, whereas the PA system reports that the obstacle is hidden. Serializing these interactions causes the final value of v to be either yes or no arbitrarily. However, applying E2's interaction and ignoring E1's interaction may be a more reasonable, if pessimistic, policy to resolve these interactions. Alternatively, applying E1's interaction and ignoring E2's interaction may also be a reasonable, if optimistic, policy. Another reasonable policy may be to construct a belief system that assigns weights to the two interactions for a final value of v that is not bi-modal. Ignoring one or the other or weighting both interactions are policies that ensure meaningful behaviour when these interactions occur concurrently.

In a model of a chemical reaction, E1 could be an acid entity, E2 could be a catalyst entity, and v could be the volume of a by-product retrieved at the end of the reaction. The two interactions could be E1. W ( v , δ v 1) and E2. W ( v , δ v 2), where δ v 1 and δ v 2 are increases in the value of v when E1 and E2 are added. In chemical reactions, it is well-known that adding a catalyst can increase the rate of a reaction tremendously. As a result, the final change in v may be more than δ v 1 + δ v 2. Serializing the interactions does not capture the cooperative nature of these interactions. If the interactions are serialized, then either the model's representation must be augmented with an attribute that keeps track of whether the acid or catalyst has been added previously, or the model must capture the effects of adding a catalyst -- an increase in the surface area of the reaction -- at a finer level of detail. Alternatively, a special policy can be formulated to increase v appropriately if these concurrent interactions occur.

In the above examples, serializing concurrent interactions produces unintended effects. Isolating them from one another produces effects that are semantically incorrect. Since serialization and alternative policies that relax or extend serialization isolate interactions, none of them is a correct policy for resolving them. These interactions are dependent particularly because they are concurrent. Therefore, they require correctness criteria that abandon isolation. The correctness criteria for dependent concurrent interactions are application-specific. Next, with the help of an abstract application, we show how resolving the effects of dependent concurrent interactions by abandoning isolation makes the design of a system complex.

7.4 Switches -- A Simple System

We use a simple system of switches as an abstraction for models with concurrent interactions. We add constraints to the initial model, explaining the effort required to design the corresponding system. Next, we introduce dependent concurrent interactions and show how designing such a simple system becomes complex. We argue that the effects of dependent concurrent interactions must be resolved in an organised manner.

7.4.1 Unconstrained System

We begin with an unconstrained system. Consider the switches SA, S1 and S2 in Figure 38, each with two states: on (or 1) and off (or 0). A client may turn a switch on or off by an interaction (shown by an arrow). The state of the system is an ordered triplet, individual triplet elements being the states of SA, S1 and S2 respectively. In the state transition diagram in Figure 39, an oval is a possible state of the system, a solid arrow is a state transition caused by turning one switch on, and a dashed arrow is a state transition caused by turning one switch off. Transitions that cause the system to begin and end in the same state, for example, turning S1 off in the state [0 0 0], are not shown in Figure 39 to reduce clutter. Since the switches are independent, all possible states are present in the state diagram.

7.4.2 Constrained System

Most practical systems are constrained, i.e., there exist relationships among components of the system. Accordingly, we add a constraint to our switches:

If S1 and S2 are both on, then SA must be on.
This constraint can be re-written as (S1 = 1) ∧ (S2 = 1) ⇒ (SA = 1). As a result of this constraint, the switches are no longer independent. Figure 40 shows the new version of the switch system with the constraint depicted by arrows between the switches. The arrows merely depict a dependency between switches without outlining the nature of the dependency. The new set of valid states for the system is a subset of the old set of valid states. Figure 41 shows the new set of valid states. The crossed-out state does not exist in the new system.

Usually, constraints reduce the possible states of a system, i.e., some states in the unconstrained state transition diagram become unreachable. All transitions going into those states must be redirected elsewhere. The implications of the reduction in the set of valid states on the state transition diagram are shown in Figure 42. The oval corresponding to the state [0 1 1] has been removed since that state can never be reached. The outward arrows from that state have been removed since transitions from an unreachable state are meaningless (unless error recovery is desired). The arrows from the states [0 1 0] and [0 0 1] to [0 1 1] have been redirected to [1 1 1] in accordance with the constraint. However, the constraint does not indicate which state to transition from [1 1 1] if only SA is turned off. In theory, it is possible to transition to any of the seven states (or even a hitherto absent state) in such a situation. However, let us abide by the constraint as far as possible. The following are re-statements of the constraint.

(S1 = 1) ∧ (S2 = 1) ⇒ (SA = 1)

¬((S1 = 1) ∧ (S2 = 1)) ∨ (SA = 1) [Implication rule]

¬(S1 = 1) ∨ ¬(S2 = 1) ∨ (SA = 1) [DeMorgan's laws]

(S1 = 0) ∨ (S2 = 0) ∨ (SA = 1) [Switch states]

(SA = 1) ∨ (S1 = 0) ∨ (S2 = 0) [Re-arrangement]

¬(SA = 1) ⇒ (S1 = 0) ∨ (S2 = 0) [Implication rule]

(SA = 0) ⇒ (S1 = 0) ∨ (S2 = 0) [Switch states]

The last statement suggests what to do when SA is turned off while S1 and S2 are on. In order to keep transitions deterministic, we choose [0 0 1] arbitrarily as the state to transition from [1 1 1] in case SA is turned off, i.e., we turn S1 off.

State transition diagrams describe a model effectively when sequences of interactions occur. The effects of each interaction are captured by appropriate transitions. Since a state transition diagram can never put the system in an inconsistent state, every interaction can take effect without violating any constraint. Concurrent interactions, whether dependent or not, introduce problems with state transition diagrams, as we show next.

7.4.3 Dependent Concurrent Interactions

In order to demonstrate the effects of dependent concurrent interactions that cannot be serialized, we add new transitions. Consider the switch system from §7.4.2, with two concurrent interactions. Let the system be in the state [0 0 1], and let the two interactions be turning SA off and turning S1 on. If we serialize the interactions, turning SA off before turning S1 on results in the transitions [0 0 1] ➛ [0 0 1] ➛ [1 1 1], while turning S1 on before turning SA off results in the transitions [0 0 1] ➛ [1 1 1] ➛ [0 0 1]. The order in which the concurrent interactions are serialized determines the final state of the system. If the final state is immaterial as long as the system stays in a valid state, i.e., a state present in the state transition diagram, then serialization is correct but non-deterministic.

For deterministic behaviour, we add other state transitions that capture the effects of concurrent interactions. In Figure 43, we add a transition between [0 0 1] and [0 1 0]. The semantics of this transition could be, for example, that if SA is turned off and S1 is turned on concurrently in the state [0 0 1], then transition directly to state [0 1 0]. The fact that the interactions were concurrent caused this transition, and the final state of the transition is different from that if the two interactions were serialized.

7.4.4 Complexity

We desire systems to behave predictably no matter what interactions occur and how they occur. Accordingly, sequential interactions as well as concurrent interactions must have predictable results. A brute-force approach to resolving the effects of all possible concurrent interactions is exponential in complexity. Therefore, a means of encoding the dependencies among interactions is necessary.

For the switches system in §7.4.2, given the different kinds of interactions (six kinds, turning one of the switches on or off) and the number of different states (seven states), an exponential number of transitions are possible on concurrent interactions. In the worst case, the total number of transitions for the switch system is: (2number of interaction types − 1) × number of states = (26 − 1) × 7 = 441. This calculation assumes that concurrent interactions of the same kind can be serialized without changing their effect. In other words, concurrent multiple occurrences of the interaction to turn S1 off, for example, can be serialized. Nevertheless, even in our simple system, the number of transitions is large. Applications with more attributes, some non-Boolean, are likely to have many more states than our simple system. Consequently, the number of transitions can grow further. However, a number of mitigating factors can reduce the number of state transitions for a system. In the switch system, in order to reduce the number of possible transitions, we stipulated that multiple occurrences of the same interaction can be serialized. Another reasonable assumption is that a switch client will not send concurrent on and off interactions to its switches. This assumption reduces the number of transitions to the product of the number of states and the number of all possible concurrent interactions. The latter number is the sum of concurrent interactions occurring in all combinations of threes, twos and ones. Therefore, the total number of transitions is: . This number of transitions is an upper bound, because we assume that no set of concurrent interactions is serializable.

Applications must exhibit predictable behaviour when concurrent interactions occur. Serialization is an example of predictability. However, as we have seen in §7.3, serialization fails to resolve dependent concurrent interactions correctly, because it assumes that the interactions can be isolated. Another example of predictability is commutation, wherein the effects of commutable interactions are the same regardless of the order in which they are applied [Rosser82]. Since commutation also assumes that interactions can be isolated, it cannot resolve the effects of dependent concurrent interactions correctly. When dependent concurrent interactions occur, predictability can be achieved by encoding transitions in rigorous formulæ. In such an approach, the behaviour of the system when any set of concurrent interactions occur must be encoded a priori . Such an encoding is similar to specifying transitions in a state diagram for every possible set of concurrent interactions. As we have shown with our simple switches system, specifying all possible transitions can become a complex task.

We encode semantic information in interactions in our technique for predictable behaviour when dependent concurrent interactions occur. Our technique does not isolate interactions, and does not incur the complexity cost of specifying all transitions a priori .

7.5 A Taxonomy of Interactions

The effects of dependent concurrent interactions are application-specific. Specifying policies for resolving the effects of every set of interactions that may occur concurrently is a complex design task. However, specifying policies for resolving the effects of classes of interactions can be less complex. We discuss the properties of a good taxonomy of interactions. MRM designers may classify their interactions into any taxonomy that exhibits these properties. We present and justify one such taxonomy consisting of four classes of interactions. Our taxonomy is based on semantic characteristics of interactions we encountered often in models. Also, we present policies for resolving the effects of classes of concurrent interactions.

7.5.1 Properties of a Taxonomy of Interactions

A good taxonomy exhibits the following properties [Amo94] [How97]:

  • · mutually exclusive : classes do not overlap
  • · exhaustive : classes jointly cover all possible members
  • · unambiguous : classification is independent of the classifier
  • · repeatable : subsequent trials lead to same classification
  • · accepted : logical and intuitive classes
  • · useful : must lead to insights in particular field

MRM designers may choose any taxonomy of interactions as long as it exhibits the above properties. Traditional taxonomies of interactions, for example, reads versus writes or serializable versus non-serializable, may not exhibit these properties.

A straightforward classification of interactions is as reads or writes. This classification does not exhibit the property of usefulness because there is inadequate semantic information associated with the classes to resolve the effects of concurrent interactions. When writes occur concurrently, we cannot determine whether the co-occurrence was a happenstance of model execution or whether the writes are simultaneous events. In the former case, the writes are independent and indistinguishable from their sequential occurrence, while in the latter case, they may be dependent concurrent interactions and must be resolved accordingly.

We rejected classifying interactions as serializable versus non-serializable. Such a classification does not aid us in resolving non-serializable interactions. Moreover, serializable and non-serializable are relative classes. An interaction may be serializable with respect to another interaction, but non-serializable with respect to yet another. Therefore, the same interaction falls into both classes, implying that the chosen characteristic does not partition interactions into exclusive classes. In other words, this taxonomy does not exhibit the property of mutually exclusive classes.

In §7.5.2, we present a taxonomy of interactions. We identify four characteristics of interactions: request , response , certain and uncertain . By combining these characteristics, we identify four classes of interactions: Types 0, 1, 2 and 3. We were able to categorise interactions encountered in a number of models into these classes. Other characteristics of interactions may exist, and if identified, may introduce new classes of interactions, which may lead to new policies or refinements of our policies for resolving the effects of dependent concurrent interactions. We evaluate our taxonomy in §7.5.3.

7.5.2 Interaction Characteristics and Classes

We present four interaction characteristics and four classes of interactions that we have defined. We show how to classify interactions based on semantic characteristics. We identify four high-level semantic characteristics of interactions. These characteristics are application-independent, i.e., they are not specific to any application. The characteristics themselves are well-known; however, using them to classify interactions is novel. We identify four interaction classes from these characteristics of interactions.

7.5.2.1 Request and Response

Interactions may be requests or responses. Request interactions are concerned with an entity soliciting some behaviour from another entity. For example, when an entity queries the status of another entity, the former sends the latter a request interaction. Likewise, if an officer entity orders a soldier entity to fire, the former sends the latter a request interaction. Response interactions are concerned with an entity responding to an action generated as part of a model's behaviour, for example, a request. Responses may not be solicited explicitly, i.e., a response may not have a request associated with it. For example, a status update is a response interaction. Likewise, billiard ball entities may send one another response interactions generated because of a collision.

The distinction between request and response interactions is temporal. A request interaction is made regarding a future action. A response interaction is made regarding an action in the past. An interaction may be a request or a response, but not both3.

  • · Request : An interaction concerned with eliciting future behaviour from an entity.
  • · Response : An interaction concerned with the effects of an action in the past.
7.5.2.2 Certain and Uncertain

Interactions may or may not have the desired outcomes. Certain interactions have predictable outcomes. For example, when billiard ball entities collide, the outcome of their interaction is predictable because of physical laws. Likewise, when an acid entity is added to an alkali entity, the outcome of their interaction is predictable because of chemical laws. Uncertain interactions are those whose outcomes are not predictable. For example, a request for information may not always be satisfied, or satisfied truthfully. Likewise, a request to perform an action is not guaranteed to be satisfied.

Uncertainty in interactions may be defined along a continuum. For example, interactions may be distinguished on a scale with completely certain interactions at one end and increasingly uncertain interactions further away from that end. In such a case, the uncertainty of an interaction is a measure of its distance from the completely-certain end of the scale. Priorities may be viewed as an example of such a continuum. High-priority interactions always take effect preferentially over lower-priority interactions.

  • · Certain : An interaction whose outcome is predictable.
  • · Uncertain : An interaction whose outcome is unpredictable.
7.5.2.3 Combining Characteristics

Combining these characteristics yields four classes of interactions, which we name Types 0, 1, 2 and 3. We list the four classes below along with the conjunction of characteristics that defines each class. Also, we present an example interaction for each class. We depict the four classes in Figure 44.

  1. Type 0: Response ∧ Certain e.g., physical events
  2. Type 1: Response ∧ Uncertain e.g., updates
  3. Type 2: Request ∧ Certain e.g., reads
  4. Type 3: Request ∧ Uncertain e.g., orders

7.5.3 Evaluating the Taxonomy

Our taxonomy of interactions exhibits the properties of a good taxonomy discussed in §7.5.1. Our four interaction classes are mutually exclusive since no two of them possess the same conjunction of characteristics. Our taxonomy is exhaustive because the four interaction classes cover all possible combinations of the four interaction characteristics. We believe our taxonomy is unambiguous, repeatable, intuitive and useful. Our characteristics capture semantic information about interactions. An interaction can be classified into our four classes according to semantic information, (i.e., its expected effect on its sender and receiver), rather than non-semantic information (e.g., its syntax, the variables it reads or writes, its size, the time taken to transmit it). We assume model designers can identify the semantics of an interaction and determine its characteristics subsequently. Determining the class of an interaction from its characteristics is unambiguous and repeatable. Our classes are logical combinations of orthogonal interaction characteristics. The classes are intuitive because they are derived from well-known characteristics of interactions. All of the interactions we have encountered exhibit combinations of these characteristics. Next, we will demonstrate the usefulness of our taxonomy by showing how to resolve the effects of concurrent interactions.

7.5.4 Resolving Effects of Concurrent Interactions

We show how to resolve the effects of concurrent interactions based on the two sets of characteristics of interactions defined above: response versus request and certain versus uncertain. Independent interactions are those whose concurrent occurrence is indistinguishable from their sequential occurrence. If we can determine that concurrent interactions are independent, then they may be resolved by serialization. The following properties enable designers to determine whether concurrent interactions are independent.

Property 1: If the concurrent occurrence of interactions is indistinguishable from a sequential occurrence, the interactions are independent.
  • Argument: Assume the interactions are dependent. Therefore, they are related by either cause-effect or concurrence. If they are related by cause-effect, they cannot occur concurrently, since cause precedes effect. If they are related by concurrence, no sequential occurrence of the interactions can have the same effect as the concurrent occurrence. Since the interactions do not depend on one another by either cause-effect or concurrence, the initial assumption is false.
Property 2: If concurrent interactions affect disjoint sets of attributes, they are independent.
  • Argument: If concurrent interactions affect disjoint sets of attributes, their effects can be applied sequentially. Therefore, the concurrent occurrence of these interactions is indistinguishable from their sequential occurrence. By Property 1, they are independent.

If concurrent interactions affect disjoint sets of attributes, they are independent. If they do not, they interfere , but cannot be determined to be dependent yet. For interactions I 1 and I 2, if in terms of attributes, I 1 .affects ∗ ∩ I 2 .affects ∗ = ∅ then I 1 and I 2 are independent, else they interfere. Figure 45 shows a number of interactions that occur during a time-step. Each interaction is shown as a labeled node in a graph. An arc between two nodes indicates that the corresponding interactions affect non-disjoint sets of attributes. For example, the arc between nodes labeled I 2 and I 3 indicates that in terms of attributes, I 2 .affects ∗ ∩ I 3 .affects ∗ ≠ ∅. The nodes that transitively affect non-disjoint sets of attributes form isolated sub-graphs. The interactions corresponding to nodes in a sub-graph are independent of the interactions corresponding to nodes in another sub-graph. For example, each of I 2, I 3 and I 4 is independent of each of I 1, I 5, I 6, I 7 and I 8. The set of interactions corresponding to nodes in a sub-graph may be serialized with respect to the set of interactions corresponding to nodes in another sub-graph. Therefore, the sets of interactions { I 2, I 3, I 4}, { I 1} and { I 5, I 6, I 7, I 8} can be serialized with one another.

Property 3: Concurrent response and request interactions are independent.
  • Argument: Consider the interactions occurring during a time-step [ ti , ti +1] (see Figure 46). Response interactions received during this time-step refer to behaviour prior to time ti . Request interactions received during this time-step refer to behaviour after time ti +1. Let there be a time t ´ such that ti < t ´ < ti +1. Re-arrange the interactions such that all response interactions occur during the time-step [ ti , t ´], and all request interactions occur during the time-step [ t ´, ti +1]. This re-arrangement does not alter the semantics of any interaction because all of the response interactions continue to refer to behaviour prior to time ti and all of the request interactions continue to refer to behaviour after time ti +1. All of the response interactions can occur before all of the request interactions. Therefore, the concurrent occurrence of response and request interactions is indistinguishable from a sequential occurrence, namely, responses before requests. By Property 1, responses and requests are independent.

When two interactions interfere, but one of them has a certain outcome and the other has an uncertain outcome, then the former takes effect preferentially over the latter. Interactions with certain outcome must take effect, whereas interactions with uncertain outcome may be ignored, delayed or permitted to take partial effect. A partial effect for an interaction is its effect on some attributes but not others, or its fractional effect as opposed to its complete effect. If certainty or uncertainty of interaction outcomes is multi-modal (e.g., as in priorities), then interactions with higher degrees of certainty take effect preferentially over those with lower degrees of certainty.

When two interactions are resolved, either one of them takes effect preferentially over another, or they are combined. In the former case, the preferred interaction retains its type. In the latter case, the resultant interaction has the same type as the original interactions. If interactions of the same type interfere, they can be resolved by application-specific policies. For example, if two Type 0 interactions interfere, then they can be combined by a policy that reflects domain-specific laws. If they cannot be combined, then the model must be re-designed to avoid such paradoxical interactions. When concurrent interactions are combined, they may have cooperative or competitive effects. When the effect of combined interactions is "greater" than the combined effects of the individual interactions, the interactions are cooperative . When the effect of combined interactions is "less" than the combined effects of the individual interactions, the interactions are competitive . Determining "greater" and "less" is application-specific. If cooperative or competitive effects exist and the original interactions are serialized, new interactions can be added to account for these effects.

7.5.5 Policies for Resolving Effects of Interactions

In order to resolve the effects of dependent concurrent interactions, we present policies based on the characteristics of interactions, and our definitions of a model and interactions from §3.2. Designers of multi-models may choose from these policies to resolve the effects of dependent concurrent interactions. Recall that the effect of an interaction Int ( ti ) k on a state of the model is the change E ( Int ( ti ) k ), and applying the effect of that interaction on the representation Rep ( ti ) is equivalent to computing a function F ( Rep ( ti ), E ( Int ( ti ) k ))4. Applying the resolved effects of all of the interactions in one time-step results in the state of the model at the next time-step.

Serializing : If interactions are independent, their concurrent effects are indistinguishable from their sequential effects (Property 1). Independent interactions may be serialized in an arbitrary order, and permitted to take effect one after another. The combined effect of concurrent interactions I and J is E ( I J ). If I and J are independent, their serialized effects are E ( I ) ⋄ E ( J ). If the effects of I are applied before the effects of J , we denote the combined effects as E ( I ), E ( J ). The effect of I and J on the representation Rep ( ti ) can be applied by computing F ( Rep ( ti ), ( E ( I ), E ( J ))). Applying their serialized effects is equivalent to computing the function F recursively: F ( F ( Rep ( ti ), E ( I )), E ( J )).

Since no ordering is implied for the interactions within a time-step, the interactions may be ordered arbitrarily. If the representation at time ti +1, Rep ( ti +1), is the same no matter how the interactions are ordered, then the interactions are commutative, i.e., the order in which their effects are applied does not change their combined effects.

Response interactions are independent of request interactions because they are temporally disjoint. Accordingly, if the first k interactions in the set Int ( ti ) are responses and all of the remaining interactions are requests, then they can be resolved as below:

Ignoring : The effects of some sets of dependent concurrent interactions can be resolved meaningfully by ignoring some of them. For example, if uncertain interactions interfere with certain interactions, the former may be ignored. If the interactions in Int ( ti ) are sorted such that the first k interactions take effect while the rest are ignored, then:

Delaying : The effects of some sets of dependent concurrent interactions can be resolved meaningfully by delaying some of them. For example, uncertain request interactions may be delayed if the receiver cannot resolve their effects within the current time-step. If the interactions in Int ( ti ) are sorted such that the first k interactions take effect during the time-step [ ti , ti +1], while the rest are delayed to a future time-step [ tj , tj +1], then:

Combining Cooperatively or Competitively : Resolving the effects of some dependent concurrent interactions may result in enhancing or diminishing the effects of the individual interactions. If the effects are enhanced, the interactions have cooperative effects, whereas if the effects are diminished, the interactions have competitive effects. The effects of such interactions may be resolved by applying the effects of the individual interactions as well as compensatory interactions that account for the cooperative or competitive effects. Let two interactions in Int ( ti ) have cooperative or competitive effects. Let the compensatory interaction be denoted by Int ( ti )0, 1. The effect of Int ( ti ) is:

7.6 Constructing an Interaction Resolver

An Interaction Resolver (IR) resolves the effects of concurrent interactions received by an MRE. This process involves determining the class of each interaction, determining if interactions of the same type interfere, propagating the effects of interactions and resolving the effects on each attribute using application-specific policies. The IR may be a single component or a number of components distributed over the attributes in an ADG for the MRE. Conceptually, the distinction is unimportant; during implementation, the distributed view may be more efficient.

7.6.1 Operation of an IR

The operation of an IR involves implementing policies for resolving the effects of classes or types of dependent concurrent interactions.

At design time, a designer encodes the type or characteristics of each interaction. Encoding the type or characteristics enables an IR to classify interactions. Also, at design time, the designer encodes policies in the IR for resolving types of concurrent interactions. For example, if Type 1 and Type 0 interactions interfere, the former can be discarded. The designer must specify a policy for discarding the Type 1 interactions. Examples of such a policy are ignoring or delaying the interactions (see §7.5.5). If choice of policies varies during run-time, the designer must specify conditions under which a policy is chosen.

At run-time, an MRE sends and receives concurrent interactions during a time-step. The IR groups the interactions according to their type. Initially, the IR determines the effect of each interaction on all attributes assuming that the interaction occurs in isolation. The semantics of an interaction I determine how I.affects is constructed. The ADG and mapping functions determine how I.affects + is constructed. The effects are not applied immediately to the attributes since interfering effects have not been resolved yet. For each attribute, a list of potential changes caused by the concurrent interactions is constructed. Not all of these changes will be applied to the attribute. The IR resolves changes caused by interactions by considering the type of interactions and policies that eliminate conflicts among types of interactions. The IR considers the changes to each attribute in the order: Type 0, 1, 2 and 3 to preserve dependencies among the corresponding interactions.

The first group of interactions the IR considers is the Type 0 group. Type 0 interactions are communications about events that have already occurred. Their effects on the receiver are certain and can be computed in accordance with model requirements. If two or more Type 0 interactions interfere, then their effects can be combined. The IR permits each Type 0 interaction to take effect.

The next group of interactions the IR considers is the Type 1 group. Type 1 interactions are communications about events that may have occurred. Their effects on the receiver are uncertain. Type 1 interactions may interfere with one another as well as with Type 0 interactions. Let the tuple < a , δ a > denote an attribute and a change to it caused by a Type 1 interaction I . The IR determines whether δ a conflicts semantically with any Type 0 change. If it does, the IR marks < a , δ a > as discarded. If I is discarded entirely, the IR marks all tuples in I.affects ∗ as discarded. Thus, the interaction can take effect entirely or not at all. If I may have partial effects, then not all of the tuples in affects ∗ need be discarded. When the only Type 1 changes remaining are the ones that do not conflict with the Type 0 changes, the Type 1 changes are checked for conflicts among themselves. If there are conflicts, the IR selects a set of non-conflicting interactions among them based on appropriate policies.

Next, the IR considers interactions in the Type 2 group. Type 2 interactions are communications about events that will occur. Type 2 interactions may be reads of attribute values, in which case, they do not interfere with any other interactions and can take effect immediately. Some Type 2 interactions may not be just reads. For example, a particular Type 2 interaction may read an attribute and have the side-effect of writing to another attribute, such as a counter. As another example, a Type 2 interaction may be a communication about an event that is certain to happen, such as a collision between two entities within the current time-step. Although Type 2 interactions occur during the same time-step as Type 0 or Type 1 interactions, Type 2 interactions are serialized with respect to Type 0 and Type 1 interactions. If Type 2 interactions interfere with one another, they can be combined in the same manner as Type 0 interactions.

Finally, the IR considers interactions in the Type 3 group. Type 3 interactions are communications about events that may occur. Type 3 interactions may be requests, orders or commands that may not be satisfied. Type 3 can be serialized with respect to Type 0 and Type 1 interactions. Type 3 interactions are resolved with respect to Type 2 interactions in the same way as Type 1 interactions are resolved with respect to Type 0 interactions. Although the actual policies may differ, Type 1 and Type 3 interactions may be discarded in favour of interactions in the other two classes.

In Figure 47, we present an algorithm for an IR. The IR determines the effects of all concurrent interactions by referring to policies encoded by the designer. The fourth step in the algorithm refers to an algorithm similar to the one we presented in Figure 34 in which we applied the effects of interactions as soon as they were determined. In Figure 47, we apply the effects of interactions after all dependent interactions have been resolved.

7.6.2 An Example IR

We demonstrate the operation of an IR with the example MRE described in Chapter 6. Let the interactions in Table 9 be received concurrently by the MRE. The class of each interaction is listed in the column headed "Type". The sets affects and affects + have been shown in the last two columns. The semantics of the various interactions are as below:

  • · Move_Tank1: Tank1 moves in the current time-step.
  • · Move_Platoon: Platoon moves in the current time-step.
  • · Collide_Tank2: Tank2 suffers a collision in the current time-step.
  • · See_Tank1: An entity requests the values of some attributes of Tank1.
  • · Refill_Tank1: Tank1 is refuelled and repaired in the current time-step.
  • · Fire_Platoon: Platoon fires in the current time-step.
  • · Detonation: Platoon is in the path of a detonation in the current time-step.
  • Example Concurrent Interactions

    Interaction

    Type

    affects

    affects +

    Move_Tank1

    3

    Pos1

    Pos, Pos2, Form, App, Dam1, Dam2

    Move_Platoon

    3

    Pos

    Pos1, Pos2, Form, App, Dam1, Dam2

    Collide_Tank2

    0

    Vel2, Pos2

    Vel, Pos, Form, Vel1, Pos1, App, Dam1, Dam2

    See_Tank1

    2

    Refill_Tank1

    1

    Ammo1, Fuel1

    Fire, Ammo2

    Fire_Platoon

    3

    Fire

    Ammo1, Ammo2

    Detonation

    0

    App

    Dam1, Dam2

At design-time, a designer encodes the type of each interaction and policies for resolving types of concurrent interactions. The encoded types of the interactions appear in Table 9. Suppose the encoded policies are:

  1. L1: If Move_Platoon occurs concurrently with Move_Tank1 or Move_Tank2, then Move_Platoon takes effect preferentially.
  2. L2: If Detonation occurs concurrently with Collide_Tank1 or Collide_Tank2, the interactions have competitive effects.
  3. L3: If a change caused by an interaction is discarded, the interaction is discarded entirely, i.e., no partial effects of interactions are permitted.

At run-time, the IR resolves the effects of concurrent instances of the interactions in Table 9. Accordingly, the IR constructs a table similar to Table 10 for these interactions. The first column lists the name of the attribute. The second column lists the interactions affecting that attribute. The rows for which the second column reads "competitive" refer to a compensatory interaction added by the IR to enforce L2. The third column lists the type of each interaction. The fourth column lists changes to that attribute caused by a corresponding interaction. These changes are computed by permitting each interaction to take effect in isolation initially, determining the changes to attributes caused directly by the interaction, traversing the ADG and invoking the appropriate mapping functions to determine the changes to attributes caused indirectly by the interaction. In Chapter 6 we explained a similar procedure in detail for singly-occurring interactions.

Effects of Concurrent Interactions

Attribute

Interaction

Type

Change

Pos

Collide_Tank2

0

δP1

Move_Platoon

3

δP2

Move_Tank1

3

δP3

Pos1

Collide_Tank2

0

δP11

Move_Tank1

3

δP12

Move_Platoon

3

δP13

Pos2

Collide_Tank2

0

δP21

Move_Tank1

3

δP22

Move_Platoon

3

δP23

Vel

Collide_Tank2

0

δV1

Vel1

Collide_Tank2

0

δV11

Vel2

Collide_Tank2

0

δV21

Form

Collide_Tank2

0

δF1

Move_Platoon

3

δF2

Move_Tank1

3

δF3

App

Detonation

0

δA1

Collide_Tank2

0

δA2

competitive

0

δA3

Move_Platoon

3

δA4

Move_Tank1

3

δA5

Dam1

Detonation

0

δD11

Collide_Tank2

0

δD12

competitive

0

δD13

Move_Platoon

3

δD14

Move_Tank1

3

δD15

Dam2

Detonation

0

δD21

Collide_Tank2

0

δD22

competitive

0

δD23

Move_Platoon

3

δD24

Move_Tank1

3

δD25

Fire

Refill_Tank1

1

δR1

Fire_Platoon

3

δR2

Ammo1

Refill_Tank1

1

δA11

Fire_Platoon

3

δA12

Ammo2

Refill_Tank1

1

δA21

Fire_Platoon

3

δA22

Fuel1

Refill_Tank1

1

δU1

For each attribute, the IR resolves the changes caused by different interactions. The order in which attributes are chosen is unimportant. Interactions that do not change any attributes, i.e., whose affects ∗ = ∅, cannot cause any inconsistencies among the multiple representations. If such interactions are reads, the values returned may be the values of attributes before any changes are applied or after all changes have been applied. We show how to resolve concurrent changes for all of the attributes in our example.

  • · Pos: The concurrent changes are δP1, δP2 and δP3. δP1 is a Type 0 change and can be applied. δP2 and δP3 are Type 3 changes that conflict with each other, but are independent of δP1 which is a Type 0 change. By L1, δP2 is applied and δP3 is discarded. By L3, Move_Tank1 is discarded entirely, and the IR discards δP12, δP22, δF3, δA5, δD15 and δD25 -- the changes caused by this interaction to each attribute in Move_Tank1. affects ∗.
  • · Pos1: The concurrent changes remaining are δP11 and δP13. δP11 can be applied since it is a Type 0 change. In practice, we expect δP11 = 0 since a collision involving Tank2 will not affect Tank1. However, this is an artifact of the particular interactions we have chosen, hence it does not factor into the decision about which changes are applied. δP13 does not conflict with δP11 because of the types of these changes. The IR has discarded δP12 already.
  • · Pos2: The concurrent changes remaining are δP21 and δP23. δP21 can be applied since it is a Type 0 change. δP23 can be applied since it does not conflict with δP21 because of the types of these changes. δP22 has been discarded already.
  • · Vel: δV1 can be applied.
  • · Vel1: δV11 can be applied.
  • · Vel2: δV21 can be applied.
  • · Form: Both the remaining changes, δF1 and δF3, can be applied.
  • · App: δA1, δA2 and δA3 can be applied because they are Type 0. δA3 is a competitive change caused by the compensatory interaction added by the IR. Since δA3 is a compensation for two Type 0 interactions, it is also Type 0. After the Type 0 interactions are applied, the Type 3 changes are applied. Since δA5 has been discarded, only δA4 can be applied.
  • · Dam1: δD11, δD12 and δD13 can be applied because they are Type 0. δD14 is applied subsequently.
  • · Dam2: δD21, δD22 and δD23 can be applied because they are Type 0. δD24 is applied subsequently.
  • · Fire: The potential changes are δR1 and δR2. δR1 is a Type 1 change. Since there are no previously-applied changes, it can be applied. δR2 can be applied as well since Type 3 interactions do not conflict with Type 1 interactions.
  • · Ammo1: δA11 and δA12 can be applied.
  • · Ammo2: δA21 and δA22 can be applied.
  • · Fuel: δU1 can be applied.

When all of these changes have been applied, the MRE will be consistent. The IR enforces policies L1, L2 and L3 specified for this application. Since the specified policies for dependent concurrent interactions do not isolate the interactions, the effects of these interactions can be resolved in a manner meaningful to the application. Consequently, the MRE interacts at multiple representation levels concurrently and consistently.

7.7 Chapter Summary

Concurrent interactions may have effects that are dependent on one another. Resolving the effects of such interactions by serializing them is incorrect since serialization isolates the interactions. Dependent concurrent interactions can be resolved efficiently by classifying them and formulating policies for resolving classes of interactions. We present four characteristics of interactions -- request, response, certain and uncertain -- and four classes of interactions based on combinations of these characteristics -- Types 0, 1, 2 and 3. The classes distinguish semantic types of interactions encountered in models. Based on these classes of interactions, we presented policies for resolving the effects of their concurrent occurrence. We showed how to construct an Interaction Resolver (IR) for an MRE. An IR resolves the effects of types of interactions at run-time. By designing a Consistency Enforcer and an Interaction Resolver, a designer can ensure that an MRE interacts at multiple representation levels concurrently. Next, we present a process for applying our framework, UNIFY , to jointly-executing models.


1. We assume that the individual operations, i.e., reads and writes, are indivisible and atomic.

2. A detailed analysis of each correctness criterion and policy presented for databases would take up too much time and space. Over 100,000 pages of new material are published every year in databases alone [Date95].

3. Interactions cannot refer to actions in the present. One explanation is that the sender may not know when an interaction may be received. Therefore, the sender cannot base the effects of an interaction on actions that will happen precisely during the time-step that a receiver receives the interaction. Another explanation is that we can think of a time-step as having two phases: a send-receive phase during which interactions are sent and received and a perform phase during which the effects of interactions are applied. If the perform phase occurs first, effects in that phase are in the past of the send-receive phase, whereas if the perform phase occurs second, effects in that phase are in the future of the send-receive phase.

4. We will use sets and individual elements of a set of interactions interchangeably as parameters for F and E in order to avoid digressing into more formalisms. Distinguishing the "overloaded" uses of F and E will be clear from context.