Chapter 2 Processes and Threads

prettybadelyngeSoftware and s/w Development

Nov 18, 2013 (3 years and 4 months ago)

71 views

Chapter 2


Processes and Threads

I.

What is a process?

a.

Process




a program in execution
”, “an abstraction of a running program”, “an instance of an executing program”

b.

Processes are managed using a
process table

that contain
s

(see table on page 92)

i.

start add
ress of code, data, and stack segments

ii.

copy of
hardware
register values (including PC)

iii.

PID

iv.

State

v.

File information (descriptors, working directory, etc)

vi.

Accounting info (start time, CPU time, etc)


II.

The Process Model

a.

Context Switch

b.

Contrast Multiprogramming

vs Multiprocessing

c.

Difference between a process and a program (birthday cake recipe analogy)

d.

Process creation events:
System Init
ialization (
daemons
),
fork
, user request, batch job

e.

Process termination events: Normal exit, Error exit (voluntary), Fatal err
or (involuntary),
kil
l

f.

Child processes and process hierarchies


III.

Process States

a.

running

b.

ready

c.

blocked

d.

4 transitions between 3 states


IV.

Threads

a.

Thread



lightweight process

b.

Each thread contains its own unique

i.

set of register values (eg. PC)

ii.

stack

iii.

state (runn
ing, ready, blocked)

c.

Each thread within a given process shares

i.

the process address space (code & global data segments)

ii.

open files

iii.

child processes

iv.

process accounting information

d.

Why use threads?

i.

Programming model becomes simpler when threads are used with a
pplications that involve lots of
concurrent activities and/or events
. Sharing address space, and open files is key.

ii.

Threads are easier (
10


100 times faster
) to create and destroy than separate processes


iii.

Using threads can dramatically speed up I/O inten
sive applications

iv.

Threads are a useful programming technique for multiple CPU systems

e.

Typical Thread Usage

i.

Word Processor threads

1.

Thread 1: user interaction

2.

Thread 2: background re
-
formatting

3.

Thread 3: automatic backup facility

ii.

Web Server threads

1.

Dispatch
er (accept incoming web requests)


2.

Worker threads (takes requests from dispatcher for processing)

iii.

Pop
-
up threads



f.

POSIX Threads








g.

Three Thread Implementation Strategies

i.

Implementing threads in user space

1.

Kernel is not aware of the existence of mu
ltiple threads

2.

Processes will need a thread table and run
-
time system (example: Java Virtual Machine)

3.

Advantages

a.

Thread switching is done in user space and is MUCH faster than a
kernel
context switch

b.

Thread scheduling is under user control; thus, it can be

tailored to the application

c.

Can be i
mplemented on a wide range of OS
s
. T
he kernel
need not

be thread
-
aware.

4.

Disadvantages

a.

Programs

must use non
-
blocking
(or
select
)
system calls
! Usually implemented w/

a
wrapper
.

b.

A page fault may block
an entire process

even though it has other threads that are runnable.

c.

thread
-
yield

is a voluntary procedure call. There is no facility that will force a misbehaving thread
to release control of the CPU to the other threads.

PROGRAMMERS BEWARE!


ii.

Implementing threads in th
e kernel

1.

Kernel contains thread table in addition to process table

2.

Advantages

a.

Programs do not

require non
-
blocking system calls. Programmer uses standard I/O techniques.

b.

When one thread blocks for I/O

(including a page fault)
, scheduler picks
another

thre
ad.
The n
ext
thread

selected

may be one in the same process as the blocked thread.

3.

Disadvantage

a.

Creation, termination, and scheduling threads in the kernel involves more system overhead than
when implemented in user space.

b.

User has no control over thread
scheduling. Kernel makes all scheduling decisions.

c.

Applications written for a thread
-
aware O.S. will not run on a non
-
aware O.S.


iii.

Hybrid implementations

(most flexible)




V.

Interprocess (or interthread) Communications and
Race Conditions

a.

Race Condition
:

Two or more processes (or threads)

are
accessing

some shared resource and the final result
depends upon who runs precisely when.

b.

Examples: printer daemon, shared global variable, file
-
naming

c.

Mutual Exclusion and
Critical Region
s

(
part of a program where a

shared resource is accessed
)















d.

Four conditions needed to implement
mutual exclusion

correctly:

i.

No two processes may be simultaneously inside their critical region

ii.

We should make no assumptions about the speed or number of CPUs

iii.

No process runn
ing outside its own critical region may block other processes

iv.

No process should have to wait forever to enter its critical region (starvation)


e.

Some inadequate (but informative) attempts to provide mutual exclusion

i.

Disabling interrupts (not a good idea to

give the user this option!; doesn’t work with multiple CPUs)

ii.

Simple
lock

variable

while (lock == 1);

lock = 1;

critical_region;

lock = 0;

iii.

Strict alternation (handout version 1)

iv.

Handout versions 2
-
4

v.

Busy waiting or Spin Lock

and the
Priority Inversion Prob
lem


f.

Peterson’s Solution
s (of historical interest)

(
uses

a spin lock
)













g.

The TSL
& XCHG
Instruction
s

(
u
ses a spin lock
)


atomic action
-


indivisible

instruction or procedure




h.

Semaphores

(E.W. Dijkstra)

(doesn’t use a
spin lock)

S
ystem calls
that operate as atomic actions:


down(s)

up(s)

{


{


if (s>0)


if (some other process waiting on s)



s
--
;



wake it up;


else


else



go to sleep on s;



s++;

}



}



Binary semaphores
; mutex semaphores; synchronization semaphores


i.

Mutex

(could be imp
lemented using a

binary semaphore)


(doesn’t use a
spin lock)

a.

mutex_lock

and
mutex_unlock

blocks
if mutex is already locked by some other process or thread


mutex
_
lock
:



TSL REGISTER,MUTEX

| copy mutex to register and set mutex to 1



CMP REGISTER,#0

| wa
s mutex zero?



JZE ok

| if it was zero, mutex was unlocked, so return



CALL thread_yield

| mutex is busy; schedule another thread



JMP mutex_
lock

| try again later


ok:

RET


| return to caller; critical region entered



mutex
_
unlock:



MOVE MUTEX,#0


| store a 0 in mutex



RET


| return to caller

b.

Mutexes in Pthreads

c.

Use of mutex (and semaphores) are completely under programmer control! (Good thing or bad thing??)


j.

Monitors

(doesn’t use a
spin lock)

Special procedure or variable implemented by a
particular language (eg. Java)

Example
s
:
1) Producer
-
Consumer; 2)
Java Applet that implements 3 types of sorts


k.

Message Passing

(doesn’t use a
spin lock)

i.

System calls
;
such as

send(destination,&message)

and
receive(source,&message)

ii.

receive()

will block
if no messages are pending

iii.

Easily scales to a large number of processes and CPUs

iv.

Requires sequence numbers and ACKs

v.

Slower than using semaphores or monitors; but eas
ier for programmers
when
using multiple CPUs

vi.

Mailbox


Buffer that holds a certain number o
f messages in sequential order

vii.

MPI


Message Passing Interface (common API used for message passing)

viii.

Barriers

ix.

Producer
-
Consumer Problem
(
using message passin
g)


VI.

Scheduling Algorithms

a.

Some definitions

i.

compute
-
bound


ii.

I/O


bound

iii.

non
-
preemptive scheduling


once selected to run it will run until it blocks, completes, or
voluntary relinquishes the CPU

iv.

preemptive scheduling


scheduler can preempt a process if it uses all of its quantum

v.

quantum


time interval a process is allowed to run before it is preempte
d (eg. 10ms)

vi.

throughput


number of jobs per hour

vii.

turnaround time


average time from submission of batch job until completion

b.

Three types of OS environments

i.

Batch

ii.

Interactive

iii.

Real time

c.

Worthy goals for process scheduling

i.

Fairness

ii.

Throughput (batch systems
)

iii.

Turnaround time (batch systems)

iv.

100% CPU utilization (batch systems)

v.

Quick response time (interactive systems)

vi.

Meet real
-
time deadlines (real
-
time systems)

d.

Scheduling in Batch Systems

i.

First
-
Come First
-
Served (non
-
preemptive)

ii.

Shortest Job First (non
-
preem
ptive)

1.

Minimizes turnaround time

2.

Must know run times in advance

iii.

Shortest Remaining Time Next (preemptive)

e.

Scheduling in Interactive Systems

i.

Round
-
Robin

1.

preemptive

2.

fair


all processes are treated as equal

3.

sensitive to value assigned to quantum

a.

too high
-
>

poor response time

b.

too low
-
> low efficiency

ii.

Priority Scheduling


1.

Uses a base priority

2.

Adjusts priority depending upon situations

iii.

Priority with multiple queues (Unix
, Linux p752
, Windows

p8
7
4
, VMS)

iv.

Shortest Process Next (or aging)

v.

Guaranteed Scheduling

vi.

Lo
ttery Scheduling

vii.

Fair
-
Share Scheduling

f.

Scheduling in Real
-
Time Systems

i.

Hard Real Time


absolute deadlines must be met

ii.

Soft Real Time


missing an occasional deadline is undesirable but tolerable


VII.

Classical Problems

a.

Dining Philosphers






















b.

Readers and Writers



























VIII.

Homework


Chapter 2 (pages 170
-
173
)

Problems #12, 14, 19, 21, 26, 35, 37, 40, 41