chapter 5: cpu scheduling
DESCRIPTION
Chapter 5: CPU Scheduling. Algorithm Evaluation. How to compare scheduling algorithms? How to determine which is a good algorithm for a given system Deterministic modeling – takes a particular predetermined workload and defines the performance of each algorithm for that workload - PowerPoint PPT PresentationTRANSCRIPT
5.1 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Chapter 5: CPU Scheduling
5.2 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Algorithm Evaluation
How to compare scheduling algorithms?
How to determine which is a good algorithm for a given system
Deterministic modeling – takes a particular predetermined workload and defines the performance of each algorithm for that workload
Queueing models
Simulation
5.3 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Evaluation of CPU schedulers by Simulation
5.4 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
End of Chapter 5
5.5 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Chapter 6: Process Synchronization
5.6 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Chapter 6: Process Synchronization
Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Atomic Transactions
5.7 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Objectives
To introduce the critical-section problem, whose solutions can be used to ensure the consistency of shared data
To present both software and hardware solutions of the critical-section problem
To introduce the concept of an atomic transaction and describe mechanisms to ensure atomicity
5.8 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Background
Processes and threads provide concurrency
Data sharing among cooperating processes/threads
Simultaneous access to shared data (especially simultaneous writes) lead to data inconsistency
Producer/Consumer problem example
5.9 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Producer
while (count == BUFFER.SIZE) ; // do nothing
// add an item to the buffer buffer[in] = item;in = (in + 1) % BUFFER.SIZE;++count;
5.10 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Consumer
while (count == 0) ; // do nothing
// remove an item from the buffer item = buffer[out];out = (out + 1) % BUFFER.SIZE;--count;
5.11 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Race Condition
count++ can be implemented as
register1 = count register1 = register1 + 1 count = register1
count-- can be implemented as
register2 = count register2 = register2 - 1 count = register2
5.12 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Race Condition (Contd.)
Consider a scenario with one producer and one consumer count++ and count-- executed simultaneously
Count value should remain unaltered 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}
5.13 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Critical Section
A conceptual tool to help programmers avoid race conditions
A section of code where shared memory/resources (variables, files, tables, etc.) are modified
At most one cooperating process can be in the critical region at any given point in time
Processes needs to follow a protocol when they modify shared resources – Critical Section ProblemProcess need to request permission before they enter
critical region Program structured as “Entry Section”, Critical Section”,
“Exit Section” and “Remainder Section”
5.14 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Structure of a Typical Process
5.15 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Critical Section Solution Requirements
1. Mutual Exclusion - If process Pi is executing in its critical section, then no other processes can be executing in their critical sections.
2. Progress - If no process is executing in its critical section and there exist some processes that wish to enter their critical section, then the selection of the processes that will enter the critical section next cannot be postponed indefinitely.
3. Bounded Waiting - A bound must exist on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted.
5.16 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Critical Section Solution Assumptions
Assume that each process executes at a nonzero speed
No assumption concerning relative speed of the N processes
5.17 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Peterson’s Solution
Two process solution Theoretical solution – May not work correctly on modern
architectures Assume that the LOAD and STORE instructions are atomic; that is,
cannot be interrupted. The two processes share two variables:
int turn; boolean flag[2]
The variable turn indicates whose turn it is to enter the critical section.
The flag array is used to indicate if a process is ready to enter the critical section. flag[i] = true implies that process Pi is ready!
5.18 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
while (true) {
flag[i] = true;
turn = j;
while (flag[j] && turn == j);
critical section
flag[i] = false;
remainder section
}
Algorithm for Process Pi
5.19 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Peterson’s Solution – Points to Note
Each process plays the “nice guy” Asserts it is the other processes turn to enter
into the critical section The infinite wait loop is broken if at least one of
the following holdsThe other process is not interested in entering the
critical regionThe other process’s write on the “turn” variable
survived (i.e., turn has been set to this process)
5.20 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Peterson’s Solution – Correctness proof
Mutual exclusion Impossible for both processes to break the while loop
simultaneously – Why? Progress and bounded wait
Process Pi can be stuck in the wait loop only if turn == j and flag[j] == true
If both conditions hold -- Pj wants to be in critical region and it has necessary permission to do so
When Pj exits the critical section it sets flag[j] to falsePi enters critical region after at most one entry by PjWhen Pj is in the remainder region it has no effect on
Pi’s entry into critical region
5.21 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Critical regions protected by locks
Processes need to acquire lock before entering CR
Acquiring and releasing locks are atomic operationswhile (true) {
acquire lock
critical section
release lock
remainder section
}
Locks – A Generic Hardware Paradigm
5.22 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Synchronization Hardware
Modern machines provide special atomic hardware instructionsAtomic mean non-interruptable (i.e., the
instruction executes as one unit) getAndSet() -- Test memory word and set its
value swap() – exchange the contents of two
memory words
5.23 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Illustration of getAndSet and swap
5.24 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Solution using GetAndSet Instruction
5.25 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Solution using Swap Instruction
5.26 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Semaphore
Synchronization tool for programmers
Semaphore S – integer variable
Two standard operations modify S: acquire() and release()
Originally called P() (proberen) and V() (verhogen)
Can only be accessed only via the above atomic operations
5.27 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Semaphore for Mutual Exclusion
Binary semaphore – integer value can range only between 0 and 1
Also known as mutex locks
5.28 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Java Example Using Semaphores
5.29 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Java Example Using Semaphores
5.30 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Semaphore for Imposing Order
P1 and P2 are concurrently running processes
S1– Statement in process P1; S2 – Statement in Process P2
Ensure that S2 gets executed only after S1
Initialize semaphore synch to 0
Process P1: Process P2:
S1; synch.acquire();synch.release(); S2;
5.31 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Counting Semaphores
Counting semaphore – integer value can range over an unrestricted domain
Controlling access to a resource with finite number of instances
Initialize semaphore to # of available instances
A process wanting to access resource will do an acquire on the semaphore
Processes will do a release on the semaphore after using the resource
Processes will wait if all available resources are currently being used
5.32 Silberschatz, Galvin and Gagne ©2009Operating System Concepts with Java – 8th Edition
Semaphore Implementation
Must guarantee that no two processes can execute acquire () and release () on the same semaphore at the same time
Disadvantage: Required busy waitingProcesses continually wait in the entry codeSpinlock – another name for this type of
semaphoreWastes CPU cycles