Processes

© 2010-2019 SysPlay Workshops <workshop@sysplay.in>
All Rights Reserved.
Processes

2© 2010-2019 SysPlay Workshops <workshop@sysplay.in>
What to Expect?
W's of a Process
Processes in Linux
Scheduling & Preemption
Process States & Transitions
Process Management
Programming the Processes

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
Process A
Process B
User Space
Kernel Space
System Call
Interface
Time

Process Context Switch
Process A
Process B
Time
Save State
into PCB A
Reload State
from PCB B
Save State
into PCB B
Reload State
from PCB A
Time Wasted in Context Switch
Interrupt or System Call Interrupt or System Call

Generic Process State Diagram
Terminated
RunningReady
New
Blocked
ExitDispatch
Wakeup on
I/O or event
completion
Admitted
Block on
I/O or
wait event
Time Run-Out
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)
Uninterruptible or Interruptible
Zombie
Stopped

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

System function
Used to execute the command from within the
program
Creates the subprocess running the system shell
& hands the command to that shell for execution
Subject to the features & limitations of the
system shell
Try system.c

fork()
Creates the duplicate of the calling process
Process invoking the fork() becomes the Parent
of newly created Child process.
Child process too executes the same program
from the same place
All the statements after the call to fork are
executed twice
Try fork.c

Distinguishing Child & Parent
fork() provides the different return values to the
parent & child process.
One process “goes in” to the fork call & 2
processes “come out” with different return values
Return value in the parent process is the process
ID of the child
Return value in the child process is 0.
Try fork_basic.c

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, …
Try exec_start.c

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”

Using fork & exec together
Allows the program calling exec to continue
execution after exec
First fork a program & then exec the subprogram
in child process
Original program continues in the parent process
& new program is executed in child process
Try fork_execv.c

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 …
Try wait_basic.c

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Processes

Ähnlich wie Processes (20)

Mehr von Anil Kumar Pugalia

Mehr von Anil Kumar Pugalia (18)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Processes