Implementing LRC

• Single writer
  • The invalidations may be sent at any time between release and the next incoming acquire
  • Sending invalidations at acquire time puts the entire inval/ack round-trip time in the critical path of acquire
  • On the receiving side, a processor may or may not choose to apply the invalidations immediately; it is perfectly fine to defer application until next acquire of the processor
  • Note that invalidations are sent to all sharers not just the acquirer (why?)
    • Otherwise, the last releaser not only sends the invalidations for pages it has written to, but also the invalidations it itself has received; optimally acquirer wants to receive invalidations for releaser’s writes and others that it hasn’t yet seen, but not all
• Single writer
  • Version numbers don’t help in limiting invalidation traffic (note the difference with single writer ERC)
  • To reduce unnecessary invalidation traffic every node maintains a vector time stamp
  • The vector has P elements if the system has P nodes
  • The execution on each node is divided into intervals such that every acquire or release starts a new one and each interval has a vector time stamp per process
  • Vector element i of the vector in node k records the last logical interval of node i that sent a notice to node k
  • When a node sends an acquire request to the last releaser it also sends the vector time stamp so that the releaser can compare it with its own and reply with the appropriate invalidations
• Multiple writers
  • Essentially same as single writer as far as invalidations are concerned
  • Diffs introduce new storage overhead
  • HLRC seems to offer the best solution: home node can maintain the diffs (already discussed)
  • Without home, vector time stamps can be used for determining correct diff order
  • Even in the presence of home node, vector time stamps can be used to reduce invalidations as in single writer case
  • One of the main design goal is to keep diff storage low so that large problems can be run