Lec12-DSM算法.pptVIP

Release Consistency Munin Release consistency was introduced with the Dash multiprocessor, which implements DSM in hardware, primarily using a write-invalidation protocol. The idea of release consistency is to reduce DSM overheads by exploiting the fact that programmers use synchronization objects such as semaphores, locks barriers. Release Consistency Munin The requirements: To preserve the synchronization semantics of objects such as locks barriers; To gain performance, we allow a degree of asynchronicity for memory operations; To constrain the overlap between memory accesses in order to guarantee executions that provide the equivalent of sequential consistency. Release Consistency Munin Gharachorloo et al. 1990 define release consistency as follows: RC1: before an ordinary read or write operation is allowed to perform with respect to any other process, all previous acquire accesses must be performed. RC2: before a release operation is allowed to perform with respect to any other process, all previous ordinary read write operations must be performed. RC3: acquire release operations are sequentially consistent with respect to one another. Processes Executing On A Release-consistent DSM Process 1: acquireLock(); //enter critical section a:=a+1; b:=b+1; releaseLock(); //leave critical section Process 2: acquireLock(); //enter critical section Print(“The values of a b are:”,a,b); releaseLock(); //leave critical section Munin The following points apply to Munin’s implementation of release consistency: Munin sends update or invalidation information as soon as a lock is released. The programmer can make annotations that associate a lock with particular data items. In this case, the DSM run-time can propagate relevant updates in the same msg that transfers the lock to a waiting process – ensuring that the lock’s recipient has copies of the data it needs before it accesses them. Sharing Annotations Munin implements a variety of consistency protocols, which are a