Consistency and Replication

Replication of data
Why?
• To enhance reliability
• To improve performance in a large scale system
However;
• Replicas must be consistent
• Modifications have to be carried out on all copies
• Problems with network performance
It is needed to handling concurrency…

Different consistency models

A consistency model is a set of rules that process obeys when accessing data
 Object Replication

a) A remote object capable of handling concurrent invocations on its own.

b) A remote object for which an object adapter is required to handle concurrent invocations
 Object Replication
Replicas need more synchronization to ensure that concurrent
invocations lead to consistent results

a) A distributed system for replication-aware distributed objects.

b) A distributed system responsible for replica management (simpler for application
developers), it ensures that concurrent invocation are passed to the replicas in the correct
order
 Replication and Scaling
Replication and caching are widely used in scaling technique, but

• Keeping replicas up to date needs networks use

• Update needs to be atomic ( transaction)
• Replicas need to be synchronized (time consuming)

Loose Consistency

In this case copies are not always the same everywhere.

 Data-Centric Consistency Models
• It is a contract between the processes and data store.
• If processes agree to obey certain rules, the store promises to work
correctly.
• For example, when a process wants to read a data item, then it expects
to have the value that is the result of the last write operation on the
the data.
• Without a global clock, it is hard to decide which write operation is
the last.
 Data-Centric Consistency Models

read or
write

• The general organization of a logical data store, physically distributed and replicated
across multiple machines.
• Each process that can access the data has its own local copy
• Write operations are propagated to the other copies
 Strict Consistency
Any read on a data item x returns a value of the last write operation on x
Two operations in the same time interval are said to conflict if they operate on the same data and one of them is a
write operation

This behavior implies a globally consistent view of data that requires synchronization across all replicas

Behavior of two processes, operating on the same data item.

a) A strictly consistent store.
b) A store that is not strictly consistent.
Strict consistency is the ideal model but it is very difficult to implement it in a distributed
system

Problem: 1. Rely on absolute global time.

2. Multiple operations may take place within an interval.
 Sequential Consistency (1)
Sequential Consistency it is a weaker consistency model than strict 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 some sequential order and the
operations of each individual process appear in this sequence in the order specified
by its program
All processes see the same interleaving of operations

a) A sequentially consistent data store. ‫كل عمليات القراءة ترى آخر قيمة مكتوبة‬،
b) A data store that is not sequentially consistent.

No reference to the timing of the operations

 Linearizability and Sequential Consistency (2)
Linearizability is weaker than strict consistency but stronger than 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 some sequential order and the
operations of each individual process appear in this sequence in the order specified
by its program.
if tsOP1(x) < tsOP2(y), then operation OP1(x) should precede OP2(y) in this sequence

Operations in this sequence are in the global time order of operations

(occurs between invocation and response)

Process P1 Process P2 Process P3

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

Example : three concurrently executing processes; (x, y, z) are data store shared items
Various (90) interleaved execution sequences are possible
 Linearizability and Sequential Consistency (3)
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: 00 10 11 Prints: 10 10 11 Prints: 01 01 11 Prints: 11 11 11

Signature: Signature: Signature: Signature:

00 10 11 10 10 11 11 01 01 11 11 11
(a) (b) (c) (d)

Not all signature pattern are allowed : 00 00 00 not permitted, 00 10 01 not permitted.
An invalid ordering would be when after assigning a value to a variable we still print a 0. Another scenario might be if we do not agree to
program order.
Constraints:
• Program order must be maintained
• Data coherence must be respected
Data coherence : any read must return the most recently written value of the data (relatively to the single data item, without regard to other data)
 Causal Consistency (1)
When there is a read followed by a write, the two events
are potentially causally related
Operation not causally related are said concurrent

Necessary 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.
 Causal Consistency (2)

This sequence is allowed with a causally-consistent store, but not with sequentially or strictly
consistent store.
Note that the writes W2(x)b and W1(x)c are concurrent

Causal consistency requires keeping records and tracks of the writes seen or processed by each
process or node in the distributed system.
 Causal Consistency (3)

a) A violation of a casually-consistent store. W2(x)b may be related to W1(x)a

b) A correct sequence of events in a casually independent consistent store. W1(x)a
and W2(x)b are concurrent
 FIFO Consistency (1)
Relaxing consistency requirements we drop causality

Necessary Condition:
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.

All writes generated by different processes are considered concurrent

It is easy to implement
 FIFO Consistency (2)

A valid sequence of events of FIFO consistency. It is not valid for causal consistency
 FIFO Consistency (3)
Process P1 Process P2 Process P3

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

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

Prints: 00 Prints: 10 Prints: 01

(a) (b) (c)

The statements in bold are the ones that generate the output shown. Their
concatenated output is 001001, that is incompatible with sequential consistency
 FIFO Consistency (4)
Different processes can see the operations in different
order

Process P1 Process P2
x = 1; y = 1;
if (y == 0) kill (P2); if (x == 0) kill (P1);

The result of this two concurrent processes can be also that both processes are killed.
 Weak Consistency
We can release the requirements of writes within the same process
seen in order everywhere introducing a synchronization variable.
A synchronization operation synchronize all local copies of the data
store.
Properties of weak consistency:
• Accesses to synchronization variables associated with a data store
are sequentially consistent
• No operation on a synchronization variable is allowed to be
performed until all previous writes have been completed
everywhere
• No read or write operation on data items are allowed to be
performed until all previous operations to synchronization
variables have been performed.
It forces consistency on a group of operations, not on individual write
and read
It limits the time when consistency holds, not the form of consistency.
 Weak Consistency

a) A valid sequence of events for weak consistency.

b) An invalid sequence for weak consistency.
 Release Consistency
If it is possible to know the difference between entering a
critical region or leaving it, a more efficient
implementation might be possible.
To do that, two kinds of synchronization variables are
needed.
Release consistency : acquire operation to tell that a
critical region is being entered; release operation when a
critical region is to be exited

A valid event sequence for release consistency.

Shared data kept consistent are called protected

 Release Consistency
Rules:
• Before a read or write operation on shared data is performed,
all previous acquires done by the process must have completed
successfully.
• Before a release is allowed to be performed, all previous reads
and writes by the process must have completed
• Accesses to synchronization variables are FIFO consistent
(sequential consistency is not required).

Explicit acquire and release calls are required

 Entry Consistency
Many synchronization variables associated with each
shared data
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.
 Entry Consistency (1)

A valid event sequence for entry consistency. Lock are associated with each data item
 Summary of Consistency Models
Consistency Description
Strict Absolute time ordering of all shared accesses matters.
All processes must see all shared accesses in the same order. Accesses are
Linearizability
furthermore ordered according to a (nonunique) global timestamp
All processes see all shared accesses in the same order. Accesses are not ordered in
Sequential
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
FIFO
different processes 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)
a) Consistency models not using synchronization operations.
b) Models with synchronization operations.