the process concept (section 3.1, 3.3 and demos)

24
The process concept (section 3.1, 3.3 and demos) Process: An entity capable of requesting and using computer resources (memory, CPU cycles, files, etc). Sometimes called a program in execution. NOTE: two processes might be associated with the same program if there are two instances of that program running simultaneously

Upload: sanaa

Post on 23-Feb-2016

27 views

Category:

Documents


0 download

DESCRIPTION

The process concept (section 3.1, 3.3 and demos). Process: An entity capable of requesting and using computer resources (memory, CPU cycles, files, etc). Sometimes called a program in execution . - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: The process concept (section 3.1, 3.3 and demos)

The process concept (section 3.1, 3.3 and demos) Process:

An entity capable of requesting and using computer resources (memory, CPU cycles, files, etc).

Sometimes called a program in execution. NOTE: two processes might be associated with

the same program if there are two instances of that program running simultaneously

Page 2: The process concept (section 3.1, 3.3 and demos)

Figure 3.1

Author refers to code as the text section.

Page 3: The process concept (section 3.1, 3.3 and demos)

Process states Figure 3.2

Page 4: The process concept (section 3.1, 3.3 and demos)

Context switch Task of switching the CPU from one process

to another. Requires saving the state of the current

process Requires restoring the state of the next

process Pure OS overhead and can be complex If the OS is running on a processor, user apps

are NOT.

Page 5: The process concept (section 3.1, 3.3 and demos)

Process Creation A process can create other processes

The process that does the creating is called a parent. The newly created process is called a child.

A child process can create others and thus become a parent of those processes.

Every process has a unique process ID assigned by the OS.

Log into Linux and enter ps or ps aux or ps ux. In Windows, enter CTRL-ALT-Delete and examine

the task manager

Page 6: The process concept (section 3.1, 3.3 and demos)

fork() command (Linux) The fork() command creates a new process that is

nearly identical to the creating process. Upon return from the fork, both run and execute the same code

Only difference: int pid = fork(); In the parent, pid is the ID of the child In the child, pid is 0. See program demos

Page 7: The process concept (section 3.1, 3.3 and demos)

exec() command Command must specify an executable file. The image of that executable replaces the current

executable in memory and begins running. In effect, a new program is running though NO new

processes is created with this command. Usually done ONLY in the child process after a

fork() command There are actually numerous exec commands (see

Linux commands handout) but we won’t distinguish them now.

Page 8: The process concept (section 3.1, 3.3 and demos)

wait() command Usually done in the parent process. Waits until a child process finishes and can return

the child’s exit status. Figure 3.11 below See program demos

Page 9: The process concept (section 3.1, 3.3 and demos)

Zombies

A parent process should always wait on a child process.

A zombie (or defunct) process is: A child process that has finished executing Still has an entry in the OS list of processes Is waiting for the parent to read its exit status via the wait

command. Effectively, the process is dead, but not completely – thus

a zombie After the wait() the child exits the system and is

no longer a zombie.

Page 10: The process concept (section 3.1, 3.3 and demos)

A system can be overrun with zombies if there’s a non-ending parent that creates processes but never waits on them.

This is a problem NOTE: if the parent finishes the zombies are

removed, but some process are ongoing (e.g. server processes that respond to incoming requests)

Page 11: The process concept (section 3.1, 3.3 and demos)

Race conditions Refers to the issue of multiple activities

producing results in different orders each time they are run.

See the race.c demo

Page 12: The process concept (section 3.1, 3.3 and demos)

Signals A process can generate signals Another process can catch the signal and respond to

it. It’s a little like exceptions except the generation and

catching of signals occurs in different processes.

Page 13: The process concept (section 3.1, 3.3 and demos)

Linux identifies many signals. [

http://www.comptechdoc.org/os/linux/programming/linux_pgsignals.html]

Common are: Ctrl-c (signal number 2 or SIGINT) Ctrl-z (signal number 20 or SIGTSTP) Ctrl-\ (signal number 3 or SIGQUIT) exit() (sends SIGCHLD (#17) signal to parent)

Page 14: The process concept (section 3.1, 3.3 and demos)

example Run a process and, while running, enter CTRL-C CTRL-C sends a signal to the process. The process catches it and exits. You have the effect of killing the process.

Page 15: The process concept (section 3.1, 3.3 and demos)

Similar you can enter CTRL-z The process catches it and goes into a temporary

sleep state. You can see this with the ps command You can resume the process by typing fg

process_name

Page 16: The process concept (section 3.1, 3.3 and demos)

kill() command Sends a signal to a specified process. See handout and demos

Page 17: The process concept (section 3.1, 3.3 and demos)

signal() command Sets up signal catching abilities. Identifies a signal and a function If the process receives the identified signal, it

immediately executes the specified function. When the function is done, the process resumes its

activities.

Page 18: The process concept (section 3.1, 3.3 and demos)

Run sigcatcher.c Enter ctrl-c Enter ctrl-z Enter ctrl-\ The same signal catching function is used for all

three and the function’s logic distinguishes how each is handled differently from each other.

Page 19: The process concept (section 3.1, 3.3 and demos)

Run sigcatcher1.c Shows different signal catching functions for

different signals. Shows what the signal() function returns, as a

function.

Page 20: The process concept (section 3.1, 3.3 and demos)

Run sigcatcher2.c Shows how a process can pause and wait for an

incoming signal In this case either ctrl-c or ctrl-\

Page 21: The process concept (section 3.1, 3.3 and demos)

Recompile sigcatcher.c and call it child Compile and run sigsender.c The latter shows how one process can send a

signal to another.

Page 22: The process concept (section 3.1, 3.3 and demos)

Compile child.c (call it child) and parent1.c Child runs and kills itself or exits gracefully Parent waits for each child and displays how it

exited and the id of the child that exited. Child processes may finish in a different order

than which they started.

Page 23: The process concept (section 3.1, 3.3 and demos)

Waitpid() command The wait() command will wait for any child process

that finishes. The waitpid() command allows the parent to specify

which child to wait for. It can also determine the status of the child

Child is a zombie Child still running Child no longer exists

See Linux command handout and demo programs.

Page 24: The process concept (section 3.1, 3.3 and demos)

Run parent2.c with the previous child This parent repeatedly checks the status of each

child using the waitpid command.