1. Concurrent Revisions: A deterministic concurrency model. Daan Leijen & Sebastian Burckhardt Microsoft Research (OOPSLA 2010, ESOP 2011)

2. Consider Common Application Scenario: Shared Data and Parallel Tasks Shared Data Mutator Reader R R R R R R R R Example 1: Office application Shared Data = Document Tasks = { Editing, Spellcheck, Background Save, Paginate, …} Example 2: Game Shared Data = Game Objects Tasks = {Physics, Collision Detection, AI, Render, Network}  How to parallelize tasks? (note: tasks do conflict frequently)

3. pessimistic concurrency control use locks to avoid parallelism where there are (real or potential) conflicts optimistic concurrency control speculate on absence of true conflicts rollback if there are real conflicts either way: true conflicts kill parallel performance. Can we do better? Conventional Concurrency Control

4. Our solution: Concurrent Revisions Reminiscent of source control systems Conceptually, each revision gets its own private copy of all the shared data On join, all effects of the joined revision are applied to the joining revision Revision A Parallel Task that gets its own logical copy of the state Revision A Parallel Task that gets its own logical copy of the state Isolation Type A type which supports automatic replication and conflict resolution Isolation Type A type which supports automatic replication and conflict resolution

5. Revision vs. Traditional Task Isolation: side effects are only visible when the revision is joined. Deterministic execution! int x = 0; task t = fork { x = 1; } assert(x==0 || x==1); join t; assert(x==1); versioned x = 0; revision r = rfork { x = 1; } assert(x==0); join r; assert(x==1); Traditional Task Concurrent Revisions Isolation types: declares shared data fork revision: forks off a private copy of the shared state join revision: waits for the revision to terminate and writes back changes into the main revision

6. int x = 0; int y = 0; task t = fork { if (x==0) y++; } if (y==0) x++; join t; int x = 0; int y = 0; task t = fork { atomic { if (x==0) y++; } } atomic { if (y==0) x++; } join t; versioned x = 0; versioned y = 0; revision r = rfork { if (x==0) y++; } if (y==0) x++; join r; Sequential Consistency Transactional Memory Concurrent Revisions assert( (x==0 && y==1) || (x==1 && y==0) || (x==1 && y==1)); assert( (x==0 && y==1) || (x==1 && y==0)); assert(x==1 && y==1);

7. The Simplest Isolation Type x = 0 x = 1x = 2 assert(x==2) x = 0 x = 1x = 0 assert(x==0) x = 0 x = 1 assert(x==1) On a write-write conflict, the modification in the child revision wins. Versioned x;

8. An Isolation Type with Custom conflict resolution x = 0 x += 1x += 2 assert(x==3) merge(1,2,0) → 3 Cumulative x; 1 2 0 int merge ( int current, int join, int original) { return current + (join – original); }

9. Revision Diagrams Describe the (dynamic) computation  Information flows only along paths in diagram Not the same as previously known diagrams for concurrency  More general than SP graphs  Less general than DAGs  We proved: are semi-lattices … but not an SP-graph … but a DAG

10. Case Study: Spacewars!

11. Sequential Game Loop Updates all positions Reads all positions Writes some positions How to parallelize given conflicts on object positions? Writes some positions Reads all positions

12. Revision Diagram for Parallelized Game Loop Coll. Det. 1Coll. Det. 2Coll. Det. 3 Coll. Det. 4 Render Physics network autosave (long running)

13. Example 1: read-write conflict.  Render task reads position of all game objects  Physics task updates position of all game objects  No interference: render task sees consistent snapshot! Coll. Det. 1Coll. Det. 2Coll. Det. 3 Coll. Det. 4 Render Physics network autosave (long running)

14. Example 2: write-write conflict.  Physics task updates position of all game objects  Network task updates position of some objects  Network updates have priority over physics updates  Order of joins establishes correct precedence! Coll. Det. 1Coll. Det. 2Coll. Det. 3 Coll. Det. 4 Render Physics network autosave (long running)

15.  Autosave now perfectly unnoticeable in background  Overall Speed-Up: 3.03x on four-core (almost completely limited by graphics card) Results Physics task Render Collision detection

16. Overhead: How much does all the copying and the indirection cost? Only a 5% slowdown in the sequential case Some individual tasks slow down much more (i.e. physics simulation)

17. For each versioned object, maintain multiple copies  Map revision ids to versions  synchronization free access to local copy (on x86) New copies are allocated lazily  Don’t copy on fork… copy on first write after fork Old copies are released on join  No space leak Implementation RevisionValue 10 402 457

18. Full algorithm in the paper…

19. Semantics of Concurrent Revisions [ESOP’11] Calculus (similar to AME-calculus by Abadi et al.)  Untyped lambda-calculus with mutable references and fork/join primitives Determinacy Proof Merge functions  Discussion of ADTs and merge functions  Relate to snapshot isolation (- nesting, - resolution) Revision Diagrams  Prove: semilattice structure

20. Local operations Synchronization

21. By construction, there is no ‘global’ state: just local state for each revision State is simply a (partial) function from a location to a value

22. Operational Semantics s → r s’ means: revision r takes a step, transforming s to s’

23. Interested? http://research.microsoft.com/revisions Videos Channel 9 interview w/ Erik Meijer Papers OOPSLA ‘10 on implementation and game ESOP ‘11 on semantics The implementation Try it online at www.rise4fun.comwww.rise4fun.com Download binary release in near future

24. The end.

25. BACKUP SLIDES

26. Revisions are not Transactions Determinism – Resolves conflicts deterministically. – No failure: never rolls back – Organized in a revision diagram No restrictions on revisions – can be long-running – can do I/O Conflicts don’t kill parallel performance – Conflicts do not force serialization