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

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

3. Scheduling algorithms for real-time systems 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 253

4. Multilevel queues 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., 80% to foreground; RR scheduling algorithm 20% to background; FCFS scheduling algorithm Lecture 254

5. Individual queues for different types of processes Lecture 255

6. Multilevel feedback queue 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 256

7. 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 257

8. Thread scheduling 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  process-contention scope (PCS). Kernel-level threads compete with all the threads in the system  system-contention scope (SCS). Lecture 258

9. Scheduling for multiprocessor/multicore 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 Processor affinity – a process has affinity for the processor on which it is currently running  soft affinity  hard affinity Lecture 259

10. NUMA and CPU Scheduling Lecture 2510

11. Multicore processors 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 2511

12. Solaris scheduling 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. 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 2512

13. Solaris scheduling classes 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 in- focus 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 2513

14. Linux scheduling Two priority ranges:  time-sharing  real-time 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. Real-time range from 0 to 99 and nice value from 100 to 140. Lecture 2514

15. Evaluation of scheduling algorithms 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 2515

16. Chapter 6 - Process synchronization 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 2516

17. Critical concepts for thread coordination 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 1817

18. Thread coordination with a bounded buffer 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 1418

19. Lecture 1419

20. Lecture 1820

21. Locks; Before-or-After actions Locks  shared variables which acts as a flag to coordinate access to a shared data. Manipulated with two primitives  ACQUIRE  RELEASE 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 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 1821

22. Lecture 1822

23. Lecture 1823

24. Deadlocks 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 1824

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

26. Lecture 1826

27. Thread deadlock Deadlocks  prevent sets of concurrent threads/processes from completing their tasks. 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. Example  locks A and B, initialized to 1 P 0 P 1 wait (A);wait(B) wait (B);wait(A) Aim  prevent or avoid deadlocks Lecture 1827

28. System model Resource types R 1, R 2,..., R m (CPU cycles, memory space, I/O devices) Each resource type R i has W i instances. Resource access model:  request  use  release Lecture 1828

29. Simultaneous conditions for deadlock 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, …, P n–1 is waiting for a resource that is held by P n, and P 0 is waiting for a resource that is held by P 0. Lecture 1829

30. Wait for graphs Lecture 1830

31. Semaphores 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 Counting semaphore – for an arbitrary resource count. Supports two operations: V - signal() increments the semaphore C P - wait() P decrements the semaphore C. Binary semaphore: C is either 0 or 1. Lecture 1831

32. 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 1832

33. Monitors Semaphores can be used incorrectly  multiple threads may be allowed to enter the critical section guarded by the semaphore  may cause deadlocks 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 1833

34. Lecture 1834

35. Asynchronous events and signals 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 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). Examples: Event - child exit, signal - to parent. Control signal from keyboard. Lecture 1835

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

37. Solutions to thread coordination problems must satisfy a set of conditions Lecture 1837 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.

38. Thread coordination problems Dining philosophers Critical section Lecture 1838

39. A solution to critical section problem Applies only to two threads T i and T j with i,j ={0,1} which share  integer turn  if turn=i then it is the turn of T i to enter the critical section  boolean flag[2]  if flag[i]= TRUE then T i is ready to enter the critical section To enter the critical section thread T i  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. T i 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 But this solution may not work as load and store instructions can be interrupted on modern computer architectures Lecture 1839

40. Signals state and implementation 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. 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 1840