Consistency model

In computer science, consistency models are used in distributed systems like distributed shared memory systems or distributed data stores (such as a filesystems, databases, optimistic replication systems or Web caching). The system supports a given model if operations on memory follow specific rules. The data consistency model specifies a contract between programmer and system, wherein the system guarantees that if the programmer follows the rules, memory will be consistent and the results of memory operations will be predictable.

High level languages, such as C++ and Java, partially maintain the contract by translating memory operations into low-level operations in a way that preserves memory semantics. To hold to the contract, compilers may reorder some memory instructions, and library calls such as pthread_mutex_lock() encapsulate required synchronization.[1]

Verifying sequential consistency is undecidable in general, even for finite-state cache-coherence protocols.[2]

Consistency models define rules for the apparent order and visibility of updates, and it is a continuum with tradeoffs.[3]

Example

Assume that the following case occurs:[3]

The consistency model has to determine whether client B sees the write from client A or not.

Types

There are two methods to define and categorize consistency models; issue and view.

Issue: Issue method describes the restrictions that defines how a process can issue operations.

View: View method which defines the order of operations visible to processes.

For example, a consistency model can define that a process is not allowed to issue an operation until all previous issued operations are completed.

Different consistency models enforce different conditions. One Consistency model can be considered stronger than another if it requires all conditions of that model and more. In other words, a model with less constraints can be considered as a weaker consistency model.

Strict consistency

Strict consistency is the strongest consistency model. It requires that if a process reads any memory location, the value returned by the read operation is the value written by the most recent write operation to that location.

A distributed system with many nodes will take some time to copy information written to one node to all the other nodes responsible for replicating that information. That time can't be zero because it takes time for information to propagate through space, and there is a limit to how fast information can travel through space: the speed of light. Therefore strict consistency is impossible. The best one can do is design a system where the time-to-replicate approaches the theoretical minimum.

Sequential consistency

The sequential consistency model as defined by Lamport(1979)[4] is a weaker memory model than strict consistency.

Linearizability (also known as atomic consistency) can be defined as sequential consistency with the real-time constraint.

Causal consistency

Causal consistency can be considered 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 must be seen in the same order by all processes.

Processor consistency

The processor consistency model[5] is similar to PRAM consistency model with a stronger condition that defines all writes to the same memory location must be seen in the same sequential order by all other processes. Process consistency is weaker than sequential consistency but stronger than PRAM consistency model.

The Stanford DASH multiprocessor system implements a variation of processor consistency which is incomparable (neither weaker nor stronger) to Goodmans definitions.[6]

PRAM consistency (also known as FIFO consistency)

PRAM consistency (Pipelined RAM) was presented by Lipton and Sandberg in 1988[7] as one of the first described consistency models. Due to its informal definition there are in fact at least two subtle different implementations,[6] one by Ahamad et al. and one by Mosberger.

In PRAM consistency, all processes view the operations of a single process in the same order that they were issued by that process, while operations issued by different processes can be viewed in different order from different processes. PRAM consistency is weaker than processor consistency.

Cache consistency

Cache consistency[5][8] requires that all write operations to the same memory location are performed in some sequential order. Cache consistency is weaker than process consistency and incomparable with PRAM consistency.

Slow consistency

Slow Memory

In slow consistency,[8] if a process reads a value previously written to a memory location, it cannot subsequently read any earlier value from that location. Writes performed by a process are immediately visible to that process. Slow consistency is a weaker model than PRAM and cache consistency.

Example: Slow memory diagram depicts a slow consistency example. The first process writes 1 to the memory location X and then it writes 1 to the memory location Y. The second process reads 1 from Y and it then reads 0 from X even though X was written before Y.

Hutto, Phillip W., and Mustaque Ahamad (1990)[9] illustrate that by appropriate programming, slow memory (consistency) can be expressive and efficient. They mention that slow memory has two valuable properties; locality and supporting reduction from atomic memory. They propose two algorithms to present the expressiveness of slow memory.

General consistency

In general consistency,[10] all the copies of a memory location are eventually identical after all processes' writes are completed.

Local consistency

In local consistency,[8] each process performs its own operations in the order defined by its program. There is no constraint on the ordering in which the write operations of other processes appear to be performed. Local consistency is the weakest consistency model in shared memory systems.

Some other consistency models are as follows:

Relaxed Memory Consistency Models

Some different consistency models can be defined by relaxing one or more requirements in sequential consistency called relaxed consistency models.[13] These consistency models do not provide memory consistency at the hardware level. In fact, the programmers are responsible for implementing the memory consistency by applying synchronization techniques.

There are four comparisons to define the relaxed consistency:

Relaxation Models

The following models are some models of relaxed consistency:

Weak Ordering

There are two categories of memory operations in weak ordering;[13] data operations and synchronization operations.

Processor Consistency

The processor consistency model[5] is similar to PRAM consistency model with a stronger condition that defines all writes to the same memory location must be seen in the same sequential order by all other processes.

Transactional Memory Models

Transactional Memory model[13] is the combination of cache coherency and memory consistency models as a communication model for shared memory systems supported by software or hardware; a transactional memory model provides both memory consistency and cache coherency. A transaction is a sequence of operations executed by a process that transforms data from one consistent state to another. A transaction either commits when there is no conflict or aborts. In commits, all changes are visible to all other processes when a transaction is completed, while aborts discard all changes. Compared to relaxed consistency models, a transactional model is easier to use and can provide the higher performance than a sequential consistency model.

Consistency and replication

Tanenbaum et al., 2007[15] defines two main reasons for replicating; reliability and performance. Reliability can be achieved in a replicated file system by switching to another replica in the case of the current replica failure. The replication also protects data from being corrupted by providing multiple copies of data on different replicas. It also improves the performance by dividing the work. While replication can improve performance and reliability, it can cause consistency problems between multiple copies of data. The multiple copies are consistent if a read operation returns the same value from all copies and a write operation as a single atomic operation (transaction) updates all copies before any other operation takes place. Tanenbaum, Andrew, & Maarten Van Steen, 2007[15] refer to this type of consistency as tight consistency provided by synchronous replication. However, applying global synchronizations to keep all copies consistent is costly. One way to decrease the cost of global synchronization and improve the performance can be weakening the consistency restrictions.

Data-centric consistency models

Tanenbaum et al., 2007[15] defines the consistency model as a contract between the software (processes) and memory implementation (data store). This model guarantees that if the software follows certain rules, the memory works correctly. Since, in a system without a global clock, defining the last operation writes is difficult, some restrictions can be applied on the values that can be returned by a read operation.

Consistent ordering of operations

Some consistency models such as sequential and also causal consistency models deal with the order of operations on shared replicated data in order to provide consistency. In this models, all replicas must agree on a consistent global ordering of updates.

Sequential consistency

The goal of data-centric consistency models is to provide a consistent view on a data store where processes may carry out concurrent updates. One important data-centric consistency model is sequential consistency defined by Lamport (1979).[4] Tanenbaum et al., 2007[15] defines sequential consistency under following condition:

"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."[15]

Adve and Gharachorloo, 1996[14] define two requirements to implement the sequential consistency; program order and write atomicity.

In sequential consistency, there is no notion of time or most recent writes operation. There are some operations interleaving that is same for all processes. A process can see the write operations of all processes but it can just see its own read operations.

Linearizability[16] (Atomic memory)[13] can be defined as a sequential consistency with real time constraint by considering a begin time and end time for each operation. An execution is linearizable if each operation taking place in linearizable order by placing a point between its begin time and its end time and guarantees sequential consistency.

Causal consistency

The causal consistency[15] defined by Hutto and Ahamad, 1990[9] is a weaker consistency model than sequential consistency by making the distinction between causally related operations and those that are not related. For example, if an event b takes effect from an earlier event a, the causal consistency guarantees that all processes see event b after event a.

Tanenbaum et al., 2007[15] defines that a data store is considered causal consistent under the following 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."[15]

Grouping operations[15]

In grouping operation, accesses to the synchronization variables are sequentially consistent. A process is allowed to access a synchronization variable that all previous writes have been completed. In other words, accesses to synchronization variables are not permitted until all operations on the synchronization variables are completely performed.

Continuous consistency

The continuous consistency is defined later in the consistency protocol section.

Client-centric consistency models[15]

In distributed systems, maintaining sequential consistency in order to control the concurrent operations is essential. In some special data stores without simultaneous updates, client-centric consistency models can deal with inconsistencies in a less costly way. The following models are some client-centric consistency models:

Eventual consistency

An eventual consistency[15] is a weak consistency model in the system with the lack of simultaneous updates. It defines that if no update takes very long time, all replicas eventually become consistent.

Monotonic read consistency

Tanenbaum et al., 2007[15] defines monotonic read consistency as follows:

"If a process reads the value of a data item x, any successive read operation on x by that process will always return that same value or a more recent value."[15]

Monotonic read consistency guarantees that after a process reads a value of data item x at time t, it will never see the older value of that data item.

Monotonic write consistency

Monotonic write consistency condition is defined by Tanenbaum et al., 2007[15] as follows:

"A write operation by a process on a data item X is completed before any successive write operation on X by the same process."[15]

Read-your-writes consistency

A value written by a process on a data item X will be always available to a successive read operation performed by the same process on data item X.[15]

Writes-follows-reads consistency

In Writes-follow-reads consistency, updates are propagated after performing the previous read operations. Tanenbaum et al., 2007[15] defines the following condition for Writes-follow-reads consistency:

"A write operation by a process on a data item x following a previous read operation on x by the same process is guaranteed to take place on the same or a more recent value of x that was read."[15]

Consistency protocols

The implementation of a consistency model is defined by a consistency protocol. Tanenbaum et al., 2007[15] illustrates some consistency protocols for data-centric models.

Continuous consistency

Continuous consistency introduced by Yu and Vahdat (2000).[17] In this model, consistency semantic of an application is described by using conits in the application. Since the consistency requirements can differ based on application semantics, Yu and Vahdat (2000)[17] believe that a predefined uniform consistency model may not be an appropriate approach. The application should specify the consistency requirements that satisfy the application semantic. In this model, an application specifies each consistency requirements as a conits (abbreviation of consistency units). A conit can be a physical or logical consistency and is used to measure the consistency. Tanenbaum et al., 2007[15] describes the notion of a conit by giving an example. There are three inconsistencies that can be tolerated by applications.

If all three deviation bounds set to zero, the continuous consistency model is the strong consistency.

Primary-based protocols

Primary backup protocol
Primary-backup protocol (local-write)

Primary-based protocols[15] can be considered as a class of consistency protocols that are simpler to implement. For instance, sequential ordering is a popular consistency model when consistent ordering of operations is considered. The sequential ordering can be determined as primary-based protocol. In these protocols, there is an associated primary for each data item in a data store to coordinate write operations on that data item.

Remote-write protocols

In the simplest primary-based protocol that supports replication, also known as primary-backup protocol, writes operation are forwarded to a single server and read operations can be performed locally.

Example: Tanenbaum et al., 2007[15] gives an example of a primary-backup protocol. The diagram of primary-backup protocol shows an example of this protocol. When a client requests a write, the write request is forwarded to a primary server. The primary server sends request to backups to perform the update. The server then receives the update acknowledgement from all backups and sends the acknowledgement of completion of writes to the client. Any client can read the last available update locally. The trade-off of this protocol is that a client who sends the update request might have to wait so long to get the acknowledgement in order to continue. This problem can be solved by performing the updates locally, and then ask other backups perform their updates. The non-blocking primary-backup protocol does not guarantee the consistency of update on all backup servers. However, it improves the performance. In the primary-backup protocol, all processes will see the same order of write operations since this protocol orders all incoming writes based on a globally unique time. Blocking protocols guarantee that processes view the result of the last write operation.
Local-write protocols

In primary-based local-write protocols,[15] primary copy moves between processes willing to perform an update. To update a data item, a process first moves it to its location. As a result, in this approach, successive write operations can be performed locally while each process can read their local copy of data items. After the primary finishes its update, the update is forwarded to other replicas and all perform the update locally. This non-blocking approach can lead to an improvement. The diagram of the local-write protocol depicts the local-write approach in primary-based protocols. A process requests a write operation in a data item x. The current server is considered as the new primary for a data item x. The write operation is performed and when the request is finished, the primary sends an update request to other backup servers. Each backup sends an acknowledgment to the primary after finishing the update operation.

Replicated-write protocols

In Replicated-write protocols,[15] unlike the primary-based protocol, all updates are carried out to all replicas.

Active replication

In active replication,[15] there is a process associated to each replica to perform the write operation. In other words, updates are sent to each replica in the form of an operation in order to be executed. All updates need to be performed in the same order in all replicas. As a result, a totally-ordered multicast mechanism is required. There is a scalability issue in implementing such a multicasting mechanism in large distributed systems. There is another approach in which each operation is sent to a central coordinator (sequencer). The coordinator first assigns a sequence number to each operation and then forwards the operation to all replicas. Second approach cannot also solve the scalability problem.

Quorum-based protocols[15]

Voting can be another approach in replicated-write protocols. In this approach, a client requests and receives permission from multiple servers in order to read and write a replicated data. As an example, suppose in a distributed file system, a file is replicated on N servers. To update a file, a client must send a request to at least N/2+1 in order to make their agreement to perform an update. After the agreement, changes are applied on the file and a new version number is assigned to the updated file. Similarly, for reading replicated file, a client sends a request to N/2+1 servers in order to receive the associated version number from those servers. Read operation is completed if all received version numbers are the most recent version.

Cache-coherence protocols

In a replicated file system, a cache-coherence protocol[15] provides the cache consistency while caches are generally controlled by clients. In many approaches, cache consistency is provided by the underlying hardware. Some other approaches in middleware-based distributed systems apply software-based solutions to provide the cache consistency. Cache consistency models can differ in their coherence detection strategies that define when inconsistencies occur. There are two approaches to detect the inconsistency; static and dynamic solutions. In the static solution, a compiler determines which variables can cause the cache inconsistency. So, the compiler enforces an instruction in order to avoid the inconsistency problem. In the dynamic solution, the server checks for inconsistencies at run time to control the consistency of the cached data that has changed after it was cached. The coherence enforcement strategy is another cache-coherence protocol. It defines that how to provide the consistency in caches by using the copies located on the server. One way to keep the data consistent is to never cache the shared data. A server can keep the data and apply some consistency protocol such as primary-based protocols to ensure the consistency of shared data. In this solution, only private data can be cached by clients. In the case that shared data are cached, there are two approaches in order to enforce the cache coherence. In first approach, when a shared data is updated, the server forwards invalidation to all caches. In second approach, an update is propagated. Most caching systems apply these two approaches or dynamically choose between them.

See also

References

  1. ↑ Mark D. Hill (August 1998). "Multiprocessors Should Support Simple Memory Consistency Models". IEEE Computer 31 (8): 28–34. doi:10.1109/2.707614.
  2. ↑ Shaz Qadeer (August 2003). "Verifying Sequential Consistency on Shared-Memory Multiprocessors by Model Checking". IEEE Transactions on Parallel and Distributed Systems 14 (8): 730–741. doi:10.1109/TPDS.2003.1225053.
  3. 1 2 Todd Lipcon (2014-10-25). "Design Patterns for Distributed Non-Relational Databases" (PDF). Retrieved 2011-03-24. A consistency model determines rules for visibility and apparent order of updates. Example: * Row X is replicated on nodes M and N * Client A writes row X to node N * Some period of time t elapses. * Client B reads row X from node M * Does client B see the write from client A? Consistency is a continuum with tradeoffs
  4. 1 2 Lamport, Leslie (Sep 1979). "How to make a multiprocessor computer that correctly executes multiprocess programs.". Computers, IEEE Transactions C–28 (9): 690–691. doi:10.1109/TC.1979.1675439.
  5. 1 2 3 Goodman, James R (1991). "Cache consistency and sequential consistency". IEEE Scalable Coherent Interface (SCI) Working Group.
  6. 1 2 Senftleben, Maximilian (2013). Operational Characterization of Weak Memory Consistency Models (PDF) (M.Sc. thesis). University of Kaiserslautern.
  7. ↑ Lipton, R.J.; J.S. Sandberg. (1988). PRAM: A scalable shared memory (Technical report). Princeton University. CS-TR-180-88.
  8. 1 2 3 4 Steinke, Robert C., and Gary J. Nutt (2004). "A unified theory of shared memory consistency.". Journal of the ACM (JACM) 51 (5): 800–849. doi:10.1145/1017460.1017464.
  9. 1 2 Hutto, Phillip W., and Mustaque Ahamad (1990). "Slow memory: Weakening consistency to enhance concurrency in distributed shared memories.". IEEE: 302–309. doi:10.1109/ICDCS.1990.89297.
  10. ↑ Singhal, Mukesh, and Niranjan G. Shivaratri (1994). "Advanced concepts in operating systems.". McGraw-Hill, Inc.
  11. ↑ Lloyd, Wyatt; Freedman, Michael; Kaminsky, Michael; Andersen, David. "Don’t Settle for Eventual:Scalable Causal Consistency for Wide-Area Storage with COPS" (PDF). Proceedings of the 23rd ACM Symposium on Operating Systems Principles (SOSP’11).
  12. ↑ Almeida, Sérgio; Leitão, João; Rodrigues, Luís. "ChainReaction: a causal+ consistent datastore based on chain replication". Proceedings of the 8th ACM European Conference on Computer Systems (EuroSys'13).
  13. 1 2 3 4 Mankin, Jenny (2007). "CSG280: Parallel Computing Memory Consistency Models: A Survey in Past and Present Research".
  14. 1 2 Sarita V. Adve, Kourosh Gharachorloo (December 1996). "Shared Memory Consistency Models: A Tutorial" (PDF). IEEE Computer 29 (12): 66–76. doi:10.1109/2.546611. Retrieved 2008-05-28.
  15. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Tanenbaum, Andrew, and Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall.
  16. ↑ Herlihy, Maurice P., and Jeannette M. Wing (July 1990). ""Linearizability: A correctness condition for concurrent objects." ACM Transactions on Programming Languages and Systems". ACM Transactions on Programming Languages and Systems 12 (3): 463–492. doi:10.1145/78969.78972.
  17. 1 2 3 4 5 Yu, Haifeng, and Amin Vahdat (2000). "Design and evaluation of a continuous consistency model for replicated services.". Proceedings of the 4th conference on Symposium on Operating System Design & Implementation 4: 21–21.

Further reading

External links

This article is issued from Wikipedia - version of the Wednesday, April 27, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.