Concurrent Revisions: A deterministic concurrency model.

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 Reader Mutator R R R R Reader Shared Data Reader Mutator Mutator • 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. Conventional Concurrency Control • pessimistic concurrency control use locks to avoid parallelism where there are (real or potential) conflicts • optimistic concurrency control speculate on absence of true conflictsrollback if there are real conflicts either way: true conflicts kill parallel performance. Can we do better?

4. Our solution: Concurrent Revisions Revision A Parallel Task that gets its own logical copy of the state Isolation Type A type which supports automatic replication andconflict resolution • 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

5. Revision vs. Traditional Task Isolation types: declares shared data • Isolation: side effects are only visible when the revision is joined. • Deterministic execution! Traditional Task Concurrent Revisions int x = 0; task t = fork { x = 1; } assert(x==0 || x==1); join t; assert(x==1); versioned<int> x = 0; revision r = rfork { x = 1; } assert(x==0); join r; assert(x==1); 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. Sequential Consistency int x = 0; int y = 0; task t = fork { if (x==0) y++; } if (y==0) x++; join t; assert( (x==0 && y==1) || (x==1 && y==0) || (x==1 && y==1)); Concurrent Revisions Transactional Memory int x = 0; int y = 0; task t = fork { atomic { if (x==0) y++; } } atomic { if (y==0) x++; } join t; versioned<int> x = 0; versioned<int> y = 0; revision r = rfork { if (x==0) y++; } if (y==0) x++; join r; assert( (x==0 && y==1) || (x==1 && y==0)); assert(x==1 && y==1);

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

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

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 generalthan DAGs • We proved: aresemi-lattices … but a DAG … but not an SP-graph

10. Case Study: Spacewars!

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

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

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

14. Example 2: write-write conflict. Coll. Det. 4 Coll. Det. 1 Coll. Det. 2 Coll. Det. 3 Render network Physics autosave (long running) • Physics taskupdates 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!

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

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. Implementation • 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

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