Download Process Control and Description

Chapter 3
Process Control
and Description
All multiprogramming operating systems, for
single user or otherwise, are built around the
concept of process. Such an OS switches back
and forth between multiple processes, to maximize the processor utilization while providing
a reasonable response time to users.
It has to allocate resources to processes according to a predetermined policy, while at the
same time avoiding deadlock and starvation.
Such an OS also has to provide inter-process
communication to facilitate concurrent execution of processes.
1
What is a process?
A process can be thought as a program in execution, or more precisely, a unit of activity
specified by the execution of a sequence of instructions, a specific state, and an associated
collection of system resources.
A process fundamentally consists of two static
pieces: a segment of program code and a set
of data associated with that segment.
When running, a process can be uniquely identified with a number of elements, collected in
the Process Control Block (PCB), such as an
identifier, a state, a priority, the address of
the next instruction to be executed, a memory
pointer indicating where the program is located
in the memory, and which piece of data will be
accessed, IO status, and accounting information such as how much CPU time has been
consumed, time limit for this run, etc..
2
The state of a process
To execute a program, we create a process, or
a task, and assign it to a processor.
As already discussed, to raise efficiency, we will
let a processor go from program to program,
as directed by a dispatcher, i.e., a scheduling
program.
From the perspective of the processor, it simply gets whatever instruction, from various processes, from the memory as the PC indicates.
On the other hand, from the perspective of
the individual program, its execution involves
a sequence of instructions within that program.
3
The Process’s view
To characterize the behavior of an individual
process, we can simply list the sequence of instructions that will be executed for that process. Below shows an example of three traces.
Trans. A
5000
5001
5002
5003
5004
5005
5006
5007
5008
5009
5010
5011
Trans. B
8000
8001
8002
8003
Trans. C
12000
12001
12002
12003
12004
12005
12006
12007
12008
12009
12010
12011
We can then characterize the behavior of the
processor by showing how the traces of various
processes are interleaved.
4
The Processor’s view
A simple strategy to prevent any program to
monopolize the processor is to allow any program to execute at most, e.g., six instructions,
then the processor will take over the control,
and switch to the next program. So on and so
forth.
For the previous three-process example, the
processor will execute the first 6 instructions
of process A, then executes a dispatcher’s program, then switches to the first 6 instructions
of process B, then again executes a dispatcher’s
program, switches to C, the dispatcher, then
back to process A, etc..
Thus, in reality, there are actually four processes in motion.,
5
An example
The execution starts with the first 6 instructions of A, then the dispatcher kicks in, by
executing the segment 100–105, to switch the
processor to B which, after four instructions,
presents an IO request, thus has to wait.
Then, the dispatcher moves the processor goes
to C. Since it takes long for B to get its data,
the processor simply moves between A and C.
6
A two-state process model
The principle responsibility of an OS is to decide which process is to execute next, which
decides the interleaving pattern of the process
execution, thus the associated resource allocation.
To characterize such a pattern, the first thing
we have to do is to specify and manage the
behavior of these processes, which can be done
by using a finite state machine.
We start with the following two-state model.
7
A few thoughts
We must provide certain information, such as
the current state (Can I be run?), and the
code location of every process (What should
be run?) to the OS so that the OS can keep
track of processes and their execution.
Moreover, processes that are not running should
be kept in a (priority) queue for their turn.
A process that just overran its share, by this
simple model, is simply taken out and put back
into the queue to wait for its next opportunity.
Question: How about “We were born, ..., we
die.”?
8
Birth and death
OS creates a process by building a data structure, PCB, to manage such a process, and
might immediately allocate address space in
the main memory for it.
There are in general four events that can lead
to the creation of a process: A new batch
job is requested; an user just logged on to
the system (Another process 1 in unix); another service is to be provided (Print something
out); and an existing process wants to create
another process to get something done (Call
fork() in unix).
There are also a few reasons terminate a process, from its normal completion to detection
because of various errors (Division by zero).
Homework: Look through Tables 3.1 (pp.113)
and 3.2(pp. 115) to check out various reasons
to create and terminate a process.
9
A five-state process model
The problem with the previous two-state model
is that it is not the case that every process is
ready to run. Some in the Not Running state
are ready to run, the others could be blocked
for various reasons, e.g., waiting for an I/O
operation to complete, thus can’t. Therefore,
a single queue is not enough.
A natural way is to split the Not Running state
in two states: Ready and Blocked.
10
Get in and out
A process is New if it is just created and admitted into the system, meaning its PCB has been
created, but not loaded into the main memory
yet.
When a process is in the Ready state, it is
in the memory, getting everything it needs,
and ready to execute when given the processor; otherwise, it still needs something, thus
Blocked.
A process exits the system in two stages. When
a process is completed, it is terminated; or
when it is aborted because of an error.
It can also be preempted out by another more
important process, when it is no longer executable, but its associated tables and other
information might still be available.
11
What could happen?
Null → New: A new process is created to execute a program.
New → Ready: OS makes such a move when
it is ready to accept another process into the
memory, without degrading the performance.
Ready → Running: When the processor becomes available, it is assigned to the next process so that it starts to run.
Running → Exit: The running process is terminated if it is completed or aborted.
Running → Ready: Most likely, it is a time out.
Running → Blocked: A running process is put
into the Blocked state if it is asking for something and has to wait for it.
Ready → Exit: A parent process may terminate a ready child process, e.g., when itself is
completed.
12
The queue structure
Below shows the case when several queues are
provided for the blocked processes, one for
each reason of blocking. When the OS decides to select another process for the Ready
queue, a predetermined policy will be applied.
Homework: Problem 3.1.
13
Process suspension
The model we have set up so far has not overcome all the problems. The original idea is that
memory holds various processes, and when one
process is waiting for some service, the processor can turn to another one.
But, since the I/O is so much slower than the
processor, it could be the case that all the processes in the memory are waiting for the I/O to
complete. Then, the processor is simply idle.
One solution might be to increase the memory size so more processes will fit, but that
is not good enough, because of the associated
cost, and the likely scenario of larger processes,
rather than more.
14
Is there another option?
Another solution is swapping, namely, moving
some of the blocked processes out of the memory and keeping them in the Suspension queue
in a disk, where they will wait for what they
want; then, when none of the processes in the
memory is ready to run, the OS will swap some
of these blocked processes out of the memory,
and move back some of the ready processes
from the disk back into the memory.
Question: Did you hear lots of swapping going on when you don’t have lots of memory in
your machine?
As an I/O operation, swapping might potentially make the whole thing even worse, taking
more time. But, in general, disk I/O is much
faster than you-know-what. Thus, swapping
usually enhances performance.
15
With the suspend state
Below shows the modified model:
Blocked and Suspend differ in where a process
waits for the stuff that it needs.
We still have a problem as all of the blocked
processes could be collected into the Suspend
state, and wait in a disk; since it does not
make sense to bring a Blocked process into
the memory if it is not ready to run.
16
Dig a bit deeper...
There are actually two aspects here: a process
can be blocked when it is waiting for something; and it can also be, independently, swapped
out of the memory into the secondary memory.
Thus, a process could actually be in one of four
states, depending on where it is and whether
it is ready to run:
Ready: The process is in memory and available
for execution.
Blocked: It is in the main memory, but waiting
for something to happen.
Blocked/Suspend: It is in the secondary memory, awaiting for something to happen.
Ready/Suspend: It is in the secondary memory, but can run as soon as loaded.
Homework: Problem 3.2.
17
Is suspension really needed?
We have so far avoided the issue of virtual
space, thus a process is either completely in,
or out. On the other hand, virtual memory
refers to a hardware mechanism which brings
in a piece when there is a need to visit a virtual address that is associated with somewhere
outside the physical real memory.
Virtual memory might be thought of as a replacement of the swapping process, typically
software based.
But, as we will see later, the virtual memory
mechanism will collapse when too many active
processes are in memory and all of them are
only partially in. When this happens, we cannot depend on the VM, but have to have an
explicit swapping facility.
18
A final FSM model for process
Below is a more sophisticated description of
the lifetime of a typical process.
The really new state is this Ready/Suspend, where
a Ready process can also be swapped out.
Homework: Problem 3.4.
19
Possible transitions
Blocked → Blocked/Suspend: When there are
no ready processes inside the memory, at least
one of the blocked process has to be swapped
out to make room for another process that
is not blocked, e.g., those Ready/Suspended
ones. This transition can happen even when
there are ready processes if OS feels that it
needs more space to keep the performance
high.
Blocked/Suspend → Ready/Suspend: When
the event this Blocked/suspended process is
waiting for has finally occurred, it will be put
back to the Ready/Suspended state.
Running → Ready/Suspend: Its time is up, but
there is not that much space in the memory for
it to stay.
20
Another possible transition
New → Ready/Suspend and New → Ready:
When a new process enters the picture, it can
be either added to the Ready queue; or the
Ready/Suspend queue. In either case, the OS
must build a few tables to manage the processes and allocate an address space to a Ready
process.
If an OS does these sorts of things early in
the game, more processes that are not blocked
will be available. But, this will lead to reduced
space in the memory, thus more processes later
on will have to be swapped out. Thus, it
makes sense to put a new process into the
Ready/Suspend state, i.e., shipped it out first.
Homework: Check out the other transitions
as stated in pp. 122 and 123, as well. Then
complete Problems 3.3.
21
When to suspend a process?
A process is suspended when it is not immediately available for execution; it might wait
for an event; it might be so placed by another
agent before explicitly freed.
Thus, besides swapping out, there could be
other reasons to suspend a process. For example, the OS may suspend a background, or
utility, process, to focus on the more important tasks. A user may wish to suspend the
execution of a program for the purpose of debugging. A process may be executed periodically, so it has to be suspended when its time
is up. Finally, a parent process may want to
suspend a child process to check it out before
letting it proceed.
In all these cases, the request of suspension
comes from an agent that originally initiated
this process.
Homework: Problems 3.5 and 3.9.
22
Describing a process
OS can be looked at as an entity that manages
the use of system resources for processes. The
following picture shows the situation: Processes
are created and exist in the virtual memory.
Each of them, during its lifetime, needs access
to certain resource, such as processor, various
I/O facilities, and main memory.
For example, P1 is running; at least part of it
is in the main memory; and it also controls two
I/O devices; P2 is blocked and waiting for an
I/O piece; and Pn has been swapped out of
the memory, and is suspended and ready.
23
A few control structures
Before we try to understand the process of process creation, let’s have a closer look at the
various structures we use to control such processes.
Memory tables are used to keep information on
both main and secondary memory. Some of
the main memory is reserved for the OS, and
the rest is available for the processes. Processes are maintained on secondary memory,
using either the virtual memory, or a simple
swapping, mechanism.
A memory table has to keep information on
the allocation of main memory to processes;
that of the secondary memory; any protection
attributes of blocks of main or virtual memory,
e.g., which processes can get access to certain
shared memory blocks.
24
A memory table also contains any other information needed to manage virtual memory,
e.g., the page tables.
If an I/O device is in progress, the OS needs to
know the status of the I/O operation and the
location in the main memory that is used for
this data transfer. These sorts of information
are collected in an I/O table.
File tables provide information about the existence of files, their location on secondary
memory, their current status, and other such
attributes.
25
Hooked up together
Those tables are not isolated, instead, they are
connected to constitute a structure.
26
Process image
To control process, the first thing an OS has
to know is where a process is located, it also
needs to know the attributes of the process
that are necessary for its management, such as
process ID, process state, location in memory,
etc..
At minimum, a process includes a program,
or a set of programs, to be executed, together
with a set of data locations for local and global
variables, and constants. Thus, a process must
be assigned enough space to hold all these information.
In addition, the execution of a program usually
needs a stack for interprocess communication
and a record of procedure calls.
Finally, each process is associated with a bunch
of attributes, called process control block. We
call this whole collection the process image.
27
Process storage
In the simplest case, the process image can be
maintained as a contiguous block of memory,
which can be stored in secondary memory such
as a disk. To execute a process, its image has
to be loaded into the main memory, or at least
in the virtual memory. Thus, the OS has to
know where the process is on disk, and for each
process that is in memory, the location in the
main memory.
Most of the modern OS use a memory management scheme, thus representing the process image as a collection of blocks that need
not be stored contiguously. It allows the OS to
bring in only some of those blocks, but not all
of them. Thus, the associated memory table
must show the location of each portion of a
process image.
28
The role of the PCB
Containing critical information about a process, PCB, i.e., the process control block, is
the most important data structure in an operating system. They are used by almost every
module in an operating system, such as those
in charge of scheduling, resource allocation, interrupt handling, and performance monitoring.
Because of its critical role, a direct access is
usually not allowed. Instead, all routines are
required to go through a handler routine, which
protects the integrity of PCBs. Just like in
Java, you cannot directly access the private
data, but you have to use a public method.
This certainly leads to some compromise of the
system performance.
29
Process attributes
The process control block contains the following three kinds of information. Process identification contains a unique identifier for each
process, providing the OS with the destination
when interprocess communication has to be
handled.
Process state information contains the contents of processor registers. When it is in the
Running state, this set of information is stored
in the registers, and when it is interrupted for
whatever reason, it is kept somewhere; and
will be restored back to the registers, when its
execution is resumed.
Process control information contains such data
as scheduling and state information (priority,
etc.), data structural information about its environment, interprocess communication, its privileges, memory management information, resource ownership, etc..
30
Process status word
Below shows an example of a process status
word as used by Intel x36, as explained in Table 3.l6 in page 131. This structure is used by
any OS running on an Intel x86 processor.
31
Two modes of execution
Most of processors support two kinds of execution modes. Certain instructions can only be
executed in the privileged system mode, or kernel mode. Such instructions include reading or
changing a control register, primitive I/O instructions that relate to memory management.
Also, certain portion of memory can only be
accessed in this mode.
The less privileged mode is referred to as the
user mode, since most user programs are executed in this mode.
The basic reason for having those two nodes is
that operating system, and its tables, have to
be protected from interference by other user
programs. In the kernel mode, the software
has complete control of the processor and all
its instructions, registers, and memory, which
is not necessary, or even desirable, for user programs.
32
Two questions
1. How does the processor know its current
mode?
A bit (NT) in the status word (PSW) indicates
the mode of current execution. When a program requests an OS service, this bit will set
to be the kernel mode.
2. How to change the mode?
This is typically done by executing an instruction. For example, in the VAX system, When
the user makes a system service call, or an
interrupt occurs, the change mode instruction
(CHM), is executed to enter the system mode,
and executed again before switching back to
the user mode.
When an user program tries to execute the
CHM instruction, the OS will send back an
error message, except this is allowed.
33
When a process is created...
Knowing the control structures, we are now in
a better position to understand the process of
creating a process, when the OS decides to do
so.
1. Assign a unique process id to the new process, when a new entry is added to the primary
process table.
2. Allocate space for the process, including
the whole process image.
Thus, the OS must know at this point how
much space is needed for the private user address space, and the user stack. This can be
either set by default, or passed in via a user
request.
Another way is for the parent process to pass
on such information, when splitting children
processes.
34
3. Initialize the process control block, where
the process identifying portion contains the ID
of the process, plus other IDs, such as that of
the parent process. The processor state information will typically be initialized with 0, except for the program counter, and the system
stack pointers. The process state word is typically initialized to Ready or Ready/Suspend.
The priority may be set by default to lowest
unless an explicit request is made. Also, at
first, the process may not own any resource,
unless there is an explicit request, or inherited
from the parent.
4. Set the appropriate linkage, e.g., join the
Ready queue.
5. Create, or expand other data structures,
e.g., the OS may have an accounting file on
each process for the billing purpose.
35
Process switching
The switching occurs when a running process
is interrupted, and the OS assigns another process to the Running state and turns the control
over to that process.
We do have to understand a few issues better. For example, what events trigger a process switch? Also, what is the difference between process switching and mode switching?
Finally, what does the OS do in terms of the
process control structures to achieve a process
switch.
36
When to do it?
A process switch occurs whenever the OS has
gained the control from the currently running
process. For example, when the OS has to
react to an external event, the current process
is interrupted; or when it has to handle an error
or an exception (trap); or it has to handle a
system call to some OS functions.
With an interrupt, control is transferred to
an interrupt handler, which, after doing some
housekeeping work, will branch off to a specific
OS routing that handles that type of interrupt.
37
A few examples
In case of a memory fault, when the processor
has to deal with a virtual memory reference to
a word which is not in the main memory. The
OS must bring in the block that contains that
word from the secondary memory.
Starting with an I/O request to bring in that
block, the OS may switch to a process to put
the original process in the blocked state, and
bring in the requested block into the memory.
It finally does a process switch to resume the
execution of another Ready process.
After the desired block is brought in, the originating process will be placed in the Ready
state, and will be running when selected later
on.
38
Remember trap...
... to capture an exception?
With a trap, the OS first determines if the
error or the exception is fatal. If it is fatal, the
currently running process is moved to the Exit
state and a process switch occurs. Otherwise,
what to do depends on the nature of the error
and design of the OS.
The OS may attempt to recover information
or simply notify the user. It also may do a
process switch to run another Ready process,
or resume the current process when the OS
returns.
The case of a supervisor call, or system call, is
similar to the interrupt case.
39
More about interrupt
When an interrupt occurs, the processor will
save all the context of the current program
being executed, before switching to the handler.
In particular, the relevant status information
must be saved, such as the program counter,
the register information, and the stack information must be saved.
What happens next depends on the nature of
the interrupt. In most OS, interrupt may not
necessarily lead to a process switch. It is quite
possible that, after executing the interrupt handler, the currently running process may resume
its execution. Thus, the only thing the processor needs to do is to save and restore the relevant information. In this case, only the mode
may change, while the process will not.
40
Process state change
When there is a need to change the status of
a process, e.g., from Ready to Suspend, OS
has to go through the following steps:
1. Save the context of the processor for the
current process.
2. Update the PCB of the currently running
process, particularly, the state has to be changed
to either Ready, Blocked, Read/Suspend, or
Exit. Other information such as accounting
information might be changed as well.
3. Move the PCB of the currently running
process to one of the appropriate queues.
41
4. Select another process for running, and update its PCB, e.g., changing its state to Running.
5. Update other necessary data structures.
6. Restore the context of the processor to that
saved for the just selected process when it was
executed.
42
How does OS run?
Since OS is also a program that is executed by
the processor, and OS frequently gains control
of the processor, and then lets it go, there
are a few approaches as how to control the
execution of the OS.
43
Execute separately
One approach is to execute the OS kernel outside any process, when the currently running
process is interrupted, or issue a supervisor
call, the mode context of the process is saved,
and the control is passed to the kernel. The
OS has its own region of memory to use and
its own system stack for controlling procedure
calls and return. It can perform any desired
function, and restore the context of any interrupted process to resume its execution. The
OS can also save the current environment of
the current process, and proceed to the dispatcher to select another process to run.
The key point is that the concept of a process only applies to the user programs. The
OS code is executed as a separate entity that
operates in a privileged mode.
44
Execute within a process
An alternative approach, particularly for smaller
machines, is to execute virtually all OS system
software in the context of a user process. The
idea is that an OS is basically a collection of
routines that the users call to perform various
functions, executed within the user’s environment. Typically, the PCB of every process,
besides its own data, also contains program,
data, and stack areas for kernel programs.
When, e.g., an interrupt, occurs, the processor
is placed in kernel mode, the context of the
process is saved, and the control is passed to
an OS routine, part of this process.
Thus, the execution continues with the currently running process: there is no process
change, just a mode change.
45
Then, what?
When the OS completes its work, if it determines that the current process should continue, it will do a mode switch and resumes the
interrupted program within the current process. Otherwise, it will pass its control to a
process switching routine, which may or may
not run within the current process. But, at
some point, the currently running process will
be put into a Ready queue, and another process is designated as the Running process.
The key point here is that the scheduler is an
OS process, shared among all the user processes, running in the OS mode. As a result,
a user process can not interfere with the scheduler.
Thus, the scheduling process will not be an
arbitrary one, but rather a controlled one.
46
Execute as a process
Yet another approach is to implement the OS
as a collection of system processes. The software belonging to the kernel will execute in a
kernel mode. A smaller amount of processswitching code has to execute outside all the
processes.
This approach encourages the designers to follow modular design with a minimum, and clean
interface in between these modules. Also, some
non-critical OS functions can be implemented
as separate processes. For example, a resource
monitoring service can be implemented as a
process, thus interleaved with other processes
under the control of the dispatcher.
Finally, this approach fits the multiprocessor
environment very well, as some of the OS processes can be assigned to dedicated processors
to improve performance.
47
What can a process get to?
With each process, an OS will associate a set
of privileges, which tells what resource that
process may have access, such as which region
in the memory can this process put its hands
on, what files it can get to, what system instructions can it execute, etc..
In particular, a process that a user executes
inherits all the privileges that user has, while a
system process will have its privileges assigned
at its configuration, or creation, time.
The highest level of privilege is the root access,
which gets to everything. Thus, the key security issue in OS is to prevent, or at least detect,
any attempt by a user from getting unauthorized privileges on the system, and particularly,
getting root access.
48
Security issues
System access threats fall into two categories:
intruders and malicious software.
There are three kinds of intruders: masquerader that gets into the system to exploit a legitimate user’s accounts; misfeasor refers to a
legitimate user who gets in somewhere s/he
is not authorized; and clandestine user who
seizes supervisory control of the system, evades
auditing and access control or suppress auditing data collection.
Intruder attacks range from the benign to the
serious, always having the objectives of gaining
access, or more access, to system resources.
49
Malicious software
This type of software tries to exploit vulnerabilities in computing systems.
It can be further divided into two categories:
Virus, logic bombs and back doors are just part
of a program that need a host program to run;
and worms and bot programs are independent.
In particular, a worm often spreads itself through
the net, besides doing anything it wants. We
once discussed the theoretical foundation of
such software in CS3780.
50
What to do?
One way is to use intrusion detection which
monitors and analyzes system events for the
purpose of finding, and providing real-time or
near real-time warning of attempts to get access to system resources in an unauthorized
manner.
There are quite a few intrusion detection systems around, which could be either host-based
or network-based. Such a system essentially
contains three pieces: sensors that collects data;
analyzers, receiving inputs from the sensors
and/or other analyzers, sends out indications
as whether any attempt has been made; and a
user interface which lets a user view the above
output.
51
Authentication
In most of the computer security context, user
authentication is the basic building block and
the first line of defense. This process really
consists of two steps: identify the user and
verify the presented information.
There are multiple ways to authenticating a
user’s identity, which can be used in combination: Something the user knows, such as
a password; or the user possesses, such as
your ATM card(s); or what the user is, such
as his/her finger prints; or something that the
user does, e.g., his/her voice, typing rhythm,
etc..
Such authentication can be made really strong.
The recent fight between Apple and FBI provides an excellent example.
52
Access control and firewall
Access control sets up a policy, specifying who
or what may have access to which system resource, and the type of access that is permitted.
A firewall can be quite effective to protect a
local system or a network. As a door keeper,
it is typically a dedicated computer that interfaces with computers outside a network and
those within.
All traffic between the protected network and
the outside world goes through such a firewall
mechanism; and only the authorized traffic can
go through to the systems within.
53
UNIX process management
In UNIX, most of the OS executes within the
environment of a user process. Thus, it needs
two modes, and manages two kinds of user
processes: system process and user process.
A system process runs in a kernel mode, and
executes OS code to perform various OS functions, such as switching process and allocating
space.
User process executes in a user mode and runs
user programs and utilities and can also execute kernel codes in the kernel mode. It enters
the kernel mode by issuing a system call, when
an exception happens, or when an interrupt
occurs.
54
Process state diagram
Below shows the state transition diagram used
in UNIX.
UNIX uses two Running states, User Running
and Kernel Running, to distinguish the two execution modes.
55
Preempted...
Unix also distinguishes the Ready to Run in
memory state and the Preempted state.
When a process, running in the kernel mode, is
completed. Besides returning the user mode to
continue, the scheduler may decide to preempt
the current process, and give the control to
another Ready process with a higher priority.
In this case, the current process will be placed
in the Preempted state.
Two processes are unique in UNIX: the process 0 is created when the system boots. Besides being the swapper process, it also creates
a process 1, which is the ancestor of all the
other processes.
Particularly, when a user logs on, it is process 1
that creates a new process for that user.
56
Process description
Process description in UNIX is a collection of
complicated data structures that provide the
OS with all the information it needs to manage
and dispatch processes.
The user-level context contains the basic elements of a user’s program, and can be generated directly from a compiled user object file,
consisting of the instruction part and the data
part. The register context area saves all the
information for a process when it is not running. The system context area contains the
remaining information.
Homework: Check out Table 3.9 for the detailed description about the process description
part of a UNIX process.
57
Process control
When a process issues a fork() call to create
a process, the OS does the following in the
kernel mode:
1. Allocate a slot in the process table for the
new process.
2. Assign a unique ID for the process.
3. Make a copy of the parent process associated data, except any shared memory information.
4. Increment a counter for the files owned by
its parent process.
5. Assign the newly created child process to
Ready to Run status.
6. Return the ID member of its parent process,
but 0 for the child process.
58
What to do?
When the OS completes the above sequence,
it can do one of the following, as part of the
dispatching process.
1. Stay in the parent process, by returning the
control to the user mode from fork.
pid=fork();
2. Switch control to the child process, and let
the child process execute at the same point as
the parent does, namely, the return point from
the fork() call.
3. Switch the control to another process, while
leaving both the parent and the child processes
in the Ready state.
59
What’s next?
The OS decides what to do next based on the
value returned from the above process.
It can do a test at that return point from the
fork() call. If a negative value is sent back,
something is wrong. If a positive value is returned, the main execution of the parent process continues; Otherwise, a 0 is picked up,
the just created child process will do its work.
if(pid=fork())
parent stuff;
else child stuff;
Confused? Project 1 will clear this up for you....
60