Unit 3.1 The Structure of Process, Process Control, Process Scheduling.ppt

Sanjivani Rural Education Society’s
Sanjivani College of Engineering, Kopargaon-423 603
(An Autonomous Institute, Affiliated to Savitribai Phule Pune University, Pune)
NAAC ‘A’ Grade Accredited, ISO 9001:2015 Certified
Department of Computer Engineering
(NBA Accredited)
Prof. A. V. Brahmane
Assistant Professor
E-mail : brahmaneanilkumarcomp@sanjivani.org.in
Contact No: 91301 91301 Ext :145, 9922827812
Subject- Operating System and Administration (CO2013)
Unit III- The Structure of Process, Process Control and
Process Scheduling

Content
• Process state and transitions,
• Layout of the system memory,
• Context of the process,
• Saving the context of the process,
• Manipulation the process address space,
• Sleep,
• Process creation,
• Signal,
• Process termination, Awaiting the process termination,
• Invoking other program, Process Scheduling
• Case Study - Access Control, Rootly Powers and Controlling Processes
DEPARTMENT OF COMPUTER ENGINEERING, Sanjivani COE, Kopargaon

Process State and transition
• The complete set of process states:
• Executing in user mode.
• Executing in kernel mode.
• Ready to run.
• Sleeping in memory.
• Ready to run, but in swap space (covered later).
• Sleeping in swap space.
• Preempted. (the process is returning from kernel to user mode, but the kernel preempts it and
does a context switch to schedule another process. Very similar to state 3)
• Newly created. Not ready run, nor sleeping. This is the start state for all processes expect process
0.
• The process executed exit system call and is in the zombie state. The process no longer exists, but
it leaves a record containing an exit code and some timing statistics for its parent process to
collect. The zombie state is the final state of a process.

Process State and its Tansistions

Kernel uses two tables Process Table and U area Table
• The fields in the process table are the following:
• State of the process
• Fields that allow the kernel to locate the process and its u-area in main memory or in
secondary storage.
• Several user identifiers (user IDs or PIDs) specify the relationship of processes to each
other.
• Event descriptor when the process is sleeping.
• Scheduling parameters allow the kernel to determine the order in which processes move
to the states kernel running and user running.
• A signal fields enumerates the signals sent to a process but not yet handled.
• Various timers give process execution time and kernel resource utilization. These are
used for calculation of process scheduling priority. One field is a user-set timer used to
send an alarm signal to a process.

U- Area Table
• The u-area contains these fields :
• A pointer in the process table identifies the entry that corresponds to the u-area.
• The real and effective user IDs determine various privileges allowed the process, such as file access rights.
• Timer fields record the time the process spent executing in user mode and in kernel mode.
• An array indicates how the process wishes to react to signals.
• The control terminal field identifies the "login terminal" associated with the process, if one exists.
• An error field records errors encountered during a system call.
• A return value field contains the result of system calls.
• I/O parameters describe the amount of data to transfer, the address of the source (or target) data array in
user space, file offsets for I/O, and so on.
• The current directory and current root describe the file system environment of the process.
• The user file descriptor table records the files the process has open.
• Limit fields restrict the size of a process and the size of a file it can write.
• A permission modes field masks mode settings on files the process creates.

Layout of System Memory
• The physical memory is addressable. Starting from offset 0, going up to the amount of
physical memory. A process in UNIX contains three sections: text, data, and stack. Text
section contains the instructions. Those instructions could refer to other addresses, for
example, addresses of different subroutines, addresses of global variables in the data
section, or the addresses of local data structures on the stack. If the addresses generated
by the compiler were to be treated as physical addresses, it would be impossible to run
more than one process at a time, because the addresses could overlap. Even if the
compiler tries to address this problem by using heuristics, it would be difficult and
impractical.
• To solve this problem, the kernel treats the addresses given by the compiler as virtual
addresses. And when the program starts executing, the memory management unit
translates the virtual addresses to physical addresses. The compiler doesn't need to
know which physical addresses the process will get. For example, two instances of a
same program could be executing in memory using the same virtual addresses but
different physical addresses. The subsystems of the kernel and the hardware that
cooperate to translate virtual to physical addresses comprise the memory
management subsystem.

Regions
• The UNIX system divides its virtual address space in logically separated regions.
The regions are contiguous area of virtual address space. A region is a logically
distinct object which can be shared. The text, data, and stack are usually separate
regions. It is common to share the text region among instances of a same process.
• The region table entries contain the physical locations at which the region is
spread. Each process contains a private per process regions table, called
a pregion. The pregion entry contains a pointer to an entry in the region table,
and contains starting virtual address of the region. pregion are stored in process
table, or u-area, or a separately allocated memory space, according to the
implementation. The pregion entries contain the access permissions: read-only,
read-write, or read-execute. The pregion and the region structure is analogous to
file table and the in-core inode table. But since, pregions are specific to a
process, pregion table is private to a process, however the file table is global.
Regions can be shared amongst processes.

An example of regions:

Pages and Page Tables
• In a memory model based a pages, the physical memory is divided into equal
sized blocks called pages. Page sizes are usually between 512 bytes to 4K bytes,
and are defined by the hardware. Every memory location can be address by a
"page number" and "byte offset" in the page. For example, a machine with 2^32
bytes of memory has pages of size 1K bytes (2^10), then it will have 2^22 pages.
• When kernel assigns physical pages of memory to a region, it need not assign the
pages contiguously or in any particular order. Just like disk blocks are not assigned
contiguously to avoid fragmentation.

• The kernel maintains a mapping of logical to physical page numbers in
a table which looks like this:

• These tables are called page tables. Region table entry has pointers to page
tables. Since logical address space is contiguous, it is just the index into an array
of physical page numbers. The page tables also contain hardware dependent
information such as permissions for pages. Modern machines have special
hardware for address translation. Because software implementation of such
translation would be too slow. Hence, when a process starts executing, the kernel
tells the hardware where its page tables reside.

• For being hardware independent, let us assume that the hardware has register
triples (in abundance) which the kernel uses for memory management. The first
register in the triple contains the address of the page table, the second register
contains the first virtual address mapped by the page table, and the third register
contains control information such as number of pages in page tables and page
access permissions. When executing a process, the kernel loads such register
triples with the data in the pregion entries.
• If a process accesses an address outside its virtual address space, an exception is
generated. Suppose a process has 0 to 16K bytes of address space and the
process accesses the virtual address 20K, an exception will generated, and it is
caught by the operating system. Similarly, if a process tries to access a page
without having enough permission, an exception will be generated. In such cases,
process normally exit.

Layout of the Kernel
• Even if the kernel executes in the context of a process, its virtual
address space is independent of processes. When the system boots
up, the kernel is loaded into memory and necessary page tables and
registers are loaded with appropriate data. Many hardware systems
slice a process' address space into many sections, user and kernel
being two of them. When in user mode, access to kernel page tables
is prohibited. When the process switches to kernel mode, only then it
can access kernel page tables. Some system implementations try to
allocate the same physical pages to the kernel, keeping the translation
function, an identity function.

Changing Mode from User to Kernel

The U area
• Even if every process has a u-area, the kernel accesses them through
its u variable. It needs to access only one u-area at a time, of the currently
executing process. The kernel knows where the page table entry of the u-area is
located, therefore, when a process is scheduled, the physical address of its u-area
is loaded into kernel page tables.

Memory Map of U area in the Kernel

The Context of a Process
• The context of a process consists of:
• Contents of its (user) address space, called as user level context
• Contents of hardware registers, called as register context
• Kernel data structures that relate to the process, called as system context
• User level context consists of the process text, data, user stack and shared
memory that is in the virtual address space of the process. The part which resides
on swap space is also part of the user level context.

The register context consists of the following components:
• Program counter specifies the next instruction to be executed. It is an address in
kernel or in user address space.
• The processor status register (PS) specifies hardware status relating the process.
It has subfields which specify if last instruction overflowed, or resulted in 0,
positive or negative value, etc. It also specifies the current processor execution
level and current and most recent modes of execution (such as kernel, user).
• The stack pointer points to the current address of the next entry in the kernel or
user stack. If it will point to next free entry or last used entry it dependent on the
machine architecture. The direction of the growth of stack (toward numerically
higher or lower addresses) also depend on machine architecture.
• The general purpose registers contain data generated by the process during its
execution.

The System Level
• The system level context has a "static part" and a "dynamic part". A
process has one static part throughout its lifetime. But it can have a
variable number of dynamic parts.

• The static part consists of the following components:
• The process table entry
• The u-area
• Pregion entries, region tables and page tables.
• The dynamic part consists of the following components:
• The kernel stack contains the stack frames the kernel functions. Even if all processes
share the kernel text and data, kernel stack needs to be different for all processes as
every process might be in a different state depending on the system calls it executes. The
pointer to the kernel stack is usually stored in the u-area but it differs according to
system implementations. The kernel stack is empty when the process executes in user
mode
• The dynamic part of the system level context consists of a set of layers, visualized as a
last-in-first-out stack. Each system-level context layer contains information necessary to
recover the previous layer, including register context of the previous layer.

Components of the Context of a Process

Saving the Context of a Process
• Interrupts and Exceptions
• The system is responsible for handling interrupts and exceptions. If the system is
executing at a lower processor execution level, when an interrupts occurs, the
kernel accepts the interrupt before decoding the next instruction and then raises
the processor execution level to block other interrupts of that or lower level. It
handles the interrupt by performing following sequence of operations:
• It saves the current register context of the executing process and creates (pushes)
a new context layer.
• The kernel determines the source (cause) of the interrupt, and if applicable, unit
number (such as which drive caused the interrupt). When the system receives an
interrupt, it gets a number. It uses that number as an index into the interrupt
vector, which stores the actions to be taken (interrupt handlers) when interrupts
occur. Example of interrupt vector:

• The kernel invokes the interrupt handler. The kernel stack of the new context
layer is logically distinct from the kernel stack of the previous context layer. Some
implementations use the processes kernel stack to store the stack frame of an
interrupt handler, while some implementations use a global interrupt stack for
the interrupt handlers which are guaranteed to return without a context switch.
• The kernel returns from the interrupt handler and executes a set of hardware
instructions which restore the previous context. The interrupt handler may affect
the behavior of the process as it might modify the kernel data structures. But
usually, the process resumes execution as if the interrupt never occurred.

Sample Interrupt Vector

Algorithm for Handling Intrrupts
• The algorithm for interrupt handling is given below:
• /* Algorithm: inthand
• * Input: none
• * Output: none
• */
• {
• save (push) current context layer;
• determine interrupt source;
• find interrupt vector;
• call interrupt handler;
• restore (pop) previous context layer;
• }

System Call Interface
• The library functions such as open, read, etc. in the standard C library
are not actually system calls. Those are normal functions and normal
functions cannot change the mode of execution of the system. These
functions invoke a special instruction which makes the system change
its execution mode to kernel mode and start executing the system call
code. The instruction is called as operating system trap. The system
calls are a special case of interrupt handling. The library routines pass
the a number unique for each system call, as the parameter to the
operating system trap through a specific register or on the stack.
Through that number, the kernel determines which system call to
execute.

Algorithm Syscall
• /* Algorithm: syscall
• * Input: system call number
• * Output: result of system call
• */
• {
• find entry in the system call table corresponding to the system call number;
• determine number of parameters to the system call;
• copy parameters from the user address space to u-area;
• save current context for abortive return; // studied later
• invoke system call code in kernel;
• if (error during execution of system call)
• {
• set register 0 in user saved register context to error number;
• turn on carry bit in PS register in user saved register context;
• }
• else
• set register 0, 1 in user saved register context to return values from system call;
• }

Context Switch
• As seen previously, the kernel permits a context switch under 4 situations:
• When a process sleeps
• When a process exits
• When a process returns from a system call to user mode but is not the most
eligible process to run.
• When a process returns from an interrupt handler to user mode but is not the
most eligible process to run.

Manipulation of the Process Address Space
• The region table entry contains the following information:
• The inode of the file from which the region was initially loaded.
• The type of the region (text, shared memory, private data, or stack).
• The size of the region.
• The location of the region in physical memory.
• The state of the region:
• Locked, in demand, being loaded into memory, valid, loaded into memory
• The reference count, giving the number of processes that reference the region
• The operations that manipulate regions are:
• lock a region
• unlock a region
• allocate a region
• attach a region to the memory space of a process
• change the size of a region
• load a region from a file into the memory space of a process
• free a region
• detach a region from the memory space of a process, and duplicate the contents of a region

Sleep
• Processes sleep inside of system calls awaiting for a particular resource or even if
a page fault occurs. In such cases, they push a context layer and do a context
switch. The context layers of a sleep process are shown below:

Algorithms for Sleep

Algorithm for Weak up

•Thank you …..

Unit 3.1 The Structure of Process, Process Control, Process Scheduling.ppt

More Related Content

Similar to Unit 3.1 The Structure of Process, Process Control, Process Scheduling.ppt (20)

More from AnilkumarBrahmane2 (20)

Recently uploaded (20)

Unit 3.1 The Structure of Process, Process Control, Process Scheduling.ppt