1. Software Transactional Objects Guy Eddon Maurice Herlihy TRAMP 2007

2. Language/Library supportfor Transactions • Lots of worn on unmanaged languages • “word-based” • What about managed languages? • Objects, GC, bounds checks, structured exceptions? • Java™, C#? • Different concerns

3. 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 ….

4. Old-School Atomic Classes public class List { publicint item; public TMObject<List> next; } Next field is explicit wrapper

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

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

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

8. Library approach • Intercept field accesses • SXM (C#) • DSTM2 (Java™) • Programmer use factories • Input is interface • Synthesize code to intercept field accesses Software Transactional Memory

9. Examples node.Key = 42; // C# property style Node.setKey(42); // Java EJB style

10. Examples node.Key = 42; // C# property style Node.setKey(42); // Java EJB style try { T version = (T) start.get().newVersion; final Method method = version.getClass().getMethod(methodName, _class); return new Adapter.Setter<V>() { public void call(V value) { try { ThreadState state = Thread.getLocalState(); …

11. Advantages • Strong Atomicity • Detects transactional/non-transactional race conditions • Natural programming style • Almost sequential • No complex conventions

12. Disadvantages • Efficiency, efficiency, efficiency • Even with fast-path optimizations • Solution • Use flow analysis to remove synchronization • Use MSFT Phoenix compiler

13. Lock-Based Runtime

14. Obstruction-Free Run-Time

15. Locking vs Obstruction-Free

16. Conclusions • Managed languages are also important • Simple flow analysis goes a long way • Do not rule out non-blocking algorithms yet

17. Clip Art