You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// Running the file: boogie 2pc-parallel.bpl /keepQuantifier
1
+
/// RUN: %parallel-boogie "%s" > "%t"
2
+
// RUN: %diff "%s.expect" "%t"
2
3
3
4
/*
4
5
2pc protocol:
5
-
A transaction needs to be executed at every replica. Every replica executes each step of the transaction but does not mark the transaction as complete until the coordinator runs the 2pc protocol to collectively decide whether to commit or abort the transaction. There are two phases in the protocol. In the first phase, the coordinator sends vote requests to all replicas. The replicas then send a reply (yes/no) to the coordinator. If all replies are yes, then the coordinator sends a commit decision to all replicas, otherwise it sends an abort decision. After receiving the decision from the coordinator, the transaction is marked as complete at each replica if it was a commit decision, or cancelled if it was an abort decision.
6
+
A transaction needs to be executed at every replica. Every replica executes each step of the transaction
7
+
but does not mark the transaction as complete until the coordinator runs the 2pc protocol to collectively
8
+
decide whether to commit or abort the transaction.
6
9
7
-
Model proved below:
8
-
Let's say there are multiple transactions at each replica that are marked as incomplete. It is now the coordinator's job to start the 2pc protocol for all of these transactions, and it does so concurrently. The goal is that we don't ever commit conflicting transactions because we can't control the order in which these transactions are applied at each replica. If conflicting transactions are committed, the data may no longer be same across all replicas.
10
+
There are two phases in the protocol. In the first phase, the coordinator sends vote requests to all replicas.
11
+
The replicas then send a reply (yes/no) to the coordinator. If all replies are yes, then the coordinator sends
12
+
a commit decision to all replicas, otherwise it sends an abort decision. After receiving the decision from the
13
+
coordinator, the transaction is marked as complete at each replica if it was a commit decision, or cancelled
14
+
if it was an abort decision.
9
15
10
-
Proof obligation: We have a ghost variable, committed_transactions, which keeps track of all transactions that have been committed so far. Before adding a transaction to this set, we assert that the transaction being added does not conflict with any previously committed transactions. If this assertion is shown to hold in all executions of the protocol, it should imply that we never commit conflicting transactions.
16
+
Model proved below:
17
+
Let's say there are multiple transactions at each replica that are marked as incomplete. Then multiple instances
18
+
of the coordinator may be running concurrently, each executing the 2pc protocol one transaction.
19
+
The goal is to ensure that we don't ever commit conflicting transactions; this condition is used to
20
+
abstractly model consistency of committed transactions.
21
+
We model the conflict relation between transactions using a 2-d array Conflict with axioms.
22
+
23
+
Proof obligation:
24
+
We have a ghost variable, committed_transactions, which keeps track of all transactions that have been committed so far.
25
+
Before adding a transaction to this set, we assert that the transaction being added does not conflict with any previously
26
+
committed transactions. If this assertion is shown to hold in all executions of the protocol, it should imply that
0 commit comments