DILLA UNIVERSITY

COLLEGE OF ENGINEERING & TECHNOLOGY

SCHOOL OF COMPUTING AND INFORMATICS

M. Sc in Computer Science & Networking

Year – 1, Semester – II

Course Title: (Distributed System)

Course Number: CN-6123
Distributed System Assignment #2

Assignment Title “Causal and Entry Consistency”

Submitted By Chimdesa Gedefa

Id no PGCSaN 004/20

Submitted To Dr. M. Prasad

Submission date: June 24/2021G.C

Causal and Entry Consistency

1. Causal Consistency

Causal consistency is a weakening model of sequential consistency by categorizing events into

those causally related and those that are not.

It defines that only write operations that are causally related, need to be seen in the same order
by all processes.

This model relaxes sequential consistency on concurrent writes by a processor and on writes that
are not causally related. Two writes can become causally related if one write to a variable is
dependent on a previous write to any variable if the processor doing the second write has just
read the first write. The two writes could have been done by the same processor or by different
processors.

As in sequential consistency, reads do not need to reflect changes instantaneously; however, they
need to reflect all changes to a variable sequentially.

W1 is not causally related to W2. R1 would be sequentially inconsistent but is causally consistent.

W(x)1 and W(x)2 are causally related due to the read made by P2 to x before W(x)2

1
Consistency model defines what values reads are admissible by the DFS/DSM

Causal consistency captures the notion that causally-related operations should appear in the
same order on all processes—though processes may disagree about the order of causally
independent operations.

For example, consider a chat between three people, where Attiya asks “shall we have lunch?”,
and Barbarella & Cyrus respond with “yes”, and “no”, respectively. Causal consistency allows
Attiya to observe “lunch?”, “yes”, “no”; and Barbarella to observe “lunch?”, “no”, “yes”.
However, no participant ever observes “yes” or “no” prior to the question “lunch?”.
Convergent causal systems require that the values of objects in the system converge to identical
values, once the same operations are visible. In such a system, users could transiently observe
“lunch”, “yes”; and “lunch”, “no” but everyone would eventually agree on (to pick an arbitrary
order) “lunch”, “yes”, “no”.

Causal consistency is sticky available: even in the presence of network partitions, every client
connected to a non-faulty node can make progress. However, clients must stick to the same
server.

A slightly stronger version of causal consistency, Real-Time Causal, is proven to be the strongest
consistency model in an always-available, one-way convergent system. Most “causally
consistent” systems actually provide these stronger properties, such as RTC or causal plus. When
a total orders is required, and you’re willing to sacrifice availability (and latency),
consider sequential consistency. If you need total availability, you’ll have to give up causal (and
read-your-writes), but can still obtain writes follow reads, monotonic reads, and monotonic
writes.

2
A more concise definition, from Viotti and Vukolić, decomposes causal consistency into three
properties:
1. Causal Visibility (the happens-before relation is a subset of the visibility order)

2. Causal Arbitration (the happens-before relation is a subset of the arbitration order: a total
order which defines how conflicts are resolved)

3. RVal (return values should be consistent with the definition of the data type; e.g. reads
should reflect recent writes)

Causal consistency is one of the consistency criteria that can be used on distributed databases as
consistency criteria.

Distributed database provides causal consistency if read and write operations that are causally
related are seen by every node of the distributed system in the same order.

Concurrent writes may be seen in different order in different nodes. Causal consistency is
weaker than sequential consistency but stronger than eventual consistency When a transaction
performs a read operation followed later by a write operation, even on different object, the first
read is said to be causally ordered before the write. This is because the value created by the write
may have been dependent upon the result of the read operation. Similarly, a read operation is
causally ordered after the earlier write on the same object that stored the data retrieved by the
read. Also, even two write operations performed by the same node are defined to be causally
ordered, in the order they were performed. Intuitively, after writing value v into object x, a node
knows that a read of x would give v, so a later write could be said to be (potentially) causally
related to the earlier one. Finally, causal order is transitive: that is, if operation A is (causally)
ordered before B, and B is ordered before C, A is ordered before C. Operations that are not
causally related, even though other operations are said to be concurrent.

3
Consider following example:

This execution is causally consistent because read operations r3[x] is causally dependent on
write w2[x] and read operation r4[x] is causally dependent on write w1[x].

Note that concurrent write operations may be seen on different order on different transactions or
nodes.

Implementing Causal Consistency

Causal consistency can be reached by using Lamport clocks or version vectors. The causal
consistency model is implemented by using multi-part timestamps, which are assigned to each
object. These timestamps are stored on a vector that contains the version number of the object at
each replica. This vector must be included (in the form of dependencies) in all update and query
requests so that operations respect the causal ordering: an operation A can only be processed at a
given node if all operations, on which the operation A causally depends, have already been
applied at that node.

Each element in the vector clock corresponds to one host and the value of element indicates the
number of messages sent from that host. The vector clock information is used to order or delay
the delivery of messages if necessary, thus maintaining the required consistency. However, for
maintaining the consistency of data items, we need information about writes on each data item,
and maintaining a clock per data item can help. Therefore, instead of a vector clock of size N
(number of hosts), we maintain a vector of size M (number of objects). The value of v[i] in the
vector v contains the number of writes on data item i.

4
Each host maintains a vector of size M. whenever it updates the value of an item, it increments
the corresponding element and sends the vector along with the message of data item and new
value to every site, which has a copy of the replica. When a host receives an update message, it
delays the delivery of a message till each element in its vector is greater than or equal to the one
that is piggybacked. After that, the updates to the data items are applied. In this case, the
message overhead is O(M) and thus is independent of the number of hosts in the system.

If each message is an update message, it carries the new value of the data item rather than
instructions. This would not have been possible if vector clocks had been used. In that case, the
delivery of a massage would have been delayed even for previous messages that are causally
overwritten.

Applications and Databases using Causal Consistency

COPS and Eiger

COPS system (Clusters of Order-Preserving Servers) introduces the causal plus consistency and
is designed to support complex online applications that are hosted in a small number of large-
scale data-centers, each of which is composed of front-end servers (clients of COPS) and back-
end key-value data stores. Eiger has a similar design but a different implementation.

COPS and Eiger support causality through a client library. Both systems replicate writes to
geographically distributed data centers and enforce observed ordering. The observed ordering is
enforced by delaying the write operations until all causally previous operations have been
already applied at that data center.

5
COPS executes all read and write operations in the local data center in a linear fashion, and then
replicates data across data centers in a causal plus consistent order in the background.

Figure 1: Architecture of COPS and Eiger

Similarly, the Eiger system provides the linearizability inside each data center and the causally-
consistent data store based on a column-family data model to achieve better performance in a
geo-distributed setting. All operations from clients are served from the local data center using a
client library. Each replica stores full replica of the database and operations are handled locally.
After an operation is executed locally, the operation is asynchronously pushed to remote data
centers, but committed only after all causally dependent operations have been previously
committed.

Bolts-on

Bailis et.al. in propose a client-side middle-ware software called Bolt-on. This middle-ware
guarantees only application-defined dependencies as an alternative to the causal consistency.

6
 Figure 2 describes the architecture of the Bolt-on middle-ware

The Bolt-on architecture assumes that the underlying data store handles most aspects of data
management, including replication, availability, and convergence. In the architecture, the
underlying data stores locally uses the eventual consistency and allows a large space of read and
write histories; the middle-ware handles causal dependencies, and consists of a set of rules,
which limit the possible histories to the histories that obey the desired consistency model.

Application: MMORPG

In Massively Multi-player Online Role-Playing Games (MMORPG), players can cooperate with
others in a virtual game world, and both players and different game words are naturally
distributed. These systems manage large amounts of data, and the biggest problem is how to
support data consistency. According to the CAP theorem, we have to sacrifice one of two
properties: consistency or availability. If an online game does not guarantee the availability,
players’ requests may fail. If data is inconsistent, players may get data not conforming to the
game logic, and this data can affect their operations. Therefore, it is important for the MMORPG
environment to find a balance between the data consistency and the system availability. For this
reason, we must analyze the data consistency requirements of MMORPG so as to find the
balance.

7
Diao has studied different consistency models for MMORPG and found that there indeed are part
of data, where the causal consistency is an appealing choice: Game data. The game data contains
e.g. the world appearance, the meta-data of non-player characters (the characters are created by
game developers and controlled only by the game logic), the system configuration and game
rules. This data is used by players and the game engine in the entire game, but can be only
modified by the game developers. Consistency requirements for the game data are not so strict
compared e.g. to the account data. Because e.g. a changes of non-player character name or of the
duration of bird animation may not be noticed by players.

Furthermore, some change of the game data needs to be delivered to all online players
synchronously, e.g. a change of the word appearance, the weapon power, non-player characters,
game rules and scripts. If there is inconsistency on these areas, it will cause errors on game
display and logic errors on players. Therefore, some data needs to be stored on the server side
and some on the client side. The game data on the client side could only synchronize with servers
when a player logs in to or starts a game. For this reason, the causal consistency is required.

This could mean that when a player A uses the browser to connect with the game server, the
game server will check the current local data and update the game data of the client side in the
form of data packets. After updating, all future local accesses will return the updated value.
Player B, who has not communicated with the game server, will still retain the outdated game
data.

Game servers maintain the primary version of game data, and transfer it to client sides.
Additionally, players on different game words cannot discuss to each other. Thus, the only need
is to make sure that the game data is consistent in one game word in a time so that all players on
that game word are handled equally. This requires using the strong consistency locally in the
game word and the causal consistency among different game words. When the game data is
modified by developers, the update value should be delivered synchronously to all replicates on
that game word, and asynchronously to other game words.

8
While the possibility of using the causal consistency on MMORPG has been identified on
research to the authors’ knowledge there is no actual publication or other information that the
causal consistency is actually used on MMORPG games (e.g. Lord of the Rings Online).

Application: Facebook

Facebook is an online Social networking service. After registering to use the site, users can
create a user profile, add other users as friends, exchange messages, post status updates and
photos, share videos and receive notifications when others update their profiles.

When you log into your account on Facebook, the server will show your own status messages
and your friends’ status messages at that point in time. Status messages on Facebook may
contain pictures, shared links and stories or your own messages. Naturally, your account data
requires a strong consistency, but for status data the weaker consistency models are acceptable.
During the time the user is online, the status updates of a user’s friends and of the user do not
need to be strictly ordered, and the causal ordering is enough.

Thus when a user A sends a status update and a user B replies to that update, there is a causal
order on the two updates. However, when users C and D do a totally unrelated update, the order
these updates appear to users A and B is not relevant. This is because users A and B do not know
in which order updates are performed.

The reason why the eventual consistency is not enough for Facebook status updates is that the
eventual consistency does not require any ordering between writes. Consider a case, where the
user A first sends a status update, and after few seconds A updates the first status update. With
the eventual consistency, all friends of A could see only the first update, because the eventual
consistency does not guarantee that first update is performed before the second one. In the causal
consistency, as there is a read (by user A) of first update and then write (updated status from user
A), these are causally related and all user A’s friends will naturally see second update.

9
 2. Entry consistency
This is a variant of the release consistency model.

It also requires the use of acquire and release instructions to explicitly state an entry or exit to a
critical section. However, under entry consistency, every shared variable is assigned a
synchronization variable specific to it. This way, only when to acquire is to variable x, all
operations related to x need to be completed with respect to that processor. This allows
concurrent operations of different critical sections of different shared variables to occur.
Concurrency cannot be seen for critical operations on the same shared variable. Such a
consistency model will be useful when different matrix elements can be processed at the same
time.

Entry Consistency

Similar to release consistency

✓ Use acquire and release at the start and end of each critical section

However, unlike to release consistency

✓ Each ordinary shared data item is associated with a synchronization variable

✓ E.g., elements of an array are associated with different synch. variable
✓ Increase the amount of parallelism

Entry Consistency Rules

✓ An acquire access of a synchronization variable is not allowed to perform with respect to

a process until all updates to the guarded shared data have been performed with respect to
that process.
✓ Before an exclusive mode access to a synchronization variable by a process is allowed to
perform with respect to that process, no other process may hold the synchronization
variable, not even in nonexclusive mode.
✓ After an exclusive mode access to a synchronization variable has been performed, any
other process's next nonexclusive mode access to that synchronization variable may not
be performed until it has performed with respect to that variable's owner.

10
 ✓ 1st point: an acquire may not complete until all guarded shared data are up to date
✓ 2nd point: before updating a shared data item
✓ A process must enter a C. S. in exclusive mode  To make sure that no other process is
trying to update it at the same time
✓ 3rd point: if a process wants to enter a C.S. in nonexclusive mode
✓ Check the owner of the synch. Variable to fetch the most recent copies of the guarded
shared data.
Example: A valid event sequence for entry consistency.

Locks associate with individual data items, as opposed to the entire data-store. Note: P2’s
read on ‘y’ may return NIL as no locks have been requested.
✓ A different twist on things is “Entry Consistency”. Acquire and release are still used, and
the data-store meets the following conditions:
1. An acquire access of a synchronization variable is not allowed to perform with
respect to a process until all updates to the guarded shared data have been
performed with respect to that process.
2. Before an exclusive mode access to a synchronization variable by a process is
allowed to perform with respect to that process, no other process may hold the
synchronization variable, not even in nonexclusive mode.

After an exclusive mode access to a synchronization variable has been performed, any other
process's next nonexclusive mode access to that synchronization variable may not be performed
until it has performed with respect to that variable's owner.

✓ So, acquire, all remote changes to guarded data must be brought up to date.
✓ Before a write to a data item, a process must ensure that no other process is trying to
write at the same time.

With entry consistency, each shared data item is associated with a synchronization variable.

11
In order to access consistent data, each synchronization variable must be explicitly acquired.
Release consistency affects all shared data but entry consistency affects only those shared data
associated with a synchronization variable.

Acquire and releases are still used, and the data-store meets the following conditions:

An acquire access of a synchronization variable is not allowed to perform with respect to a

process until all updates to the guarded shared data have been performed with respect to that
process. n Before an exclusive mode access to a synchronization variable by a process is allowed
to perform with respect to that process, no other process may hold the synchronization variable,
not even in nonexclusive mode.

After an exclusive mode access to a synchronization variable has been performed, any other
process's next nonexclusive mode access to that synchronization variable may not be performed
until it has performed with respect to that variable's owner.

Acquire and release is still used, and the data-store meets the following conditions:

✓ An acquire access of a synchronization variable is not allowed to perform with respect to

a process until all updates to the guarded shared data have been performed with respect
to that process.
✓ Before an exclusive mode access to a synchronization variable by a process is allowed to
perform with respect to that process, no other process may hold the synchronization
variable, not even in nonexclusive mode.
✓ After an exclusive mode access to a synchronization variable has been performed, any
other process's next nonexclusive mode access to that synchronization variable may not
be performed until it has performed with respect to that variable's owner.
✓ At acquire, all remote changes to guarded data must be brought up to date
✓ Before a write to a data item, a process must ensure that no other process is trying to
write at the same time.
✓ Locks are associates with individual data items, as opposed to the entire data-store.
✓ Lock is a synchronization mechanism for enforcing limits on access to a resource in an
environment where there are many threads of execution.

12
Conclusions

The causal consistency model can be enforced with Lamport clocks. Transactions using the
causal consistency are executed in an order that reflects their causally-related read/write
operations’ order. Concurrent operations may be committed in different orders and their results
can be read also in different orders.

Actually, the causal consistency can solve many problems, which cannot be solved in the
eventual consistency, such as ordering operations. The causal consistency ensures that every sees
operation in the same causal order and this makes the causal consistency stronger than the
eventual consistency. However, the causal consistency cannot support e.g. distributed integrity
constraints.

Entry Consistency Model: "Like... variants of release consistency, it requires the programmer (or
compiler) to use acquires and release at the start and end of each critical section, respectively.
However, unlike release consistency, entry consistency requires each ordinary shared data item
to be associated with some synchronization variable, such as a lock or barrier. If it is desired that
elements of an array be accessed independently in parallel, then different array elements must be

13
References

[1] Mustaque Ahamad , Gil Neiger , James E. Burns , Prince Kohli , P.W. Hutto: Causal Memory
Definitions.
[2] Leslie Lamport: How to Make a Multiprocessor Computer That Correctly Executes
Multiprocess Programs, IEEE Trans. Comput. C-28,9 (Sept. 1979), 690-691.
[3] Werner Vogels: Eventually consistent. Communications of the ACM 52:
40. doi:10.1145/1435417.1435432
[4] Leslie Lamport: Time, clocks, and the ordering of events in a distributed
system, Communications of the ACM, 21: 7, pp. 558–565, 1978.

[5] C. J. Fidge: Timestamps in message passing systems that preserve the partial ordering, in
Theoretical Computer Science, 1988.

[6] W. Lloyd, M. J. Freedman, M. Kaminsky, and D. G. Andersen: Don’t settle for eventual:
scalable causal consistency for wide-area storage with COPS, in Proceedings of the 23rd ACM
Symposium on Operating Systems Principles, pp. 401–416, Portugal, October 23-26, 2011.

14