Eager and lazy release

• Propagating invalidations at release is still conservative
  • P1 does not care about the writes from P0 until P1 executes the next acquire; at this point P1 must see all updated values
  • Delay write notices until next acquire of the consumer
  • Let the consumer ask for the updates (on demand)
  • This leads to lazy release consistency (LRC); the conventional release consistency is often called eager release consistency (ERC) in SDSM world
  • In LRC a process executing an acquire obtains all write notices corresponding to all releases that happened in the system since its last acquire (conservative)

Lazy release

• All synchronization operations must be carefully labeled

  P0:	P1:
  LOCK(L);	while (!ptr);
  ptr = some_non_null_value;	LOCK(L);
  UNLOCK(L);	f(ptr);
  	UNLOCK(L);

• Hardware DSM binaries may not work directly in SVM
  • The fence instructions are largely useless here
  • What is more important is a way to tell the SVM library to propagate writes at proper points

Multiple writers

• Thus far we have silently assumed only one writer
  • With multiple writers if the coherence protocol only allows a single modified page at a time, ownership must be transferred every time a new writer arrives
  • Clearly, under release consistency there is no problem in having multiple writers; you just need to pretend as if all the writes from one processor happened before all the writes from another even though they actually interleaved (assume that none of these writes are part of a release)
  • So we just need to design a multiple writer protocol which allows multiple writers to co-exist between two consecutive synchronization points, allows pages to be modified locally and become inconsistent
  • The main design concern of this protocol is: what happens when a process reaches acquire? How to collect all write notices?
• Multiple writer protocol (from TreadMarks SVM)
  • When a page is brought in, the PTE is marked to have only read permission
  • On the first write to the page an access fault handler is invoked and the handler makes a copy of the page (called twin); also at this point the PTE is set to have RW
  • Now the process can write to the page as many times as it wishes
  • At release boundary (for ERC) or at the time of an incoming acquire request (for LRC), the page is compared with the twin and a diff is created (containing just the modifications)
  • Finally, the diff is propagated to the requester
  • The requester collects all the diffs and merges them into its own copies