Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Consistency model
open-in-new
<h2 id="example">Example</h2> <p>Assume that the following case occurs:<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a> </p> <ul><li>The row X is replicated on nodes M and N</li> <li>The client A writes row X to node M</li> <li>After a period of time t, client B reads row X from node N</li></ul> <p>The consistency model determines whether client B will definitely see the write performed by client A, will definitely not, or cannot depend on seeing the write. </p> <h2 id="types">Types</h2> <p>Consistency models define rules for the apparent order and visibility of updates, and are on a <a href="/facts/Linear_continuum/BHs0Wn5m">continuum</a> with tradeoffs.<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> There are two methods to define and categorize consistency models; issue and view. </p> Issue Issue method describes the restrictions that define how a process can issue operations. View View method which defines the order of operations visible to processes. <p>For example, a consistency model can define that a process is not allowed to issue an operation until all previously 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 fewer constraints is considered a weaker consistency model. </p><p>These models define how the hardware needs to be laid out and at a high-level, how the programmer must code. The chosen model also affects how the compiler can re-order instructions. Generally, if control dependencies between instructions and if writes to same location are ordered, then the compiler can reorder as required. However, with the models described below, some may allow writes before loads to be reordered while some may not. </p> <h2 id="strong-consistency-models">Strong consistency models</h2> <h3>Strict consistency</h3> <p>Strict consistency is the strongest consistency model. Under this model, a write to a variable by any processor needs to be seen instantaneously by all processors. </p><p>The strict model diagram and non-strict model diagrams describe the time constraint – instantaneous. It can be better understood as though a global clock is present in which every write should be reflected in all processor caches by the end of that clock period. The next operation must happen only in the next clock period. </p><p>In the following diagram, P means "process" and the global clock's value is represented in the Sequence column. </p> <table><tbody><tr><th rowspan="2">Sequence</th><th colspan="2">Strict model</th><th colspan="2">Non-strict model</th></tr><tr><th>P1</th><th>P2</th><th>P1</th><th>P2</th></tr><tr><th>1</th><td><i>W</i>(<i>x</i>)1</td><td></td><td><i>W</i>(<i>x</i>)1</td><td></td></tr><tr><th>2</th><td></td><td><i>R</i>(<i>x</i>)1</td><td></td><td><i>R</i>(<i>x</i>)0</td></tr><tr><th>3</th><td></td><td></td><td></td><td><i>R</i>(<i>x</i>)1</td></tr></tbody></table> <p>This is the most rigid model. In this model, the programmer's expected result will be received every time. It is deterministic. Its practical relevance is restricted to a thought experiment and formalism, because instantaneous message exchange is impossible. It doesn't help in answering the question of conflict resolution in concurrent writes to the same data item, because it assumes concurrent writes to be impossible. </p> <h3>Sequential consistency</h3> <p class="note">Main article: <a href="/facts/Sequential_consistency/LlMBzcTH">Sequential consistency</a></p> <p>The <a href="/facts/Sequential_consistency/LlMBzcTH">sequential consistency</a> model was proposed by Lamport (1979). It is a weaker memory model than strict consistency model.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> A write to a variable does not have to be seen instantaneously, however, writes to variables by different processors have to be seen in the same order by all processors. Sequential consistency is met if "the result of any execution is the same as if the (read and write) operations of all processes on the data store were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program."<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a><a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> Adve and Gharachorloo, 1996<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> define two requirements to implement the sequential consistency; program order and write atomicity. </p> <ul><li>Program order: Program order guarantees that each process issues a memory request ordered by its program.</li> <li>Write atomicity: Write atomicity defines that memory requests are serviced based on the order of a single FIFO queue.</li></ul> <p>In sequential consistency, there is no notion of time or most recent write operations. There are some operations interleaving that is the same for all processes. A process can see the write operations of all processes but it can just see its own read operations. Program order within each processor and sequential ordering of operations between processors should be maintained. In order to preserve sequential order of execution between processors, all operations must appear to execute instantaneously or atomically with respect to every other processor. </p><p>These operations need only "appear" to be completed because it is physically impossible to send information instantaneously. For instance, in a system utilizing a single globally shared bus, once a bus line is posted with information, it is guaranteed that all processors will see the information at the same instant. Thus, passing the information to the bus line completes the execution with respect to all processors and has appeared to have been executed. Cache-less architectures or cached architectures with interconnect networks that are not instantaneous can contain a slow path between processors and memories. These slow paths can result in sequential inconsistency, because some memories receive the broadcast data faster than others. </p><p>Sequential consistency can produce non-deterministic results. This is because the sequence of sequential operations between processors can be different during different runs of the program. All memory operations need to happen in the program order. </p><p><a href="/facts/Linearizability/u3pnNCvs">Linearizability</a><a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a> (also known as atomic consistency or atomic memory)<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a> can be defined as sequential consistency with a 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. </p><p>Verifying <a href="/facts/Sequential_consistency/LlMBzcTH">sequential consistency</a> through <a href="/facts/Model_checking/FwvKMlw9">model checking</a> is <a href="/facts/Undecidable_problem/QBxmXBbY">undecidable</a> in general, even for finite-state <a href="/facts/Cache_coherence/MhUD576q">cache coherence</a> protocols.<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a> </p> <h3>Causal consistency</h3> <p><a href="/facts/Causal_consistency/qdwBqVgL">Causal consistency</a><a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a> defined by Hutto and Ahamad, 1990,<a class="footnote-ref" id="fnref:12" href="#fn:12"><sup>12</sup></a> is a weakening of the sequential consistency model 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. 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 provide a stricter definition, that a data store is considered causally consistent under the following conditions:<a class="footnote-ref" id="fnref:13" href="#fn:13"><sup>13</sup></a> </p> <ul><li>Writes that are potentially causally related must be seen by all processes in the same order.</li> <li>Concurrent writes may be seen in a different order on different machines.</li></ul> <p>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. </p><p>As in sequential consistency, reads do not need to reflect changes instantaneously, however, they need to reflect all changes to a variable sequentially. </p> <table><tbody><tr><th>Sequence</th><th>P1</th><th>P2</th><th>P3</th><th>P4</th></tr><tr><th>1</th><td>W(x)1</td><td>R(x)1</td><td>R(x)1</td><td>R(x)1</td></tr><tr><th>2</th><td></td><td>W(x)2</td><td></td><td></td></tr><tr><th>3</th><td>W(x)3</td><td></td><td>R(x)3</td><td>R(x)2</td></tr><tr><th>4</th><td></td><td></td><td>R(x)2</td><td>R(x)3</td></tr></tbody></table> <p>W(x)2 happens after W(x)1 due to the read made by P2 to x before W(x)2, hence this example is <i>causally consistent</i> under Hutto and Ahamad's definition (although not under Tanenbaum et al.'s, because W(x)2 and W(x)3 are not seen in the same order for all processes). However R(x)2 and R(x)3 happen in a different order on P3 and P4, hence this example is <i>sequentially inconsistent</i>.<a class="footnote-ref" id="fnref:14" href="#fn:14"><sup>14</sup></a> </p> <h3>Processor consistency</h3> <p>In order for consistency in data to be maintained and to attain scalable processor systems where every processor has its own memory, the <a href="/facts/Processor_consistency/NyfQ3Cfk">processor consistency</a> model was derived.<a class="footnote-ref" id="fnref:15" href="#fn:15"><sup>15</sup></a> All processors need to be consistent in the order in which they see writes done by one processor and in the way they see writes by different processors to the same location (coherence is maintained). However, they do not need to be consistent when the writes are by different processors to different locations. </p><p>Every write operation can be divided into several sub-writes to all memories. A read from one such memory can happen before the write to this memory completes. Therefore, the data read can be stale. Thus, a processor under PC can execute a younger load when an older store needs to be stalled. Read before write, read after read and write before write ordering is still preserved in this model. </p><p>The processor consistency model<a class="footnote-ref" id="fnref:16" href="#fn:16"><sup>16</sup></a> is similar to the <a href="/facts/PRAM_consistency/wPdGFIWH">PRAM consistency</a> 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. Processor consistency is weaker than sequential consistency but stronger than the PRAM consistency model. </p><p>The <a href="/facts/Stanford_DASH/heeBY2cT">Stanford DASH multiprocessor system</a> implements a variation of processor consistency which is incomparable (neither weaker nor stronger) to Goodman's definitions.<a class="footnote-ref" id="fnref:17" href="#fn:17"><sup>17</sup></a> All processors need to be consistent in the order in which they see writes by one processor and in the way they see writes by different processors to the same location. However, they do not need to be consistent when the writes are by different processors to different locations. </p> <h3>Pipelined RAM consistency, or FIFO consistency</h3> <p><a href="/facts/PRAM_consistency/wPdGFIWH">Pipelined RAM consistency</a> (PRAM consistency) was presented by Lipton and Sandberg in 1988<a class="footnote-ref" id="fnref:18" href="#fn:18"><sup>18</sup></a> as one of the first described consistency models. Due to its informal definition, there are in fact at least two subtly different implementations,<a class="footnote-ref" id="fnref:19" href="#fn:19"><sup>19</sup></a> one by Ahamad et al. and one by Mosberger. </p><p>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. PRAM relaxes the need to maintain coherence to a location across all its processors. Here, reads to any variable can be executed before writes in a processor. Read before write, read after read and write before write ordering is still preserved in this model. </p> <table><tbody><tr><th>Sequence</th><th>P1</th><th>P2</th><th>P3</th><th>P4</th></tr><tr><th>1</th><td>W(x)1</td><td></td><td></td><td></td></tr><tr><th>2</th><td></td><td>R(x)1</td><td></td><td></td></tr><tr><th>3</th><td></td><td>W(x)2</td><td></td><td></td></tr><tr><th>4</th><td></td><td></td><td>R(x)1</td><td>R(x)2</td></tr><tr><th>5</th><td></td><td></td><td>R(x)2</td><td>R(x)1</td></tr></tbody></table> <h3>Cache consistency</h3> <p>Cache consistency<a class="footnote-ref" id="fnref:20" href="#fn:20"><sup>20</sup></a><a class="footnote-ref" id="fnref:21" href="#fn:21"><sup>21</sup></a> requires that all write operations to the same memory location are performed in some sequential order. Cache consistency is weaker than processor consistency and incomparable with PRAM consistency. </p> <h3>Slow consistency</h3> <p>In slow consistency,<a class="footnote-ref" id="fnref:22" href="#fn:22"><sup>22</sup></a> 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. </p><p>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. </p><p>Hutto, Phillip W., and Mustaque Ahamad (1990)<a class="footnote-ref" id="fnref:23" href="#fn:23"><sup>23</sup></a> 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. </p> <h2 id="session-guarantees">Session guarantees</h2> <p>These 4 consistency models were proposed in a 1994 paper. They focus on guarantees in the situation where only a single user or application is making data modifications.<a class="footnote-ref" id="fnref:24" href="#fn:24"><sup>24</sup></a> </p> <h3>Monotonic read consistency</h3> <p>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.<a class="footnote-ref" id="fnref:25" href="#fn:25"><sup>25</sup></a> </p> <h3>Monotonic write consistency</h3> <p>A write operation by a process on a data item X is completed before any successive write operation on X by the same process.<a class="footnote-ref" id="fnref:26" href="#fn:26"><sup>26</sup></a> </p> <h3>Read-your-writes consistency</h3> <p>A value written by a process on a data item X will always be available to a successive read operation performed by the same process on data item X.<a class="footnote-ref" id="fnref:27" href="#fn:27"><sup>27</sup></a> </p> <h3>Writes-follows-reads consistency</h3> <p>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.<a class="footnote-ref" id="fnref:28" href="#fn:28"><sup>28</sup></a> </p> <h2 id="weak-memory-consistency-models">Weak memory consistency models</h2> <p>The following models require specific synchronization by programmers. </p> <h3>Weak ordering</h3> <p>Weak ordering classifies memory operations into two categories: <i>data operations</i> and <i>synchronization operations</i>. To enforce program order, a programmer needs to find at least one synchronisation operation in a program. Synchronization operations signal the processor to make sure it has completed and seen all previous operations done by all processors. Program order and atomicity is maintained only on synchronisation operations and not on all reads and writes. This was derived from the understanding that certain memory operations – such as those conducted in a critical section - need not be seen by all processors until after all operations in the critical section are completed. It assumes reordering memory operations to data regions between synchronisation operations does not affect the outcome of the program. This exploits the fact that programs written to be executed on a multi-processor system contain the required synchronization to make sure that data races do not occur and SC outcomes are produced always.<a class="footnote-ref" id="fnref:29" href="#fn:29"><sup>29</sup></a> </p> <table><tbody><tr><th>P1</th><th>P2</th></tr><tr><td>X = 1;<i>fence</i> xready = 1;</td><td><i>fence</i>while (!xready) {}; <i>fence</i> y = 2;</td></tr></tbody></table> <p>Coherence is not relaxed in this model. Once these requirements are met, all other "data" operations can be reordered. The way this works is that a counter tracks the number of data operations and until this counter becomes zero, the synchronisation operation isn't issued. Furthermore, no more data operations are issued unless all the previous synchronisations are completed. Memory operations in between two synchronisation variables can be overlapped and reordered without affecting the correctness of the program. This model ensures that write atomicity is always maintained, therefore no additional safety net is required for weak ordering. </p><p>In order to maintain weak ordering, write operations prior to a synchronization operation must be globally performed before the synchronization operation. Operations present after a synchronization operation should also be performed only after the synchronization operation completes. Therefore, accesses to synchronization variables is sequentially consistent and any read or write should be performed only after previous synchronization operations have completed. </p><p>There is high reliance on explicit synchronization in the program. For weak ordering models, the programmer must use atomic locking instructions such as test-and-set, fetch-and-op, store conditional, load linked or must label synchronization variables or use fences. </p> <h3>Release consistency</h3> <p>The <a href="/facts/Release_consistency/XLPMbgdH">release consistency</a> model relaxes the weak consistency model by distinguishing the entrance synchronization operation from the exit synchronization operation. Under weak ordering, when a synchronization operation is to be seen, all operations in all processors need to be visible before the synchronization operation is done and the processor proceeds. However, under the release consistency model, during the entry to a critical section, termed as "acquire", all operations with respect to the local memory variables need to be completed. During the exit, termed as "release", all changes made by the local processor should be propagated to all other processors. Coherence is still maintained. </p><p>The acquire operation is a load/read that is performed to access the critical section. A release operation is a store/write performed to allow other processors to use the shared variables. </p><p>Among synchronization variables, sequential consistency or processor consistency can be maintained. Using SC, all competing synchronization variables should be processed in order. However, with PC, a pair of competing variables need to only follow this order. Younger acquires can be allowed to happen before older releases. </p> <h4>RCsc and RCpc</h4> <p>There are two types of release consistency, release consistency with sequential consistency (RCsc) and release consistency with processor consistency (RCpc). The latter type denotes which type of consistency is applied to those operations nominated below as special. </p><p>There are special (cf. ordinary) memory operations, themselves consisting of two classes of operations: <i>sync</i> or <i>nsync</i> operations. The latter are operations not used for synchronisation; the former are, and consist of <i>acquire</i> and <i>release</i> operations. An acquire is effectively a read memory operation used to obtain access to a certain set of shared locations. Release, on the other hand, is a write operation that is performed for granting permission to access the shared locations. </p><p>For sequential consistency (RCsc), the constraints are: </p> <ul><li>acquire → all,</li> <li>all → release,</li> <li>special → special.</li></ul> <p>For processor consistency (RCpc) the write to read program order is relaxed, having constraints: </p> <ul><li>acquire → all,</li> <li>all → release,</li> <li>special → special (except when special write is followed by special read).</li></ul> <p>Note: the above notation A → B, implies that if the operation A precedes B in the program order, then program order is enforced. </p> <h3>Entry consistency</h3> <p>This is a variant of the release consistency model. It also requires the use of <i>acquire</i> and <i>release</i> 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 the 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. </p> <h3>Local consistency</h3> <p>In local consistency,<a class="footnote-ref" id="fnref:30" href="#fn:30"><sup>30</sup></a> 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. </p> <h3>General consistency</h3> <p>In general consistency,<a class="footnote-ref" id="fnref:31" href="#fn:31"><sup>31</sup></a> all the copies of a memory location are eventually identical after all processes' writes are completed. </p> <h3>Eventual consistency</h3> <p>An <a href="/facts/Eventual_consistency/Un19vCr0">eventual consistency</a><a class="footnote-ref" id="fnref:32" href="#fn:32"><sup>32</sup></a> is a weak consistency model in a system with the lack of simultaneous updates. It defines that if no update takes a very long time, all replicas eventually become consistent. </p><p>Most shared decentralized databases have an eventual consistency model, either BASE: basically available; soft state; eventually consistent, or a combination of <a href="/facts/ACID_(computer_science)/XdHkYzHN">ACID</a> and BASE sometimes called SALT: sequential; agreed; ledgered; tamper-resistant, and also symmetric; admin-free; ledgered; and time-consensual.<a class="footnote-ref" id="fnref:33" href="#fn:33"><sup>33</sup></a><a class="footnote-ref" id="fnref:34" href="#fn:34"><sup>34</sup></a><a class="footnote-ref" id="fnref:35" href="#fn:35"><sup>35</sup></a> </p> <h2 id="relaxed-memory-consistency-models">Relaxed memory consistency models</h2> <p>Some different consistency models can be defined by relaxing one or more requirements in <a href="/facts/Sequential_consistency/LlMBzcTH">sequential consistency</a> called relaxed consistency models.<a class="footnote-ref" id="fnref:36" href="#fn:36"><sup>36</sup></a> 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. The above models are classified based on four criteria and are detailed further. </p><p>There are four comparisons to define the relaxed consistency: </p> Relaxation One way to categorize the relaxed consistency is to define which sequential consistency requirements are relaxed. We can have less strict models by relaxing either program order or write atomicity requirements defined by Adve and Gharachorloo, 1996.<a class="footnote-ref" id="fnref:37" href="#fn:37"><sup>37</sup></a> Program order guarantees that each process issues a memory request ordered by its program and write atomicity defines that memory requests are serviced based on the order of a single FIFO queue. In relaxing program order, any or all the ordering of operation pairs, write-after-write, read-after-write, or read/write-after-read, can be relaxed. In the relaxed write atomicity model, a process can view its own writes before any other processors. Synchronizing vs. non-synchronizing A synchronizing model can be defined by dividing the memory accesses into two groups and assigning different consistency restrictions to each group considering that one group can have a weak consistency model while the other one needs a more restrictive consistency model. In contrast, a non-synchronizing model assigns the same consistency model to the memory access types. Issue vs. view-based <a class="footnote-ref" id="fnref:38" href="#fn:38"><sup>38</sup></a> Issue method provides sequential consistency simulation by defining the restrictions for processes to issue memory operations. Whereas, view method describes the visibility restrictions on the events order for processes. Relative model strength Some consistency models are more restrictive than others. In other words, strict consistency models enforce more constraints as consistency requirements. The strength of a model can be defined by the program order or atomicity relaxations and the strength of models can also be compared. Some models are directly related if they apply the same relaxations or more. On the other hand, the models that relax different requirements are not directly related. <p>Sequential consistency has two requirements, program order and write atomicity. Different relaxed consistency models can be obtained by relaxing these requirements. This is done so that, along with relaxed constraints, the performance increases, but the programmer is responsible for implementing the memory consistency by applying synchronisation techniques and must have a good understanding of the hardware. </p><p>Potential relaxations: </p> <ul><li>Write to read program order</li> <li>Write to write program order</li> <li>Read to read and read to write program orders</li></ul> <h3>Relaxed write to read</h3> <p>An approach to improving the performance at the hardware level is by relaxing the PO of a write followed by a read which effectively hides the latency of write operations. The optimisation this type of relaxation relies on is that it allows the subsequent reads to be in a relaxed order with respect to the previous writes from the processor. Because of this relaxation some programs like XXX may fail to give SC results because of this relaxation. Whereas, programs like YYY are still expected to give consistent results because of the enforcement of the remaining program order constraints. </p><p>Three models fall under this category. The IBM 370 model is the strictest model. A read can be complete before an earlier write to a different address, but it is prohibited from returning the value of the write unless all the processors have seen the write. The SPARC V8 total store ordering model (TSO) model partially relaxes the IBM 370 Model, it allows a read to return the value of its own processor's write with respect to other writes to the same location i.e. it returns the value of its own write before others see it. Similar to the previous model, this cannot return the value of write unless all the processors have seen the write. The processor consistency model (PC) is the most relaxed of the three models and relaxes both the constraints such that a read can complete before an earlier write even before it is made visible to other processors. </p><p>In Example A, the result is possible only in IBM 370 because read(A) is not issued until the write(A) in that processor is completed. On the other hand, this result is possible in TSO and PC because they allow the reads of the flags before the writes of the flags in a single processor. </p><p>In Example B the result is possible only with PC as it allows P2 to return the value of a write even before it is visible to P3. This won't be possible in the other two models. </p><p>To ensure sequential consistency in the above models, safety nets or fences are used to manually enforce the constraint. The IBM370 model has some specialised <i>serialisation instructions</i> which are manually placed between operations. These instructions can consist of memory instructions or non-memory instructions such as branches. On the other hand, the TSO and PC models do not provide safety nets, but the programmers can still use read-modify-write operations to make it appear like the program order is still maintained between a write and a following read. In case of TSO, PO appears to be maintained if the R or W which is already a part of a R-modify-W is replaced by a R-modify-W, this requires the W in the R-modify-W is a ‘dummy’ that returns the read value. Similarly for PC, PO seems to be maintained if the read is replaced by a write or is already a part of R-modify-W. </p><p>However, compiler optimisations cannot be done after exercising this relaxation alone. Compiler optimisations require the full flexibility of reordering any two operations in the PO, so the ability to reorder a write with respect to a read is not sufficiently helpful in this case. </p> Example A<table><tbody><tr><th>P1</th><th>P2</th></tr><tr><td colspan="2">A = flag1 = flag2 = 0</td></tr><tr><td>flag1 = 1</td><td>flag2 = 1</td></tr><tr><td>A = 1</td><td>A = 2</td></tr><tr><td>reg1 = A</td><td>reg3 = A</td></tr><tr><td>reg2 = flag2</td><td>reg4 = flag1</td></tr><tr><td colspan="2">reg1 = 1; reg3 = 2, reg2 = reg4 = 0</td></tr></tbody></table> Example B<table><tbody><tr><th>P1</th><th>P2</th><th>P3</th></tr><tr><td colspan="3">A = B = 0</td></tr><tr><td>A = 1</td><td></td><td></td></tr><tr><td></td><td>if (A == 1)</td><td></td></tr><tr><td></td><td>B = 1</td><td>if (B == 1)</td></tr><tr><td></td><td></td><td>reg1 = A</td></tr><tr><td colspan="3">B = 1, reg1 = 0</td></tr></tbody></table> <h3>Relaxed write to read and write to write</h3> <p>Some models relax the program order even further by relaxing even the ordering constraints between writes to different locations. The SPARC V8 partial store ordering model (PSO) is the only example of such a model. The ability to pipeline and overlap writes to different locations from the same processor is the key hardware optimisation enabled by PSO. PSO is similar to TSO in terms of atomicity requirements, in that it allows a processor to read the value of its own write and prevents other processors from reading another processor's write before the write is visible to all other processors. Program order between two writes is maintained by PSO using an explicit STBAR instruction. The STBAR is inserted in a write buffer in implementations with FIFO write buffers. A counter is used to determine when all the writes before the STBAR instruction have been completed, which triggers a write to the memory system to increment the counter. A write acknowledgement decrements the counter, and when the counter becomes 0, it signifies that all the previous writes are completed. </p><p>In the examples A and B, PSO allows both these non-sequentially consistent results. The safety net that PSO provides is similar to TSO's, it imposes program order from a write to a read and enforces write atomicity. </p><p>Similar to the previous models, the relaxations allowed by PSO are not sufficiently flexible to be useful for compiler optimisation, which requires a much more flexible optimisation. </p> <h3>Relaxing read and read to write program orders: Alpha, RMO, and PowerPC</h3> <p>In some models, all operations to different locations are relaxed. A read or write may be reordered with respect to a different read or write in a different location. The <i>weak ordering</i> may be classified under this category and two types of release consistency models (RCsc and RCpc) also come under this model. Three commercial architectures are also proposed under this category of relaxation: the Digital Alpha, SPARC V9 relaxed memory order (RMO), and IBM PowerPC models. </p><p>These three commercial architectures exhibit explicit fence instructions as their safety nets. The Alpha model provides two types of fence instructions, <i>memory barrier</i> (MB) and <i>write memory barrier</i> (WMB). The MB operation can be used to maintain program order of any memory operation before the MB with a memory operation after the barrier. Similarly, the WMB maintains program order only among writes. The SPARC V9 RMO model provides a MEMBAR instruction which can be customised to order previous reads and writes with respect to future read and write operations. There is no need for using read-modify-writes to achieve this order because the MEMBAR instruction can be used to order a write with respect to a succeeding read. The PowerPC model uses a single fence instruction called the SYNC instruction. It is similar to the MB instruction, but with a little exception that reads can occur out of program order even if a SYNC is placed between two reads to the same location. This model also differs from Alpha and RMO in terms of atomicity. It allows a write to be seen earlier than a read's completion. A combination of read modify write operations may be required to make an illusion of write atomicity. </p><p>RMO and PowerPC allow reordering of reads to the same location. These models violate sequential order in examples A and B. An additional relaxation allowed in these models is that memory operations following a read operation can be overlapped and reordered with respect to the read. Alpha and RMO allow a read to return the value of another processor's early write. From a programmer's perspective these models must maintain the illusion of write atomicity even though they allow the processor to read its own write early. </p> <h2 id="transactional-memory-models">Transactional memory models</h2> <p>Transactional memory model<a class="footnote-ref" id="fnref:39" href="#fn:39"><sup>39</sup></a> 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 higher performance than a sequential consistency model. </p> <h2 id="other-consistency-models">Other consistency models</h2> <p>Some other consistency models are as follows: </p> <ul><li>Causal+ consistency<a class="footnote-ref" id="fnref:40" href="#fn:40"><sup>40</sup></a><a class="footnote-ref" id="fnref:41" href="#fn:41"><sup>41</sup></a></li> <li>Cross-Client Monotonicity<a class="footnote-ref" id="fnref:42" href="#fn:42"><sup>42</sup></a></li> <li><a href="/facts/Delta_consistency/93FNf3eb">Delta consistency</a></li> <li>Fork consistency</li> <li><a href="/facts/One-copy_serializability/j6LY0fqE">One-copy serializability</a></li> <li><a href="/facts/Serializability/j6LY0fqE">Serializability</a></li> <li><a href="/facts/Vector-field_consistency/JomUXtXK">Vector-field consistency</a></li> <li><a href="/facts/Weak_consistency/2C1v50Vo">Weak consistency</a></li> <li><a href="/facts/Strong_consistency/4cbcSQGc">Strong consistency</a></li></ul> <p>Several other consistency models have been conceived to express restrictions with respect to ordering or visibility of operations, or to deal with specific fault assumptions.<a class="footnote-ref" id="fnref:43" href="#fn:43"><sup>43</sup></a> </p> <h2 id="consistency-and-replication">Consistency and replication</h2> <p>Tanenbaum et al., 2007<a class="footnote-ref" id="fnref:44" href="#fn:44"><sup>44</sup></a> 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<a class="footnote-ref" id="fnref:45" href="#fn:45"><sup>45</sup></a> 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. </p> <h3>Data-centric consistency models</h3> <p>Tanenbaum et al., 2007<a class="footnote-ref" id="fnref:46" href="#fn:46"><sup>46</sup></a> 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 among writes is difficult, some restrictions can be applied on the values that can be returned by a read operation. The goal of data-centric consistency models is to provide a consistent view on a data store where processes may carry out concurrent updates. </p> <h4>Consistent ordering of operations</h4> <p>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 these models, all replicas must agree on a consistent global ordering of updates. </p> <h5>Grouping operations</h5> <p>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.<a class="footnote-ref" id="fnref:47" href="#fn:47"><sup>47</sup></a> </p> <h3>Client-centric consistency models</h3> <p>In distributed systems, maintaining <a href="/facts/Sequential_consistency/LlMBzcTH">sequential consistency</a> 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:<a class="footnote-ref" id="fnref:48" href="#fn:48"><sup>48</sup></a> </p> <h3>Consistency protocols</h3> <p>The implementation of a consistency model is defined by a consistency protocol. Tanenbaum et al., 2007<a class="footnote-ref" id="fnref:49" href="#fn:49"><sup>49</sup></a> illustrates some consistency protocols for data-centric models. </p> <h4>Continuous consistency</h4> <p>Continuous consistency introduced by Yu and Vahdat (2000).<a class="footnote-ref" id="fnref:50" href="#fn:50"><sup>50</sup></a> In this model, the consistency semantics 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)<a class="footnote-ref" id="fnref:51" href="#fn:51"><sup>51</sup></a> believe that a predefined uniform consistency model may not be an appropriate approach. The application should specify the consistency requirements that satisfy the application semantics. In this model, an application specifies each consistency requirement as a conit (abbreviation of consistency units). A conit can be a physical or logical consistency and is used to measure the consistency. Tanenbaum et al., 2007<a class="footnote-ref" id="fnref:52" href="#fn:52"><sup>52</sup></a> describes the notion of a conit by giving an example. </p><p>There are three inconsistencies that can be tolerated by applications. </p> Deviation in numerical values <a class="footnote-ref" id="fnref:53" href="#fn:53"><sup>53</sup></a> Numerical deviation bounds the difference between the conit value and the relative value of the last update. A weight can be assigned to the writes which defines the importance of the writes in a specific application. The total weights of unseen writes for a conit can be defined as a numerical deviation in an application. There are two different types of numerical deviation; absolute and relative numerical deviation. Deviation in ordering <a class="footnote-ref" id="fnref:54" href="#fn:54"><sup>54</sup></a> Ordering deviation is the discrepancy between the local order of writes in a replica and their relative ordering in the eventual final image. Deviation in staleness between replicas <a class="footnote-ref" id="fnref:55" href="#fn:55"><sup>55</sup></a> Staleness deviation defines the validity of the oldest write by bounding the difference between the current time and the time of the oldest write on a conit not seen locally. Each server has a local queue of uncertain write that is required an actual order to be determined and applied on a conit. The maximal length of uncertain writes queue is the bound of ordering deviation. When the number of writes exceeds the limit, instead of accepting new submitted write, the server will attempt to commit uncertain writes by communicating with other servers based on the order that writes should be executed. <p>If all three deviation bounds are set to zero, the continuous consistency model is the strong consistency. </p> <h4>Primary-based protocols</h4> <p>Primary-based protocols<a class="footnote-ref" id="fnref:56" href="#fn:56"><sup>56</sup></a> 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. </p> <h5>Remote-write protocols</h5> <p>In the simplest primary-based protocol that supports replication, also known as primary-backup protocol, write operations are forwarded to a single server and read operations can be performed locally. </p> Example: Tanenbaum et al., 2007<a class="footnote-ref" id="fnref:57" href="#fn:57"><sup>57</sup></a> 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 asking other backups to 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. <h5>Local-write protocols</h5> <p>In primary-based local-write protocols,<a class="footnote-ref" id="fnref:58" href="#fn:58"><sup>58</sup></a> 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. </p> <h4>Replicated-write protocols</h4> <p>In replicated-write protocols,<a class="footnote-ref" id="fnref:59" href="#fn:59"><sup>59</sup></a> unlike the primary-based protocol, all updates are carried out to all replicas. </p> <h5>Active replication</h5> <p>In active replication,<a class="footnote-ref" id="fnref:60" href="#fn:60"><sup>60</sup></a> there is a process associated with 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. </p> <h5>Quorum-based protocols</h5> <p>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.<a class="footnote-ref" id="fnref:61" href="#fn:61"><sup>61</sup></a> </p> <h5>Cache-coherence protocols</h5> <p>In a replicated file system, a cache-coherence protocol<a class="footnote-ref" id="fnref:62" href="#fn:62"><sup>62</sup></a> 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. </p><p>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. </p><p>The coherence enforcement strategy is another cache-coherence protocol. It defines <i>how</i> 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 is cached, there are two approaches in order to enforce the cache coherence. </p><p>In the first approach, when a shared data is updated, the server forwards invalidation to all caches. In the second approach, an update is propagated. Most caching systems apply these two approaches or dynamically choose between them. </p> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/Cache_coherence/MhUD576q">Cache coherence</a> – Equivalence of all cached copies of a memory location</li> <li><a href="/facts/Distributed_shared_memory/IboHJvt6">Distributed shared memory</a> – software and hardware implementations in which each cluster node accesses a large shared memoryPages displaying wikidata descriptions as a fallback</li> <li><a href="/facts/Non-uniform_memory_access/MpmN5mN0">Non-uniform memory access</a> – Computer memory design used in multiprocessing</li></ul> <h2 id="further-reading">Further reading</h2> <ul><li>Paolo Viotti; Marko Vukolic (2016). "Consistency in Non-Transactional Distributed Storage Systems". <i>ACM Computing Surveys</i>. 49 (1): 19:1–19:34. <a href="/facts/ArXiv_(identifier)/H6EtgnBe">arXiv</a>:<a href="https://arxiv.org/abs/1512.00168">1512.00168</a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1145%2F2926965">10.1145/2926965</a>. <a href="/facts/S2CID_(identifier)/ldJsHa2Y">S2CID</a> <a href="https://api.semanticscholar.org/CorpusID:118557">118557</a>.</li> <li>Sezgin, Ali (August 2004). <a href="https://users.cs.utah.edu/~ganesh/unpublished/sezgin_phd_04.pdf"><i>Formalization and Verification of Shared Memory</i></a> (PDF) (PhD thesis). The University of Utah. Retrieved June 27, 2024. (contains many valuable references)</li> <li>Yelick, Katherine; Bonachea, Dan; Wallace, Charles (2004), <a href="https://web.archive.org/web/20050520185509/http://www.gwu.edu/%7Eupc/downloads/upcmem.pdf"><i>A Proposal for a UPC Memory Consistency Model, v1.0</i></a> (PDF), Lawrence Berkeley National Lab Tech Report, <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.2172%2F823757">10.2172/823757</a>, LBNL-54983, archived from <a href="http://www.gwu.edu/~upc/downloads/upcmem.pdf">the original</a> (PDF) on 20 May 2005</li> <li>Mosberger, David (1993). <a href="http://citeseer.ist.psu.edu/mosberger93memory.html">"Memory Consistency Models"</a>. <i>Operating Systems Review</i>. 27 (1): 18–26. <a href="/facts/CiteSeerX_(identifier)/SceDmd3c">CiteSeerX</a> <a href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.331.2924">10.1.1.331.2924</a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1145%2F160551.160553">10.1145/160551.160553</a>. <a href="/facts/S2CID_(identifier)/ldJsHa2Y">S2CID</a> <a href="https://api.semanticscholar.org/CorpusID:16123648">16123648</a>.</li> <li>Sarita V. Adve; Kourosh Gharachorloo (December 1996). <a href="https://web.archive.org/web/20080907125534/http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf">"Shared Memory Consistency Models: A Tutorial"</a> (PDF). <i>IEEE Computer</i>. 29 (12): 66–76. <a href="/facts/CiteSeerX_(identifier)/SceDmd3c">CiteSeerX</a> <a href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.8566">10.1.1.36.8566</a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1109%2F2.546611">10.1109/2.546611</a>. Archived from <a href="http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf">the original</a> (PDF) on 2008-09-07. Retrieved 2008-05-28.</li> <li>Steinke, Robert C.; Gary J. Nutt (2004). "A unified theory of shared memory consistency". <i>Journal of the ACM</i>. 51 (5): 800–849. <a href="/facts/ArXiv_(identifier)/H6EtgnBe">arXiv</a>:<a href="https://arxiv.org/abs/cs.DC/0208027">cs.DC/0208027</a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1145%2F1017460.1017464">10.1145/1017460.1017464</a>. <a href="/facts/S2CID_(identifier)/ldJsHa2Y">S2CID</a> <a href="https://api.semanticscholar.org/CorpusID:3206071">3206071</a>.</li> <li>Terry, Doug. "Replicated data consistency explained through baseball." Communications of the ACM 56.12 (2013): 82-89. <a href="https://www.microsoft.com/en-us/research/wp-content/uploads/2011/10/ConsistencyAndBaseballReport.pdf">https://www.microsoft.com/en-us/research/wp-content/uploads/2011/10/ConsistencyAndBaseballReport.pdf</a></li></ul> <h2 id="external-links">External links</h2> <ul><li><a href="http://www.ietf.org/old/2009/proceedings/01mar/slides/webi-1/sld006.htm">IETF slides</a></li> <li><a href="http://www.linuxjournal.com/article/8211">Memory Ordering in Modern Microprocessors, Part I</a> and <a href="http://www.linuxjournal.com/article/8212">Part II</a>, by Paul E. McKenney (2005). <i><a href="/facts/Linux_Journal/m7rosgex">Linux Journal</a></i></li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>Mark D. Hill (August 1998). "Multiprocessors Should Support Simple Memory Consistency Models". IEEE Computer. 31 (8): 28–34. doi:10.1109/2.707614. <a href="http://digital.library.wisc.edu/1793/8706" target="_blank">http://digital.library.wisc.edu/1793/8706</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>Todd Lipcon (2014-10-25). "Design Patterns for Distributed Non-Relational Databases" (PDF). Archived from the original (PDF) on 2014-11-03. 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 <a href="https://web.archive.org/web/20141103164710/http://cloudera-todd.s3.amazonaws.com/nosql.pdf" target="_blank">https://web.archive.org/web/20141103164710/http://cloudera-todd.s3.amazonaws.com/nosql.pdf</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>Todd Lipcon (2014-10-25). "Design Patterns for Distributed Non-Relational Databases" (PDF). Archived from the original (PDF) on 2014-11-03. 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 <a href="https://web.archive.org/web/20141103164710/http://cloudera-todd.s3.amazonaws.com/nosql.pdf" target="_blank">https://web.archive.org/web/20141103164710/http://cloudera-todd.s3.amazonaws.com/nosql.pdf</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>Lamport, Leslie (Sep 1979). "How to make a multiprocessor computer that correctly executes multiprocess programs". IEEE Transactions on Computers. C-28 (9): 690–691. doi:10.1109/TC.1979.1675439. S2CID 5679366. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>Lamport, Leslie (Sep 1979). "How to make a multiprocessor computer that correctly executes multiprocess programs". IEEE Transactions on Computers. C-28 (9): 690–691. doi:10.1109/TC.1979.1675439. S2CID 5679366. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>Sarita V. Adve; Kourosh Gharachorloo (December 1996). "Shared Memory Consistency Models: A Tutorial" (PDF). IEEE Computer. 29 (12): 66–76. CiteSeerX 10.1.1.36.8566. doi:10.1109/2.546611. Archived from the original (PDF) on 2008-09-07. Retrieved 2008-05-28. <a href="https://web.archive.org/web/20080907125534/http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf" target="_blank">https://web.archive.org/web/20080907125534/http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>Herlihy, Maurice P.; 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. CiteSeerX 10.1.1.142.5315. doi:10.1145/78969.78972. S2CID 228785. <a href="/wiki/CiteSeerX_(identifier)" target="_blank">/wiki/CiteSeerX_(identifier)</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> <li id="fn:9"><p>Mankin, Jenny (2007), CSG280: Parallel Computing Memory Consistency Models: A Survey in Past and Present Research <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li> <li id="fn:10"><p>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. arXiv:cs/0108016. doi:10.1109/TPDS.2003.1225053. S2CID 1641693. <a href="/wiki/ArXiv_(identifier)" target="_blank">/wiki/ArXiv_(identifier)</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li> <li id="fn:11"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li> <li id="fn:12"><p>Hutto, Phillip W.; Mustaque Ahamad (1990). "Slow memory: Weakening consistency to enhance concurrency in distributed shared memories". Proceedings.,10th International Conference on Distributed Computing Systems. IEEE. pp. 302–309. doi:10.1109/ICDCS.1990.89297. ISBN 978-0-8186-2048-5. S2CID 798676. <a href="978-0-8186-2048-5" target="_blank">978-0-8186-2048-5</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></p></li> <li id="fn:13"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:13" class="footnote-back-ref">↩</a></p></li> <li id="fn:14"><p>"Memory Consistency Models" (PDF). Archived from the original (PDF) on 2016-03-03. Retrieved 2016-11-17. <a href="https://web.archive.org/web/20160303220106/https://www-vs.informatik.uni-ulm.de/teach/ss05/dsm/arizona.pdf" target="_blank">https://web.archive.org/web/20160303220106/https://www-vs.informatik.uni-ulm.de/teach/ss05/dsm/arizona.pdf</a> <a href="#fnref:14" class="footnote-back-ref">↩</a></p></li> <li id="fn:15"><p>"Memory Consistency Models" (PDF). Archived from the original (PDF) on 2016-03-03. Retrieved 2016-11-17. <a href="https://web.archive.org/web/20160303220106/https://www-vs.informatik.uni-ulm.de/teach/ss05/dsm/arizona.pdf" target="_blank">https://web.archive.org/web/20160303220106/https://www-vs.informatik.uni-ulm.de/teach/ss05/dsm/arizona.pdf</a> <a href="#fnref:15" class="footnote-back-ref">↩</a></p></li> <li id="fn:16"><p>Goodman, James R (1991). "Cache consistency and sequential consistency". IEEE Scalable Coherent Interface (SCI) Working Group. <a href="#fnref:16" class="footnote-back-ref">↩</a></p></li> <li id="fn:17"><p>Senftleben, Maximilian (2013). Operational Characterization of Weak Memory Consistency Models (PDF) (M.Sc. thesis). University of Kaiserslautern. <a href="https://es.cs.uni-kl.de/publications/datarsg/Senf13.pdf" target="_blank">https://es.cs.uni-kl.de/publications/datarsg/Senf13.pdf</a> <a href="#fnref:17" class="footnote-back-ref">↩</a></p></li> <li id="fn:18"><p>Lipton, R.J.; J.S. Sandberg. (1988). PRAM: A scalable shared memory (Technical report). Princeton University. CS-TR-180-88. <a href="#fnref:18" class="footnote-back-ref">↩</a></p></li> <li id="fn:19"><p>Senftleben, Maximilian (2013). Operational Characterization of Weak Memory Consistency Models (PDF) (M.Sc. thesis). University of Kaiserslautern. <a href="https://es.cs.uni-kl.de/publications/datarsg/Senf13.pdf" target="_blank">https://es.cs.uni-kl.de/publications/datarsg/Senf13.pdf</a> <a href="#fnref:19" class="footnote-back-ref">↩</a></p></li> <li id="fn:20"><p>Goodman, James R (1991). "Cache consistency and sequential consistency". IEEE Scalable Coherent Interface (SCI) Working Group. <a href="#fnref:20" class="footnote-back-ref">↩</a></p></li> <li id="fn:21"><p>Steinke, Robert C.; Gary J. Nutt (2004). "A unified theory of shared memory consistency". Journal of the ACM. 51 (5): 800–849. arXiv:cs/0208027. doi:10.1145/1017460.1017464. S2CID 3206071. <a href="/wiki/ArXiv_(identifier)" target="_blank">/wiki/ArXiv_(identifier)</a> <a href="#fnref:21" class="footnote-back-ref">↩</a></p></li> <li id="fn:22"><p>Steinke, Robert C.; Gary J. Nutt (2004). "A unified theory of shared memory consistency". Journal of the ACM. 51 (5): 800–849. arXiv:cs/0208027. doi:10.1145/1017460.1017464. S2CID 3206071. <a href="/wiki/ArXiv_(identifier)" target="_blank">/wiki/ArXiv_(identifier)</a> <a href="#fnref:22" class="footnote-back-ref">↩</a></p></li> <li id="fn:23"><p>Hutto, Phillip W.; Mustaque Ahamad (1990). "Slow memory: Weakening consistency to enhance concurrency in distributed shared memories". Proceedings.,10th International Conference on Distributed Computing Systems. IEEE. pp. 302–309. doi:10.1109/ICDCS.1990.89297. ISBN 978-0-8186-2048-5. S2CID 798676. <a href="978-0-8186-2048-5" target="_blank">978-0-8186-2048-5</a> <a href="#fnref:23" class="footnote-back-ref">↩</a></p></li> <li id="fn:24"><p>Terry, Douglas B.; Demers, Alan J.; Petersen, Karin; Spreitzer, Mike J.; Theimer, Marvin M.; Welch, Brent B. (1 October 1994). "Session guarantees for weakly consistent replicated data". Proceedings of 3rd International Conference on Parallel and Distributed Information Systems. IEEE Computer Society Press. pp. 140–150. doi:10.1109/PDIS.1994.331722. ISBN 0-8186-6400-2. S2CID 2807044. <a href="0-8186-6400-2" target="_blank">0-8186-6400-2</a> <a href="#fnref:24" class="footnote-back-ref">↩</a></p></li> <li id="fn:25"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:25" class="footnote-back-ref">↩</a></p></li> <li id="fn:26"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:26" class="footnote-back-ref">↩</a></p></li> <li id="fn:27"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:27" class="footnote-back-ref">↩</a></p></li> <li id="fn:28"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:28" class="footnote-back-ref">↩</a></p></li> <li id="fn:29"><p>"Shared Memory Consistency Models : A tutorial" (PDF). Archived from the original (PDF) on 2008-09-07. Retrieved 2008-05-28. <a href="https://web.archive.org/web/20080907125534/http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf" target="_blank">https://web.archive.org/web/20080907125534/http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf</a> <a href="#fnref:29" class="footnote-back-ref">↩</a></p></li> <li id="fn:30"><p>Steinke, Robert C.; Gary J. Nutt (2004). "A unified theory of shared memory consistency". Journal of the ACM. 51 (5): 800–849. arXiv:cs/0208027. doi:10.1145/1017460.1017464. S2CID 3206071. <a href="/wiki/ArXiv_(identifier)" target="_blank">/wiki/ArXiv_(identifier)</a> <a href="#fnref:30" class="footnote-back-ref">↩</a></p></li> <li id="fn:31"><p>Singhal, Mukesh; Niranjan G. Shivaratri (1994). "Advanced concepts in operating systems". McGraw-Hill, Inc. <a href="https://archive.org/details/advancedconcepts0000sing" target="_blank">https://archive.org/details/advancedconcepts0000sing</a> <a href="#fnref:31" class="footnote-back-ref">↩</a></p></li> <li id="fn:32"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:32" class="footnote-back-ref">↩</a></p></li> <li id="fn:33"><p>Collin Cusce. "SALT: A Descriptive Model For Blockchain" Archived 2020-08-03 at the Wayback Machine. 2018. <a href="https://medium.com/@collin.cusce/blockchain-salt-a-descriptive-model-b19c973fef5f" target="_blank">https://medium.com/@collin.cusce/blockchain-salt-a-descriptive-model-b19c973fef5f</a> <a href="#fnref:33" class="footnote-back-ref">↩</a></p></li> <li id="fn:34"><p>Stefan Tai, Jacob Eberhardt, and Markus Klems. "Not ACID, not BASE, but SALT: A Transaction Processing Perspective on Blockchains". 2017. <a href="http://www.ise.tu-berlin.de/fileadmin/fg308/publications/2017/2017-tai-eberhardt-klems-SALT.pdf" target="_blank">http://www.ise.tu-berlin.de/fileadmin/fg308/publications/2017/2017-tai-eberhardt-klems-SALT.pdf</a> <a href="#fnref:34" class="footnote-back-ref">↩</a></p></li> <li id="fn:35"><p>Chao Xie, Chunzhi Su, Manos Kapritsos, Yang Wang, Navid Yaghmazadeh, Lorenzo Alvisi, Prince Mahajan. "Salt: Combining ACID and BASE in a Distributed Database". <a href="https://web.archive.org/web/20181019205538/https://pdfs.semanticscholar.org/d2ed/d36bc2ce58f26132980b5d609716d084c7b4.pdf" target="_blank">https://web.archive.org/web/20181019205538/https://pdfs.semanticscholar.org/d2ed/d36bc2ce58f26132980b5d609716d084c7b4.pdf</a> <a href="#fnref:35" class="footnote-back-ref">↩</a></p></li> <li id="fn:36"><p>Mankin, Jenny (2007), CSG280: Parallel Computing Memory Consistency Models: A Survey in Past and Present Research <a href="#fnref:36" class="footnote-back-ref">↩</a></p></li> <li id="fn:37"><p>Sarita V. Adve; Kourosh Gharachorloo (December 1996). "Shared Memory Consistency Models: A Tutorial" (PDF). IEEE Computer. 29 (12): 66–76. CiteSeerX 10.1.1.36.8566. doi:10.1109/2.546611. Archived from the original (PDF) on 2008-09-07. Retrieved 2008-05-28. <a href="https://web.archive.org/web/20080907125534/http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf" target="_blank">https://web.archive.org/web/20080907125534/http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf</a> <a href="#fnref:37" class="footnote-back-ref">↩</a></p></li> <li id="fn:38"><p>Steinke, Robert C.; Gary J. Nutt (2004). "A unified theory of shared memory consistency". Journal of the ACM. 51 (5): 800–849. arXiv:cs/0208027. doi:10.1145/1017460.1017464. S2CID 3206071. <a href="/wiki/ArXiv_(identifier)" target="_blank">/wiki/ArXiv_(identifier)</a> <a href="#fnref:38" class="footnote-back-ref">↩</a></p></li> <li id="fn:39"><p>Mankin, Jenny (2007), CSG280: Parallel Computing Memory Consistency Models: A Survey in Past and Present Research <a href="#fnref:39" class="footnote-back-ref">↩</a></p></li> <li id="fn:40"><p>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). <a href="https://www.cs.cmu.edu/~dga/papers/cops-sosp2011.pdf" target="_blank">https://www.cs.cmu.edu/~dga/papers/cops-sosp2011.pdf</a> <a href="#fnref:40" class="footnote-back-ref">↩</a></p></li> <li id="fn:41"><p>Almeida, Sérgio; Leitão, João; Rodrigues, Luís (2013). "ChainReaction: A causal+ consistent datastore based on chain replication". Proceedings of the 8th ACM European Conference on Computer Systems. pp. 85–98. doi:10.1145/2465351.2465361. ISBN 9781450319942. S2CID 651196. <a href="9781450319942" target="_blank">9781450319942</a> <a href="#fnref:41" class="footnote-back-ref">↩</a></p></li> <li id="fn:42"><p>Ganesan, Aishwarya; Alagappan, Ramnatthan; Arpaci-Dusseau, Andrea; Arpaci-Dusseau, Remzi (2020). "Strong and Efficient Consistency with Consistency-Aware Durability" (PDF). 18th USENIX Conference on File and Storage Technologies (FAST 20). <a href="https://www.usenix.org/system/files/fast20-ganesan.pdf" target="_blank">https://www.usenix.org/system/files/fast20-ganesan.pdf</a> <a href="#fnref:42" class="footnote-back-ref">↩</a></p></li> <li id="fn:43"><p>Paolo Viotti; Marko Vukolic (2016). "Consistency in Non-Transactional Distributed Storage Systems". ACM Computing Surveys. 49 (1): 19:1–19:34. arXiv:1512.00168. doi:10.1145/2926965. S2CID 118557. <a href="/wiki/ArXiv_(identifier)" target="_blank">/wiki/ArXiv_(identifier)</a> <a href="#fnref:43" class="footnote-back-ref">↩</a></p></li> <li id="fn:44"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:44" class="footnote-back-ref">↩</a></p></li> <li id="fn:45"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:45" class="footnote-back-ref">↩</a></p></li> <li id="fn:46"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:46" class="footnote-back-ref">↩</a></p></li> <li id="fn:47"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:47" class="footnote-back-ref">↩</a></p></li> <li id="fn:48"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:48" class="footnote-back-ref">↩</a></p></li> <li id="fn:49"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:49" class="footnote-back-ref">↩</a></p></li> <li id="fn:50"><p>Yu, Haifeng; 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. <a href="#fnref:50" class="footnote-back-ref">↩</a></p></li> <li id="fn:51"><p>Yu, Haifeng; 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. <a href="#fnref:51" class="footnote-back-ref">↩</a></p></li> <li id="fn:52"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:52" class="footnote-back-ref">↩</a></p></li> <li id="fn:53"><p>Yu, Haifeng; 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. <a href="#fnref:53" class="footnote-back-ref">↩</a></p></li> <li id="fn:54"><p>Yu, Haifeng; 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. <a href="#fnref:54" class="footnote-back-ref">↩</a></p></li> <li id="fn:55"><p>Yu, Haifeng; 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. <a href="#fnref:55" class="footnote-back-ref">↩</a></p></li> <li id="fn:56"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:56" class="footnote-back-ref">↩</a></p></li> <li id="fn:57"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:57" class="footnote-back-ref">↩</a></p></li> <li id="fn:58"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:58" class="footnote-back-ref">↩</a></p></li> <li id="fn:59"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:59" class="footnote-back-ref">↩</a></p></li> <li id="fn:60"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:60" class="footnote-back-ref">↩</a></p></li> <li id="fn:61"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:61" class="footnote-back-ref">↩</a></p></li> <li id="fn:62"><p>Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall. <a href="#fnref:62" class="footnote-back-ref">↩</a></p></li> </ol>