Processes

Processes

© 2010 Anil Kumar Pugalia <email@sarika-pugs.com>
All Rights Reserved.

What to Expect?
W's of a Process
Processes in Linux
Scheduling & Preemption
Process States & Transitions
Process Management
Programming the Processes

© 2010 Anil Kumar Pugalia <email@sarika-pugs.com> 2

What is a Process?
Program in Execution
Executable/Program Loaded → Process
Program is just the Code & initial Data part
Additionally
Value of Variables
Stack
Heap
Program Counter
Processor Registers
And any other OS resources, needed by the Program
make it a Process

Why we need a Process?
To do any task or job
Moreover, to achieve multi-processing
Really do multiple tasks at a time (in multi-processor
systems), Or
At least get a feel of doing multiple tasks at a time (on
uni-processor systems)
In turn needs
Timesharing (on same processor)
Scheduling
Priority
And for all these: Process Identifier (pid)

Let's View
Shell Local Processes: ps
Console attached System Processes: ps a
All System Processes: ps ax
List many more details: Add l
Observe
uid, pid, ppid, priority, nice, status, tty, time
Dynamic Process Status: top
Try pid.c

Processes in Linux


Linux Schedulers
Provide multi-tasking capabilities by
Time Slicing
Preemption
Based on various task priorities
Specified by its scheduling policies
Understand the following execution instances
Kernel Thread
User Process
User Thread


Linux Schedulers ...
Linux Basic Scheduling
Normal (SCHED_OTHER) – Fairness
Scheduling
Other Advanced Scheduling supported
Round Robin (SCHED_RR)
FIFO (SCHED_FIFO)
All Schedulers are O(1)


Linux Kernel Preemption Levels
None (PREEMPT_NONE)
No forced preemption
Overall throughput, on average, is good
Voluntary (PREEMPT_VOLUNTARY)
First stage of latency reduction
Explicit preemption points are placed at strategic locations
Standard (PREEMPT_DESKTOP)
Preemption enabled everywhere except within critical sections
Good for soft real-time applications, like audio, multimedia, …
Kernel Parameter: preempt


Kernel Preemption Visualization

Time

User Space

System Call
Interface

Kernel Space
Process A
Process B


Process Context Switch

Time

Save State Save State
into PCB A into PCB B
Reload State Reload State
from PCB B from PCB A

Interrupt or System Call Interrupt or System Call

Process A Time Wasted in Context Switch
Process B


Generic Process State Diagram
Time Run-Out
New Terminated
Admitted Dispatch Exit
Ready Running Zombie
Wakeup on
Block on
I/O or event
I/O or
completion
wait event
Blocked Stopped
Uninterruptible or Interruptible

Ready & Blocked states have Queues
Additional States in Linux
Defunct / Zombie (Terminated but not reaped by its parent)
Stopped (By job control signal or because being traced)


Linux Process States
Process States as in Linux
TASK_RUNNING (R) – ready or running
TASK_INTERRUPTIBLE (S) – blocked (waiting for an event)
TASK_UNINTERRUPTIBLE (D) – blocked (usually for I/O)
TASK_ZOMBIE (Z) – terminated but not cleaned up by its
parent
TASK_STOPPED (T) – execution stopped
Mutually exclusive
Additional Information: Foreground (+), Threaded (l)


Process Management in Linux
Needs collation of all this information
Address Space (Code, Variables, Stack, Heap)
Processor State (PC, Registers, …)
OS resources in use (File descriptors, ...)
Scheduling Info, Priority, ...
Preemption Info, Process State, ...
for every Process
Stored in structure of type 'task_struct'
Maintained by Linux Kernel on a per process basis
Also called the Process Descriptor / Process Control Block


Process Control Block (PCB)
Listing: <kernel_source>/include/linux/sched.h
Some of its fields are
volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */
void *stack;
unsigned int flags; /* per process flags */
int prio, static_prio, normal_prio;
unsigned int rt_priority;
const struct sched_class *sched_class;
unsigned int policy;
struct mm_struct *mm, active_mm; / Pointers to Memory Regions, Descriptors */
pid_t pid, tgid;
struct task_struct *real_parent; /* real parent process */
struct task_struct *parent; /* recipient of SIGCHLD, wait4() reports */
struct list_head children /* list of its children */, sibling; /* linkage in its parent's children list */
struct task_struct *group_leader; /* threadgroup leader */
struct list_head thread_group;
struct fs_struct fs; /* file system info like current directory, … */
struct files_struct files; / file descriptors */
struct signal_struct signal; / signal handlers */
sigset_t blocked, real_blocked, saved_sigmask;
struct sigpending pending; /* signals received */


Basic Process Management
bg - Starts a suspended process in the
background
fg - Starts a suspended process in the
foreground
jobs - Lists the jobs running
pidof - Find the process ID of a running
program
top - Display the processes that are using
the most CPU resources

Programming Linux Processes


Process Creation
From Shell
By running a Command / Program / Script (Even by .)
By 'exec' ing a Command / Program
By Programming
Using system()
Simple but Inefficient
Security risks
Using fork() and exec() family function
Comparatively complex
Greater flexibility, speed, and security


Using the exec family
All exec* functions do the same thing
Just in different ways
Replaces current program by a new one
And hence never returns, unless an error
New program is immediately started
Process remains the same
Process Id, Parent Process Id
Current directory, ...
Open file descriptor tables, ...

exec* function specifics
exec*p (execvp, execlp)
Accepts a program name
Searches it in the current execution path
Others must be given the full path
execv* (execv, execvp, execve)
Argument list should be a NULL-terminated array of pointers to strings
execl* (execl, execlp, execle)
Argument list uses the varargs mechanism
exec*e (execve, execle)
Accepts an additional argument: an array of environment variables
It should be a NULL-terminated array of pointers to character strings
Each character string should be of the form “VARIABLE=value”


Cons of using fork
Forked child process executes the copy of
parent process' program
And typically, a fork is followed by exec
Replacing the copy by the new program
What is the point of copying?
Overhead!! What else?
Is there any way out to prevent this?
Yes. And it is ...

Copy On Write (COW)
Parent and Child shares the Address Space (ro)
Data & other Resources are marked COW
If written to, a duplicate is made and each
process receives a unique copy
Consequently, the duplication of resources occurs
only when they are written to
Avoids copy in cases of immediate exec
fork()'s only overheads
Duplication of the parent's page tables
Creation of a unique PCB for the child

Process Termination
Parent & Children Processes terminate as usual
Success Exit – Normal Success
Error Exit – Normal Failure
Fatal Exit – Signaled from Kernel Space for a Bug
Kill Exit – Signaled by a Process
But which one of them terminates, first?
Does it matter?
If it matters, parents can wait for their children
Using wait family of system calls
And can retrieve information about its child’s termination
In fact, wait does the cleanup act for the exited child

Using the wait family
Four different system calls in the wait family
wait(): Block until one of its child processes exits
waitpid(): Wait for a specific child to exit/stop/resume
wait3(): Along with, return resource usage information
about the exiting/stopping/resuming child process
wait4(): wait3() for a specific child or children
All of these fill up a status code
in an integer pointer argument
about how the child process exited
which can be decoded using ...


wait status macros
WIFEXITED, WEXITSTATUS
WIFSIGNALED, WTERMSIG, WCOREDUMP
WIFSTOPPED, WSTOPSIG
WIFCONTINUED


What if Parents Don't Wait?
If Parent dies before the Children
Children become Orphans
And are adopted by the Init Process
which then does the cleanup on their exit
If a Child exits before the Parent
That's a sad thing :)
It will become a Ghost / Zombie
Note that, even if the parent does a wait later
It remains a Zombie till then

Who Cleans Up a Zombie?
Typically, again a Parent
By doing a wait on it
What if the parent exits without “wait”?
Does it stay around in the system?
Not really. It gets inherited by init
which then cleans it up, right there


What all have we learnt?
W's of a Process?
Process Scheduling & Preemption in Linux
Process States & Transitions (Linux specific)
Linux Process Management using PCB
Programming Linux Processes
Creation Techniques: fork, exec* & COW
Termination & Waiting Techniques
Orphans & Zombies


Any Queries?


Processes

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Processes (20)

More from Anil Kumar Pugalia (17)

Recently uploaded (20)

Processes