1 / 17

Software Transactional Objects: Library Support and Implementation for Managed Languages

Explore the challenges and solutions in implementing software transactional objects in managed languages like Java and C#. Learn about transactional wrappers, versioning concepts, and the importance of programmer conventions in this field. Discover efficient techniques and advantages of using software transactional memory, along with considerations for optimizing performance and utilizing flow analysis.

freira
Télécharger la présentation

Software Transactional Objects: Library Support and Implementation for Managed Languages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related