Process Management
The Process Management subsystem controls the creation, termination, accounting, and scheduling of processes. It also oversees process state transitions and the switching between privileged and nonprivileged modes of execution. The Process Management subsystem also facilitates and manages the complex task of the creation of child processes.
A simple definition of a process is that it is an executing program. It is an entity that requires system resources, and it has a finite lifetime. It has the capability to create other processes via the system call interface. In short, it is an electronic representation of a user's or programmer's desire to accomplish some useful piece of work. A process may appear to the user as if it is the only job running in the machine. This "sleight of hand" is only an illusion. At any one time a
processor is only executing a single process.
Process Structure
A process has a definite structure (see Figure 19.1). The kernel views this string of bits as the process image. This binary image consists of both a user and system address space as well as registers that store the process's data during its execution. The user address space is also known as the user image. This is the code that is written by a programmer and compiled into an ".o " object file. An object file is a file that contains machine language code/data and is in a format that the linker program can use to then create an executable program.
***19uni01***
Figure 19.1.
Diagram of process areas.
Diagram of process areas.
The user address space consists of five separate areas: Text,
Data, Bss, stack, and user area.
Text Segment The first area of a process is its text segment. This area contains the executable program code for the process. This area is shared by other processes that execute the program. It is therefore fixed and unchangeable and is usually swapped out to disk by the system when memory gets too tight.
Data Area The data area contains both the global and static variables used by the program. For example, a programmer may know in advance that a certain data variable needs to be set to a certain value. In the C programming language, it would look like:
int x = 15;
If you were to look at the data segment when the program was loaded, you would see that the variable x was an integer type with an initial value of 15.
Bss Area The bss area, like the data area, holds
information for the programs variables. The difference is that the bss area maintains variables that will have their data values assigned to them during the programs execution. For example, a programmer may know that she needs variables to hold certain data that will be input by a user during the execution of the program.
int a,b,c; // a,b and c are variables that hold integer values.
char *ptr; // ptr is an unitialized character pointer.
The program code can also make calls to library routines like malloc to obtain a chunk of memory and assign it to a variable like the one declared above.
Stack Area The stack area maintains the process's local variables, parameters used in functions, and values returned by functions. For example, a program may contain code that calls another block of code (possibly written by someone else). The calling
block of code passes data to the receiving block of code by way of the stack. The called block of code then process's the data and returns data back to the calling code. The stack plays an important role in allowing a process to work with temporary data.
User Area The user area maintains data that is used by the kernel while the process is running. The user area contains the real and effective user identifiers, real and effective group identifiers, current directory, and a list of open files. Sizes of the text, data, and stack areas, as well as pointers to process data structures, are maintained. Other areas that can be considered part of the process's address space are the heap, private shared libraries data, shared libraries, and shared memory. During initial startup and execution of the program, the kernel allocates the memory and creates the necessary structures to maintain these areas.
The
user area is used by the kernel to manage the process. This area maintains the majority of the accounting information for a process. It is part of the process address space and is only used by the kernel while the process is executing(see Figure 19.2). When the process is not executing, its user area may be swapped out to disk by the Memory Manager. In most versions of UNIX, the user area is mapped to a fixed virtual memory address. Under HP-UX 10.X, this virtual address is 0x7FFE6000. When the kernel performs a context switch (starts executing a different process) to a new process, it will always map the process's physical address to this virtual address. Since the kernel already has a pointer fixed to this location in memory, it is a simple matter of referencing the current u pointer to be able to begin managing the newly switched in process. The file /usr/include/sys/user.h contains the user area's structure
definition for your version of UNIX.
Figure 19.2.
Diagram of kernel address space.
Diagram of kernel address space.
Process Table The process table is another important structure used by the kernel to manage the processes in the system. The process table is an array of process structures that the kernel uses to manage the execution of programs. Each table entry defines a process that the kernel has created. The process table is always resident in the computer's memory. This is because the kernel is repeatedly querying and updating this table as it switches processes in and out of the CPU. For those processes that are not currently executing, their process table structures are being updated by the kernel for scheduling purposes. The process structures for your system are defined in /usr/include/sys/proc.h.
Fork
Process The kernel provides each process with the tools to duplicate itself for the purpose of creating a new process. This new entity is termed a child process. The fork() system call is invoked by an existing process (termed the parent process) and creates a replica of the parent process. While a process will have one parent, it can spawn many children. The new child process inherits certain attributes from its parent. The fork() system call documentation for HP-UX 10.0 (fork(2) in HP-UX Reference Release 10.0 Volume 3 (of 4) HP 9000 Series Computers) lists the following as being inherited by the child:
Real, effective, and saved user IDs
Real, effective, and saved group IDs
Supplementary group IDs
Process group ID
Environment
File descriptors
Close-on-exec flags
Signal handling settings
Signal mask
Profiling on/off status
Command name in the accounting record
Nice value
All attached shared memory segments
Current working directory
Root directory
File mode creation mask
File size limit
Real-time priority
It is important to note how the child process differs from the parent process in order to see how one tells the difference between the parent and the child. When the kernel creates a child process on behalf of the parent, it gives the child a new process identifier. This unique process ID is returned to the parent by the kernel to be used by the parents code (of which the child also has a copy at this point) to determine the next step the parent process should follow: either continue on with additional work,
wait for the child to finish, or terminate. The kernel will return the user ID of 0 (zero) to the child. Since the child is still executing the parent's copy of the program at this point, the code simply checks for a return status of 0 (zero) and continues executing that branch of the code. The following short pseudocode segment should help clarify this concept.
start
print " I am a process "
print " I will now make a copy of myself "
if fork() is greater than 0
print " I am the parent"
exit () or wait ()
else if fork() = 0
print " I am the new child "
print " I am now ready to start a new program "
exec("new_program")
else fork() failed
The child process can also make another system call that will
replace the child's process image with that of a new one. The system call that will completely overlay the child's text, data, and BSS areas with that of a new program one is called exec(). This is how the system is able to execute multiple programs. By using both the fork() and the exec() systems calls in conjunction with one another, a single process is able to execute numerous programs that perform any number of tasks that the programmer needs to have done. Except for a few system level processes started at boot time, this is how the kernel goes about executing the numerous jobs your system is required to run to support your organization.
To see how all this looks running on your system, you can use the ps command to view the fact that the system has created all these new child processes. The ps -ef command will show you that the child's parent process ID column (PPID) will
match that of the parent's process ID column (PID). The simplest way to test this is to logon and, at the shell prompt, issue a UNIX command. By doing this you are telling the shell to spawn off a child process that will execute the command (program) you just gave it and to return control to you once the command has finished executing. Another way to experiment with this is to start a program in what is termed the background. This is done by simply appending an ampersand (&) to the end of your command line statement. This has the effect of telling the system to start this new program, but not to wait for it to finish before giving control back to your current shell process. This way you can use the ps -ef command to view your current shell and background processes.
Sample ps -ef output from a system running AIX 4.2
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Apr 24 - 2:55 /etc/init
root 2060 17606 0 10:38:30 - 0:02 dtwm
root 2486 1 0 Apr 24 - 0:00 /usr/dt/bin/dtlogin -daemon
root 2750 2486 0 Apr 24 - 3:12 /usr/lpp/X11/bin/X -x xv -D/usr/lib/X11//rgb -T -force :0 -auth /var/dt/A:0-yjc2ya
root 2910 1 0 Apr 24 - 0:00 /usr/sbin/srcmstr
root 3176 2486 0 Apr 25 - 0:00 dtlogin <:0> -daemon
root 3794 1 0 Apr 25 - 0:00 /usr/ns-home/admserv/ns-admin-d /usr/ns-home/admserv .
root 3854 2910 0 Apr 24 - 0:00 /usr/lpp/info/bin/infod
root 4192 6550 0 Apr 24 - 0:00 rpc.ttdbserver 100083 1
root 4364 1 0 Apr 24 - 2:59 /usr/sbin/syncd 60
root 4628 1 0 Apr 24 - 0:00 /usr/lib/errdemon
root 5066 1 0 Apr 24 - 0:03 /usr/sbin/cron
root 5236 2910 0 Apr 24 - 0:00 /usr/sbin/syslogd
root 5526 2910 0 Apr 24 - 0:00 /usr/sbin/biod 6
root 6014 2910 0 Apr 24 - 0:00 sendmail: accepting connections
root 6284 2910 0 Apr 24 - 0:00 /usr/sbin/portmap
root 6550 2910 0 Apr 24 - 0:00 /usr/sbin/inetd
root 6814 2910 0 Apr 24 - 9:04 /usr/sbin/snmpd
root 7080 2910 0 Apr 24 - 0:00 /usr/sbin/dpid2
root 7390 1 0 Apr 24 - 0:00 /usr/sbin/uprintfd
root 7626 1 0 Apr 24 - 0:00 /usr/OV/bin/ntl_reader0 1 1 1 1000 /usr/OV/log/nettl
root 8140 7626 0 Apr 24 - 0:00 netfmt -CF
root 8410 8662 0 Apr 24 - 0:00 nvsecd -O
root 8662 1 0 Apr 24 - 0:15 ovspmd
root 8926 8662 0 Apr 24 - 0:19 ovwdb -O -n5000 -t
root 9184 8662 0 Apr 24 - 0:04 pmd -Au -At -Mu -Mt -m
root 9442 8662 0 Apr 24 - 0:32 trapgend -f
root 9700 8662 0 Apr 24 - 0:01 mgragentd -f
root 9958 8662 0 Apr 24 - 0:00 nvpagerd
root 10216 8662 0 Apr 24 - 0:00 nvlockd
root 10478 8662 0 Apr 24 - 0:05 trapd
root 10736 8662 0 Apr 24 - 0:04 orsd
root 11004 8662 0 Apr 24 - 0:31 ovtopmd -O -t
root 11254 8662 0 Apr 24 - 0:00 nvcold -O
root 11518 8662 0 Apr 24 - 0:03 ovactiond
root 11520 8662 0 Apr 24 - 0:05 nvcorrd
root 11780 8662 0 Apr 24 - 0:00 actionsvr
root 12038 8662 0 Apr 24 - 0:00 nvserverd
root 12310 8662 0 Apr 24 - 0:04 ovelmd
root 12558 8662 0 Apr 24 - 4:28 netmon -P
root 12816 8662 0 Apr 24 - 0:04 ovesmd
root 13074 8662 0 Apr 24 - 0:00 snmpCollect
root 13442 2910 0 Apr 24 - 0:00 /usr/lib/netsvc/yp/ypbind
root 13738 5526 0 Apr 24 - 0:00 /usr/sbin/biod 6
root 13992 5526 0 Apr 24 - 0:00 /usr/sbin/biod 6
root 14252 5526 0 Apr 24 - 0:00 /usr/sbin/biod 6
root 14510 5526 0 Apr 24 - 0:00 /usr/sbin/biod 6
root 14768 5526 0 Apr 24 - 0:00 /usr/sbin/biod 6
root 15028 2910 0 Apr 24 - 0:00 /usr/sbin/rpc.statd
root 15210 6550 0 Apr 24 - 0:00 rpc.ttdbserver 100083 1
root 15580 2910 0 Apr 24 - 0:00 /usr/sbin/writesrv
root 15816 2910 0 Apr 24 - 0:00 /usr/sbin/rpc.lockd
root 16338 2910 0 Apr 24 - 0:00 /usr/sbin/qdaemon
root 16520 2060 0 13:44:46 - 0:00 /usr/dt/bin/dtexec -open 0-ttprocid 2.pOtBq 01 17916 1342177279 1 0 0 10.19.12.115 3_101_1 /usr/dt/bin/dtterm
root 16640 1 0 Apr 24 lft0 0:00 /usr/sbin/getty /dev/console
root 17378 1 0 Apr 24 - 0:13 /usr/bin/pmd
root 17606 3176 0 10:38:27 - 0:00 /usr/dt/bin/dtsession
root 17916 1 0 10:38:28 - 0:00 /usr/dt/bin/ttsession -s
root 18168 1 0 Apr 24 - 0:00 /usr/lpp/diagnostics/bin/diagd
nobody 18562 19324 0 Apr 25 - 0:32 ./ns-httpd -d/usr/ns-home/httpd-supp_aix/config
root 18828 22410 0 13:44:47 pts/2 0:00 /bin/ksh
root 19100 21146 0 13:45:38 pts/3 0:00 vi hp.c
nobody 19324 1 0 Apr 25 - 0:00 ./ns-httpd -d/usr/ns-home/httpd-supp_aix/config
root 19576 6550 0 13:43:38 - 0:00 telnetd
nobody 19840 19324 0 Apr 25 - 0:33 ./ns-httpd -d/usr/ns-home/httpd-supp_aix/config
root 19982 17606 0 10:38:32 - 0:03 dtfile
nobody 20356 19324 0 Apr 25 - 0:33 ./ns-httpd -d/usr/ns-home/httpd-supp_aix/config
root 20694 20948 0 Apr 25 - 0:00/usr/ns-home/admserv/ns-admin -d /usr/ns-home/admserv .
root 20948 3794 0 Apr 25 - 0:01/usr/ns-home/admserv/ns-admin -d /usr/ns-home/admserv .
root 21146 23192 0 13:45:32 pts/3 0:00 /bin/ksh
nobody 21374 19324 0 Apr 25 - 0:00 ./ns-httpd -d /usr/ns-home/httpd-supp_aix/config
root 21654 2060 0 13:45:31 - 0:00 /usr/dt/bin/dtexec-open 0 -ttprocid 2.pOtBq 01 17916 1342177279 1 0 0 10.19.12.115 3_102_1 /usr/dt/bin/dtterm
root 21882 19576 0 13:43:39 pts/0 0:00 -ksh
root 22038 19982 0 10:38:37 - 0:04 dtfile
root 22410 16520 0 13:44:47 - 0:00 /usr/dt/bin/dtterm
root 22950 21882 8 13:46:06 pts/0 0:00 ps -ef
root 23192 21654 0 13:45:31 - 0:00 /usr/dt/bin/dtterm
root 23438 18828 0 13:45:03 pts/2 0:00 vi aix.c
Process Run States
A process moves between several states during its lifetime, although a process can only be in one state at any one time. Certain events, such as system interrupts, blocking of resources, or software traps will cause a process to change its run state. The kernel maintains queues in memory that it uses to assign a process to based upon that process's state. It keeps track of the process by its user ID.
UNIX version System V Release 4 (SVR4) recognizes the following process run states:
- SIDLE This is the state right after a process has issueda fork() system call. A process image has yet to be copied into memory.
- SRUN The process is ready to run and is waiting to be executed by the CPU.
- SONPROC The process is currently being executed by the CPU.
- SSLEEP The process is blocking on an event or resource.
- SZOMB The process has terminated and is waiting oneither its parent or the init process to allow it to completely exit.
- SXBRK The process is has been switched out so that another process can be executed.
- SSTOP The process is stopped.
When a process first starts, the kernel allocates it a slot in the process table and places the process in the SIDL state. Once the process has the resources it needs to run, the kernel places it onto the run queue. The process is now in the SRUN state awaiting its turn in the CPU. Once its turn comes for the process to be switched into the CPU, the kernel will tag it as being in the SONPROC state. In this state, the process will execute
in either user or kernel mode. User mode is where the process is executing nonprivileged code from the user's compiled program. Kernel mode is where kernel code is being executed from the kernel's privileged address space via a system call.
At some point the process is switched out of the CPU because it has either been signaled to do so (for instance, the user issues a stop signal--SSTOP state) or the process has exceeded its quota of allowable CPU time and the kernel needs the CPU to do some work for another process. The act of switching the focus of the CPU from one process to another is called a context switch. When this occurs, the process enters what is known as the SXBRK state. If the process still needs to run and is waiting for another system resource, such as disk services, it will enter the SSLEEP state until the resource is available and the kernel wakes the process up and
places it on the SRUN queue. When the process has finally completed its work and is ready to terminate, it enters the SZOMB state. We have seen the fundamentals of what states a process can exist in and how it moves through them. Let's now learn how a kernel schedules a process to run.
Process Scheduler
Most modern versions of UNIX (for instance, SVR4 and Solaris 2.x) are classified as preemptive operating systems. They are capable of interrupting an executing a process and "freezing" it so that the CPU can service a different process. This obviously has the advantage of fairly allocating the system's resources to all the processes in the system. This is one goal of the many systems architects and programmers who design and write schedulers. The disadvantages are that not all processes are equal and that complex algorithms must be designed and
implemented as kernel code in order to maintain the illusion that each user process is running as if it was the only job in the system. The kernel maintains this balance by placing processes in the various priority queues or run queues and apportioning its CPU time-slice based on its priority class (Real-Time versus Timeshare).
Universities and UNIX system vendors have conducted extensive studies on how best to design and build an optimal scheduler. Each vendor's flavor of UNIX--4.4BSD, SVR4, HP-UX, Solaris, and AIX, to name a few--attempts to implement this research to provide a scheduler that best balances its customers' needs. The systems administrator must realize that there are limits to the scheduler's ability to service batch, real-time, and interactive users in the same environment. Once the system becomes overloaded, it will become necessary for some jobs to suffer at the expense of others. This is an extremely
important issue to both users and systems administrators alike. The reader should refer to Chapter 22, "Systems Performance and Tuning," to gain a better understanding of what he can do to balance and tune his system.
| |
| |
| |
Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP.
SPONSORED LINKS
| Technical support | Computer security | Computer technical support |
| Computer training | Free computer technical support |
YAHOO! GROUPS LINKS
- Visit your group "tech4all" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
