170 likes | 255 Views
Software Transactional Objects. Guy Eddon Maurice Herlihy TRAMP 2007. Language/Library support for Transactions. Lots of worn on unmanaged languages “word-based” What about managed languages? Objects, GC, bounds checks, structured exceptions? Java™, C#? Different concerns.
E N D
Software Transactional Objects Guy Eddon Maurice Herlihy TRAMP 2007
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
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 ….
Old-School Atomic Classes public class List { publicint item; public TMObject<List> next; } Next field is explicit wrapper
Old-School Atomic Classes List next = list.next.OpenRead(); Explicit open (specify read or write)
Old-School Atomic Classes List next = list.next.OpenRead(); Must discard after transaction, don’t modify, etc…
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
Library approach • Intercept field accesses • SXM (C#) • DSTM2 (Java™) • Programmer use factories • Input is interface • Synthesize code to intercept field accesses Software Transactional Memory
Examples node.Key = 42; // C# property style Node.setKey(42); // Java EJB style
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(); …
Advantages • Strong Atomicity • Detects transactional/non-transactional race conditions • Natural programming style • Almost sequential • No complex conventions
Disadvantages • Efficiency, efficiency, efficiency • Even with fast-path optimizations • Solution • Use flow analysis to remove synchronization • Use MSFT Phoenix compiler
Conclusions • Managed languages are also important • Simple flow analysis goes a long way • Do not rule out non-blocking algorithms yet