Concurrent programming with revisions and isolation types

Abstract

Building applications that are responsive and can exploit parallel hardware while remaining simple to write, understand, test, and maintain, poses an important challenge for developers. In particular, it is often desirable to enable various tasks to read or modify shared data concurrently without requiring complicated locking schemes that may throttle concurrency and introduce bugs.We introduce a mechanism that simplifies the parallel execution of different application tasks. Programmers declare what data they wish to share between tasks by using isolation types, and execute tasks concurrently by forking and joining revisions. These revisions are isolated: they read and modify their own private copy of the shared data only. A runtime creates and merges copies automatically, and resolves conflicts deterministically, in a manner declared by the chosen isolation type.To demonstrate the practical viability of our approach, we developed an efficient algorithm and an implementation in the form of a C# library, and used it to parallelize an interactive game application. Our results show that the parallelized game, while simple and very similar to the original sequential game, achieves satisfactory speedups on a multicore processor.

Semantics of Concurrent Revisions

“…A key insight that makes state merging practical and convenient is that we need not define merge functions or policies globally, but can do so separately for each variable. In fact, we used this insight in previous work to parallelize a game application [8] by declaring the policy for each variable using special isolation types. Such isolation types allow the user to convey deep semantic knowledge that helps to exploit the available parallelism even if there are numerous conflicts.…”

“…Our proposed programming model, concurrent revisions [8], simplifies parallelization of conflicting tasks by (conceptually) copying shared state automatically on a fork. Tasks execute in complete isolation because each has its own copy of the shared data (e.g.…”

“…Our previous work [8] has already provided some evidence that this concurrent revision model can be implemented efficiently enough to achieve satisfactory parallelization speedups, and that it is easier to use than locks or transactions [3]. However, our previous work left many important questions about the semantics unaddressed, in particular relating to determinacy and consistency guarantees.…”

“…In fact, it was inspired (and is very similar to) the AME calculus [24] which served a similar purpose in the context of transactional memory. Note that we published a preliminary version of this calculus (without discussion or proofs) in the previous paper [8]. 2.…”

“…4. We formalize the notion of a revision diagram (informally introduced in [8]). These diagrams capture the revision history of an execution, by showing the order and nesting of forks and joins.…”