Page 46 -
P. 46
2 The Language: Rationale and Fundamentals 33
Table 2.3 Multiple instance patterns
Pattern Instance Extent of Post-synchronization
determination synchronization task handling
Multiple instances without Runtime before task None No action
synchronization initiation
Multiple instances with a Design time All instances No action
priori design time
knowledge
Multiple instances with a Runtime before task All instances No action
priori runtime knowledge initiation
Multiple instances without Runtime before task All instances No action
apriori runtime completion
knowledge
Static partial join for Runtime before task Some instances No action
multiple instances initiation
Canceling partial join for Runtime before task Some instances Cancel incomplete
multiple instances initiation instances
Dynamic partial join for Runtime during task Some instances No action
multiple instances completion
Arbitrary Cycles, where a process contains a path in the form of a cycle that
connects a set of tasks, thus allowing them to be executed multiple times. An
arbitrary cycle may have more than one entry or exit point. Figure 2.5a illustrates
two overlapping cycles involving tasks DEC and BCF .
Recursion provides a means of repeated execution of a task through the use of
self-invocation. Figure 2.5b provides an example of this pattern, where the imple-
mentation of task A is made up of a set of tasks that also include task A, hence
during its execution, task A may invoke subsequent instances of itself in order to
fulfill its operational requirements.
Repetition patterns involve the iterative execution of one or more tasks. Another
desirable property of processes is the ability for multiple instances of a task to
execute concurrently, possibly with some form of synchronization. The multiple
instance patterns document the various options in this area.
Multiple Instance (MI) Patterns
Multiple instance patterns identify scenarios where multiple instances of a task are
required to execute concurrently. There are various options for the controlled con-
currency of a task depending on the time that the required number of instances is
determined, on what basis the various instances need to be synchronized, and what
happens to any remaining instances after this synchronization has occurred. Various
combinations of these factors lead to distinct patterns as illustrated in Table 2.3.
Each of these patterns corresponds to a distinct scenario involving concurrent
execution of the same task. Figure 2.6a–e illustrate the operation of the patterns.