Concurrent Programming With
Revisions and Isolation Types
Sebastian Burckhardt Alexandro Baldassin
Daan Leijen
Microsoft Research
Microsoft Research
University of Campinas, Brazil
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
Puzzle Time..
1
int x = 0;
2
int y = 0;
3
Task t = fork {
What will be printed in line 8?
a)
1,1
b)
1,0
c)
0,1
d) All of the above?
if (x==0) y++;
4
5
}
6
if (y==0) x++;
7
join t;
8
Print x , y;
Let’s use a diagram…
int x = 0
int y = 0
if (y==0) x++;
assert(
(x==0 && y==1)
|| (x==1 && y==0)
|| (x==1 && y==1));
if (x==0) y++;
1
int x = 0;
2
int y = 0;
3
Task t = fork {
if (x==0) y++;
4
5
}
6
if (y==0) x++;
7
join t;
8
Print x , y;
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
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”
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
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
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);
Reading Revisions – Revision Diagrams
 Revision Diagram
Versioned<int> x = 0
Versioned<int> y = 0
if (y==0) x++;
 Concurrent Revisions
Versioned<int> x = 0;
Versioned<int> y = 0;
if (x==0) y++;
Revision r = rfork {
if (x==0) y++;
}
if (y==0) x++;
rjoin r;
assert(x==1 && y==1);
Revision Diagrams – Original look
 Revision Diagram
 Concurrent Revisions
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
Nested Revisions - restrictions
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
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
current value of the revision that is being joined.
If there were no modifications in the joinee revision then do nothing.
Types of Isolation (Types) - Versioned
It is a good choice for tasks that have relative priorities.
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>
Types
of Isolation
(Types)
- Cumulative
cumulative
<T,
f> example
Complex structures with isolation types
versioned <T>
Isolation typed fields might not preserve objects behavior…
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
Comparison to current methods –
Transactions with transactions
Comparison
Transactions
Two possible ways of execution
Revision
Single (deterministic) execution
Case Study
Space Wars 3D
Game designed to teach DirectX Programming in C#
Space Wars 3D – Sequential Version
Parallel
Collision
Detection
Parallel
Collision
Parallel CollisionDetection
Detection
Simulate
Physics
Shared
State
Render
Screen
Graphics
Card
Play
Sounds
Send
Receive
Autosave
Process
Inputs
Keyboard
Network Connection
Disk
Sequential Game Loop:
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
• RenderFrameToScreen cannot 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
Parallelizing the Game Loop
lelizing the game loop (2)
Parallel Collision Detection
Parallel Collision Detection
Parallel Collision Detection
Render
Screen
Graphics
Card
Simulate
Physics
Shared State
Play
Sounds
Send
Receive
Autosave
Process
Inputs
Keyboard
Network Connection
…
Disk
autosave
(long
running)
network
Physics
Render
Coll. Det. 4
Coll. Det. 3
Coll. Det. 2
Coll. Det. 1
Parallelizing the Game Loop
autosave
(long
running)
network
Physics
Render
Coll. Det. 4
Coll. Det. 3
Coll. Det. 2
• The Physics
revision updates
objects location
while Render
revision reads
locations, minor
changes don’t
affect most
computations
Coll. Det. 1
Parallelizing the Game Loop - explained
autosave
(long
running)
network
Physics
Render
Coll. Det. 4
Coll. Det. 3
Coll. Det. 2
 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 precedence!
Coll. Det. 1
Parallelizing the Game Loop - explained
Performance Evaluation
Testing environment:
Intel Xeon W3520 (quad-core) 2.66Ghz, 6GB of DDR3,
NVIDIA Quadro FX580 512MB, Windows 7 Enterprise 64-bit
Performance Evaluation
• Autosave now totally undetected and unnoticeable
• Overall speedup x3.03 than sequential run
Almost entirely depends on graphics card
Performance Evaluation - Overhead
How much did all the copying and indirection cost?
Collision detection accounts for 82% of
frame runtime
Memory
consumption
Performance
Evaluation - Overhead
• If revision writes to a versioned object then revisioning
If revision
writes
to atoversioned
object
then revisioning
subsystem
needs
clone object
to enforce
isolation.
subsystem needs to clone object to enforce isolation.
Performance Evaluation - Speed
Parallel performance
• Average speedup of 2.6x on quad-core processor
• Average speedup of 2.6x on quad-core processor
• Up to 3.03x speedup for 1500 asteroids
• Up to 3.03x speedup for 1500 asteroids
• Render task takes 95.5% of the frame time
• Render task takes 95.5% of the frame time (collisions check speedu
(collisions check speedup)
Implementation
Revisions - Implementation
sions and segments (example)
o C# Library
o Revision
o Segment
o Versioned
o Cumulative
Revisions - Implementation
Implementation
Revisions
• C# library
 Stores current segment that points to
segment created for that revision
• the
Revisions
after last fork
• Stores current segment that points to
segment
created
forright
that revision
 Rootthe
segment
is the
segment
above
forklast fork
after
• Root segment is the segment right
Segments
above fork
 Tree structure
• Segments
 Stores versioned data
• Tree structure
• Storesofversioned
data
 Ancestors
the current
segment can
be•removed
after
there issegment
no
Ancestors
of join
the ifcurrent
can
otherbe
revisions
that
uses
them.
removed after join if there is no
other revisions that uses them.
Revisions
Implementation
sions
and segments (example)
Implementation
• C# library
• 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.
Revisions
Implementation
sions and segments (example)
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
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
Questions?
Thank you