operating systems - unit2

8/14/2019 Operating Systems - Unit2

http://slidepdf.com/reader/full/operating-systems-unit2 1/94

UNI T - 2



Operating Systems 2

Threads

• Overview• Multithreading Models

• Threading Issues



Operating Systems 3

Single vs. MultithreadedProcesses

Process: everything we’ve seen up to now

Thread: like a process, only shares memory, global variables, files, PID

with other threads within the same process



Operating Systems 4

Should you use threads orprocesses?

• Why use threads instead of processes?

– Faster context switch (why?)

– Easier to share data

– Uses less memory and resources– Thread creation faster than process creation (30xfaster in Solaris)

• Less things to set-up

• Why use processes instead of threads?

– Different code– Running on different machines

– Different owners

– Little communication

– Sharing memory can lead to obscure bugs



Operating Systems 5

User-level threads

• Threads can be provided at the user or kernellevel

• User level: kernel knows nothing about threads

• Implemented in a library by somebody withouttouching the kernel

• User library handles– Thread creation

– Thread deletion

– Thread scheduling

• Benefits:– Faster creation and scheduling (why?)

• Drawbacks:

– One thread blocking during I/O blocks all threads in process (even ready-to-run

threads)



Operating Systems 6

User-level threads(cont’d)

• Three primary threadlibraries:– POSIX Pthreads

– Win32 threads

– Java threads



Operating Systems 7

Kernel-level threads

• Kernel knows about threads• Kernel handles thread creation, deletion,scheduling

• Benefits:

– Kernel can schedule another thread if current

one does blocking I/O– Kernel can schedule multiple threads ondifferent CPUs on SMP multiprocessor

• Drawbacks:

– Slower to schedule, create, delete than user-level

• Most modern OSes support kernel-level threads

– Windows XP/2000

– Solaris

– Linux

– Tru64 UNIX– Mac OS X



Operating Systems 8

Multithreading Models

• How to map kernel-levelthreads to user-levelthreads?

– Many-to-One

– One-to-One

– Many-to-Many



Operating Systems 9

Many-to-One Model



Operating Systems 10

Many-to-One

• Many user-level threads mapped tosingle kernel thread

• Examples:

– Solaris Green Threads

– GNU Portable Threads

• Any disadvantages?– All block when one blocks

– All run on 1 CPU




One-to-one Model




One-to-One

• Each user-level thread maps to a kernelthread

• Examples:

– Windows NT/XP/2000

– Linux

– Solaris 9 and later

• Any disadvantages?

– Overhead for creating threads

– Many operating systems limit number

of threads




Many-to-Many Model




Many-to-Many Model

• Allows many user levelthreads to be mapped tosmaller or equal number of

kernel threads

• Allows the flexibility of choosing the number of kernel

threads allocated to a process• “Best of both worlds”

• Solaris prior to version 9




Two-level Model




Two-level Model

• Similar to many-to-many,but allows a user thread tobe bound to kernel thread

• Examples– IRIX

– HP-UX

– Tru64 UNIX– Solaris 8 and earlier




Threading Issues

• Semantics of fork() andexec() system calls

• Thread cancellation• Signal handling

• Thread pools

• Thread-specific data

i f d




Semantics of fork() andexec()

• Does fork() duplicate only the calling thread or all threads?

• Some UNIX systems have two versions of fork()

• exec() usually replaces all threads with new program

fork1()

fork2()




Thread Cancellation

• Terminating a thread before it has finished• E.g., two cooperating threads, one

discovers an error

• Two general approaches:

– Asynchronous cancellation terminates the target threadimmediately

– Deferred cancellation allows thetarget thread to periodically check if itshould be cancelled

• Why is this an issue?

– What if a thread is in the middle of

• Allocating resources

• Performing I/O

• Updating a shared data structure




Thread Cancellation(cont’d)

• Essentially, deferredcancellation = “target, pleasecancel yourself”

– Occurs when target checks forcancellation signal

• Allows cancellation at “safe”points– Called cancellation points in

Pthreads




Signal Handling

• Signals are used in UNIX to notify a process that aparticular event has occurred

• A signal handler is used to process signals

1. Signal is generated by a particular event

2. Signal is delivered to a process

3. Signal is handled (or ignored/blocked)• Options:

– Deliver the signal to the thread to which thesignal applies

• Applicable with synchronous signals e.g.,

illegal memory access

– Deliver the signal to every thread in the process

– Deliver the signal to certain threads in theprocess

– Assign a specific threat to receive all signals forthe process




Thread Pools

• Motivating example: a web server running on anSMP machine

• To handle each connection:

1. Create a new process to handle it

• too slow, inefficient

2. Create a new thread to handle it• Option 2 better but still has some problems:

– Some overhead for thread creation/deletion

– Thread will only be used for this connection

– Unbounded number of threads might crashweb server

• Better solution: use a thread pool of (usually) fixedsize




Thread Pools (cont’d)

• Threads in pool sit idle

• Request comes in:

– Wake up a thread in pool

– Assign it the request

– When it completes, return it to pool– If no threads in pool available, wait

• Advantages:

– Usually slightly faster to wake up anexisting thread than create a new one

– Allows the number of threads in theapplication to be limited by the size of thepool

– More sophisticated systems dynamicallyadjust pool size




Thread-specific Data

• Allows each thread to have its own copy of data

• Useful for implementing protection

– For example, user connects to bank’sdatabase server

– Server process responds, has access to allaccounts

– Multiple people may be accessing theiraccounts at the same time

– Thread assigned to manipulate or view user’s

bank account– Using thread-specific data limits (unintentional

or erroneous) access by other threads




CPU Scheduling

• Basic Concepts

• Scheduling Criteria

• Scheduling Algorithms• Multiple-ProcessorScheduling

• Real-Time Scheduling




Basic Concepts

• Maximum CPU utilizationobtained withmultiprogramming

• CPU–I/O Burst Cycle – Processexecution consists of a cycle of CPU execution and I/O wait

• CPU burst distribution




Alternating Sequence of CPU And I/OBursts




Histogram of CPU-burst Times




CPU Scheduler

• Selects from among the processes inmemory that are ready to execute, andallocates the CPU to one of them

• CPU scheduling decisions may take placewhen a process:

1. Switches from running to waiting state

2. Switches from running to ready state

3. Switches from waiting to ready

4. Terminates

• Scheduling under 1 and 4 isnonpreemptive

• All other scheduling is preemptive




Dispatcher

• Dispatcher module gives control of the CPUto the process selected by the short-termscheduler; this involves:

– switching context

– switching to user mode– jumping to the proper location in the user

program to restart that program

• Dispatch latency – time it takes for the

dispatcher to stop one process and startanother running




Scheduling Criteria

• CPU utilization – keep the CPU as busy aspossible

• Throughput – # of processes that completetheir execution per time unit

• Turnaround time – amount of time to executea particular process

• Waiting time – amount of time a process hasbeen waiting in the ready queue

• Response time – amount of time it takes from

when a request was submitted until the firstresponse is produced, not output (for time-sharing environment)




Optimization Criteria

• Max CPU utilization• Max throughput

• Min turnaround time

• Min waiting time

• Min response time

Fi t C Fi t S d (FCFS)




First-Come, First-Served (FCFS)Scheduling

Process Burst TimeP1 24

P2 3

P3 3

• Suppose that the processes arrive in the order: P1 , P2

, P3

The Gantt Chart for the schedule is:

• Waiting time for P1 = 0; P2 = 24; P3 = 27

• Average waiting time: (0 + 24 + 27)/3 = 17

P1 P2 P3

24 27 300




FCFS Scheduling (Cont.)

Suppose that the processes arrive in the order

P2 , P3 , P1

• The Gantt chart for the schedule is:

• Waiting time for P1 = 6; P2 = 0; P3 = 3

• Average waiting time: (6 + 0 + 3)/3 = 3

•Much better than previous case• Convoy effect short process behind longprocess

P1P3P2

63 300




Shortest-Job-First (SJR)Scheduling

• Associate with each process the length of itsnext CPU burst. Use these lengths toschedule the process with the shortest time

• Two schemes:

– nonpreemptive – once CPU given to theprocess it cannot be preempted untilcompletes its CPU burst

– preemptive – if a new process arrives withCPU burst length less than remaining timeof current executing process, preempt.

This scheme is know as theShortest-Remaining-Time-First (SRTF)

• SJF is optimal – gives minimum averagewaiting time for a given set of processes

l f




Process Arrival Time Burst TimeP1 0.0 7

P2 2.0 4

P3 4.0 1

P4 5.0 4• SJF (non-preemptive)

• Average waiting time = (0 + 6 + 3 + 7)/4 = 4

Example of Non-Preemptive SJF

P1 P3 P2

73 160

P4

8 12

l f i




Example of PreemptiveSJF

Process Arrival Time Burst Time

P1 0.0 7

P2 2.0 4

P3 4.0 1

P4 5.0 4

• SJF (preemptive)

• Average waiting time = (9 + 1 + 0 +2)/4 = 3

P1 P3P2

42110

P4

5 7

P2 P1

16

Determining Length of Next




Determining Length of NextCPU Burst

• Can only estimate the length

• Can be done by using the length of previous CPU bursts, using exponential

averaging

:Define 4.

10, 3.

burst CPUnextthefor valuepredicted 2.

burst CPUof lenghtactual 1.

1

≤≤

=

=

+

α α

τ n

th

nnt ( ) .1

1 nnnt τ α α τ −+=

=




Prediction of the Length of the NextCPU Burst

E l f E ti l




Examples of ExponentialAveraging

∀ α =0 τn+1 = τn

– Recent history does not count

∀ α =1

– τn+1

= α t n

– Only the actual last CPU burst counts

• If we expand the formula, we get:

τn+1 = α tn+(1 - α )α t n -1 + …

+( 1 - α ) j α t n - j + …

+( 1 - α )n +1 τ0

• Since both α and (1 - α) are less than orequal to 1, each successive term has lessweight than its predecessor




Priority Scheduling

• A priority number (integer) is associatedwith each process

• The CPU is allocated to the process withthe highest priority (smallest integer ≡highest priority)

– Preemptive

– nonpreemptive

• SJF is a priority scheduling where priorityis the predicted next CPU burst time

• Problem ≡Starvation – low priorityprocesses may never execute

• Solution ≡Aging – as time progressesincrease the priority of the process




Round Robin (RR)

• Each process gets a small unit of CPU time (timequantum), usually 10-100 milliseconds. After thistime has elapsed, the process is preempted andadded to the end of the ready queue.

• If there are n processes in the ready queue and

the time quantum is q, then each process gets 1/n of the CPU time in chunks of at most q time unitsat once. No process waits more than (n-1)q timeunits.

• Performance

– q large ⇒FIFO– q small ⇒q must be large with respect to

context switch, otherwise overhead is too high

Example of RR with Time Quantum




Example of RR with Time Quantum= 20

Process Burst TimeP1 53

P2 17

P3 68

P

4 24• The Gantt chart is:

• Typically, higher average turnaround than SJF,but better response

P1 P2 P3 P4 P1 P3 P4 P1 P3 P3

0 20 37 57 77 97 117 121 134 154 162

Ti Q t d C t t




Time Quantum and ContextSwitch Time

T d Ti V i With Th




Turnaround Time Varies With The Time Quantum




Multilevel Queue

• Ready queue is partitioned into separate queues:foreground (interactive)background (batch)

• Each queue has its own scheduling algorithm

– foreground – RR

– background – FCFS

• Scheduling must be done between the queues

– Fixed priority scheduling; (i.e., serve all fromforeground then from background).

Possibility of starvation.– Time slice – each queue gets a certain

amount of CPU time which it can scheduleamongst its processes; i.e., 80% toforeground in RR

– 20% to background in FCFS

Multilevel Queue




Multilevel QueueScheduling

Multilevel Feedback




Multilevel FeedbackQueue

• A process can move between the various queues;aging can be implemented this way

• Multilevel-feedback-queue scheduler defined by thefollowing parameters:

– number of queues

– scheduling algorithms for each queue

– method used to determine when to upgrade aprocess

– method used to determine when to demote aprocess

– method used to determine which queue aprocess will enter when that process needsservice

Example of Multilevel Feedback




Example of Multilevel FeedbackQueue

• Three queues:

– Q0 – RR with time quantum 8 milliseconds

– Q1 – RR time quantum 16 milliseconds

– Q2 – FCFS

• Scheduling

– A new job enters queue Q0 which is served

FCFS. When it gains CPU, job receives 8milliseconds. If it does not finish in 8milliseconds, job is moved to queue Q1.

– At Q1 job is again served FCFS and receives

16 additional milliseconds. If it still doesnot complete, it is preempted and movedto queue Q2.

Multilevel Feedback




Multilevel FeedbackQueues

Multiple Processor




Multiple-ProcessorScheduling

• CPU scheduling more complex when multiple CPUsare available

• Homogeneous processors within a multiprocessor

• Load sharing

• Asymmetric multiprocessing – only one processoraccesses the system data structures, alleviating theneed for data sharing




Process Synchronization

• Background• The Critical-Section Problem• Peterson’s Solution

• Synchronization Hardware• Semaphores• Classic Problems of

Synchronization• Monitors




Background

• Concurrent access to shared data may result in datainconsistency (e.g., due to race conditions)

• Maintaining data consistency requires mechanismsto ensure the orderly execution of cooperatingprocesses

• Suppose that we wanted to provide a solution to theconsumer-producer problem that fills all the buffers.

– We can do so by having an integer count thatkeeps track of the number of full buffers.

– Initially, count is set to 0.

– Incremented by producer after producing a newbuffer

– Decremented by consumer after consuming abuffer




Producer

while (true) {

/* produce an item and put innextProduced */

while (count == BUFFER_SIZE)

; // do nothing

buffer [in] = nextProduced;

in = (in + 1) % BUFFER_SIZE;

count++;

}




Consumer

while (true) {while (count == 0)

; // do nothing

nextConsumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;

count--;

/* consume the item innextConsumed

}




Race Condition• count++ could be implemented as

register1 := count

register1 := register1 + 1

count := register1

• count-- could be implemented as

register2 := count

register2 := register2 - 1

count := register2

• Consider this execution interleaving with “count = 5” initially:

T0: producer execute register1 := count {register1 = 5}

T1: producer execute register1 := register1 + 1 {register1 = 6}

T2: consumer execute register2 := count {register2 = 5}

T3: consumer execute register2 := register2 - 1 {register2 = 4}

T4: producer execute count := register1 {count = 6}

T5: consumer execute count := register2 {count = 4}




Process States

• Thinking – Executing independent actions• Hungry – Requesting access to shared

resources

• Eating – Executing within a critical section of

code

• Exiting – Relinquishing shared resources

Solution to Critical




Solution to Critical-Section Problem

1. Mutual Exclusion – No two processes eatsimultaneously

¢ Progress - If no process eats forever, and someprocess is hungry, then some (potententiallydifferent) hungry process eventually eats.

3. Bounded Waiting - A bound exists on thenumber of times that other processes areallowed to eat after a process P becomeshungry and before process P eats.

Assume that each process executes at anonzero speed

No assumption concerning relative speed of the N processes




Peterson’s Solution

• Two process solution• Assume that the LOAD and STORE instructions are

atomic

• The two processes share two variables:

– int turn;– Boolean flag[2] Initially: flag[0]=flag[1]= false

• The variable turn indicates whose turn it is to enterthe critical section.

• The flag array is used to indicate if a process isready to enter the critical section. flag[i] = true implies that process Pi is ready!




Algorithm for Process Pi

while (true) {flag[i] = TRUE;

turn = j;

while ( flag[j] && turn == j);

CRITICAL SECTION

flag[i] = FALSE;

REMAINDER SECTION

}

Synchronization




SynchronizationHardware

• Many systems provide hardware support forcritical sections

• Uniprocessors – could disable interrupts

– Current running code would execute without

preemption– Generally too inefficient on multiprocessor

systems

• Operating systems using this not broadlyscalable

• Modern machines provide special atomichardware instructions

• Atomic = non-interruptable

– Either test memory word and set value

– Or swap contents of two memory words




TestAndSet Instruction

• Definition: (rv is “return value”)

boolean TestAndSet (boolean*target)

{boolean rv = *target;

*target = TRUE;

return rv:

}




Solution using TestAndSet

• Shared boolean variable lock, initialized tofalse.

• Solution:

while (true) {

while (TestAndSet (&lock ))

; /* do nothing

// critical section

lock := FALSE;

// remainder section

}




Solution using Swap• Shared Boolean variable lock initialized to

FALSE; Each process has a local Booleanvariable key.

• Solution:

while (true) {

key = TRUE;

while ( key == TRUE)Swap (&lock, &key );

// critical section

lock = FALSE;

// remainder section

}

Semaphores in the Real




Semaphores in the RealWorld

• Semaphores were a mechanism for opticaltelegraphy

– Used to send information using visualsignals

– Information encoded in the position

(value) of flags

• Public domain images sourced from Wikipedia article

“Semaphore”

h

http://upload.wikimedia.org/wikipedia/en/1/1e/Chappetouranimation.gif




Semaphore

• Synchronization tool that does not require busy waiting

(spinlocks)• Invented by The Man – Edsger Dijkstra (“Eddie D”)

• A semaphore S is a protected integer-valued variable

• Two standard operations modify semaphore:

– wait() – Originally called P(), from Dutch proberen “to test”

– signal() – Originally called V(), from Dutch verhogen “to increment”

• Busy-waiting implementation of these indivisible (atomic)

operations:– wait (S) {

while (S <= 0); // empty loop body (no-op)

S--;}

– signal (S) { S++; }

Semaphore as General Synchronization




Tool

• Counting semaphore– Integer value can range over an unrestricted

domain

– Useful for k-exclusion scenarios of replicatedresources

• Binary semaphore

– Integer value ranges only between 0 and 1

– Can be simpler to implement

– Also known as mutex locks

• Provides mutual exclusion– Semaphore S; // initialized to 1

– wait (S);

Critical Section

signal (S);

Semaphore




SemaphoreImplementation

• Must guarantee that no two processes canexecute wait () and signal () on the samesemaphore at the same time

• Thus, semaphore implementation is a criticalsection problem where the wait and signal

code are placed in critical sections– Could now have busy waiting in critical

section implementation

• But implementation code is short

• Little busy waiting if critical sectionrarely occupied

• Note that applications may spend lots of timein critical sections and therefore this is not agood general solution.

Semaphore Implementation without busyiti




waiting

• With each semaphore there is an associatedwaiting queue. Each entry in a waiting queuehas two data items:

– Value (of type integer)

– Pointer to next record in the list

• Two operations:

– block – place the process invoking the waitoperation on the appropriate waitingqueue.

– wakeup – remove one of processes in thewaiting queue and place it in the readyqueue.

Semaphore Implementation with no Busyiti (C t )




waiting (Cont.)

• Implementation of wait:

Wait (S){value--;if (value < 0) {

add this process to waiting queue

block(); }}

• Implementation of signal:

Signal (S){value++;if (value <= 0) {

remove a process P from thewaiting queue

wakeup(P); }

}

D dl k d St ti




Deadlock and Starvation• Deadlock – two or more processes are waiting

indefinitely for an event that can be caused by onlyone of the waiting processes

• Let S and Q be two semaphores initialized to 1

P0 P1

wait (S); wait (Q);

wait (Q); wait (S);. .

. .

. .

signal (S); signal

(Q);signal (Q); signal (S);

• Starvation – indefinite blocking. A process may neverbe removed from the semaphore queue in which it is

suspended.

Classical Problems of




Synchronization

• Bounded-Buffer Problem

• Readers and WritersProblem

• Dining-PhilosophersProblem

B d d B ff P bl




Bounded-Buffer Problem

• Example of a producer-consumer problem

• N buffers, each can hold one item

• Semaphore mutex initialized to the value 1

• Semaphore full initialized to the value 0

• Semaphore empty initialized to the value N.

Bounded Buffer Problem




ou ded u e ob e(Cont.)

• The structure of the producer process:

while (true) {

// produce an item

wait (empty); // initially empty = Nwait (mutex); // intiallly mutex = 1

// add the item to the buffer

signal (mutex); // currently mutex = 0

signal (full); // initially full = 0

}



Readers-Writers Problem




(Cont.)

• The structure of a writer process

while (true) {

wait (wrt) ;

// writing is performed

signal (wrt) ;

}

Readers-Writers Problem




(Cont.)

• The structure of a reader process

while (true) {wait (mutex) ;readcount ++ ;

if (readcount == 1) wait (wrt) ;signal (mutex)

// reading is performed

wait (mutex) ;readcount - - ;if (readcount == 0) signal (wrt) ;signal (mutex) ;

}

Dining-Philosophers




g pProblem

• Shared data

– Bowl of rice (data set)

– Semaphore chopstick [5] initializedto 1

Dining-Philosophers




g pProblem (Cont.)

• The structure of Philosopher i:

While (true) {

wait ( chopstick[i] );

wait ( chopstick[ (i + 1) % 5] );

// eat

signal ( chopstick[i] );

signal ( chopstick[ (i + 1) % 5] );

// think

}

Problems with




Semaphores

• Correct use of semaphore operations:

– signal (mutex) …. wait (mutex)

• Can violate mutual exclusion

– wait (mutex) … wait (mutex)

• Can lead to deadlock!

– Omitting of wait (mutex) or signal(mutex)

Monitors




Monitors

• A higher-level abstraction that provides a convenient

and effective mechanism for process synchronization• Key Idea: Only one process may be active within the

monitor at a time

monitor monitor-name

{

// shared variable declarationsprocedure P1 (…) { …. }

…

procedure Pn (…) {……}

Initialization code ( ….) { … }

…

}

}

Schematic view of a




Monitor

Condition Variables




Condition Variables

• condition x, y;

• Two operations on a condition variable:

– x.wait () – process invoking the operation

is suspended.

– x.signal () – resumes one of the processes (if any) that

invoked x.wait ()

Monitor with Condition




Variables

Solution to Dining Philosophers




monitor DP{

enum { THINKING; HUNGRY, EATING) state [5] ;condition self [5];

void pickup (int i) {state[i] = HUNGRY;test(i);if (state[i] != EATING) self [i].wait;

}

void test (int i) {if ( (state[(i + 4) % 5] != EATING) &&

(state[i] == HUNGRY) &&(state[(i + 1) % 5] != EATING) ) {

state[i] = EATING ;self[i].signal () ;

}

}

Solution to Dining Philosophers (cont)




void putdown (int i) {state[i] = THINKING;

// test left and right neighborstest((i + 4) % 5);test((i + 1) % 5);

}

initialization_code() {for (int i = 0; i < 5; i++)

state[i] = THINKING;}}

Solution to Dining Philosophers (cont)




• Each philosopher I invokes the operationspickup()

and putdown() in the following sequence:

dp.pickup (i)

EAT

dp.putdown (i)

Monitor Implementation Using




Semaphores• Variables

semaphore mutex; // (initially = 1)semaphore next; // (initially = 0)int next-count = 0; // Number of processes

suspended

• Each procedure P will be replaced by

wait(mutex);…

body of procedure P;…if (next-count > 0) // Yield to a waiting process.

signal(next)else // Nobody waiting? Then exit.signal(mutex);

• Mutual exclusion within a monitor is ensured.

Monitor Implementation





• For each condition variable x , we have:

semaphore x-sem; // (initially = 0)

int x-count = 0; // Number of processes waiting oncond x

• The operation x.wait can be implemented as:

x-count++;

if (next-count > 0)

signal(next); // Yield to a waiting process.else

signal(mutex); // Nobody waiting? Release mutex.

wait(x-sem);

x-count--;






• The operation x.signal can be implementedas:

if (x-count > 0) {

next-count++;

signal(x-sem);wait(next);

next-count--;

}

Note: Signal is idempotent if x-count == 0.



Thank you

operating systems - unit2

Documents