✏️ Introduction

DSM motivation: memory optimization → shard the memory itself and store in chunks across servers

Set up: maintain cache at each process, all read and write go through the cache first


❌ DSM Invalidate Protocol

This is the gist but scenarios below!


DSM Invalidate: Read Scenarios

Scenario #1: When P1 is the owner and only copy, the state doesn’t matter. P1 can directly read from its cache, no messages exchanged

image.png

Scenario #3: If P1 doesn’t have a copy but wants to read the page, it gets a cache miss → page fault → trigger DSM software → sends a multicast to other processes so P1 gets a copy → P1 reads from its R state copy

image.png

Scenario #2: When P1 is the owner and other copies exist (note - only in R mode), P1 can still simply read from its cache, no messages exchanged. May not be the most consistent but we don’t care about that.

The same is true if P3 wanted to read from the page but is not owner - it can simply read its own cache - no messages exchanged

image.png

Scenario #4: If the only copy exists in W mode at the owner, and P1 wants to read, it asks the owner to downgrade to R mode and share a copy → performs read

image.png


DSM Invalidate: Write Scenarios

Scenario #1: P1 is the only owner, has file in W mode → simply write to it, no messages exchanged

image.png

Scenario #2: If P1 is the owner and has the file in R mode but other copies exist too, and P1 wants to perform a write, it sends a multicast asking other copies to invalid themselves → then it upgrades to W and performs the write

Similarly, in the same example, if all copies were R and someone else was the owner, P1 can ask to invalidate all copies, become the owner, turn its copy to W state and do the write

image.png

Scenario #3: If all copies were R and P1 had nothing, to write to the page, it has to invalidate other copies + request the LATEST of the existing copies → set that to W mode + become the owner → write to it

image.png


👎🏽 DSM Invalidate Downsides