Data-Centric

Consistency Models

School Of Computer Engineering, KI

Data-Centric Consistency
Models
 A data-store can be read from or written to by any process in a distributed
system.
 A local copy of the data-store (replica) can support “fast reads”.
 However, a write to a local replica needs to be propagated to all remote
replicas.

• Various consistency models help to understand the various mechanisms used

to achieve and enable this. 2
What is a Consistency
Model?
 A “consistency model” is a CONTRACT between a
DS data-store and its processes.

 If the processes agree to the rules, the data-store

will perform properly and as advertised.

 We start with Strict Consistency, which is defined

as:

 Any read on a data item ‘x’ returns a value

corresponding to the result of the most recent write
on ‘x’ (regardless of where the write occurred).

3
Consistency Model Diagram
Notation
 Wi(x)a – a write by process ‘i’ to item ‘x’
with a value of ‘a’. That is, ‘x’ is set to ‘a’.

 (Note: The process is often shown as ‘Pi’).

 Ri(x)b – a read by process ‘i’ from item ‘x’

producing the value ‘b’. That is, reading ‘x’
returns ‘b’.

 Time moves from left to right in all

diagrams.
4
Strict Consistency Diagrams

 Behavior of two processes, operating on the same data

item:
a) A strictly consistent data-store.
b) A data-store that is not strictly consistent.

• With Strict Consistency, all writes are instantaneously

visible to all processes and absolute global time order is
maintained throughout the DS. This is the consistency
model “Holy Grail” – not at all easy in the real world, and all
but impossible within a DS.

• So, other, less strict (or “weaker”) models have been

developed …
5
Sequential Consistency
 A weaker consistency model, which represents a
relaxation of the rules.
 It is also must easier (possible) to implement.

 Definition of “Sequential Consistency”:

 The result of any execution is the same as if the

(read and write) operations by all processes on
the data-store were executed in the same
sequential order and the operations of each
individual process appear in this sequence in the
order specified by its program.

6
Sequential Consistency Diagrams
In other words: all processes see the same interleaving set of
operations, regardless of what that interleaving is.

a) A sequentially consistent data-store – the “first” write

occurred after the “second” on all replicas.
b) A data-store that is not sequentially consistent – it appears
the writes have occurred in a non-sequential order, and this
is NOT allowed.

7
Problem with Sequential
Consistency
 With this consistency model, adjusting the
protocol to favour reads over writes (or
vice-versa) can have a devastating impact
on performance (refer to the textbook for
the gory details).

 For this reason, other weaker consistency

models have been proposed and developed.

 Again, a relaxation of the rules allows for

these weaker models to make sense.
8
Linearizability and Sequential
Consistency (1)

Process P1 Process P2 Process P3

x = 1; y = 1; z = 1;
print ( y, z); print (x, z); print (x, y);

 Three concurrently executing processes.

9
Linearizability and Sequential
Consistency (2)
 Four valid execution sequences for the processes
of the previous slide. The vertical axis is time.

x = 1; x = 1; y = 1; y = 1;
print ((y, z); y = 1; z = 1; x = 1;
y = 1; print (x,z); print (x, y); z = 1;
print (x, z); print(y, z); print (x, z); print (x, z);
z = 1; z = 1; x = 1; print (y, z);
print (x, y); print (x, y); print (y, z); print (x, y);

Prints: 001011 Prints: 101011 Prints: 010111 Prints: 111111

Signature: Signature: Signature: Signature:

001011 101011 110101 111111
(a) (b) (c) (d)

But, for instance, 001001 is not allowed.

10
Causal Consistency
 This model distinguishes between events
that are “causally related” and those that are
not.

 If event B is caused or influenced by an

earlier event A, then causal consistency
requires that every other process see event
A, then event B.

 Operations that are not causally related are

said to be concurrent.
11
 More on Causal Consistency
 A causally consistent data-store obeys this condition:
 Writes that are potentially causally related
must be seen by all processes in the same
order. Concurrent writes may be seen in a
different order on different machines (i.e., by
different processes).

This sequence is allowed with a causally-consistent store, but not with

sequentially or strictly consistent store. Note: it is assumed that W 2(x)b and
W1(x)c are concurrent. 12
 Another Causal Consistency
Example

incorrect

correct

a) Violation of causal-consistency – P2’s write is related to P1’s

write due to the read on ‘x’ giving ‘a’ (all processes must see
them in the same order).
b) A causally-consistent data-store: the read has been removed,
so the two writes are now concurrent. The reads by P3 and P4
are now OK. 13
FIFO Consistency
 Defined as follows:

Writes done by a single process are seen by all other

processes in the order in which they were issued,
but writes from different processes may be seen in
a different order by different processes.

 This is also called “PRAM Consistency” – Pipelined

RAM.
 The attractive characteristic of FIFO is that it is easy
to implement. There are no guarantees about the
order in which different processes see writes –
except that two or more writes from a single
process must be seen in order. 14
FIFO Consistency Example

 A valid sequence of FIFO consistency events.

 Note that none of the consistency models studied so
far would allow this sequence of events.

15
Introducing Weak
Consistency
 Not all applications need to see all writes,
let alone seeing them in the same order.

 This leads to “Weak Consistency” (which is

primarily designed to work with distributed
critical regions).

 This model introduces the notion of a

“synchronization variable”, which is used
update all copies of the data-store.

16
Weak Consistency
Properties
 The three properties of Weak Consistency:
1. Accesses to synchronization variables
associated with a data-store are
sequentially consistent.
2. No operation on a synchronization
variable is allowed to be performed until
all previous writes have been completed
everywhere.
3. No read or write operation on data items
are allowed to be performed until all
previous operations to synchronization
variables have been performed.
17
Weak Consistency: What It
Means
 So …

 By doing a sync., a process can force the just

written value out to all the other replicas.
 Also, by doing a sync., a process can be sure it’s
getting the most recently written value before it
reads.

 In essence, the weak consistency models enforce

consistency on a group of operations, as opposed
to individual reads and writes (as is the case with
strict, sequential, causal and FIFO consistency).

18
Weak Consistency Examples

before sync., any results are acceptable

Wrong!!

a) A valid sequence of events for weak consistency. This is

because P2 and P3 have yet to synchronize, so there’s no
guarantees about the value in ‘x’.
b) An invalid sequence for weak consistency. P2 has
synchronized, so it cannot read ‘a’ from ‘x’ – it should be
getting ‘b’. 19
Introducing Release
Consistency
 Question: how does a weakly consistent
data-store know that the sync is the result
of a read or a write?

 Answer: It doesn’t!

 It is possible to implement efficiencies if the

data-store is able to determine whether the
sync is a read or write.

 Two sync variables can be used, “acquire”

and “release”, and their use leads to the
“Release Consistency” model. 20
Release Consistency
 Defined as follows:

When a process does an “acquire”, the data-

store will ensure that all the local copies of
the protected data are brought up to date
to be consistent with the remote ones if
needs be.

When a “release” is done, protected data that

have been changed are propagated out to
the local copies of the data-store.
21
Release Consistency
Example

 A valid event sequence for release consistency.

 Process P3 has not performed an acquire, so there

are no guarantees that the read of ‘x’ is consistent.
The data-store is simply not obligated to provide
the correct answer.
 P2 does perform an acquire, so its read of ‘x’ is
consistent.
22
Release Consistency Rules
 A distributed data-store is “Release
Consistent” if it obeys the following rules:

1. Before a read or write operation on

shared data is performed, all previous
acquires done by the process must have
completed successfully.
2. Before a release is allowed to be
performed, all previous reads and writes
by the process must have completed.
3. Accesses to synchronization variables are
FIFO consistent (sequential consistency is
not required).
23
Introducing Entry
Consistency
 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.
3. 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. 24
Entry Consistency: What It
Means
 So, at an 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 associate with individual data items, as opposed to

the entire data-store. Note: P2’s read on ‘y’ returns NIL
as no locks have been requested. 25
 Summary of Consistency
Models
a) Consistency models that do not use synchronization operations.
b) Models that do use synchronization operations. (These require additional
programming constructs, and allow programmers to treat the data-store
as if it is sequentially consistent, when in fact it is not. They “should” also
offer the best performance).
Consistency Description

Strict Absolute time ordering of all shared accesses matters.

All processes must see all shared accesses in the same order. Accesses are furthermore ordered
Linearizability
according to a (nonunique) global timestamp.

Sequential All processes see all shared accesses in the same order. Accesses are not ordered in time.

Causal All processes see causally-related shared accesses in the same order.

All processes see writes from each other in the order they were used. Writes from different processes
FIFO
may not always be seen in that order.

(a)

Consistency Description

Weak Shared data can be counted on to be consistent only after a synchronization is done.

Release Shared data are made consistent when a critical region is exited.

Entry Shared data pertaining to a critical region are made consistent when a critical region is entered.

(b) 26