El derecho a la identidad de las personas de ascendencia haitiana

The following directed graphs, D, D2, and G, are used throughout the proofs in Section 3.4.

The D graph captures where read events get their values. The vertices in the graph are events, and each edge in the graph connects a read for some variable to the last commit that wrote the same variable. We also include two extra transactions in a D graph, one at the beginning of the history to initialize all variables and another at the end of the history that reads all variables.

The D2graph captures which events conflict with one another and, of these conflicting events,

which events must come before other events. The vertices of a D2 graph are events (read and

• Read

Pre: T ∈ active(h) ∧ valid (T, h)

Post: h0 = h · hT, x.read (value(x, h))i

• Commit.1

Pre: T ∈ active(h) ∧ valid (T, h) ∧ (∀Tx. Tx ∈ active(h) ∧ valid (Tx, h) ∧ (writes(T, h) ∩

reads(Tx, h) 6= ∅) → allowAbort (T, Tx, h)) Post:

(1) I = ∅

(2) T ∈ active(h) ∧ valid (T, h) ∧ (∀Tx. Tx ∈ active(h) ∧ valid (Tx, h) ∧ (writes(T, h) ∩

reads(Tx, h) 6= ∅) → I = I ∪ Tx))

(3) h0= h · hT commit , I, W i

• Commit.2

Pre: T ∈ active(h) ∧ valid (T, h) ∧ (∃Tx.Tx ∈ active(h) ∧ valid (Tx, h) ∧ (writes(T, h) ∩

reads(Tx, h) 6= ∅) ∧ ¬allowAbort (T, Tx, h))

Post: h0 = h · hT abort i

• Abort

Pre: T ∈ active(h)

Post: h0 = h · hT abort i

The G graph lifts the D2 graph from events to transactions. So all the vertices associated

with a transaction in D2 are represented by a single vertex in G. With that compression, all of the

edges in D2 between events from two transactions are collapsed to a single edge between those two

transactions in G. To recap, the G graph captures which transactions conflict with one another and which transactions must come before others.

3.3.1 Formal Definitions of the Graphs

An augmented history of h, denoted by ˆh, is defined as the history h including two additional

transactions, T0 and T∞. T0 initializes (writes to) all of the variables in h to some arbitrary value

and executes serially before any other transaction in h begins. T∞ reads all variables in h and

executes serially after all other transactions in h have completed.

With augmented histories defined, we can now define the directed graph D(h). D(h)’s vertices

are the events of the transactions in the augmented history, ˆh. The edges of D(h) are specified as

follows.

• If e_i and ej are events in different transactions, where ei is a commit event and ej is a read

event and ei writes to variable x (i.e., x ∈ ei’s dom(W )) while ej reads x, and ei is the last

step in ˆh before ej that writes to x, then edge (ei, ej) is in D(h).

We now define D2(h) as a directed graph whose vertices are the events of h and whose edges

specify the happens before ordering between conflicting event pairs from different transactions in h. Specifically, there is an edge (e1, e2) ∈ D2(h) if conflicts−with(e1, e2, h).

Finally, we define a lazy conflict graph G(h) as a directed graph whose vertices are transactions and whose edges specify the happens before ordering between conflicting transactions. There is an edge (T1, T2) ∈ G(h) if conflicts−with(T1, T2, h).

A lazy conflict graph is named as such because it captures the happens before ordering that exists between transactions in a lazy write acquisition (also known as deferred update) TM that uses an atomic commit operation. In such systems, because writes events always occur during

the commit phase, and because the commit phase is atomic (no other transactions can commit at the same time), the edges formed by the happens before ordering for write operations between transactions are always one directional. In other words, when two transactions have write-after- write conflicts with each other, one transaction is clearly defined as happening before the other. This same behavior is not true in eager write acquisition (also known as direct update) TMs.

Like Papadimitriou’s conflict graph [68], a history is conflict serializable iff its lazy conflict graph is acyclic (proof forthcoming).

3.3.2 View Serializability

In addition to conflict serializability, there is another form of serializability called view seri- alizability. Before we provide the formal definition of view serializability, we first give the intuition behind it. In essence, view serialization is a form of serialization that ensures transactions see a consistent view of the world. For example, using view serializability, an active transaction’s oper- ations are required to be isolated from other active transactions. Thus a transaction’s view of the world is always consistent.

Both view serializability and conflict serializability ensure transactions see a consistent view of the world. However, it is more computationally expensive to verify if a history is view serial- izable than if it is conflict serializable. Specifically, verifying if a history is view serializable has a complexity of NP, while verifying if a history is conflict serializable has a complexity of P [68]. Although view serializability is more computationally expensive than conflict serializability, view serializability is more relaxed than conflict serializability and therefore accepts a wider range of histories. To speak more formally, in the universe of all histories those histories accepted by a sys- tem that accepts all view serializable histories is a superset of those histories accepted by a system that accepts all conflict serializable histories.

In the following section, D graphs are used to prove that if two histories are view equivalent then their respective D graphs are also equivalent. D graphs are also used, indirectly, to prove that

h1 and h2 are said to be view equivalent when the following conditions are satisfied:

• If the transaction Ti in h1 reads an initial value (from T0) for a variable x, so does the

transaction Ti in h2.

• If the transaction Ti in h1 reads the value written by transaction Tj in h1 for a variable x,

so does the transaction Ti in h2.

• If the transaction T_i in h1 is the final transaction to write the value for a variable x, so is

the transaction Ti in h2.

A history h is view serializable if it is view equivalent to some serial history.