The structure of the framework is as follows (Weber et al., 1998). There are three elements in the DSM: Consistency Models, Coherence Protocols and Concurrency Control. The consistency models and coherence protocols perform the roles that were identified in the last chapter, defining acceptable event-orderings and implementing those event-orderings. The concurrency control implements locks and barriers that are used by the consistency model to control in what order events are seen.
Consistency Model
All consistency models are derived from a base class that defines the common interface for consistency models: the operations read, write, lock and unlock. This ensures that they all can perform the function of a consistency model in the framework. Lock and unlock have corresponding methods in concurrency control. Read and write have corresponding methods in the coherence protocol base class that perform the actual accesses. There are subclasses of the base class for strict and relaxed consistencies. The classes for actual implementations of particular consistency models can then be derived from either the strict or the relaxed consistency model. As we will use Release Consistency and Lazy Release Consistency, these two are explained in more detail below.
Release Consistency
Release consistency defines two primitives that stand at either end of a critical piece of code: acquire and release. Updates are not forced until the release is encountered, the hope is that several updates will have taken place, and only one message will be required to deliver them.
This is implemented as shown in Fig. 2. A worker wishing to update shared data makes a lock request. The master replies when the lock has been established. The worker updates the master with the new value of the shared data and requests an unlock, (i.e. release is
Consistency Model Coherence Protocol Dist Mgt Own Mgt Mem Mgt Communication Service Concurrency Control Fig. 3.1 Structure of the Framework
called) this causes the master to issue an update to all relevant workers and then remove the lock.
Lazy Release Consistency
Lazy Release Consistency is similar except that updates are not propagated to other workers until they attempt to access the variable. The hope is that many updates will have been made before an access and only the last update will be sent to the worker in question.
This is implemented by having each worker make its updates locally. Then when another worker requests access the master gets the update from the updating worker and it is passed to the worker requesting access.
1. Lock Request 2. Data Locked 4. Unlock Request 5. Update 6. Unlock 3. Update Data Data Data
Fig. 3.2 Release Consistency
2. Update Request
Data
Data Writesdone Data
locally
1. Request Access
4. Update after request access 3. Update
Coherence Protocol
The coherence protocol describes the mechanisms that are used to ensure that the virtual shared memory in DSM is maintained in a coherent state. It is responsible for ensuring that accesses are performed correctly so that the consistency model that has been specified is implemented. There are three elements to the coherence protocol as outlined already: memory management, tracking ownership, and distribution management. They perform the roles that have been outlined above.
Concurrency control
This provides implementations of distributed locks and barriers for use by the consistency model. When a lock is requested it locks all copies of a data item according to the semantics of the particular type of lock requested. At the moment this implements a concurrent read, exclusive write (CREW) lock and an exclusive read, exclusive write (EREW) lock. It also implements a barrier.
Master and Workers
In addition to the DSM per se the framework also includes the master and worker classes. The master issues work to the workers and receives updates back. The workers perform the work on each work item they are sent. At the moment this is the only means of allocating work that has been implemented. However there is no reason within the DSM classes why there should not be some other system, for example workers working together without a master.
When workers are being initialised at the start of the program there are three modes in which they can be issued data:
Full Distribution: all data issued at initialisation Empty Distribution: update at access time
(data sent out as worker tries to access it) Empty Distribution: update at sharing time
When workers are being initialised they may or may not be provided with full copies of all the data they need to set up the problem, depending on the initialisation mode.
When a worker requests a work item it is supplied with a section of the problem data. This is inserted into its location in the data structure that is has been extracted from (i.e. a matrix row is inserted into the appropriate row of the workers copy of the matrix. The problem is solved by workers requesting and processing work items until all work items have been processed.
Not fault tolerant
A point worth bearing in mind in regard to the framework is that it has not been designed to be fault tolerant. It was designed to investigate how well the consistency model / coherence protocol structure would work.
Worker
Data Objects
Master
Worker Worker