The Compiler Parallel Support Library (CPSlib:See compiler parallel support library>
CPSlib) is a library of thread management and synchronization routines
for use in controlling parallelism. Most programs can fully exploit
their parallelism via higher-level devices such as automatic parallelization,
compiler directives, and message-passing; CPSlib is provided for
those few cases requiring a lower-level interface. Using CPSlib
requires you to manually control all aspects of parallelism, synchronization,
and data partitioning.
This appendix includes a discussion of the forms of parallelism
available via CPSlib, instructions for accessing CPSlib, a brief
description of each routine included in CPSlib, and examples of
common programming constructs as implemented using CPSlib routines.
For further information, refer to the section 3 man pages
for the routine in question, or to the cps(3) man page for an overview.
CPSlib supports two forms of parallelism: symmetric and asymmetric.
Symmetric parallelism |
 |
In symmetric parallelism, several threads execute the same
instruction stream. Symmetric parallelism is typically used by the
compilers to parallelize a loop; the description of parallelism
given in Chapter 3, "Chapter 3 “Compiler optimizations”," is a description of symmetric
parallelism.
Symmetric parallel threads are spawned using cps_ppcall()
or cps_ppcalln(), which, along
with all CPSlib routines, are described in detail further on. These
functions automatically spawn a given number of threads, which call
a specified routine in parallel. All parallel work must occur in
the called routine. When the routine returns, cps_ppcall()
or cps_ppcalln() automatically
executes a join and the program proceeds in serial.
Figure F-1 “Symmetric parallelism” shows a cps_ppcall()
that spawns two threads, each of which in turn spawns four threads.
The arrows represent a thread's instruction flow; the numbers
labeling the arrows indicate the spawn thread IDs. Kernel and spawn
thread IDs are also discussed in the section “Thread ID assignments”.
Shaded boxes represent operations hidden from the user by
cps_ppcall(). As shown in the left
branch of the first spawn, when a cps_ppcall()
or cps_ppcalln() is processed,
the parent thread is allocated to the computation as spawn thread
ID 0; its kernel thread ID, which is uninteresting to the
user, is unchanged. Additional peer threads in both spawned threads
are spawned and assigned spawn thread IDs from one to the number
of threads spawned minus one.
When the threads join, the original parent thread (spawn thread
ID 0) leaves the join after all other threads that were spawned
last have also joined. The join operation contains an implicit barrier,
so that all threads must reach the join before the original thread
continues.
Spawns and joins may thus be arbitrarily nested; however,
each thread that was allocated as a result of a spawn must eventually
join for correct program operation. The spawn thread ID has a scope
between the immediately enclosing spawn/join pair; a single
thread may change its spawn thread ID as the result of executing
a spawn or join operation.
Asymmetric parallelism |
|
Asymmetric parallelism is
used when each thread executes a
different, independent instruction stream. Asymmetric threads are
analogous to the Unix fork system
call construct; the threads are disjoint. Either the parent or the
child may terminate first in any order. Either or both the parent
and the child may spawn additional symmetric or asymmetric threads.
Asymmetric threads are spawned using the cps_thread_create()
function and terminated using the cps_thread_exit()
function. Asymmetric threads cannot
join with their parent thread; they terminate separately. If you
do not specifically call cps_thread_exit()
to terminate an asymmetric thread, the thread will automatically
terminate when the procedure called by cps_thread_create()
successfully terminates.
Figure F-2 “Asymmetric parallelism” shows an asymmetric
thread tree. Asymmetrically spawned child threads do not have spawn
thread IDs; they do, however, have unique kernel thread IDs, which
are assigned in no particular order. The parent which executed the
cps_thread_create() retains the
same kernel thread ID it had before it spawned the child thread.
You can spawn symmetric threads from asymmetric threads using
cps_ppcall and cps_ppcalln.
In this case, the parent thread retains its kernel thread ID and,
along with the symmetric threads, receives a spawn thread ID. These
symmetric threads must join before the asymmetric parent can exit;
if an asymmetric parent attempts to exit while its symmetric children
are still active, it will join instead.
Printable version
