Making sense of  transactional memory

Making sense of transactional memory PowerPoint PPT Presentation

  • Updated On :
  • Presentation posted in: General

Example: double-ended queue. . . . . . . . . Left sentinel. . . . . X. X. 20. Right sentinel. Support push/pop on both endsAllow concurrency where possibleAvoid deadlock. Implementing this: atomic blocks. Class Q { QElem leftSentinel; QElem rightSentinel; void pushLeft(int item) { atomic { QElem e = new QElem(item); e.right = this.leftSentinel.right; e.left = this.leftSentinel; this.leftSentinel.right.left = e; this.leftSentinel.right = e; } }31816

Download Presentation

Making sense of transactional memory

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

1. Making sense of transactional memory Tim Harris (MSR Cambridge) Based on joint work with colleagues at MSR Cambridge, MSR Mountain View, MSR Redmond, the Parallel Computing Platform group, Barcelona Supercomputing Centre, and the University of Cambridge Computer Lab

2. Example: double-ended queue Support push/pop on both ends Allow concurrency where possible Avoid deadlock

3. Implementing this: atomic blocks

4. Design questions

5. Example: a privatization idiom

6. Example: a privatization idiom

7. Example: a privatization idiom

8. Example: a privatization idiom

9. Example: a privatization idiom

10. Example: a privatization idiom

11. Example: a privatization idiom

12. Example: a privatization idiom

13. The main argument

14. An analogy

15. Defining “atomic”, not “TM”

16. Strong semantics: a simple interleaved model

17. Example: a privatization idiom

18. Example: a privatization idiom

19. Example: a privatization idiom

20. Example: a privatization idiom

21. Example: a privatization idiom

22. Example: a privatization idiom

23. Example: a privatization idiom

24. Example: a privatization idiom

25. Example: a privatization idiom

26. Example: a privatization idiom

27. Pragmatically, do we care about...

28. How: strong semantics for race-free programs

29. Hiding TM from programmers

30. Example: a privatization idiom

31. Example: a “racy” publication idiom

32. What about... ...I/O? ...volatile fields? ...locks inside/outside atomic blocks? ...condition variables?

33. What about I/O?

34. What about C#/Java volatile fields?

35. What about locks?

36. What about locks?

37. What about condition variables?

38. What about condition variables?

39. Defining “atomic”, not “TM”

40. Division of responsibility

41. Implementation 1: “classical” atomic blocks on TM

42. Implementation 2: very weak TM

43. Implementation 3: lock inference

44. Integrating non-TM features Prohibit Directly execute over TM Use irrevocable execution Integrate it with TM

45. Integrating non-TM features Prohibit Directly execute over TM Use irrevocable execution Integrate it with TM

46. Integrating non-TM features Prohibit Directly execute over TM Use irrevocable execution Integrate it with TM

47. Integrating non-TM features Prohibit Directly execute over TM Use irrevocable execution Integrate it with TM

48. Defining “atomic”, not “TM”

49. Performance figures depend on... Workload : What do the atomic blocks do? How long is spent inside them? Baseline implementation: Mature existing compiler, or prototype? Intended semantics: Support static separation? Violation freedom (TDRF)? STM implementation: In-place updates, deferred updates, eager/lazy conflict detection, visible/invisible readers? STM-specific optimizations: e.g. to remove or downgrade redundant TM operations Integration: e.g. dynamically between the GC and the STM, or inlining of STM functions during compilation Implementation effort: low-level perf tweaks, tuning, etc. Hardware: e.g. performance of CAS and memory system

50. Labyrinth STAMP v0.9.10 256x256x3 grid Routing 256 paths Almost all execution inside atomic blocks Atomic blocks can attempt 100K+ updates C# version derived from original C Compiled using Bartok, whole program mode, C# -> x86 (~80% perf of original C with VS2008) Overhead results with Core2 Duo running Windows Vista

51. Sequential overhead

52. Sequential overhead

53. Sequential overhead

54. Sequential overhead

55. Sequential overhead

56. Scaling – Genome

57. Scaling – Labyrinth

58. Making sense of TM Focus on the interface between the language and the programmer Talk about atomicity, not TM Permit a range of tx and non-tx implementations Define idealized “strong semantics” for the language (c.f. sequential consistency) Define what it means for a program to be “correctly synchronized” under these semantics Treat complicated cases methodically (I/O, locking, etc)

  • Login