Process Control Block

Please download to get full document.

View again

of 63
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Similar Documents
Information Report



Views: 0 | Pages: 63

Extension: PDF | Download: 0

7. Process Control Block 7.1 Process creation 7.2 Signals 7.2.1 Handling signals. 7.2.2 Process group 7.2.3 Sending signals from processes 7.3 Process termination 7.4 Awaiting process termination 7.5 Invoking other programs . 7.6 The user id of a process 7.7 Changing the size of a process 7.8 The shell 7.9 System boot and the init process Algorithms: fork() isisg() psig() exit() wait() exec() xalloc() brk() start() init()
  • 1. 7. Process Control Block 7.1 Process creation 7.2 Signals 7.2.1 Handling signals. 7.2.2 Process group 7.2.3 Sending signals from processes 7.3 Process termination 7.4 Awaiting process termination 7.5 Invoking other programs . 7.6 The user id of a process 7.7 Changing the size of a process 7.8 The shell 7.9 System boot and the init process
  • 2. Algorithms:  fork() isisg() psig()  exit()  wait()  exec()  xalloc()  brk()  start()  init()
  • 3. Process creation The only way for a user to create a new process in the UNIX operating system is to invoke the fork system call. The process that invokes fork is called the parent process, and the newly created process is called the child process. Syntax of fork() system call pid= fork();
  • 4. On return from the fork system call, the two processes have identical copies of their user-level context except for the return value pid. In the parent process, pid is the child process ID while in the child process, pid is 0. Process 0, created internally by the kernel when the system is booted, is the only process not created via fork.
  • 5. The kernel does the following sequence of operations for fork. 1. It allocates a slot in the process table for the new process. 2. It assigns a unique ID number to the child process. 3. It makes a logical copy of the context of the parent process. Since certain portions of a process, such as the text region, may be shared between processes, the kernel can sometimes increment a region reference count instead of copying the region to a new physical location in memory, 4. It increments file and mode table counters for files associated with the process.
  • 6. 5. It returns the ID number of the child to the parent process, and a 0 value to the child process.
  • 7. Steps of algorithm fork() 1. The kernel first make sure that it has available resources to complete the fork successfully. Means in OS that supports swapping , kernel needs enough space either in memory or on disk to hold the child process. In OS that supports demand paging kernel need page table and associated register triples. If resources are not available ,call to fork() fails. 2. The kernel finds a slot in the process table to start constructing the context of the child process, It also picks a unique ID number for the new process, one greater than the most recently assigned ID number.
  • 8. 3. Then kernel observes the process table and checks whether , user already has too many processes or not . 4. The kernel next initializes the child's process table slot, copying various fields from the parent slot . It sets the state field in child’s process table entry as “being created”. 5. As child process also inherits “current directory file” and “current root file”, kernel increments reference count of “current directory file” and “current root file” by 1. 6. Then kernel searches the parent's user file descriptor table for open files known to the process and increments the global file table reference count associated with each open file.
  • 9. 7. The kernel is now ready to create the context of the child process. While creating static level context ,It allocates memory for the child process u area, regions, and auxiliary page tables, duplicates every region in the parent process using algorithm dupreg, and attaches every region to the child process using algorithm attachreg. while creating dynamic context for a child process, kernel copies the parent context layer (1) , containing the user saved register context and the kernel stack frame of the fork system call'.
  • 10. 8. The kernel then creates a dummy context layer (2) for the child process, containing the saved register context for context layer (1). It sets the program counter and other registers in the saved register context so that it can "restore" the child context, even though it had never executed before, and so that the child process can recognize itself as the child when it runs. 9. Now kernel sets “state” of the child process “ready to run in memory” and child process’s ID is returned to the parent. Here parent fork ends. Now child process follow all usual scheduling algorithms and ready to execute, here child's fork ends, by returning 0 from the system call
  • 11. SIGNALS Signals are the entities that inform processes about the occurrences of asynchronous events. Either processes can send signals to each other or kernel can send signals to processes. To send a signal to a process, the kernel sets a bit in the signal field of the process table entry, corresponding to the type of signal received. A process can remember different types of signals, but it has no memory of how many signals it receives of a particular type.
  • 12. System call issig() To determine whether a process really received signal or not Kernel executes an algorithm called as issig().
  • 13. steps of system call issig() 1. Kernel looks inside the process table for “received signal” field .If this field is nonzero, then it is as indication that signal is received. 2. from “received signal” field kernel also gets the signal number . 2. If signal number corresponds to the signal “death of child” ,then it takes two actions according to the reaction to the “death of child “ signal. Means, if signal is to be ignored , then kernel just frees the process table entries for “zombie state” children. But if this signal is going to be catch , then kernel returns true.
  • 14. 3. For other all signals (besides “death of child”) ,if they are not going to be ignored, kernel returns true. 4.But if all signals are going to be ignored , then there is no meaning to keep the “received signal field” .So it turns that bit “off” and returns false. 5.If received signal is not ignorable ,kernel returns true. 6. If process table’s “received signal” field is 0 then kernel returns false.
  • 15. Handling of signals kernel can handle signals only when process returns to user mode (either from kernel mode or from preempted state) But kernel can checks for two signals at 2 locations… 1. When process enters in sleep or returning from sleep. 2. And when process enters from kernel to user mode
  • 16. Handling of signals is done by kernel on the behalf of process. We can say that.. It is the kernel who handles the signal in the context of the process that receives signal. there are 3 cases for handling signals… 1. The process exits on receipt of signal ,or 2. The process ignores the signal, or 3. The process executes a particular user defined function on receipt of the signal.
  • 17. Process can specify special action on the receipt of signal using signal() system call. Syntax of signal() system call oldfunction=signal(signal_number,new_function) Where, Signal_no :- is the signals number for which the process wants to specify special action. New_function :- it is the particular user defined function that process wants to execute on receipt of the signal. Oldfunction :- it is the address of the function that was executed by the process in past when the same signal was dealt.
  • 18. new_function parameter can have value… a) 1 ,then process will ignore all future and present occurrences of the signal. b) 0 ,(which is default if unless defined) ,the kernel assumes that you want to exit the process in kernel mode on receipt of the signal. c) address of user defined function, then process will execute that function on the receipt of this signal.
  • 19. Algorithm psig() psig() algorithm is used by kernel to handle the signals generated for process’s.
  • 20. Steps of psig() system call 1. Kernel gets the signal number form process table for the received signal 2. Then it turn “off” the appropriate signal’s bit in the process table entry. 3. If process receives such a signal which was received to be ignored ,then kernel returns and proceed as if signal is never received 4. If process had decide to catch the received signal ,then kernel executes that user defined function on the behalf of process. Kernel performs following task to do this …..
  • 21. a) Kernel first accesses the saved register context of this process (which was previously saved for return to user mode) and finds out program counter and stack pointer in it. This “saved register context” has return address of system call in program counter. b) It clears the signal catcher functions field in U area’s “signal array” . c) Now kernel creates “new stack frame” and writes program counter and stack pointer in it. Here it writes the return address of system call. Now the user’s stack looks as if the process had called the “signal catcher” function at that point where process had made the system call where the kernel had interrupted the process before recognition of the signal.
  • 22. c) now kernel modifies the saved register context .Kernel changes program counter to the address of signal catcher function and also changes the stack pointer to consider growth of stack which occurred due to addition of new frame .after doing all above five steps kernel allows process to return to user mode ,where it is ready to handle signal. 5. If signals for which “0” is specified in 2nd parameter of signal() system call. If there is need to make core dump of image of the process before exiting. otherwise kernel does not make core dump and exits immediately.
  • 23. Process Group Although processes on a UNIX system are identified by unique ID number, the system must sometimes identify processes by "group.“ E.g. For instance, processes with a common ancestor process that is a login shell are generally related, and therefore all such processes receive signals when a user hits the "delete" or "break" key or when the terminal line hangs up. The kernel uses the process group ID to identify groups of related processes that should receive a common signal' for certain events. It saves the group ID in the process table; processes in the same process group have identical group ID's.
  • 24. The system call for process group ID is the setpgrp(). When it is called in a process, the this system call gives process group id equal to the caller process’s PID. Syntax is… grp=setpgrp(); Where grp is the new “process group ID” Child of a process always inherits its parents “process group id” as its own “process group id”,during the fork system call.
  • 25. How process to process to process signaling occurs Process use kill() system call to send signals to each other, The syntax is… kill(pid,signal_number); Where… pid-> it is the process’s id to whom this process wants to send the signal. signal_number-> It is the number of the signal that process wants to send.
  • 26. parameter pid has different meanings which are as follows.. 1. 1f pid is a positive integer, the kernel sends the signal to the process with process ID pid. 2. If pid is 0, the kernel sends the signal to all processes in the sender's process group. 3. If pid is —1, the kernel sends the signal to all processes whose real user ID equals the effective user ID of the sender If the sending process has effective user ID of super user, the kernel sends the signal to all processes except processes 0 and 1. 4. If pid is a negative integer but not — 1, the kernel sends the signal to all processes in the process group equal to the absolute value of pid.
  • 27. Process Termination Processes in UNIX get terminated by executing exit() system call. The exiting process first enters in zombie state before actually exit . In zombie state the process “give up” it’s all occupied resources , then dismantles its whole context but leaves its slot in process table occupied.
  • 28. Syntax of exit() system call exit(status); where the “status” is returned to the parent process by this process as “exit status of child” .So parent can use this “status” for examination of child’s exit. Any process can call exit implicitly or explicitly means, if child does not call exit() as part of its code ,it gets exit after termination of main() function of it. Explicitly means a process can call exit() as a part of its code anywhere in its body. Kernel itself invoke exit() system call internally when process receives uncaught signals. In this case status is the signal’s number.
  • 29. Steps of exit() system call 1. Kernel first ignore all signals coming to this process because this process is going to exit. 2. If sometimes in past this process had called setpgrp() to become leader of its children and suppose this process also has terminal’s control, then… a) send hang up signals to all processes of this process’s group. b) As this process is going to exit ,its children will require new “group leader” .Hence kernel sets group ID as 0 for all these processes of this process’s group . 3. Then kernel close all open files of this process ,one-by-one By using internal variation of close() system call. 4. The kernel releases current directory inode using iput algorithm
  • 30. 5. Then kernel also releases “ current root “ inode by using iput() algorithm. 6. Then kernel releases all memory means regions, page tables by using detachreg() algorithm but it saves - Exit status code - Accumulated user time - Kernel execution time for this process and for its children in the “process table slot” of this process. 7. Kernel also writes an accounting record of this process to a global accounting file. This accounting record contains.. - User ID of process. - CPU usage - Memory usage - Amount of I/O of the process - pid (process ID)
  • 31. 8. Now kernel makes process’s state “zombie” 9. As this process is now going to exit ,its children will lose their parent .So kernel makes “INIT” process as new parent of these child processes. To do this kernel assigns id of init to all theses children as their “parent process ID” .This id is 1. 10.Sometimes it may happen that when process is exiting. Any of its children may be already in zombie state ,actually this is to be informed to the parent of this child .But as parent is going to be exit and thus “INIT” is now new parent, this exiting process tells init about its zombie children by sending “death of child” signal . 11.Now this exiting process also has its own parent and as this process is now exiting ,it itself sends ‘death of child” signal “ to its own parent. . 12. Now this “zombie state” process forces kernel to make “context switch” so that kernel can schedule other process.
  • 32. Waiting for process termination(wait()) Many times a process wants to synchronize its execution with the termination (i.e. exit) of its child process. For this purpose wait() system cal is used… Syntax of wait() system call.. pid= wait( status_address) where, pid-> It is the process ID of that zombie child with whose termination the process wants to synchronize. Status_address-> is the address of an integer where” exit status code” of the child ,will be stored.
  • 33. Steps of wait() system call 1. The kernel searches for a zombie child of the process and, if there are no children, returns an error. 2. But if it finds a zombie child, it enters in an infinite for loop and then…  Picks up this zombie child process.  Adds “Accumulated time of child process” ( i.e CPU usage) to the appropriate field of parent’s uarea.  Release this zombie child’s process table entry.  Finally returns pid number of zombie child and exit status of the zombie child together to the parent process of this zombie child.
  • 34. 3. Then it again checks for any child of this process in this infinite loop and returns error when no child remains. 4. But when process has child but not in “zombie state” ,then process sleeps at “ITERRRUPTABLE” priority until the event of “Any zombie child occurs” . 5. The loop terminates only when internal statements of return is executed ,otherwise this is an infinite loop.
  • 35. Invoking Other programs(exec()) The exec() system call invoke other programs when a process calls it . While doing this the memory space of calling process is overlaid with executable file. Because of this the original contents of “user level context” of the calling process become un-accessible except the parameters of exec() system call. This is because during overlying process kernel copies these parameters from process address’s space to some other address space in memory.
  • 36. The syntax of exec() system call execve(filename, argv, envp) where, filename is the name of executable program’s file which is to be invoked . Argv is pointer to an array of character pointer which are strings from this parameters to executable program .and Envp is another pointer to an array of a character pointers which are strings for “ENVIRONMENT” of the executable program.
  • 37. Steps of exec() system call 1. First kernel gets the executable file’s inode by using namei() algorithm for the path specified in first parameter. 2. Then it determines the file is really “executable” or not by studying its inode .It also determines whether user has “executable” permission for executing this file. 3. Kernel then reads executable file’s header to study its layout .it determines that this file is “executable module” 4. As image of executable file is going to be overlay on existing address space of calling process , kernel must free the current address space of the process. Kernel first copies parameters of exec() from this address space to temporary buffer in system’s memory
  • 38. 5. Now kernel is ready to free the current address space of calling process .Hence it uses detachreg() algorithm for every region in the process’s current address space. 6. Kernel then allocates new region for process’s text and data by allocreg() ,then it attaches theses regions to the process by using attachreg() and loads them by using loadreg() . The data region of a process is (initially) divided into two parts: data initialized at compile time and data not initialized at compile time ("bss"). The initial allocation and attachment of the data region is for the initialized data. The kernel then increases the size of the data region using algorithm growreg() for the "bss" data, and initializes the value of the memory to 0.
  • 39. 7. finally kernel allocates a region for the process stack, attaches it to the process, and allocates memory to store the exec parameters. If the kernel has saved the exec parameters in memory pages, it can use those pages for the stack. Otherwise, it copies the exec parameters to the user stack. 8. The kernel clears the addresses of user signal catchers from the u area, because those addresses are meaningless in the new user-level context. 9. Then kernel takes special action for setuid programs and for process tracing.
  • 40. 10. Now kernel goes to register context of the process. This context is going to be used by process when it will run in user mode . Here kernel specifically sets stack pointer to new grown stack’s top and then sets the program counter to the starting address of execution . 11. Finally kernel invoke iput() algorithm to release the inode of executable file which was locked in the first step of algorithm.
  • 41. The user ID of a process Kernel gives two ID’s than process other than process ID 1. Real User ID. the real user identifies the user who is responsible for running the process. 2. Effective User ID The effective user ID is used to assign ownership of newly created files.
  • 42. Out of these two kernel allows to change the effective user ID of the process when it executes setuid () program by exec() or when setuid() system call is called directly. So when process executes setuid program ,kernel sets the effective ID field in process
  • We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks

    We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

    More details...

    Sign Now!

    We are very appreciated for your Prompt Action!