here - Stefan-Marr.de

2. Context and Motivation
section. For instance, the implementation of barriers that are used in parallel
programming rely on concurrent programming concepts [Marr et al., 2010b].
Thus, in many cases developers need to combine parallel and concurrent programming
techniques to account for their requirements.
It remains to be mentioned that similar definitions have been proposed
before. For instance, in the teaching material of Grossman [2012]. 9 The definitions
given by this dissertation use a different wording to avoid the implication
of performance and the concrete notions of threads, since concurrent
and parallel programming are more general.
Rationale These two definitions are partially based on the following observations:
Classic parallel programming approaches such as single program multiple
data (SPMD) techniques based on MPI [Message Passing Interface Forum,
2009] or shared memory approaches such as OpenMP [OpenMP Architecture
Review Board, 2011] are used to decompose problems to use multiple computational
resources such as processor cores. All activities in such programs
collaborate to calculate the overall result. They are coordinated by the use of
barriers and collective operations to make an abstraction of concrete data dependencies
requiring all activities to actively participate, which is trivial in a
single program model. However, even contemporary APGAS languages such
as X10 (cf. Sec. 2.4.4) provide barriers [Shirako et al., 2008], while advocating
for fork/join-like programming models that encourage a much higher degree
of dynamics than in the SPMD model.
In addition to the use of barriers, the fork/join-based programming model
in the style of Cilk [Blumofe et al., 1995] is strongly based on the notion of
collaborating activities. It uses the notion of recursive divide-and-conquer to
expose the parallelism in a problem. One important assumption that is inherent
to this model is that the recursive devision makes an abstraction of all data
dependencies. Thus, it is assumed that the resulting program is data-race-free
when it synchronizes correctly on completion of its sub-tasks. The fork/join
model itself does not provide any means to coordinate access to shared resources
other than by synchronizing on the completion of sub-tasks. Thus, all
activities have to collaborate and it is assumed that no independent activities
in the system interact in any way with the fork/join computation. Therefore,
correctness of the computation is ensured by construction and does not need
to be enforced at runtime.
9 The key notions are also mentioned in Grossman and Anderson [2012].
22