|
Pattern Name: Notation |
Background Information |
This document describes the notation used in our parallel computing pattern language. The notation provides a clear and consistent way to write down patterns throughout the language.
This section contains a brief, focused statement of the problem solved by this pattern. The goal of this section is to make it easy for a designer scanning quickly through a number of patterns to decide quickly which pattern fits the problem to be solved.
This section lists other names by which a pattern is commonly known.
A pattern is defined as a "solution to a problem in a context". This section is where we describe the context in which one would use this pattern; it explains why a design would use this pattern and what background information should be kept in mind when using it. We first describe the pattern and the context in which it can be used somewhat informally, often by means of one or more motivating examples. We then provide a more careful formal description (possibly including a link into a separate "supporting theory" document).
The goal of this section is to help the designer decide whether the pattern being described really fits the problem to be solved. We address this question in two ways: First, we discuss in clear but informal language the context in which the pattern can be applied. Second, we provide a more careful formal description (again perhaps including a link into a "supporting theory" document) of restrictions on the pattern's use, including information about unusual boundary conditions, such that a designer can be confident that if these restrictions are followed the use of the pattern will work.
This section describes key elements that an implementation of this pattern will include, or in the case of the Introduction patterns in each design space gives an overview of the other patterns in the space and how they are related.
This section describes how the pattern is used. It references other patterns as applicable to explain how it can be used to solve larger problems; where applicable, it also gives an API.
Every design decision has consequences; there are advantages and disadvantages associated with the use of any pattern. The designer must understand these issues and make tradeoffs between them. This section gives designers the information they need to intelligently manage these tradeoffs. Specific advantages and disadvantages are listed (in the form of a bulleted list) and discussed.
This section explains how to implement the pattern, usually in terms of patterns from lower-level design spaces. The discussion focuses on high-level considerations common to all or most programming environments. We use a consistent format for this section, consisting of an introduction and the following subsections.
In this section we discuss each of the elements named in the Structure section.
In this section we summarize key results from supporting theory, ideally in the form of detailed guidelines that if followed carefully will result in correct programs.
In this section we discuss implementation issues that affect efficiency.
Programmers learn by example. In this section, we support this mode of learning by providing an implementation or implementations of the pattern in a particular programming environment. For patterns in higher-level design spaces, we often provide simply a pseudocode implementation; for patterns in lower-level design spaces, we provide sample code based on one or more popular programming environments such as OpenMP, MPI, or Java. Here too we use a consistent format; for each example we provide a problem description and a bulleted list of solutions (with details provided via links to separate documents).
The problem description goes here. Solutions are listed:
This section describes contexts in which the pattern has been used, including real programs, where possible in the form of literature references.
This section lists patterns related to this pattern. In some cases, a small change in the parameters of the problem can mean that a different pattern is indicated; this section notes such cases. Circumstances in which designers should use a different pattern are spelled out in detail.