Keep in mind that the name multicore is a popular substitution for single chip multiprocessor or CMP. Multiprocessors are computers that have more than two or more CPUs or processors. Although multiprocessor computers have been around for some time now, the wide availability and low cost of the CMP has brought multiprocessor capabilities within the reach of virtually all software developers. This raises a series of questions: How do single applications take advantage of CMPs? How do single user versus multiple user applications take advantage of CMPs? Using C++ how do you take advantage of the operating system's multiprocessing and multiprogramming capabilities? Once you have a software design that includes a requirement for some tasks to execute concurrently, how do you map those tasks to the multiple processors available in your multicore computers?

Recall from Chapter 4 that the operating system schedules execution units that it can understand. If your software design consists of some tasks that can be executed in parallel, you will have to find a way to relate those tasks to execution units the operating system can understand. Association of your tasks with operating system execution units is part of a four-stage process involving three transformations.

Each transformation in Figure 5-1 changes the view of the model, but the meaning of the model should remain intact. That is, the implementation of the application frameworks, class libraries, and templates as processes and threads should not change the meaning or semantics of what those components are doing. The execution units in stage four are what the operating system deals with directly. The execution units shown in stage four of Figure 5-1 are the only things that can be assigned directly to the cores. From the operating system's viewpoint your application is a collection of one or more processes. Concurrency in a C++ application is ultimately accomplished by factoring your program into either multiple processes or multiple threads. While there are variations on how the logic for a C++ program can be organized (for example, within objects, predicates, functions, or generic templates), the options for parallelization (with the exception of instruction level) are accounted for through the use of multiple processes and threads.

Figure 5.1. Figure 5-1

This chapter focuses on the notion of a process and how C++ applications and programs can be divided into multiple processes using the POSIX API process management services.

A process is a unit of work created by the operating system. It is important to note that processes and programs are not necessarily equivalent. A program may consist of multiple tasks, and each task can be associated with one or more processes. Processes are artifacts of the operating system, and programs are artifacts of the developer. Current operating systems are capable of managing hundreds even thousands of concurrently loaded processes. In order for a unit of work to be called a process, it must have an address space assigned to it by the operating system. It must have a process id. It must have a state and an entry in the process table. According to the POSIX standard, it must have one or more flows of controls executing within that address space and the required system resources for those flows of control. A process has a set of executing instructions that resides in the address space of that process. Space is allocated for the instructions, any data that belongs to the process, and stacks for functions calls and local variables. One of the important differences between a process and a thread is the fact that each process has its own address space, whereas threads share the address space of the processes that created them. A program can be broken down into one or more processes.

When you are mapping C++ tasks to execution units that the operating system can understand, threads turn out to be easier to program. This is because threads share the same address space. This makes communication and synchronization between threads much easier. It takes the operating system less work to create a thread or to terminate a thread than it takes for processes. In general, you can create more threads within the context of a single computer than processes. The starting and stopping of threads is typically faster than processes.

So why use processes at all? First, processes have their own address space. This is important because separate address spaces provide a certain amount security and isolation from rogue or poorly designed processes. Second, the number of open files that threads may use is limited to how many open files a single process can have. Dividing your C++ application up into multiple processes instead of or in conjunction with multithreading provides access to more open file resources. For multiuser applications, you want each user's process to be isolated. If one user's process fails, the other users can continue to perform work. If you use some threading approach for multiuser applications, a single errant thread can disrupt all the users. Operating system resources are assigned primarily to processes and then shared by threads. So, in general, threads are limited to the number of resources that a single process can have. Thus, when isolation security, address space isolation, and maximum number of resources that concurrently executing tasks may have are major concerns, it is better to use processes than threads. Communication between processes and startup time are the primary tradeoffs.

The functions listed in Table 5-1 are declared in spawn.h. This header contains the POSIX functions used to spawn and manage processes.

posix_spawn()
posix_spawnp()

posix_spawnattr_init()

posix_spawnattr_destroy()

posix_spawnattr_setsigdefault()
posix_spawnattr_getsigdefault()
posix_spawnattr_setsigmask()
posix_spawnattr_getsigmask()
posix_spawnattr_setflags()
posix_spawnattr_getflags()
posix_spawnattr_setpgroup()
posix_spawnattr_getpgroup()

posix_spawnattr_setschedparam()
posix_spawnattr_setschedpolicy()
posix_spawnattr_getschedparam()
posix_spawnattr_getschedpolicy()
sched_setscheduler()
sched_setparm()

posix_spawn_file_actions_addclose()
posix_spawn_file_actions_adddup2()
posix_spawn_file_actions_addopen()
posix_spawn_file_actions_destroy()
posix_spawn_file_actions_init()

Similarly to the fork-exec() and system() methods of process creation, the posix_spawn() functions create new child processes from specified process images. But the posix_spawn() functions create child processes with more fine-grained control during creation. While the POSIX API also supports the fork-exec() class of functions, we focus on the posix_spawn functions for process creation to achieve greater cross-platform compatibility. Some platforms may have trouble implementing fork(), so the posix_spawn() functions can be used as substitution. These functions control the attributes that the child process inherits from the parent process, including:

They also control whether signals ignored by the parent are ignored by the child or reset to some default action. Controlling file descriptors allow the child process independent access to the data stream opened by the parent. Being able to set the child's process group id affects how the child's job control relates to that of the parent. The child's scheduling policy can be set to be different from the scheduling policy of the parent.

Synopsis

#include <spawn.h>

int posix_spawn(pid_t *restrict pid, const char *restrict path,
                const posix_spawn_file_actions_t *file_actions,
                const posix_spawnattr_t *restrict attrp,
                char *const argv[restrict],
                char *const envp[restrict]);
int posix_spawnp(pid_t *restrict pid, const char *restrict file,
                 const posix_spawn_file_actions_t *file_actions,
                 const posix_spawnattr_t *restrict attrp,
                 char *const argv[restrict],
                 char *const envp[restrict]);

The difference between these two functions is that posix_spawn() has a path parameter and posix_spawnp() has a file parameter. The path parameter in the posix_spawn() function is the absolute or relative pathname to the executable program file. file in posix_spawnp() is the name of the executable program. If the parameter contains a slash, then file is used as a pathname. If not, the path to the executable is determined by PATH environment variable.

struct posix_spawn_file_actions_t{
{
   int __allocated;
   int __used;
   struct __spawn_action *actions;
   int __pad[16];
};

int
posix_spawn_file_actions_addclose
 (posix_spawn_file_actions_t
  *file_actions, int fildes);

int
posix_spawn_file_actions_addopen
(posix_spawn_file_actions_t
 *file_actions, int fildes,
 const char *restrict path,
 int oflag, mode_t mode);

int
posix_spawn_file_actions_adddup2
 (posix_spawn_file_actions_t
 *file_actions, int fildes,
int newfildes);

int
posix_spawn_file_actions_destroy
 (posix_spawn_file_actions_t
  *file_actions);

int
posix_spawn_file_actions_init
 (posix_spawn_file_actions_t
  *file_actions);

struct posix_spawnattr_t
{
   short int __flags;
   pid_t __pgrp;
   sigset_t __sd;
   sigset_t __ss;
   struct sched_param __sp;
   int __policy;
   int __pad[16];
}

int posix_spawnattr_getflags
(const posix_spawnattr_t *restrict
attr, short *restrict flags);

int posix_spawnattr_setflags
(posix_spawnattr_t *attr,
 short flags);

int posix_spawnattr_getpgroup
(const posix_spawnattr_t *restrict
 attr, pid_t *restrict pgroup);

int posix_spawnattr_setpgroup
(posix_spawnattr_t *attr,
pid_t pgroup);

int posix_spawnattr_getschedparam
(const posix_spawnattr_t
*restrict attr, struct sched_param
*restrict schedparam);

int posix_spawnattr_setschedparam
(posix_spawnattr_t *attr,
 const struct sched_param *restrict
 schedparam);

int posix_spawnattr_getpschedpolicy
(const posix_spawnattr_t *restrict
 attr, int *restrict schedpolicy);

int posix_spawnattr_setpschedpolicy
(posix_spawnattr_t *attr,
 int schedpolicy);

int posix_spawnattr_getsigdefault
(const posix_spawnattr_t *restrict
 attr, sigset_t *restrict
 sigdefault);

int posix_spawnattr_setsigdefault
(posix_spawnattr_t *attr,
 const sigset_t *restrict
 sigdefault);

int posix_spawnattr_getsigmask
(const posix_spawnattr_t *restrict
 attr, sigset_t *restrict sigmask);

int posix_spawnattr_setsigmask
(posix_spawnattr_t *restrict attr,
 const sigset_t *restrict sigmask);

int posix_spawnattr_destroy
(posix_spawnattr_t *attr);

int posix_spawnattr_init
(posix_spawnattr_t *attr);

// Example 5-1 Spawns a process, using the posix_spawn()
// function that calls the ps utility.

#include <spawn.h>
#include <stdio.h>
#include <errno.h>
#include <iostream>
{
   //...
   posix_spawnattr_t X;
   posix_spawn_file_actions_t Y;
   pid_t Pid;
   char * argv[] = {"/bin/ps","-lf",NULL};
   char * envp[] = {"PROCESSES=2"};
   posix_spawnattr_init(&X);
   posix_spawn_file_actions_init(&Y);
   posix_spawn(&Pid,"/bin/ps",&Y,&X,argv,envp);
   perror("posix_spawn");
   cout << "spawned PID: " << Pid << endl;
   //...
   return(0);

}

posix_spawn: Success

/bin/ps -lf

// Listing 5-1  Program used to launch ofind_code.

 1  using namespace std;
 2  #include <iostream>
 3  #include <string>
 4  #include <spawn.h>
 5  #include <sys/wait.h>
 6
 7  int main(int argc,char *argv[],char *envp[])
 8  {
 9
10     pid_t ChildProcess;
11     pid_t ChildProcess2;
12     int RetCode1;
13     int RetCode2;
14     int Value;
15     RetCode1 = posix_spawn(&ChildProcess,"find_code",NULL,
16                              NULL,argv,envp);
17     RetCode2 = posix_spawn(&ChildProcess2,"find_code",NULL,
18                              NULL,argv,envp);
19     wait(&Value);
20     wait(&Value);
21     return(0);
22  }

//Listing 5-2  An initial interface class for a posix process.

 1  #ifndef __POSIX_PROCESS_H
 2  #define __POSIX_PROCESS_H
 3  using namespace std;
 4
 5  #include <spawn.h>
 6  #include <errno.h>
 7  #include <iostream>
 8  #include <string>
 9
10
11  class posix_process{
12  protected:
13     pid_t  Pid;
14     posix_spawnattr_t   SpawnAttr;
15     posix_spawn_file_actions_t   FileActions;
16     char **argv;
17     char **envp;
18     string ProgramPath;
19  public:
20     posix_process(string Path,char **av,char **env);
21     posix_process(string Path,char **av,char **env, posix_spawnattr_t X,
                     posix_spawn_file_actions_t Y);
22     void run(void);
23     void pwait(int &X);
24  };
25
26
27  #endif
28

//Listing 5-3  Our guess_it program using an interface class for the posix_spawn
capability.


 1  #include "posix_process.h"
 2
 3  int main(int argc,char *argv[],char *envp[])
 4  {
 5     int Value;
 6     posix_process  Child1("ofind_code",argv,envp);
 7     posix_process  Child2("ofind_code",argv,envp);
 8     Child1.run();
 9     Child2.run();
10     Child1.pwait(&Value);
11     Child2.pwait(&Value);
12     return(0);
13  }
14

vector<posix_process>
list<posix_process>
multiset<posix_process>
etc...

// Listing 5-4 The initial method definitions for the posix_process interface class.

 1  #include "posix_process.h"
 2  #include <sys/wait.h>
 3
 4
 5  posix_process::posix_process(string Path,char **av,char **env)
 6  {
 7
 8     argv = av;
 9     envp = env;
10     ProgramPath = Path;
11     posix_spawnattr_init(&SpawnAttr);
12     posix_spawn_file_actions_init(&FileActions);
13
14

15  }
16
17  posix_process::posix_process(string Path,char **av,char **env,
                   posix_spawnattr_t  X, posix_spawn_file_actions_t Y)
18  {
19     argv = av;
20     envp = env;
21     ProgramPath = Path;
22     SpawnAttr = X;
23     FileActions = Y;
24     posix_spawnattr_init(&SpawnAttr);
25     posix_spawn_file_actions_init(&FileActions);
26
27
28
29  }
30
31  void posix_process::run(void)
32  {
33
34     posix_spawn(&Pid,ProgramPath.c_str(),&FileActions,
                   &SpawnAttr,argv,envp);
35
36
37  }
38
39  void posix_process::pwait(int &X)
40  {
41
42     wait(&X);
43  }

There are two functions that return the process id (PID) of the process and parent process:

These functions are always successful; therefore no errors are defined.

Synopsis

#include <unistd.h>

pid_t getpid(void);
pid_t getppid(void);

When a process executes, the operating system assigns the process to a processor. The process executes its instructions for a quantum. The process is preempted, so another process can be assigned the processor. The operating system scheduler switches between the code of one process, user, or system to the code of another process, giving each process a chance to execute its instructions. There are system and user processes.

Anatomy of a Process

The address space of a process is divided into three logical segments: text (program code), data, and stack segments. Figure 5-2 shows the logical layout of a process. The text segment is at the bottom of the address space. The text segment contains the instructions to be executed called the program code. The data segment above it contains the initialized global, external, and static variables for the process. The stack segment contains locally allocated variables and parameters passed to functions. Because a process can make system function calls as well as user-defined function calls, two stacks are maintained in the stack segment, the user stack and the kernel stack. When a function call is made, a stack-frame is constructed and pushed onto either the user or kernel stack, depending on whether the process is in user or kernel mode. The stack segment grows downward toward the data segment. The stack frame is popped from the stack when the function returns. The text, data, and stack segments and the process control block are part of what forms the process image.

Figure 5.2. Figure 5-2

The address space of a process is virtual. Virtual storage dissociates the addresses referenced in an executing process from the addresses actually available in internal memory. This allows the addressing of storage space much larger than what is available. The segments of the process's virtual address space are contiguous blocks of memory. Each segment and physical address space are broken up into chunks called pages. Each page has a unique page frame number. The virtual page frame number (VPFN) is used as an index into the process's page tables. The page tables entries contain a physical page frame number (PFN), thus mapping the virtual page frames to physical page frames. This is depicted in Figure 5-3. As illustrated, virtual address space is contiguous but it is mapped to physical pages in any order.

Figure 5.3. Figure 5-3

Even though the virtual address space of each process is protected to prevent another process from accessing it, the text segment of a process can be shared among several processes. Figure 5-3 also shows how two processes can share the same program code. The same physical page frame number is stored in the page table entries of both processes' page tables. As illustrated in Figure 5-3, process A's virtual page frame 0 is mapped to physical page frame 5, as is process B's virtual page frame 2.

For the operating system to manage all the processes stored in internal memory, it creates and maintains process tables. Actually, the operating system has a table for all of the entities that it manages. Keep in mind that the operating system manages not only processes but all the resources of the computer including devices, memory, and files. Some of the memory, devices, and files are managed on the behalf of the user processes. This information is referenced in the PCB as resources allocated to the process. The process table has an entry for each process image in memory. This is depicted in Figure 5-4. Each entry contains the process and parent process id; the real and effective user id and group id; a list of pending signals; the location of the text, data, and stack segments; and the current state of the process. When the operating system needs to access a process, the process is looked up in the process table, and then the process image is located in memory.

Figure 5.4. Figure 5-4

Process States

During a process's execution, it changes its state. The state of the process is the current condition or status of the process. In a POSIX-compliant environment, a process can be in the following states:

• Running

• Runnable (ready)

• Zombied

• Waiting (blocked)

• Stopped

The current condition of the process depends upon the circumstances created by the process or by the operating system. When certain circumstances exist, the process will change its state. State transition is the circumstance that causes the process to change its state. Figure 5-5 is the state diagram for the processes. The state diagram has nodes and directed edges between the nodes. Each node represents the state of the process. The directed edges between the nodes are state transitions. Table 5-4 lists the state transitions with a brief description. As Figure 5-5 and Table 5-4 show, only certain transitions are allowed between states. For example, there is a transition, an edge, between ready and running, but there is no transition, no edge, between sleeping and running. Meaning, there are circumstances that causes a process to move from the ready state to the running state, but there are no circumstances that cause a process to move from the sleeping state to a running state.

Figure 5.5. Figure 5-5

Table 5.4. Table 5-4

State Transitions	Descriptions
READY->RUNNING (dispatch)	The process is assigned to the processor.
RUNNING->READY(timer runout)	The time slice the process assigned to the processor has run out. The process is placed back in the ready queue.
RUNNING->READY(preempt)	The process has been preempted before the time slice ran out. This can occur if a process with a higher priority is runnable. The process is placed back in the ready queue.
RUNNING->SLEEPING (block)	The process gives up the processor before the time slice has run out. The process may need to wait for an event or has made a system call, for example, a request for I/O. The process is placed in a queue with other sleeping processes.
SLEEPING->READY (unblock)	The event the process was waiting for has occurred, or the system call has completed. For example, the I/O request is filled. The process is placed back in the ready queue.
RUNNING->STOPPED	The process gives up the processor because it has received a signal to stop.
STOPPED->READY	The process has received the signal to continue and is placed back in the ready queue.
RUNNING->ZOMBIED	The process has been terminated and awaits the parent to retrieve its exit status from the process table.
ZOMBIED->EXIT	The parent process has retrieved the exit status, and the process exits the system.
RUNNING->EXIT	The process has terminated, the parent has retrieved the exit status, and the process exits the system.

When a process is created, it is ready to execute its instructions but must first wait until the processor is available. Each process is allowed to use the processor only for a discrete interval called a time slice. Processes waiting to use the processor are placed in ready queues. Only processes in the ready queues are selected (by the scheduler) to use the processor. Processes in the ready queues are runnable. When the processor is available, a runnable process is assigned the processor by the dispatcher. When the time slice has expired, the process is removed from the processor, whether it has finished executing all its instructions or not. The process is placed back in the ready queue to wait for its next turn to use the processor. A new process is selected from a ready queue and is given its time slice to execute. System processes are not preempted. When they are given the processor, they run until completion. If the time slice has not expired, a process may voluntarily give up the processor if it cannot continue to execute because it must wait for an event to occur. The process may have made a request to access an I/O device by making a system call, or it may need to wait on a synchronization variable to be released. Processes that cannot continue to execute because they are waiting for an event to occur are in a sleeping state. They are placed in a queue with other sleeping processes. They are removed from that queue and placed back in the ready queue when the event has occurred. The processor may be taken away from a process before its time slice has run out. This may occur if a process with a higher priority, like a system process, is runnable. The preempted process is still runnable and, therefore, is placed back in the ready queue.

A running process can receive a signal to stop. The stopped state is different from a sleeping state. The process's time slice has not expired nor has the process made any request of the system. The process may receive a signal to stop because it is being debugged or some situation has occurred in the system. The process has made a transition from running to stopped state. Later the process may be awakened, or it may be destroyed.

When a process has executed all its instructions, it exits the system. The process is removed from the process table, the PCB is destroyed, and all of its resources are deallocated and returned to the system pool of available resources. A process that is unable to continue executing but cannot exit the system is in a zombied state. A zombied process does not use any system resources, but it still maintains an entry in the process table. When the process table contains too many zombied processes, this can affect the performance of the system, possibly causing the system to reboot.

How Are Processes Scheduled?

When a ready queue contains several processes, the scheduler must determine which process should be assigned to a processor first. The scheduler maintains data structures that allow it to schedule the processes in an efficient manner. Each process is given a priority class and placed in a priority queue with other runnable processes with the same priority class. There are multiple priority queues, each representing a different priority class used by the system. These priority queues are stratified and placed in a dispatch array called the multilevel priority queue. Figure 5-6 depicts the multilevel priority queue. Each element in the array points to a priority queue. The scheduler assigns the process at the head of the nonempty highest priority queue to the processor.

Figure 5.6. Figure 5-6

Priorities can be dynamic or static. Once a static priority of a process is set, it cannot be changed. Dynamic priorities can be changed. Processes with the highest priority can monopolize the use of the processor. If the priority of a process is dynamic, the initial priority can be adjusted to a more appropriate value. The process is placed in a priority queue that has a higher priority. A process monopolizing the processor can also be given a lower priority, or other processes can be given a higher priority than that process has. When you are assigning priority to a user process, consider what the process spends most of its time doing. Some processes are CPU-intensive. CPU-intensive processes use the processor for the whole time slice. Some processes spend most of its time waiting for I/O or some other event to occur. When such a process is ready to use the processor, it should be given the processor immediately so it can make its next request for I/O. Processes that are interactive may require a high priority to assure good response time. System processes have a higher priority than user processes.

The processes are placed in a priority queue according to a scheduling policy. Two of the primary scheduling policies used in the POSIX API are the First-In, First-Out (FIFO) and round robin (RR) policies.

• Figure 5-7 (a) shows the FIFO scheduling policy. With a FIFO scheduling policy, processes are assigned the processor according to the arrival time in the queue. When a running process time slice has expired, it is placed at the head of its priority queue. When a sleeping process becomes runnable, the process is placed at the end of its priority queue. A process can make a system call and give up the processor to another process with the same priority level. The process is then placed at the end of its priority queue.

• In round robin scheduling policy, all processes are considered equal. Figure 5-7 (b) depicts the RR scheduling policy. RR scheduling is the same as FIFO scheduling with one exception: When the time slice expires, the process is placed at the back of the queue and the next process in the queue is assigned the processor.

Figure 5.7. Figure 5-7

Figure 5-7 shows the behavior of the FIFO and RR scheduling policies. The FIFO scheduling policy assigns processes to the processor according to its arrival time in the queue. The process runs until completion. RR scheduling policy assigns processes using FIFO scheduling, but when the time slice runs out, the process is placed at the back of the ready queue.

The ps utility generates a report that summarizes execution statistics for the current processes. This information can be used to monitor the status of current processes. Table 5-5 lists the common headers and the meaning of the output for the ps utility for the Solaris/Linux environments.

In a multiprocessor environment, the ps utility is useful to monitor the state, CPU and memory usage, processor utilized, priority, and start time of the current processes executing. Command options control which processes are listed and what information is displayed about each process. In the Solaris environment, by default (meaning no command options are used), information about processes with the same effective user id and controlling terminal of the calling invoker is displayed. In the Linux environment, by default, the processes with the same user id as the invoker are displayed. In both environments, the only information that is displayed is PID, TTY, TIME, and COMMAND. These are some of the options that control which processes are displayed:

Synopsis

(Linux)
ps -[Unix98 options]
   [BSD-style options]
   --[GNU-style long options

(Solaris)
ps [-aAdeflcjLPy][-o format][-t termlist][-u userlist]
   [-G grouplist][-p proclist][-g pgrplist][-s sidlist]

The following lists some of the command options used to control the information displayed about the processes:

This is an example of using the ps utility in Solaris/Linux environments:

ps -f

This displays information about the default processes in each environment. Figure 5-8 shows the output in the Solaris environment. The command options can also be used in tandem. Figure 5-8 also shows the output of using -l and -f together in the Solaris environment:

ps -lf

Figure 5.8. Figure 5-8

The -l command option shows the additional headers F, S, PRI, NI, ADDR, SZ, and WCHAN.

The P command option displays the PSR header. Under this header is the number of the processor to which the process is assigned or bound.

Figure 5-9 shows the output of the ps utility using the Tux command options in the Linux environment.

Figure 5.9. Figure 5-9

The %CPU, %MEM, and STAT information is displayed for the processes. In a multiprocessor environment, this information can be used to monitor which processes are dominating CPU and memory usage. The STAT header shows the state or status of the process. Table 5-6 lists how the status is encoded and their meanings.

The STAT header can reveal additional information about the status of the process:

These codes precede the status codes. If an N precedes the status, this means that the process is running at a lower priority level. If a process has a status S<W, this means the process is sleeping, swapped out, and has a high priority level.

The priority level of a process can be changed by using the nice() function. Each process has a nice value that is used to calculate the priority level of the calling process. A process inherits the priority of the process that created it. But the priority of a process can be lowered by raising its nice value. Only superuser and kernel processes can raise priority levels.

Synopsis

#include <unistd.h>

int nice(int incr);

A low nice value raises the priority level of the process. The incr parameter is the value added to the current nice value of the calling process. The incr can be negative or positive. The nice value is a non-negative number. A positive incr value raises the nice value, thus lowering the priority level. A negative incr value lowers the nice value, thus raising the priority level. If the incr value raises the nice value above or below its limits, the nice value of the process is set to the highest or lowest limit accordingly. If successful, the nice() function returns the new nice value of the process. If unsuccessful, the function returns −1, and the nice value is not changed.

Synopsis

#include <sys/resource.h>

int getpriority(int which, id_t who);
int setpriority(int which, id_t who, int value);

setpriority() sets the nice value for a process, process group, or user. getpriority() returns the priority of a process, process group, or user. Example 5-2 shows the syntax for the functions setpriority() and getpriority() to set and return the nice value of the current process.

//Example 5-2 shows how setpriority() and getpriority() can be used.

#include <sys/resource.h>

//...
id_t pid = 0;
int which  = PRIO_PROCESS;
int value = 10;
int nice_value;
int ret;

nice_value = getpriority(which,pid);
if(nice_value < value){
   ret = setpriority(which,pid,value);
}
//...

In Example 5-2, the priority of the calling process is being returned and set. If the calling process's nice value is < 10, the nice value of the process is set to 10. The target process is determined by the values stored in the which and who parameters. The which parameter can specify a process, process group, or a user. It can have the following values:

Depending on the value of which, the who parameter is the id number of a process, process group, or effective user. In Example 5-2, which is assigned PRIO_PROCESS. A 0 value for who indicates the current process, process group, or user. In Example 5-2, who is set to 0, indicating that the current process value for setpriority() will be the new nice value for the specified process, process group, or user.

The range of nice value in the Linux environment is −20 to 19. In Example 5-2, the value of nice is set to 10 if the current nice value is less than 10. In contrast to how things worked with the function nice(), the value passed to setpriority() is the actual value of nice, not an offset to be added to the current nice value. In a process with multiple threads, the modification of the priority affects the priority of all the threads in that process. If successful, getpriority() returns the nice value of the specified process. If successful, setpriority() returns 0. If unsuccessful, both functions return −1. The return value −1 is a legitimate nice value for a process. To determine if an error has occurred, check the external variable errno.

A context switch occurs when the use of the processor is switched from one process to another process. When a context switch occurs, the system saves the context of the current running process and restores the context of the next process selected to use the processor. The PCB of the preempted process is updated. The process state field is changed from the running to the appropriate state (runnable, blocked, zombied, or so forth). The contents of the processor's registers, state of the stack, user and process identification and privileges, and scheduling and accounting information are saved and updated.

The system must keep track of the status of the process's I/O and other resources, and any memory management data structures. The preempted process is placed in the appropriate queue.

A context switch occurs when a:

When the preempted process is selected to use the processor again, its context is restored, and execution continues where it left off.

To run any program, the operating system must first create a process. When a new process is created, a new entry is placed in the main process table. A new PCB is created and initialized. The process identification portion of the PCB contains a unique process id number and the parent process id. The program counter is set to point to the program entry point, and the system stack pointers are set to define the stack boundaries for the process. The process is initialized with any of the attributes requested. If the process is not given a priority value, it is given the lowest-priority value by default. The process initially does not own any resources unless there is an explicit request for resources or they have been inherited from the creator process. The state of the process is runnable, and it is placed in the runnable or ready queue. Address space is allocated for the process. How much space to be set aside can be determined by default, based on the type of process. The size can also be set as a request by the creator of the process. The creator process can pass the size of the address space to the system at the time the process is created.

#include <unistd.h>

pid_t fork(void);

// Example 5-3 Using the fork-exec system calls.

//...
RtValue = fork();
if(RtValue == 0){
   execl("/home/user/direct","direct",".");
}

char *const args[] = {"direct",".",NULL};
char *const envp[] = {"files=50",NULL};

execl("/home/tracey/direct","direct",".",NULL);
execle("/home/tracey/direct","direct",".",NULL,envp);
execlp("direct","direct",".",NULL);

#include <unistd.h>

int execl(const char *path,const char *arg0,.../*,(char *)0 */);
int execle(const char *path,const char *arg0,.../*,
          (char *)0 *,char *const envp[]*/);
int execv(const char *path,char *const arg[]);
int execlp(const char *file,const char *arg0,.../*,(char *)0 */);
int execve(const char *path,char *const arg[],
           char *const envp[]);
int execvp(const char *file,char *const arg[]);

char *const arg[] = {"traverse",".", ">","1000",NULL};
char *const envp[] = {"files=50",NULL};

execv("/home/tracey/traverse",arg);
execve("/home/tracey/traverse",arg,envp);
execvp("traverse",arg);

#include <unistd.h>

long sysconf(int name);

Environment variables are null-terminated strings that store system-dependent information such as paths to directories that contain commands, libraries, functions, and procedures used by a process. They can also be used to transmit any useful user-defined information between the parent and the child processes. They are a mechanism for providing specific information to a process without having it hardcoded in the program code. System environment variables are predefined and common to all shells and processes in that system. The variables are initialized by startup files. These are the common system variables:

They can be stored in a file or in an environment list. The environment list contains pointers to null-terminated strings. The variable:

extern char **environ

points to the environment list when the process begins to execute. These strings have the form:

name=value

as explained earlier. Processes initialized with the functions execl(), execlp(), execv(), and execvp() inherit the environment of the parent process. Processes initialized with the functions execve() and execle() set the environment for the new process.

There are functions and utilities that can be called to examine, add, or modify environment variables. getenv() is used to determine whether a specific variable has been set. The parameter name is the environment variable in question. The function returns NULL if the specified variable has not been set. If the variable has been set, the function returns a pointer to a string containing the value.

Synopsis

#include <stdlib.h>

char *getenv(const char *name);
int setenv(const char *name, const char *value, int overwrite);
void unsetenv(const char *name);

For example:

string Path;

Path = getenv("PATH");

the string Path is assigned the value contained in the predefined environment PATH.

setenv()is used to change or add an environment variable. The parameter name contains the name of the environment variable added with the value stored in value. If the name variable already exists, then the value is changed to value if the overwrite parameter is non-zero. If overwrite is 0, the content of the specified environment variable is not modified. setenv() returns 0 if it is successful and −1 if it is unsuccessful. The unsetenv() removes the environment variable specified by name.

system() is another function that is used to execute a command or executable program. system() causes the execution of fork(), exec(), and a shell. The system() function executes a fork(), and the child process calls an exec() with a shell that executes the given command or program.

Synopsis

#include <stdlib.h>

int system(const char *string);

The string parameter can be a system command or the name of an executable file. If successful, the function returns the termination status of the command or return value (if any) of the program. Errors can happen at several levels; the fork() or exec() may fail, or the shell may not be able to execute the command or program.

The function returns a value to the parent process. The function returns 127 if the exec() fails and −1 if some other error occurs. The return code of the command is returned if the function succeeds. This function does not affect the wait status of any of the child processes.

When a process is terminated, the PCB is erased, and the address space and resources used by the terminated process are deallocated. An exit code is placed in its entry in the main process table. The entry is removed once the parent has accepted the exit code. The termination of the process can occur under several conditions:

Abnormal termination of a process can occur when the process itself does something that it shouldn't:

The termination of a process can also be initiated by a user when the process is interactive.

The parent process is responsible for the termination/deallocation of its children. The parent process should wait until all its child processes have terminated. When a parent process retrieves a child process's exit code, the child process exits the system normally. The process is in a zombied state until the parent accepts the signal. If the parent never accepts the signal because it has already terminated and exited the system or because it is not waiting for the child process, the child remains in the zombied state until the init process (the original system process) accepts its exit code. Many zombied processes can negatively affect the performance of the system.

#include <stdlib.h>

void exit(int status);
void abort(void);

#include <signal.h>

int kill(pid_t pid, int sig);

In order for a process to perform whatever task it is instructed to perform, it may need to write data to a file, send data to a printer, or display data to the screen. A process may need input from the user via the keyboard or input from a file. Processes can also use other processes such as a subroutine as a resource. Subroutines, files, semaphores, mutexes, keyboards, and display screens are all examples of resources that can be utilized by a process. A resource is anything used by the process at any given time as a source of data, as a means to process or compute, or as the means by which the data or information is displayed.

For a process to access a resource, it must first make a request to the operating system. If the resource is available, the operating system allows the process to use the resource. The process uses the resource then releases it so that it will be available to other processes. If the resource is not available, the request is denied, and the process must wait. When the resource becomes available, the process is awakened. This is the basic format of resource allocation. Figure 5-10 shows a resource allocation graph. The resource allocation graph shows which processes hold resources and which processes are requesting resources. In Figure 5-10, Process B makes a request for resource 2, which is held by Process C. Process C makes a request for resource 3, which is held by Process D.

Figure 5.10. Figure 5-10

When more than one request to access a resource is granted, the resource is sharable. This is shown in Figure 5-10 as well. Process A shares resource 1 with Process D. A resource may allow many processes concurrent access or may allow one process only limited time before allowing another process access. An example of this type of shared resource is the processor. A process is assigned a processor for a short interval and then another process is assigned the processor. When only one request to access a resource is granted at a time and that occurs after the resource has been released by another process, the resource is unshared, and the process has exclusive access to the resource. In a multiprocessor environment, it is important to know whether a shared resource can be accessed simultaneously or only by one process at a time, in order to avoid some of the pitfalls inherent in concurrency.

Some resources can be changed or modified by a process. Other resources do not allow a process to change it. The behavior of shared modifiable or unmodifiable resources is determined by the resource type.

#include <sys/resource.h>

int setrlimit(int resource, const struct rlimit *rlp);
int getrlimit(int resource, struct rlimit *rlp);
int getrusage(int who, struct rusage *r_usage);

struct rlimit
{
    rlim_t rlim_cur;
    rlim_t rlim_max;
}

//Example 5-4 Using setrlimit() to set the soft limit for file size.

#include <sys/resource.h>

//...
struct rlimit R_limit;
struct rlimit R_limit_values;

//...

R_limit.rlim_cur = 2000;
R_limit.rlim_max = RLIM_SAVED_MAX;
setrlimit(RLIMIT_FSIZE,&R_limit);
getrlimit(RLIMIT_FSIZE,&R_limit_values);
cout << "file size soft limit: " << R_limit_values.rlim_cur << endl;

//...

Asynchronous processes execute independent of each other. Process A runs until completion without any regard to process B. Asynchronous processes may or may not have a parent-child relationship. If process A creates process B, they can both execute independently, but at some point the parent retrieves the exit status of the child. If the processes do not have a parent-child relationship, they may share the same parent.

Asynchronous processes may execute serially or simultaneously or their execution may overlap. These scenarios are depicted in Figure 5-11.

In Case 1, process A runs until completion, then process B runs until completion, and then process C runs until completion. This is serial execution of these processes.

Case 2 depicts simultaneous execution of processes. Process A and B are active processes. While process A is running, process B is sleeping. At some point both processes are sleeping. Process B awakens before process A. Then process A awakens, and now both processes are running at the same time. This shows that asynchronous processes may execute simultaneously only during certain intervals of their execution.

In Case 3, the execution of process A and the execution of process B overlap.

Figure 5.11. Figure 5-11

Asynchronous processes may share resources like a file or memory. This may or may not require synchronization or cooperation of the use of the resource. If the processes are executing serially (Case 1), then they will not require any synchronization. For example, all three processes, A, B, and C, may share a global variable. Process A writes to the variable before it terminates. Then, when process B runs, it reads the data stored in the variable, and before it terminates it writes to the variable. When Process C runs, it reads data from the variable. But in Case 2 and 3, the processes may attempt to modify the variable at the same time, thus requiring synchronization of its use.

For our purposes, we define synchronous processes as processes with interleaved execution; one process suspends its execution until another process finishes. For example, process A, the parent process, executes and creates process B, the child process. Process A suspends its execution until process B runs to completion. When process B terminates, its exit code is placed in the process table. Process A is informed process B has terminated. Process A can resume additional processing and then terminate, or it can immediately terminate. Process A and process B are synchronous processes. Figure 5-11 contrasts synchronous and asynchronous execution of processes A and B.

Asynchronous processes can suspend execution until a child process terminates by executing wait() system call. After the child process terminates, a waiting parent process collects the child's exit status that prevents zombied processes. The wait() function obtains the exit status from the process table. The status parameter points to a location that contains the exit status of the child process. If the parent process has more than one child process and several of them have terminated, the wait() function retrieves the exit status for only one child process from the process table. If the status information is available before the execution of the wait() function, the function returns immediately. If the parent process does not have any children, the function returns with an error code. The wait() function can also be called when the calling process is to wait until a signal is delivered and then perform some signal-handling action.

Synopsis

#include <sys/wait.h>

pid_t wait(int *status);
pid_t waitpid(pid_t pid, int *status, int options);

The waitpid() function is the same as wait(), except that it takes an additional parameter, pid. The pid parameter specifies a set of child processes for which the exit status is retrieved. Which processes are in the set is determined by the value of pid:

The options parameter determines how the wait should behave and can have the value of the following constants defined in the header <sys/wait.h>:

These constants can be logically ORRED and passed as the options parameter (for example: WCONTINUED | WUNTRACED).

Both the wait() and waitpid() functions return the PID of the child process whose exit status was obtained. If the value stored in status is 0, then the child process has terminated under these conditions:

Table 5-9 lists the macros in which the value of the exit status can be evaluated.

Recall that a predicate in C++ is a function object that returns a bool [Stroustrup, 1997]. One thing that's often overlooked in this definition is the word object. A predicate is not simply a function. It has object semantics. Predicates give a declarative interpretation to a sequence of actions. A predicate is a statement that can be evaluated to true or false. In a shift toward a more declarative approach to parallelism, you will find that is sometimes convenient to encapsulate a process or a thread as a C++ predicate. Enapsulating the process or thread within a predicate allows you to thread them as objects for use with containers and algorithms. This subtle use of the notion of a predicate in C++ allows you to take a big step away from the procedural approach to parallelism and toward a declarative approach.

Take, for example, the guess_it program from Listing 5-3 earlier in the chapter. Although we used an interface class to provide a more declarative interface for the posix_spawn function, we can do better. In other words, Listing 5-3 is a more declarative version of the guess_it program from Chapter 4, and now Listing 5-5 is a more declarative form of the program in Listing 5-3.

// Listing 5-5  A restatement of the guess_it program from Chapter 4.

 1  #include "posix_process.h"
 2  #include "posix_queue.h"
 3  #include "valid_code.h"
 4
 5
 6  char **av;
 7  char **env;
 8
 9
10  int main(int argc,char *argv[],char *envp[])
11  {
12
13     valid_code  ValidCode;
14     ValidCode.determination("ofind_code");
15     cout <<  (ValidCode() ? "you win": "you lose");
16     return(0);
17  }

Here, we have decided to model the code from our game as a C++ class named valid_code. We have decided to encapsulate the invocation of the posix_process.run() method within a C++ predicate. Line 15 of Listing 5-5 contains the ValidCode() predicate. If the predicate ValidCode() is true, then the user has guessed the right six-character code within the 5-minute time constraint. The program in Listing 5-5 spawns two processes using the posix_process class and four threads using the user_thread class from Chapter 4. Both the posix_process class and the user_thread class are interface classes that adapt the interface to posix_spawn() and pthread_create().

pthread, rt

c++ -o oguess_it oguess_it.cc posix_process.cc -lrt

//Listing 5-6  Declaration of our valid_code predicate class.

 1  #ifndef __VALID_CODE_H
 2  #define __VALID_CODE_H
 3  using namespace std;
 4
 5  #include <string>
 6  class valid_code{
 7  private:
 8     string Code;
 9     float  TimeFrame;
10     string Determination;
11     bool InTime;
12  public:
13     bool operator()(void);
14     void determination(string X);
15  };
16
17  #endif

//Listing 5-7  Definition of our valid_code predicate class.

 1  #include "valid_code.h"
 2  #include "posix_process.h"
 3  #include "posix_queue.h"
 4
 5  extern char **av;
 6  extern char **env;
 7
 8
 9  bool valid_code::operator()(void)
10  {
11     int Status;
12     int N;
13     string Result;
14     posix_process Child[2];
15     for(N = 0; N < 2; N++)
16     {
17        Child[N].binary(Determination);
18        Child[N].arguments(av);
19        Child[N].environment(env);
20        Child[N].run();
21        Child[N].pwait(Status);
22     }
23     posix_queue PosixQueue("queue_name");
24     PosixQueue.receive(Result);
25     if((Result == Code) && InTime){
26        return(true);
27     }
28     return(false);
29  }
30
31
32  void valid_code::determination(string X)
33  {
34     Determination = X;
35  }
36

The bulk of this chapter has dealt with processes and how you can leverage them to aid your multicore programming. Some of the key points covered include:

In the next chapter, we discuss multithreading. A thread is a sequence of executable code within a process that is scheduled for execution by the operating system on a processor or core. The use of threads for parallel programming on multicore processors has a number of advantages over multiple processes. In the next chapter, we discuss those advantages and some of the pitfalls. We discuss POSIX APIs functions for creating and managing threads and show how that functionality can be encapsulated in a thread class first introduced in Chapter 4.