Object-Based Distributed Shared Memory

An object is a programmer-defined encapsulated data structure. It consists of:

The procedures are called methods or operations, that operate on the object state. To access or operate on the internal state, the program must invoke one of the methods. The method can change the internal state, return the state, or something else. Direct access to the internal state is not allowed. This property, called information hiding. Forcing all references to an object's data to go through the methods helps structure the program in a modular way.

In an object-based distributed shared memory, processes on multiple machines share an abstract space filled with shared objects. The location and management of the objects is handled automatically by the runtime system. This model is in contrast to page-based DSM systems, which just provide a raw linear memory of bytes from 0 to some maximum. Any process can invoke any object's methods, regardless of where the process and object are located. It is the job of the operating system and runtime system to make the act of invoking work no matter where the process and the object are located.

Because processes cannot directly access the internal state of any of the shared objects, various optimizations are possible here that are not possible with page-based DSM. For example, since access to the internal state is strictly controlled, it may be possible to relax the memory consistency protocol without the programmer even knowing it.

Once a decision has been made to structure a shared memory as a collection of separate objects instead of as a linear address space, there are many other choices to be made. Probably the most important issue is whether objects should be replicated or not. If replication is not used, all accesses to an object go through the one and only copy, which is simple, but may lead to poor performance. By allowing objects to migrate from machine to machine, as needed, it may be possible to reduce the performance loss by moving objects to where they are needed.

On the other hand, if objects are replicated, what should be done when one copy is updated? One approach is to invalidate all the other copies so that only the up to date copy remains. Additional copies can be created later, on demand, as needed. An alternative choice is not to invalidate the copies, but to update them. Shared-variable DSM also has this choice, but for page-based DSM, invalidation is the only feasible choice. Similarly, object-based DSM, like shared-variable DSM, eliminates most false sharing.

Object-based DSM has three advantages over the other methods:

  1. It is more modular than the other techniques.
  2. The implementation is more flexible because accesses are controlled.
  3. Synchronization and access can be integrated together cleanly.

Object-based DSM also has disadvantages. For one thing, it cannot be used to run old "dusty deck" multiprocessor programs that assume the existence of a shared linear address space that every process can read and write at random. However, since multiprocessors are relatively new, the existing stock of multiprocessor programs that anyone cares about is small.

A second potential disadvantage is that since all accesses to shared objects must be done by invoking the objects' methods, extra overhead is incurred that is not present with shared pages that can be accessed directly.

DSM Home   Subway   Shared Mem  Shared         
  Page       Map      Systems   Variable