Transcript Processes

System Services
• System services are functions that the operating
system offers to perform on behalf of application
programs. For example, a compiler will translate
any request for input or output in a high level
language to one of the most common system
services, read() and write()
• System services are written and called as C
functions
• If called from a C program the processor changes
from user mode to kernel mode
• System calls return value of -1 if successful, 0 or
other if not.
• If system call fails it returns a number to errno
indicating the type of failure.
• Use perror() to display
Processes
• Definition - a process is a program in operation
• A reasonable analogy is baking a cake.
 The recipe for the cake is analogous to the
program
 The process in the kitchen from obtaining the
ingredients, mixing, baking and eating is
analogous to the process.
 If the process is held up – we’ve run out of sugar.
The process is swapped out and a new one loaded
(prepare the vegetables for main course i.e. a new
process).
 This swap will require that we need to put away all
the resources for baking the cake and get out new
one for preparing main course – although some may
be the same – process resources
 We will also need to keep a record of where we are
– process status
• Two things to note about processes:
• There may be more than one program per process
– programs are frequently written separately and
called during runtime.
• A program may be involved with one or more
processes - switching on the oven and putting the
food into it may be common and so called from
other processes.
Processes
Dispatch
Enter
Not
Running
Running
Exit
Pause
Figure 1 State Transition Diagram
Enter
Queue
Exit
Dispatch
Pause
Figure 2 Queuing Diagram
Processor
The Five State Model
• Running – the process is being executed.
• Ready – the process is sitting in a queue waiting its
turn.
• Blocked – the process is waiting for I/O or some
other service.
• New – the process has been created but not added to
the pool of executable processes.
• Exit – released from the pool of executable
processes
Dispatch
Admit
New
Ready
Release
Running
Exit
Timeout
Event
Occurs
Event
Wait
Blocked
Figure 3 Five Process Model
Release
Ready Queue
Admit
Dispatch
Processor
Timeout
Event
Occurs Blocked Queue
Event Wait
Figure 4 Single Blocked Queue
Release
Ready Queue
Admit
Dispatch
Processor
Figure 5
Timeout
Event 1 queue
Event 1 Wait
Event 2 queue
Event 2 Wait
Event n queue
Event n Wait
Dispatch
Admit
New
Ready
Release
Running
Timeout
Activate
Suspend
Event
Occurs
Blocked
Suspend
Event
Wait
Figure 6
Exit
7 Stage Process Model
New
Activate
Dispatch
Ready
Ready suspend
Suspend
Event
Occurs
Activate
Blocked
Suspend
Running
Timeout
Event
Occurs
Blocked suspend
Release
Event
Wait
Exit
Process Transitions
• Blocked  Blocked, suspend – If no processes have
received I/O then a process is moved to secondary
storage.
• Blocked, suspend  Ready, suspend – a process is
switched when it receives the event it has been waiting
for.
• Ready  Ready, suspend – this may occur in order to
free up a sufficiently large block in main memory.
• New  Ready, suspend and New  Ready – if a new
process goes firstly to ready, suspend it gives the
operating system time to create the necessary tables before
it is swapped to the ready queue. If the process goes
directly to the ready queue then creating tables with a
"just in time" philosophy will reduce overheads.
• Blocked, suspend  Blocked – this scenario sounds daft.
However if a process terminates, freeing up some main
memory while a process in the Blocked, suspend is of
higher priority than the others and the operating system
has reason to believe that the blocking event may occur
soon, then it is not so daft.
• Running  Ready, suspend – if the operating system if
preempting a process because a higher priority process in
the blocked, suspend queue has become unblocked, then
the operating system could move it directly to ready
suspend
In Unix, all processes are created with the system call fork(). This is without
exception. What fork() does is the following:
It creates a new process which is a copy of the calling process. That means that it
copies the caller's memory (code, globals, heap and stack), registers, and open
files. The calling process returns from fork() with the pid of the newly created
process (which is called the "child" process. The calling process is called the
"parent" process). The newly created process, as it is a duplicate of the parent,
also returns from the fork() call (this is because it is a duplicate -- it has the same
memory and registers, and thus the same stack pointer, frame pointer, and
program counter, and thus has to return from the fork() call). It returns with a
value of zero. This is how you know what process you're in when fork() returns.
main()
{ int i; printf("simpfork: pid = %d\n", getpid());
i = fork();
printf("Did a fork. It returned %d. getpid = %d.
getppid = %d\n",
i, getpid(), getppid());}
When it is run, the following happens:
UNIX> simpforksimpfork: pid = 914
Did a fork. It returned 915. getpid = 914. getppid
= 381
Did a fork. It returned 0. getpid = 915. getppid =
914UNIX>
The system call exec transforms the calling process by loading a new program
into its memory space. If the exec is successful the calling program is
completely overlaid by the new program, which is then started from its
beginning. The result can be regarded as a new process, but one that is given the
same PID as the calling process. exec does not create a sub-process to run
concurrently with the calling process. The old program is completely obliterated
by the new program.
Below is an example:
main()
{
printf("executing ls\n");
execl("/bin/ls", "ls", "-l", (char *)0);
perror("execl failed to run ls");
exit(1);
}
printf(…..);
PC
execl(“/bin/ls”…..);
BEFORE
AFTER
/* first line of ls */
PC
Android Life Cycle of an Activity
Android Life Cycle
•
•
•
OnCreate - this is the first method to be called when an activity
is created. OnCreate performs any startup initialisations that
may be required
OnStart - called when the activity is becoming visible to the
user. Android will call OnResume immediately after this
method
OnResume - the system calls this method when the Activity is
ready to start interacting with the user.
–
Analogy - onPause() is when I come to a temporary stop. When I come to a red
light I pause...the light goes green and I resume. Another red light and I pause,
then green so I resume. The onPause() ->onResume() ->onPause() >onResume() loop is a tight one and occurs many times through my journey.
•
OnPause - called when the system is about to start resuming a
previous activity. If the user does not interact with the phone the
screen will fade and the phone lock – this is also in OnPause
•
OnStop - called when the activity is no longer visible to the user,
because another activity has been resumed and is covering this
one
•
OnRestart - called after your activity has been stopped,
prior to it being started again.
•
OnDestroy - the final call you receive before your
activity is destroyed
Scheduling
• The long-term scheduler (or dispatcher) selects processes
from this pool and loads them into memory for execution.
• The short-term scheduler (or CPU scheduler) selects from
among the processes that are ready to execute, and allocates the
CPU to one of them.
• Often, the short-term scheduler executes at least once every
100 milliseconds.
• The long-term scheduler, executes much less frequently e.g
minutes between the creation of new processes in the system.
• The long-term scheduler controls the degree of
multiprogramming (the number of processes in memory).
• An I/O-bound process is one that spends more of its time
doing I/O than it spends doing computations.
• A CPU-bound process, on the other hand, is one that generates
I/O requests infrequently, using more of its time doing
computation than an I/O-bound process uses.
• If all processes are I/O bound, the ready queue will almost
always be empty, and the short-term scheduler will have little to
do.
• If all processes are CPU bound, the I/O waiting queue will
almost always be empty, devices will go unused, and again the
system will be unbalanced.
• The system with the best performance will have a combination
of CPU-bound and I/O-bound processes.
.
Threads
• Instead of completely suspending the process if we require a
resource we could just suspend part of the process and carry
on with a different part.
• So if we require, the butter to continue, we could suspend this
part of the process and move back to weighing out the flour
for the next batch of cakes.
• This would reduce the overheads substantially as now we still
have to save some of the status but don’t need to relinquish
the resources like spoons bowls etc.
• The process will still be using the same files, memory
locations, devices etc – it is just jumping to a different
location in the program code. This idea is known as multithreading and each unit of execution is called a thread.
• However, process still needs to save status information – state
of registers, program counter, stack etc.
Process resource management in Unix
•Working directory.
•Program instructions
•Registers
•Stack
•Heap
•Process ID, process group ID, user ID, and group ID
•File descriptors
•Environment
•Signal actions
•Shared libraries
Process Control Block
• Process Identification
– Identifier of this process
– Identifier of parent process
– User Identifier
• Processor State Information
– User visible registers
– Control and status registers
• Program counter
• Condition codes
• Status information
– Stack pointers
• Process Control Information
– Scheduling and state information
• Process state – ready, running,blocked etc.
• Priority
• Scheduling related information e.g. waiting time
• Event – identity of the event it is waiting for
– Data structuring
• Processes may be linked
– Interprocess communication
• Flags, signals associated with processes
– Process privileges
• e.g. memory that may be accessed
– Memory management
• Pointers to page tables
– Resource ownership
• Opened files, history of processor usage
Thread resource management
•Stack pointer
•Registers
•Scheduling properties (such as policy or priority)
•Set of pending and blocked signals
•Thread specific data
Microsoft Windows
• A thread is Windows smallest kernel-level object of execution.
• Processes in Windows can consist of one or more threads.
• When a process is created, one thread is generated along with it,
called the primary thread.
• Can create other threads that share its address space and
system resources but have independent contexts, which include
execution stacks and thread specific data.
Thread States in Windows
• Waiting state is the same as the Blocked state.
• Initialised state identifies a thread that is in the process of being
created but is not yet ready to run.
• Terminated state indicates that the thread has ended but it’s
resources have not been reclaimed by the system.
• Standby when it is between the time it is selected by the
scheduler and time it is given to the CPU (it is in the queue).
• Transition state identifies that the thread is no longer blocked
on the condition that it made to enter the Waiting state.
UNIX process creation
• fork() – this system call creates a clone of itself and
returns its process ID (PID) number.
• e.g
int pid;
pid = fork();
• exec() – there are a series of these call and they
basically overlays a current process with a program
of your choice.
• Hence you can create a child process using fork()
and then overlay it to produce a new process
The End
#include <stdio.h>
fatal(char *s)
{
perror(s);
exit(1);
}
main()
{
int pid;
pid = fork();
if (pid > 0)
{
wait((int *)0);
printf("ls completed\n");
exit(0);
}
if (pid == 0)
{
execl(" /bin/ls", "ls", "-l", (char *)0);
fatal("execl failed");
}
fatal ("fork failed");
}
• When a system call is identified a C library
routine runs which assigns the particular
system call a number and then causes a
software interrupt.
• This interrupt vector is called INT 0x80.
• This causes the CPU to go to the
appropriate entry in the interrupt descriptor
table, changes to kernel mode and jumps to
a common system call handler, known as
system_call().
• It then uses the system call number stored
in EAX to index into a system dispatch
table, sys_call_table to find the address of
the kernel code which executes that
particular system service.