SXM: Software Transactional Memory in C# Maurice Herlihy

2 Prior STM Work Awkward user interface –Long-lived transactional “wrappers” vs –Short-lived “versions” Programmer conventions –List element points to wrapper which points to list …. –Don’t use short-lived objects beyond lifetime ….

3 public class List { public int item; public TMObject next; } Old-School Atomic Classes Next field is explicit wrapper

4 List next = list.next.OpenRead(); Old-School Atomic Classes Explicit open (specify read or write)

5 List next = list.next.OpenRead(); Old-School Atomic Classes Must discard after transaction, don’t modify, etc…

6 List rVersion = list.next.OpenRead(); Old-School Atomic Classes Read version unchanged Read version changed List wVersion = list.next.OpenWrite(); wVersion.item++; List wVersion = list.next.OpenWrite(); List rVersion = list.next.OpenRead();

7 Software Transactional Memory Current Work Rewriting STM from scratch in C# Use Reflection.Emit to provide reasonable user interface Ability to generate code at run-time opens up new possibilities …

8 [Atomic] public class List { private int item; private List next; } Atomic Classes in SXM Declare “Atomic” property

9 [Atomic] public class List { private int item; private List next; } Atomic Classes in SXM Declare fields private No explicit wrapper!

10 public class List { private int item; private List next; public virtual int Item { get { return this.item; } set { this.item = value; } } C# Properties

11 public class List { private int item; private List next; public virtual int Item { get { return this.item; } set { this.item = value; } } C# Properties Wrap each field in a public virtual property

12 XObjectFactory listFactory = new XObjectFactory(typeof(List)); Transactional List Generates code to intercept property get & set methods for List type

13 XObjectFactory listFactory = new XObjectFactory(typeof(List)); Transactional List Uses reflection to “walk” over type and generate synchronization wrappers for Properties

14 List list = (List)ListFactory.Create(); Transactional List Anonymous subtype of List with transparent transactional machinery

15 public override object Insert(int v) { Node prevNode = Find(v); if (prevNode.Next.Value == v) { return false; } else { Node newNode = (Node)factory.Create(v); newNode.Next = prevNode.Next; prevNode.Next = newNode; return true; } Transaction Code

16 public bool Insert(int v) { Node prevNode = Find(v); if (prevNode.Next.Value == v) { return false; } else { Node newNode = (Node)factory.Create(v); newNode.Next = prevNode.Next; prevNode.Next = newNode; return true; } Transaction Code Look like field references … actually property calls

17 public override object Insert(int v) { Node prevNode = Find(v); if (prevNode.Next.Value == v) { return false; } else { Node newNode = (Node)factory.Create(v); newNode.Next = prevNode.Next; prevNode.Next = newNode; return true; } Transaction Code Create a new node (same args as constructor)

18 Transactions: Simple C# Interface XStart insertXStart = new XStart(Insert); Create a delegate (function ptr)

19 Transactions: Simple C# Interface XStart insertXStart = new XStart(Insert); Xaction.Run(insertXStart); Run the transaction

20 Transactions in SXM No explicit retry loop –Contention manager decides when to retry failed transactions Transaction == method –Reduces scoping errors

21 In Progress Modular Retry –As in [HPJMH 05] –Requires 1 st class nested transactions Polymorphic contention managers –Easier on-the-fly switching –Communication among heterogeneous CMs