Consistency Models

1
Consistency Models

• Ref Tanenbaum/van Steen chpt 6

2
Outline

• Consistency and Replication Introduction
• Consistency Models
• Strict Consistency
• Sequential Consistency
• Linearizability
• Causal Consistency
• FIFO Consistency
• Weak Consistency
• Release Consistency
• Entry Consistency

3
Replication of Data

• Two main reasons to replicate
• Reliability so there are backup copies if
  failures occur
• Performance - cache copies of data closer to
  users needing the information
• Main issue Consistency
• If data is modified, how are the different copies
  updated
• Overhead a concern if data is updated much more
  often than it is referenced, updating copies will
  consume much resources w/o benefit
• What exactly does consistency mean, anyway?
• Consistency models
• Implementing the strictest type of consistency
  may require costly implementations
• Much work in relaxing consistency models to
  provide weaker forms of consistency with less
  runtime overhead

4
Consistency Models

• Data store - system (possibly distributed) where
  data is held
• Shared memory (as in multiprocessor)
• Distributed shared memory
• Shared database system
• Distributed file system
• Assume data is cached near to the processes
  accessing it
• A consistency model is a contract between
  processes and the data store regarding how the
  memory works (semantics of read and write
  operations) - the memory provides certain
  guarantees, provided the software follows certain
  rules
• Trick is to define rules that are not too
  restrictive, but allow fast execution in most
  common cases

5
Strict Consistency

• Any read on a data item x returns a value
  corresponding to the result of the most recent
  write on x
• Assumes the existence of absolute global time (to
  define what most recent means)
• This cannot be implemented in a distributed
  system w/ caches!
• Notation
• Wi(x)a means Process Pi writes the value a into
  variable x
• Rj(y)b means Process Pj reads the value b from
  variable y

T2-T1 can be arbitrarily small Pi and Pj may be
arbitrarily far apart
6
Strict Consistency
Example P1 W(x)1 P2 R(x)0
R(x)1 Is this strictly consistent?

• Writes are instantaneously visible to all
  processes throughout system
• If data is changed, all subsequent reads (prior
  to the next write) return the new value, no
  matter how soon the read comes, nor how far away
  the reader is from the writer
• If a process reads the variable, it gets the
  current value, no matter how quickly the next
  write occurs
• Unirpocessors provide this ordering can be
  implemented by serializing all operations at a
  central site (e.g., Sprite file system)
• Actually, we are taking some liberties here,
  e.g., we get to define when exactly a read/write
  operation occurs given that real operations are
  not instantaneous

7
Sequential Consistency

• Fortunately strict consistency is seldom needed
• Would like each processor to see a consistent
  ordering of the operations made by each process,
  however
• 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
• Basically,
• Take the read/write operations performed by each
  process and put them in the order the process
  does them (process order)
• Interleave the operations in some way to form a
  total order
• Read operations must return most recently written
  data in the total order for the execution to be
  sequentially consistent
• Implies all processes see the same total ordering
  of the operations

8
Linearizability

• Weaker than strict consistency, stronger that
  sequential consistency
• Sequential consistency, plus an additional
  constraint
• Assign a finite precision timestamp to each
  operation
• If the time stamp of operation 1 lt timestamp of
  operation 2, the operation 1 should precede
  operation 2 in the total order
• Mostly used for formal verification of
  distributed algorithms

9
Performance

• Sequential consistency is programmer friendly,
  but difficult to implement efficiently
• It can be shown (Lipton/Sandberg)
• If the read time is r, and the write time is w,
  and the minimum packet transfer time between
  nodes is t, then rw t
• Optimizing read time will degrade write time, and
  vice versa for any sequentially consistent store
• Weaker models of consistency are often used in
  order to achieve better performance
• Causal consistency
• FIFO consistency
• Weak consistency
• Release consistency
• Entry consistency

10
Casual Consistency

• Focus on data dependencies between write
  operations
• If one computation depends (or could depend) on
  another, all processors observing these
  operations (writes) should see them in the same
  order (consistent with order implied by the
  dependence)
• If no dependence exists, different processes may
  see them in different orders
• Write operations
• Causally-related writes example W1(x) R2(x)
  W2(y) these two writes are causally dependent
  because the value written by W2(y) could depend
  on value written by W1(x)
• Fact that one could depend on the other is
  sufficient doesnt matter if one really does
  depend on the other
• Concurrent writes those that are not causally
  related to each other
• Causal consistency
• Writes that are (potentially) casually related
  must be seen by all processes in the same order.
• Concurrent writes may be seen in a different
  order on different machines.

11
Casual Consistency Example

• This sequence is allowed with a
  casually-consistent store, but not with
  sequentially or strictly consistent store.
• Why?

12
Casual Consistency (cont)
How about these?
violates causal consistency
OK
This assumes two writes to same variable not
dependent Implementation needs to keep track of
(potential) dependencies
13
FIFO Consistency

• Necessary ConditionWrites 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.
• Relaxes requirement that causally related writes
  be seen in the same order on different machines

14
FIFO Consistency (cont.)

• Aka Pipelined RAM (PRAM)
• Writes from a single process can be pipelined
  without stalling the processor to wait for
  previous writes to complete
• All writes from different processors considered
  concurrent - different processors can see the
  same set of writes in a different order
• Simple implementation
• Can lead to somewhat surprising results

With FIFO consistency, both processes could be
killed This cannot happen with sequential
consistency
15
Weak Consistency

• Idea Accesses to shared variables should be done
  within critical sections exploit this fact
• Relax consistency except at synchronization
  points
• Properties
• Accesses to synchronization variables associated
  with a data store are sequentially consistent
• All processes see accesses to synchronization
  variables in the same order
• No operation on a synchronization variable is
  allowed to be performed until all previous writes
  have been completed everywhere
• Synchronization operations flush the pipeline
• Synch operation forces new values of variables
  out to other processes
• No read or write operation on data items are
  allowed to be performed until all previous
  operations to synchronization variables have been
  performed.
• Data accessed only after synch operation has
  completed

16
Weak Consistency Example
Are these valid sequences with weak consistency?
Valid
Invalid
Operations between synchronization points treated
as a block Only worry about synchronization
between blocks of operations
17
Weak and Release Consistency
18
Release Consistency

• Extends weak consistency by considering lock
  (acquire) and unlock (release) operations on
  synchronization variables

• 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 (flush writes)
• Accesses to synchronization variables are FIFO
  consistent (sequential consistency is not
  required).

19
Release Consistency

• If all accesses to shared variables are
  surrounded by acquire and release operations,
  results are the same as with sequential
  consistency
• Blocks of operations within critical section are
  made atomic via acquire/release operations
• Release operation
• Eager (normal) release consistency - release
  operation causes process to push out all write
  operations to other processes
• Lazy release consistency - at release, nothing is
  sent rather, wait until subsequent acquire
  operation, and then get most recent values
• Entry consistency
• Like lazy release consistency, but all data
  variables are explicitly associated with
  synchronization variables

20
Summary of Consistency Models

• Consistency models not using synchronization
  operations.
• Models with synchronization operations.