Learning from Concurrent, Parallel, and Distributed Systems Design

• multi-threaded processing) is literally multi-tasking! It is when multiple threads are active at the same time for a single process.

For a better explanation of these and other concurrency concepts, I heartily recommend chapter 5 of Patterns of Enterprise Application Architecture , which explicitly uses examples from the area of source-code version control "because it's relatively easy to understand as well as familiar. After all, if you aren't familiar with source code control systems, you really shouldn't be developing enterprise applications."

Mapping to the Parallel Development Domain
How does it all translate into parallel development? I would suggest the following is one valid translation (and there are probably others):

• A process is like a development task (or set of related tasks), and a place to capture the evolving contents of artifacts that were created/updated as a result of the work done.
• A heavyweight process is like a project for a particular release/variant of a product or component. It can also correspond to a subproject for a significant feature.

• A lightweight process (thread) corresponds to a change-task to develop all or part of a particular fix, feature or enhancement.

• A storage area (address space) corresponds to either a  workspace in which files may be modified and temporary versions created or a  version-space, in which versions may be created (e.g., a version repository, or a branch or codeline).

• Concurrent processing corresponds to simultaneous update of a file, component, or codeline

• Parallel processing corresponds to working on multiple versions (e.g., releases, variants) of a product or component at the same time (often called multi-project development)

• Distributed processing corresponds to working on the same project across multiple networked sites at the same time (often called multi-sited development).

• Multi-threading is like having multiple change-tasks active at the same either using the same codeline, or within the same workspace.

Big Deal! So what can I do with that?

This means the field of concurrent, parallel and distributed systems is ripe for pattern mining. By studying existing patterns and solutions in that field, I can identify possible candidate patterns and solutions in the other. The trick is to always keep in mind what the corresponding problem and solution means in the new context, and if it translates into something valid or well-formed that still makes sense and is still practical. (And of course remembering that people can behave and respond quite differently than source code !)

With that in mind, let's take a look at a sampling of related patterns in this field. I chose a number of sources that are already documented in pattern form, and for which substantial material is available both online and in book form. By taking a quick tour of these patterns, we can make a quick initial guess at the potential applicability of the pattern to parallel development. I won't pretend that these initial guesses are completely accurate, nor definitive. And I'm very much interested in hearing others' ideas of how these (and other) patterns do or do not "translate" into our CM-related context.

If we are right, then in many cases these "translations" will correspond to some existing tried and true CM patterns for parallel development. In other cases, they may correspond to new or uncommon solutions - and we need to question their applicability, feasibility, or practicality unless we know more about their successfully recurring use on "real world" projects.

Fowler's Patterns of Enterprise Application Architecture
Since we already mentioned this book, let's start by looking thru some of its concurrency-related patterns. 

Data Transfer Object collects and carries data between processes "in bulk" to reduce the number of inter-process procedure