Putting DSM On Sale

So, we can implement a DSM with atomic consistency -- but it is expensive. What happens if we don't need atomic consistency? Atomic consistency guarantees that all reads so the most recently written value. But this might not be a requirment for any particular application. If we can relax this guarantee, we can implement DSM more cheaply. Let's consider some common options:

• Sequential consistency is almost the same as atomic consistency, except that a read can return a stale value. In other words, we can view the system as having two queues: reads and writes. The writes must occur in the same order on all systems, but the reads can be interleaved, on each system, as convenient. This approach is often very convenient, because many systems can produce viable results, even if some of the data is outdated -- but not inverted.
• Causal consistency is much the same as the causal ordering that we discussed earlier this semester. We just consider the reads and writes as messages any message sent after a read to be causally related to it. In other words, we maintain sequential consistency only in (potentially) causally related operations. Although this sounds really nice and useful, there is a "small" problem: it takes a tremendous amount of accounting. It requires that the system maintain and utilize large dependency graphs to determine the causal relationships. (Recall our discussion of causality with respect to message passing). In most cases, the cost of this makes it impractical.
• Processor Consistency is much the same as the it was during our discussion of message passing. The writes from a single processor must be seen by all processors in order, but writes from different processors may be interleaved in any order. This consistency model is useful, because in many applications the actions of a processor are based only on its own actions, not the actions of other processors. Furthermore, processor consistency is cheap to implement, because it can be done using only sender-based sequence numbers, without global coordination.

Weak Consistency Models

The consistency models that we have discussed so far are called unsynchronized consistency models. What this really means is that consistency, the synchronization of data, is handled without the involvement of the programmer. Another collection of consistency models, known as synchronized consistency models, a.k.a. weak consistency models require the involvement of the programmer. This models are unfortunate in the sense that they don't allow the DSM to remain entirely transparent to the application developer. But, the good thing is that the application developer can provide the DSM system with information that makes its job much simpler and cheaper.

• Proper consistency, a.k.a. weak consistency is a very simple approach that should seem pretty intuitive to many of you. When the programmer wants to get the most up-to-date value of a variable, he or she invokes a sync() operation first -- this updates the local copy. When he or she wants to guarantee that the local changes are world visible, he or she invokes the same sync() operation. In this way, the programmer is in complete control of the synchronization events. The programmer can use traditional synchronization primatives, such as monitors, semaphores, or mutexes to ensure that values don't change mid-stream, as necessarry.
• Release consistency is another approach. Unfortunately, the sync() operation described above must synchronize both reads and writes. This can be wasteful. Release consistency allows the programmer to get the up-to-date copy of a variable using some acquire() operation at the beginning of a critical section and to publish changes using a release() operation at the end of the critical section. If the code is structured within a mutual exclusive block that gathers the values first, then manipulates them, and then releases them, this is more efficient than the sync() operation described earlier. Of course, this forces the programmer into a little more structure.