Write a program to provide a simple distributed shared memory among a group of 6 - 8 machines (or
sites/nodes). Each machine contributes a small chunk of memory to be shared among all other
machines. This distributed shared memory system is implemented with read replication and supports
strict memory coherence. (See book/notes for the “definition” of these terms). Somewhat similar to
PLUS system discussed in class, your implementation should have a “larger” page size (say, 100 bytes
) for transfer & fault management and a “smaller” size (say, 4 bytes) for coherence management.
Memory coherence at the 4-bytes level is strictly maintained using write-invalidation protocol and
Lamport’s mutual exclusion. It uses Lamport’s mutual exclusion to make sure that a write operation is
not concurrent with read or other write operations. Here, processes/sites/machines having a copy of the
page can concurrently request for write operations. You may update after invalidation or you may
choose not to.
As you know, distributed shared memory needs a name server/memory mapper to resolve memory
address references. In this project, you should have a distributed memory mapper (no credits for
centralized one). Section 2 gives you a possible approach. You can implement your own
variations/version but ensure that it will be distributed in nature.
1.1 Demo Programs
This distributed shared memory has to be demonstrated through 2 simple demo programs (that can be
physically part of the above program). One demo program is to generate the log files for submission and
the other one is for the demo to the TA. Both the demo programs will have several aspects in common.
For these programs, you can identify 3 - 4 “variables” that would occupy 4 bytes in the distributed
shared space. The term “variables” is in quotes because they are “like” variables but are managed only
in your program for demonstration purposes. For instance, you can define a variable X whose contents
will be in shared memory. X will not be allocated by the local machine’s operating system. Instead, it
will be allocated and managed in the distributed shared memory by your program. The program should
show multiple, concurrent reads and writes on each of these 3 - 4 variables. These reads and writes
should demonstrate the strict memory coherence offered by your implementation.
With respect to differences between the 2 demo programs, the program used for creating log files does
not need any user interface. Whereas the other one used for demo to the TA will need a user interface.
In this program (for demo to the TA), you should be able to give commands that will help in reading
and writing values from/to the variables. These commands (e.g. show/read X; write 5 to X, etc) should
demonstrate mutual exclusion, read replication, and other salient features of your implementation.
1. Program Design
1. Each machine can provide a small chunk, say 100 bytes of memory, as its contribution to
distributed shared memory.
2. This chunk can be considered as 1 page of memory.
3. Each page needs to be assigned a page address.
4. This page address is used by memory mapper to track the host owning the page.
5. Each page can have a copy list that specifies having a copy of the page.
6. For enforcing strict memory coherence, the program invalidates the copies first before updating
(i.e., write invalidate protocol). Note that you may need to get acknowledgements on
invalidation (from the copies) before update to ensure strict coherence.
7. The process/site should get exclusive access to the variable before invalidation. Mutual
exclusion on 3 – 4 variables implies that you should 3 – 4 instances of Lamport’s algorithm
running (1 for each variable). You have to modify your Project 2 with suitable header message
to identify the variable for which mutual exclusion is being sought.
8. Note that it is sufficient to get permission from members of the copyset of a page for mutual
exclusion – implies that the Request Set for the Lamport’s algorithm will keep changing. You
may decide to keep the Request Set fixed too by asking permission from all sites.
9. Process/site updating the variable becomes the “new owner” for the variable. For simplicity,
you can assume that the 3 – 4 shared variables are in different pages. So the process/site can be
the owner of the page too.
10. Distributed memory mapper can use a hashing a function on the page address (whole address or
part of it) to determine the initial owner. Irrespective of whether the owner has the page or not,
the owner will always track the page migrations and will always have the address of the
process/site owning the page. You can also use hints to improve the performance.
11. The above mapper is a kind of distributed name server: the initial owners maintain information
that cumulatively gives the global information. You can/should try variations of the suggested
approach or totally new distributed approaches too.
Obviously, you can follow different approaches than the ones mentioned above. Again, if in doubt, get
in touch with me. Email is fine.
It may be easier for you to first start with 2 machines and develop the distributed shared memory part.
The demo program can then run on 1 machine to test the shared memory. Next, you can expand to more
machines. Later, you can expand the demo program to more machines.
The program should be demonstrated with 6 - 8 systems. Each machine should contribute a small chunk
of memory, say 100 bytes. You should have 3 – 4 variables defined in the shared memory. Log files
should show concurrent read/write accesses to shared memory. A reasonable estimate is to show 20-25
operations on each of the variables. During demo also, you should be able to run this demo program for
logging and show that your implementation can run without crashing for 15-20 operations on the 3 – 4
10 % for documentation
15 % for program comments and structure
15% for the sample log files
15% for the program running without crashing
10% for showing mutual exclusion on 3-4 variables
20% for showing strict consistency
15% for distributed memory mapper