CGS 3763 Operating Systems Concepts Spring 2013 Dan

CGS 3763 Operating Systems Concepts Spring 2013 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 11: 30 - 12: 30 AM

Lecture 25 – Friday, March 15, 2013 n Last time: ¨ n Today: n n n CPU scheduling Process synchronization Next time ¨ n CPU Scheduling Process synchronization Reading assignments ¨ Chapter 6 of the textbook Lecture 25 2

Scheduling algorithms for real-time systems n n Activities in a real-time (RT) systems are subject to deadlines. If a thread T does not finishes execution by its deadline then the system fails. Earliest deadline first (EDF) is a scheduling algorithm for RT the tread/process with the earliest deadline is scheduled first. Lecture 25 3

Multilevel queues n n n Ready queue is partitioned into separate queues: 1. foreground (interactive) 2. background (batch) Each queue has its own scheduling algorithm ¨ foreground – RR ¨ background – FCFS The CPU must be shared among the queues ¨ Fixed priority scheduling; (i. e. , serve all from foreground then from background). Possibility of starvation. ¨ Time slice – each queue gets a certain amount of CPU time which it can schedule amongst its processes; i. e. , n 80% to foreground; RR scheduling algorithm n 20% to background; FCFS scheduling algorithm Lecture 25 4

Individual queues for different types of processes Lecture 25 5

Multilevel feedback queue n n n Multiple queues are defined, each one with its own scheduling strategy and time quantum. As the process ages it moves amongst the queues. Parameters of the multilevel-feedback-queue scheduler: ¨ number of queues ¨ scheduling algorithms for each queue ¨ method used to determine when to upgrade a process ¨ method used to determine when to demote a process ¨ method used to determine which queue a process will enter when that process needs service Lecture 25 6

n n Three queues: ¨ Q 0 – RR with time quantum 8 milliseconds ¨ Q 1 – RR with time quantum 16 milliseconds ¨ Q 2 – FCFS Scheduling ¨ A new job enters queue Q 0 which is served FCFS. When it gains CPU, job receives 8 milliseconds. If it does not finish in 8 milliseconds, job is moved to queue Q 1. ¨ At Q 1 job is again served FCFS and receives 16 additional milliseconds. If it still does not complete, it is preempted and moved to queue Q 2. Lecture 25 7

Thread scheduling n n Distinction between user-level and kernel-level threads. Many-to-one and many-to-many models, thread library schedules user-level threads to run using the LWP (Light Weight Process) model. User-level the threads compete with one another for the time allocated to the process-contention scope (PCS). Kernel-level threads compete with all the threads in the system-contention scope (SCS). Lecture 25 8

Scheduling for multiprocessor/multicore n n Scheduling more complex when multiple CPUs/cores are available. Homogeneous processors within a multiprocessor. NUMA – Non-Uniform Memory Access. Multiproccessing: Symmetric multiprocessing (SMP) – each processor is self-scheduling, all processes in common ready queue, or each has its own private queue of ready processes. ¨ Asymmetric multiprocessing – only one processor accesses the system data structures, alleviating the need for data sharing ¨ n Processor affinity – a process has affinity for the processor on which it is currently running ¨ soft affinity ¨ hard affinity Lecture 25 9

NUMA and CPU Scheduling Lecture 25 10

Multicore processors n n Faster and consume less power Multiple threads per core; takes advantage of memory stall to make progress on another thread while memory retrieve happens Lecture 25 11

Solaris scheduling n The Solaris 10 kernel threads model consists of the following objects: kernel threads This is what is scheduled/executed on a processor ¨ user threads The user-level thread state within a process. ¨ process The object that tracks the execution environment of a program. ¨ lightweight process (lwp) Execution context for a user thread. Associates a user thread with a kernel thread. ¨ n Fair Share Scheduler (FSS) allows more flexible process priority management. Each project is allocated a certain number of CPU shares via the project. cpu-shares resource control. ¨ Each project is allocated CPU time based on its cpu-shares value divided by the sum of the cpu-shares values for all active projects. ¨ Anything with a zero cpu-shares value will not be granted CPU time until all projects with non-zero cpu-shares are done with the CPU. ¨ Lecture 25 12

Solaris scheduling classes n n n TS (timeshare): default class for processes and their associated kernel threads. Priority range 0 -59; dynamically adjusted (vary during the lifetime of a process to allocate processor resources evenly. IA (interactive): enhanced version of the TS class that applies to the infocus window in the GUI. Its intent is to give extra resources to processes associated with that specific window. Like TS, IA's range is 0 -59. FSS (fair-share scheduler): Share-based rather than priority- based. Threads scheduled based on their associated shares and the processor's utilization. FSS also has a range 0 -59. FX (fixed-priority): The priorities for threads associated with this class are fixed, do not vary dynamically over the lifetime of the thread. Range 0 -59. SYS (system): Used to schedule kernel threads. Threads in this class are "bound" threads, which means that they run until they block or complete. Priorities for SYS threads are in the 60 -99 range. RT (real-time): Threads in the RT class are fixed-priority, with a fixed time quantum. Their priorities range 100 -159, so an RT thread will preempt a system thread. Lecture 25 13

Linux scheduling n Two priority ranges: time-sharing ¨ real-time ¨ n Nice is used Unix and Unix-like operating systems e. g. , as Linux Invokes a utility or shell script with a particular priority and gives a process more or less CPU time than other processes. ¨ − 20 is the highest priority and 20 is the lowest priority. ¨ Default niceness for processes is inherited from its parent process, usually 0. ¨ n Real-time range from 0 to 99 and nice value from 100 to 140. Lecture 25 14

Evaluation of scheduling algorithms n n n Deterministic modeling –defines the performance of each scheduling algorithm for a particular type of workload Simulation – using a set of trace data. Data obtained from past execution of a certain type of workload. Benchmarks –sets of programs to test hardware performance, scheduling algorithms, other types of software. Lecture 25 15

Chapter 6 - Process synchronization n The need for concurrency control: ¨ Concurrent access to shared data may result in data inconsistency. ¨ Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes. ¨ The producer-consumer problem. Lecture 25 16

Critical concepts for thread coordination n n n Critical section code that accesses a shared resource. Race conditions two or more threads access shared data and the result depends on the order in which the threads access the shared data. Mutual exclusion only one thread should execute a critical section at any one time. Lock shared variable which acts as a flag to coordinate access to shared data. Spin lock a thread keeps checking a control variable/semaphore “until the light turns green” Side effects of thread coordination Deadlock ¨ Priority inversion a lower priority activity is allowed to run before one with a higher priority ¨ Lecture 18 17

Thread coordination with a bounded buffer n n Producer-consumer problem two threads cooperate – the producer is writing in a buffer and the consumer is reading from the buffer. Basic assumptions: We have only two threads ¨ Threads proceed concurrently at independent speeds/rates ¨ Bounded buffer – only N buffer cells ¨ Messages are of fixed size and occupy only one buffer cell. ¨ Lecture 14 18

Lecture 14 19

Lecture 18 20

Locks; Before-or-After actions n Locks shared variables which acts as a flag to coordinate access to a shared data. Manipulated with two primitives ACQUIRE ¨ RELEASE ¨ n n Support implementation of Before-or-After actions; only one thread can acquire the lock, the others have to wait. All threads must obey the convention regarding the locks. The two operations ACQUIRE and RELEASE must be atomic. Hardware support for implementation of locks RSM – Read and Set Memory ¨ CMP –Compare and Swap ¨ n RSM (mem) If mem=LOCKED then RSM returns r=LOCKED and sets mem=LOCKED ¨ If mem=UNLOCKED the RSM returns r=LOCKED and sets mem=LOCKED ¨ Lecture 18 21

Lecture 18 22

Lecture 18 23

Deadlocks n n n Happen quite often in real life and the proposed solutions are not always logical: “When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other has gone. ” a pearl from Kansas legislation. Deadlock jury. Deadlock legislative body. Lecture 18 24

Examples of deadlock n Traffic only in one direction. n Solution one car backs up (preempt resources and rollback). Several cars may have to be backed up. Starvation is possible. n Lecture 18 25

Lecture 18 26

Thread deadlock Deadlocks prevent sets of concurrent threads/processes from completing their tasks. n How does a deadlock occur a set of blocked threads each holding a resource and waiting to acquire a resource held by another thread in the set. n Example ¨ locks A and B, initialized to 1 P 0 P 1 wait (A); wait(B) wait (B); wait(A) n n Aim prevent or avoid deadlocks Lecture 18 27

System model n n n Resource types R 1, R 2, . . . , Rm (CPU cycles, memory space, I/O devices) Each resource type Ri has Wi instances. Resource access model: ¨ request ¨ use ¨ release Lecture 18 28

Simultaneous conditions for deadlock n n Mutual exclusion: only one process at a time can use a resource. Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes. No preemption: a resource can be released only voluntarily by the process holding it (presumably after that process has finished). Circular wait: there exists a set {P 0, P 1, …, P 0} of waiting processes such that P 0 is waiting for a resource that is held by P 1, P 1 is waiting for a resource that is held by P 2, …, Pn– 1 is waiting for a resource that is held by Pn, and P 0 is waiting for a resource that is held by P 0. Lecture 18 29

Wait for graphs Lecture 18 30

Semaphores n Abstract data structure introduced by Dijkstra to reduce complexity of threads coordination; has two components C count giving the status of the contention for the resource guarded by s ¨ L list of threads waiting for the semaphore s ¨ n Counting semaphore – for an arbitrary resource count. Supports two operations: V - signal() increments the semaphore C P - wait() P decrements the semaphore C. n Binary semaphore: C is either 0 or 1. Lecture 18 31

The wait and signal operations P (s) (wait) { If s. C > 0 then s. C − −; else join s. L; } V (s) (signal) { If s. L is empty then s. C + +; else release a process from s. L; } Lecture 18 32

Monitors n Semaphores can be used incorrectly multiple threads may be allowed to enter the critical section guarded by the semaphore ¨ may cause deadlocks ¨ n n n Threads may access the shared data directly without checking the semaphore. Solution encapsulate shared data with access methods to operate on them. Monitors an abstract data type that allows access to shared data with specific methods that guarantee mutual exclusion Lecture 18 33

Lecture 18 34

Asynchronous events and signals n n Signals, or software interrupts, were originally introduced in Unix to notify a process about the occurrence of a particular event in the system. Signals are analogous to hardware I/O interrupts: When a signal arrives, control will abruptly switch to the signal handler. ¨ When the handler is finished and returns, control goes back to where it came from ¨ n After receiving a signal, the receiver reacts to it in a well-defined manner. That is, a process can tell the system (OS) what they want to do when signal arrives: Ignore it. ¨ Catch it and deliver it. In this case, it must specify (register) the signal handling procedure. This procedure resides in the user space. The kernel will make a call to this procedure during the signal handling and control returns to kernel after it is done. ¨ Kill the process (default for most signals). ¨ n Examples: Event - child exit, signal - to parent. Control signal from keyboard. Lecture 18 35

Implicit assumptions for the correctness of the implementation 1. 2. 3. 4. 5. 6. One sending and one receiving thread. Only one thread updates each shared variable. Sender and receiver threads run on different processors to allow spin locks in and out are implemented as integers large enough so that they do not overflow (e. g. , 64 bit integers) The shared memory used for the buffer provides read/write coherence The memory provides before-or-after atomicity for the shared variables in and out The result of executing a statement becomes visible to all threads in program order. No compiler optimization supported Lecture 14 36

Solutions to thread coordination problems must satisfy a set of conditions 1. Safety: The required condition will never be violated. 2. Liveness: The system should eventually progress irrespective of contention. 3. Freedom From Starvation: No process should be denied progress for ever. That is, every process should make progress in a finite time. 4. Bounded Wait: Every process is assured of not more than a fixed number of overtakes by other processes in the system before it makes progress. 5. Fairness: dependent on the scheduling algorithm • FIFO: No process will ever overtake another process. • LRU: The process which received the service least recently gets the service next. For example for the mutual exclusion problem the solution should guarantee that: Safety the mutual exclusion property is never violated Liveness a thread will access the shared resource in a finite time Freedom for starvation a thread will access the shared resource in a finite time Bounded wait a thread will access the shared resource at least after a fixed number of accesses by other threads. Lecture 18 37

Thread coordination problems n n Dining philosophers Critical section Lecture 18 38

A solution to critical section problem n Applies only to two threads Ti and Tj with i, j ={0, 1} which share integer turn if turn=i then it is the turn of Ti to enter the critical section ¨ boolean flag[2] if flag[i]= TRUE then Ti is ready to enter the critical section ¨ n To enter the critical section thread Ti ¨ ¨ n n n sets flag[i]= TRUE sets turn=j If both threads want to enter then turn will end up with a value of either i or j and the corresponding thread will enter the critical section. Ti enters the critical section only if either flag[j]= FALSE or turn=i The solution is correct Mutual exclusion is guaranteed ¨ The liveliness is ensured ¨ The bounded-waiting is met ¨ n But this solution may not work as load and store instructions can be interrupted on modern computer architectures Lecture 18 39

Signals state and implementation n A signal has the following states: Signal send - A process can send signal to one of its group member process (parent, sibling, children, and further descendants). ¨ Signal delivered - Signal bit is set. ¨ Pending signal - delivered but not yet received (action has not been taken). ¨ Signal lost - either ignored or overwritten. ¨ n Implementation: Each process has a kernel space (created by default) called signal descriptor having bits for each signal. Setting a bit is delivering the signal, and resetting the bit is to indicate that the signal is received. A signal could be blocked/ignored. This requires an additional bit for each signal. Most signals are system controlled signals. Lecture 18 40