1. Combining the best of: SMP (programmability) and DCS (expandability)

2. Memory: physically distributed and logically compact

3. Implementing the DSM mechanism:

  9. New systems

10. New research avenues

1. The hardware update mechanism works on the point-to-point basis.
Upon a write to a location, only one remote node is updated - the home,
no matter how many different nodes share that same data item.

2. The home for a specific page is determined at run time,
as the node which writes the first into a page.
It is assumed that the first writer will become the most frequent writer.

3. On the next acquire point, the acquiring node sends messages to the homes,
to obtain the current versions of all pages (in jurisdiction of these homes)
to be needed during the critical region which is just about to start.

4. Homes return the current version number of each page,
and the requesting node compares it with the version number
of the corresponding page in its possession.

5. The version at the node might be older,
but still usable,
if its version corresponds to the last update made by the same lock.

The current version might be #21, and the node may have the version #18,
but #18 may be the last version written to by the lock (process),
which is related to the acquire point in question.

If the node already has the last version of interest for it,
the page will not be ported over the network;
otherwise, it will.

6. The major issue here is to minimize the negative effects of false sharing,
in cases when page sizes are relatively large,
and several processes (locks) share the same page.

7. Home keeps the copy set (list of sharers) and the updated "version vector"
telling which locks were writing to a particular version of each page,
in the set of pages for which he/she is the home.

Each node keeps just one element of the "version vector."

This is the vector element related to the pages
replicated in that specific node.

8. During the execution of the code in the critical region,
the node will update both itself and the home,
on each write, as indicated earlier.

Others will be updated after they acquire the lock
and after they contact the home
to obtain the last update of the page.

This decreases the ICN traffic,
in comparison with some other reflective (write-through-update) schemes,
which update ALL sharers using a hardware reflection mechanism (RM and/or MC).

9. The above implements the lazy release consistency model
through a joint effort of hardware and software
(unlike TreadMarks, which does the entire work in software).

10. The AURC scheme has been implemented in the SHRIMP-II project
at Princeton.

1. The SCOPE is the same as the AURC, except for the following differences.

2. The version update vector at the home includes one more field,
telling which variables (addresses) were written into,
by a given lock; this is repeated for each version of the page.

3. Consequently, the home is not checked at the next acquire point,
but after that point, when the variable is invoked,
which corresponds to the ENTRY consistency model.

4. However, unlike with the ENTRY, the activity upon invoking a variable
is related to the entire page,
i.e. the entire page is brought over, if so necessary,

5. This means page-based maintenance and more traffic,
rather than object-based maintenance and less traffic (like in Midway).
In principle, Midway can also do page-based maintenance, but it does not.

6. The SCOPE is faster, although it is page-based rather than object-based,
since it does a part of the protocol in hardware,
using the same automatic update hardware as the AURC.

7. In conclusion,
SCOPE can be treated as a hw/sw implementation of ENTRY.

8. Its advantage over ENTRY is in complete avoidance of compiler assistance.

9. The SCOPE was not implemented in any of the Princeton DSM machines.

10. The SCOPE research brings up a number of new ideas: merge, diff-avoid.