Processor consistency

In Example 1 to the right, the simple system follows Processor Consistency, as all the writes by each processor are seen in the order they occurred in by the other processors, and the transactions are coherent.

Example 2 is not Processor Consistent, as the writes by P1 and P3 are seen out of order by P2 and P4 respectively.

Example 3 is Processor Consistent and not Causally Consistent because R(y)3,R(x)1 in P3: for Causal Consistency it should be R(y)3,R(x)2 since W(x)2 in P1 causally precedes W(y)3 in P2.

Example 4 is not Processor Consistent because R(y)3,R(x)1 in P2: for Processor Consistency it should be R(y)3,R(x)2 because W(x)2 is the latest write to x preceding W(y)3 in P1.
This example Cache Consistent because P2 sees writes to individual memory locations in the order they were issued in P1.

Processor Consistency (PC) relaxes the ordering between older stores and younger loads that is enforced in Sequential consistency (SC).[2] This allows loads to be issued to the cache and potentially complete before older stores, meaning that stores can be queued in a write buffer without the need for load speculation to be implemented (the loads can continue freely).[3] In this regard, PC performs better than SC because recovery techniques for failed speculations aren’t necessary, which means fewer pipeline flushes.[3] The prefetching optimization that SC systems employ is also applicable to PC systems.[3] Prefetching is the act of fetching data in advance for upcoming loads and stores before it is actually needed, to cut down on load/store latency. Since PC reduces load latency by allowing loads to be re-ordered before corresponding stores, the need for prefetching is somewhat reduced, as the prefetched data will be used more for stores than for loads.[3]

In terms of how well a PC system follows a programmer’s intuition, it turns out that in properly synchronized systems, the outcomes of PC and SC are the same.[3] Programmer’s intuition is essentially how the programmer expects the instructions to execute, usually in what is referred to as “program order.” Program order in a multiprocessor system is the execution of instructions resulting in the same outcome as a sequential execution. The fact that PC and SC both follow this expectation is a direct consequence of the fact that corresponding loads and stores in PC systems are still ordered with respect to each other.[3] For example, in lock synchronization, the only operation whose behavior is not fully defined by PC is the lock-acquire store, where subsequent loads are in the critical section and their order affects the outcome.[3] This operation, however, is usually implemented with a store conditional or atomic instruction, so that if the operation fails it will be repeated later and all the younger loads will also be repeated.[3] All loads occurring before this store are still ordered with respect to the loads occurring in the critical section, and as such all the older loads have to complete before loads in the critical section can run.

Processor consistency, while weaker than sequential consistency, is still in most cases a stronger consistency model than is needed. This is due to the number of synchronization points inherent to programs that run on multiprocessor systems.[4] This means that no data races can occur (a data race being multiple simultaneous accesses to memory location where at least one access is a write).[3] With this in mind, it is clear to see that a model could allow for reorganization of all memory operations, as long as no operation crosses a synchronization point[3] and one does, called Weak Ordering. However, weak ordering does impose some of the same restrictions as processor consistency, namely that the system must remain coherent and thus all writes to the same memory location must be seen by all processors in the same order.[4] Similar to weak ordering, the release consistency model allows reordering of all memory operations, but it gets even more specific and breaks down synchronization operations to allow more relaxation of reorders.[3] Both of these models assume proper synchronization of code and in some cases hardware synchronization support, and so processor consistency is a safer model to adhere to if one is unsure about the reliability of the programs to be run using the model.

One of the main components of processor consistency is that if a write followed by a read is allowed to execute out of program order. This essentially results in the hiding of write latency when loads are allowed to go ahead of stores. Since many applications function correctly with this structure, systems that implement this type of relaxed ordering typically appear sequentially consistent. Two other models that conform to this specification are the SPARC V8 TSO (Total Store Ordering) and the IBM-370.[4]

The IBM-370 model follows the specification of allowing a write followed by a read to execute out of program order, with a few exceptions. The first is that if the operations are to the same location, they must be in program order. The second is that if either operation is part of a serialization instruction or there is a serialization instruction between the two operations, then the operations must execute in program order.[4] This model is perhaps the strictest of the three models being considered, as the TSO model removes one of the exceptions mentioned.

The SPARC V8 TSO model is very similar to the IBM-370 model with the key difference that it allows operations to the same location to complete out of program order. With this, it is possible that a load returns a store that occurred that is “out of date” in terms of program order.[4] These models are similar to processor consistency, but whereas these models only have one copy of memory, processor consistency has no such restriction. This suggests a system in which each processor has its own memory, which emphasizes upon processor consistency the “coherence requirement.[4]"

The x86-TSO model has a number of different definitions. The total store model, as the name suggests, is very similar to the SPARC V8. The other definition is based on local write buffers. The differences in the x86 and SPARC TSO models is in the omission of some instructions and inclusion of others, but the models themselves are very similar.[5] The write buffer definition utilizes various states and locks to determine whether a particular value can be read/written to. In addition, this particular model for the x86 architecture is not plagued by the issues of previous (weaker consistency) models, and provides a more intuitive base for programmers to build upon.[5]

• Serializability