Learning from Concurrent, Parallel, and Distributed Systems Design

calls. This might correspond to a kind of "Patch"-set or Update-Packet for remote update of a repository from a networked client at a different site.

Optimistic Offline Lock "prevents conflicts between concurrent business transactions by detecting a conflict and rolling back the transaction." This seems similar to the part of a two-phased atomic commit operation allows either all of the changes to be committed to a codeline, or none of the changes to be committed.

Pessimistic Offline Lock prevents concurrent transactions altogether by allowing only transaction at a time to access data. This seems like classic file-locking to prevent concurrent checkouts of the same file, or like Full-Codeline Locking  to prevent any other changes from being committed to the codeline at the same time (even if they are accessing completely different sets of files).

Coarse Grained Lock allows locking of a group of related objects together with a single lock. Like Remote Façade, this pattern also seems related to fine-grained artifact management. It could also correspond to locking all the files in an associated directory or component with a single (possibly scripted) operation.

Implicit Lock enforces locking policies/protocols using custom implementations that automatically perform the necessary checking and acquiring/releasing of locks in accordance with their protocol. In parallel development, we do this every time we write a script or program to automate tasks like Workspace Update and/or Task-Level Commit as part of a Two-Phased Codeline Commit .

There are other candidate patterns in this book, and even more in its companion book Enterprise Integration Patterns which may be applicable to parallel development. I encourage readers to take a look and submit their feedback to the appropriate CMCrossroads.com forum and/or the scm-patterns YahooGroup!

Paul McKenney's "selecting locking designs for parallel programs"
This work is available online at http://www.rdrop.com/users/paulmck/ and describes approximately ten locking design patterns. First it discusses the various factors that force or toward or away from a particular style of locking solution. It discusses factors like: speedup, contention, overhead, read-to-write ratio, economics, and solution complexity. I think we can all appreciate how the majority of those issues relate to parallel development. Next the paper describes the various locking design patterns, including the following:

http://www.refactoring.com/catalog/ ).

File Splitting is a common type of extraction refactoring pattern that takes a high-checkout-contention source file and splits it up into multiple files. This not only reduces checkout-contention, it also reduces the likelihood of merging and merge conflicts, and possibly also the amount of recompilation when rebuilding.

File Fusing is a common type of consolidation refactoring pattern where two (or more) files have code that so frequently must all be modified together that is makes sense to consolidate the related sections of code the same module/class in a single source file that already exists.

Doug Schmidt's TAO/ACE Patterns
Doug Schmidt and colleagues have published a significant collection of network computing design patterns for concurrent, parallel and distributed systems. The patterns are used extensively in the public domain ACE and TAO C++ and Java frameworks (see http://www.cs.wustl.edu/~schmidt/patterns-ace.html ). I won’t delve into descriptions of the patterns here; I’ll just briefly describe some possible “translations” into the domain of parallel development:

Active Object appears to resemble a combination of Transaction Script and Unit of Work to implement the concept of a Change-Task for Task-Based Development.

Scoped Locking appears similar to implementing a Two-Phased Codeline Commit mechanism to automatically lock and unlock the codeline at the appropriate times during the two-phased commit process.

Double-Checked Locking Optimization bears some resemblance to the Double-Checked Codeline Locking pattern. (In fact, the name of the latter pattern was “inspired” by that