The simplest and oldest flow of control is the process, which wraps a complete address space around a flow of control. All modern machines support multiple processes, although some parallel machines or schedulers do not allow them or place restrictions on them. For example, Myricom's GM interface does not allow fork or system calls while Myrinet network ports are open. Other exceptions include the Blue Gene/L [2] and ASCI Red [36] microkernels, which do not have conventional virtual memory systems and hence do not support UNIX system calls such as fork, system and exec.
The advantage of the process model is its complete separation of state. Because a processes' flow of control is completely walled off within its own separate address space and operating system context, processes fully support separate global variables, memory management, blocking I/O calls, and signals.
However, for parallel programming, the total separation of the process model makes it more difficult to communicate between the various flows of control that make up a program. Processes can only interact using relatively limited, cumbersome methods such as pipes and sockets, or with more difficult explicitly shared memory regions such as SYSV Interprocess Communication (IPC). Furthermore, processes are considered ``heavy-weight''. The substantial amount of per-process kernel state increases the amount of memory used by each process, and increases the overhead of process creation and switching. Worse, some operating systems have a fixed and fairly low limit on the number of processes that can be created. Table 2 in Section 4 summarizes these practical limitations on several stock systems.