archives

Distributed Transactional Memory

Hi, I am new to this Forum. I hope this will be of interest to this community. I am working on a project that tries to combine some of the strengths of shared state and of the Actor model. How to allow developers to model the world using object orientation, while offering safety and composability when writing parallel and distributed applications? The option I am exploring is an innovative STM implementation, with very simple transactions semantics and an extension mechanism to allow custom processing of transactions' write sets. Transactions are View Isolated, i.e. take a full and stable snapshot of memory, without significantly compromising performance thanks to a new lock free algorithm. Transactions never read inconsistent data, do not abort while partially executed, and global progress is guaranteed. The extension mechanism allows processing like logging every changes occurring on transactional objects. Our most sophisticated extension sends transactions’ data over a network, and commits them identically on two machines. This enables a high-performance form of object replication. Our implementations can replicate data between Java, .NET and GWT. If you are at JavaOne next week, I am going to present the project on Monday:

Session ID: S312949
Title: Simpler and Faster Cloud Applications Using Distributed Transactional Memory
Duration: 60 min.
Schedule: Monday, September 20, 13:00 | Parc 55, Powell I / II

A paper is available here and an open-source implementation here.

Comments suggestions welcome.
Thanks.

OoO Java

We typically hear about optimistic transactional memory, so it's refreshing to see analysis-driven work on the pessimistic side in OoOJava: Software Out-of-Order Execution. Of note, they guarantee determinism:

Developing parallel software using current tools can be challenging. Even experts find it difficult to reason about the use of locks and often accidentally introduce race conditions and deadlocks into parallel software. We present OoOJava, a new approach to parallel programming inspired by out-of-order processors. Out-of-order processors have long extracted unstructured parallelism from sequential instruction streams. In our approach, a developer annotates code blocks as tasks to decouple these blocks from the parent execution thread. OoOJava extracts all data dependences through static analysis to generate an executable that is guaranteed to preserve the behavior of the original sequential program.

We have implemented OoOJava and achieved an average speedup of 15.3× on our nine benchmarks. The combination of a simple parallelism model, compiler feedback, and speedups are indications that out-of-order execution-based programming models can become mainstream.

(James C. Jenista, Yong hun Eom, and Brian Demsky)

In discussions with the authors, it seems that the evaluation benchmarks were on embarrassingly parallel programs with no library dependencies, so there are many questions left to answer about the pragmatics involved.

Perhaps another interesting paper in this vein is Deterministic Parallel Java which takes a type specification based approach. A question arises of software engineering: when writing a maintainable parallel programs with potential algorithmic interference, which invariants should we specify? If just basic task boundaries, OoOJ is almost like program analysis (instead of type inference) for DPJ; if non-interference guarantees, we start to get a very different picture.