1 / 41

Concurrent Programming With Revisions and Isolation Types

Concurrent Programming With Revisions and Isolation Types. Presented by: Ran Breuer. Outline. Introduction Main Ideas and Assumptions Revisions and Isolation Types Comparison to the classic locking scheme Case Study – Space Ward 3D Performance Evaluation Implemetation. int x = 0;

callie
Download Presentation

Concurrent Programming With Revisions and Isolation Types

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. Concurrent Programming With Revisions and Isolation Types Presented by: Ran Breuer

  2. Outline • Introduction • Main Ideas and Assumptions • Revisions and Isolation Types • Comparison to the classic locking scheme • Case Study – Space Ward 3D • Performance Evaluation • Implemetation

  3. int x = 0; • int y = 0; • Task t = fork { • if (x==0) y++; • } • if (y==0) x++; • join t; • Printx , y; Puzzle Time.. What will be printed in line 8? 1 , 1 1 , 0 0 , 1 And the winner is: All of the above?

  4. Let’s use a diagram… int x = 0 int y = 0 • int x = 0; • int y = 0; • Task t = fork { • if (x==0) y++; • } • if (y==0) x++; • join t; • Printx , y; if (y==0) x++; if (x==0) y++; assert( (x==0 && y==1) || (x==1 && y==0) || (x==1 && y==1));

  5. Introduction Sequential Consistency – • For every concurrent execution exists a sequential execution that • Contains the same operations • Is legal (obeys the sequential specification) • Preserves the order of operations by the same process Linearizability- • For every concurrent execution exists a sequential execution that • Contains the same operations • Is legal (obeys the specification of the ADTs) • Preserves the real-time order of non-overlapping operations

  6. Introduction • We want to use concurrent programs and tools deterministically • Locking schemes introduce bugs • Need to ensure consistency of shared data and variables • Programmers control outcome and run, don’t leave anything to “chance”

  7. Key Concepts in Design • Declarative Data Sharing • The programmer uses special isolation types to declare what data can be shared between tasks. • Automatic Isolation • Forked asynchronous tasks (Revisions) operate in isolation. • Each Revision operates on a single copy of the entire shared data. => Guaranteed consistency and stability. • Deterministic Conflict Resolution • All conflicts resolved by definition of isolation type involved in conflict

  8. Introducing: Revisions • Basic unit of concurrency • Revisions function like tasks, forked and joined • Called “Revisions” to suit source control systems • Main thread considered a Revision as well • Joining of all forked revisions is done explicitly by the programmer

  9. Reading Revisions • Traditional Tasks • 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);

  10. Reading Revisions – Revision Diagrams Versioned<int> x = 0 Versioned<int> y = 0 • Concurrent Revisions • Revision Diagram Versioned<int> x = 0; Versioned<int> y = 0; Revisionr = rfork { if (x==0) y++; } if (y==0) x++; rjoin r; if (y==0) x++; if (x==0) y++; Fork() Join() assert(x==1 && y==1);

  11. Revision Diagrams – Original look • Concurrent Revisions • Revision Diagram Fork() Join()

  12. Nested Revisions • Simplifies modular reasoning about program execution • Typically revisions fork its own inner revision and then join it. • Classic nesting of tasks. • Revisions lifetime is not restricted to lexical scope • it is possible that inner (more nested) revision „survives” outer revision. • Supports ‘fork-join’ pattern

  13. Nested Revisions - restrictions

  14. Isolation Types • When joining revision, we wish to merge the copies of the shared data back together deterministically • To decide how this merge should be done, we need to know what this data represents • Let’s ask the programmer! • The programmer explicitly supplies this information by choosing an appropriate type for the data

  15. Types of Isolation (Types) Versioned • Value is changed\merged according to the most recent write • Upon join, we check if value was changed in original revision since fork() • For a basic type T we write Versioned<T> • Good for most data and variables • When few writes but many reads • When there is a clear relative priority between revisions

  16. Types of Isolation (Types) - Versioned

  17. Types of Isolation (Types) Cumulative • Combined effect of modifications is determined by a Merge function f • Merge function • Takes 3 parameters: • Original – value at time of fork() • Master – current value in joining revision • Revised – current value in joined revision • We write these types as Cumulative<T,f>

  18. Types of Isolation (Types) - Cumulative

  19. Complex structures with isolation types Isolation typed fields might not preserve objects behavior…

  20. Comparison to current methods – Locking Schemes • Traditional locking scheme • Requires programmers to think about placement of critical sections • Complicates code readability and maintenance • Reduces concurrency by pausing tasks • Eg. animating and rendering game objects in separate tasks • Presented solution • Isolation of the read-only tasks and single writer task(so-called double-buffering) • Might be not the most space-efficient solution

  21. Comparison to current methods – Transactions

  22. Case Study Space Wars 3D Game designed to teach DirectX Programming in C#

  23. Space Wars 3D – Sequential Version Sequential Game Loop: Parallel Collision Detection Render Screen Parallel Collision Detection Parallel Collision Detection Graphics Card Simulate Physics Shared State Play Sounds Send Process Inputs Receive Autosave Keyboard Network Connection Disk

  24. Parallelizing the Game Loop - design • Declared isolation types: • VersionedValue<T> - mainly simple types • VersionedObject<T> - asteroids, positions, particle effects • CumulativeValue<T> - message buffer • CumulativeList<T> - lists of asteroids • CollisionsCheck could be executed in parallel. Optimizing • RenderFrameToScreencannot be parallelized • but it can be executed in parallel with other tasks • Updates from the network have higher priority than updates done • by UpdateWorld or CollisionsCheck • Deterministic Record and Replay • Used in performance evaluation

  25. Parallelizing the Game Loop Parallel Collision Detection Render Screen Parallel Collision Detection Parallel Collision Detection Graphics Card Simulate Physics Shared State Play Sounds Send Process Inputs Receive Autosave Keyboard Network Connection Disk

  26. Parallelizing the Game Loop Coll. Det. 4 Coll. Det. 1 Coll. Det. 2 Coll. Det. 3 Render Physics network autosave (long running)

  27. Parallelizing the Game Loop - explained • The Physics revision updates objects location while Render revision reads locations, minor changes don’t affect most computations Coll. Det. 4 Coll. Det. 1 Coll. Det. 2 Coll. Det. 3 Render Physics network autosave (long running)

  28. Parallelizing the Game Loop - explained • 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 precedence! Coll. Det. 4 Coll. Det. 1 Coll. Det. 2 Coll. Det. 3 Render Physics network autosave (long running)

  29. Performance Evaluation Testing environment:Intel Xeon W3520 (quad-core) 2.66Ghz, 6GB of DDR3, NVIDIA Quadro FX580 512MB, Windows 7 Enterprise 64-bit

  30. Performance Evaluation • Autosave now totally undetected and unnoticeable • Overall speedup x3.03 than sequential runAlmost entirely depends on graphics card

  31. Performance Evaluation - Overhead How much did all the copying and indirection cost? Collision detection accounts for 82% of frame runtime

  32. Performance Evaluation - Overhead If revision writes to a versioned object then revisioningsubsystem needs to clone object to enforce isolation.

  33. Performance Evaluation - Speed • Average speedup of 2.6x on quad-core processor • Up to 3.03x speedup for 1500 asteroids • Render task takes 95.5% of the frame time (collisions check speedup)

  34. Implementation

  35. Revisions - Implementation • C# Library • Revision • Segment • Versioned • Cumulative

  36. Revisions - Implementation Revisions • Stores current segment that points to the segment created for that revision after last fork • Root segment is the segment right above fork Segments • Tree structure • Stores versioned data • Ancestors of the current segment can be removed after join if there is no other revisions that uses them.

  37. Revisions - Implementation

  38. Revisions - Implementation Fork • Creates new current segments for both revisions • Assigns new revision with the new thread Join • Creates one new segment • Merges versioned objects from both revisions • Releases unused ancestors of the current segment of the joined revision

  39. Summary • Programming model based on revisions and isolation types. • Efficient mechanism for executing different tasks within interactive applications. • Allows programming deterministic concurrent programs • Depend on programmer to declare proper use of data

  40. Questions?

  41. Thank you

More Related