Presentation is loading. Please wait.

Presentation is loading. Please wait.

MULTITASKING AND SCHEDULING EEN 417 Fall 2013. Layers of Abstraction for Concurrency in Programs.

Similar presentations


Presentation on theme: "MULTITASKING AND SCHEDULING EEN 417 Fall 2013. Layers of Abstraction for Concurrency in Programs."— Presentation transcript:

1 MULTITASKING AND SCHEDULING EEN 417 Fall 2013

2 Layers of Abstraction for Concurrency in Programs

3 What is a thread? Definition?

4 Definition and Uses Threads are sequential procedures that share memory. Uses of concurrency: Reacting to external events (interrupts) Exception handling (software interrupts) Creating the illusion of simultaneously running different programs (multitasking) Exploiting parallelism in the hardware (e.g. multicore machines). Dealing with real-time constraints.

5 Thread Scheduling Predicting the thread schedule is an iffy proposition. Without an OS, multithreading is achieved with interrupts. Timing is determined by external events. Generic OSs (Linux, Windows, OSX, …) provide thread libraries (like “pthreads”) and provide no fixed guarantees about when threads will execute. Real-time operating systems (RTOSs), like QNX, VxWorks, RTLinux, Windows CE, support a variety of ways of controlling when threads execute (priorities, preemption policies, deadlines, …).

6 Processes vs. Threads?

7 Processes are collections of threads with their own memory, not visible to other processes. Segmentation faults are attempts to access memory not allocated to the process. Communication between processes must occur via OS facilities (like pipes or files).

8 Modeling Threads via Asynchronous Composition of Extended State Machines States or transitions represent atomic instructions Interleaving semantics: Choose one machine, arbitrarily. Advance to a next state if guards are satisfied. Repeat. For the machines at the left, what are the reachable states?

9 Modeling Threads via Asynchronous Composition of Extended State Machines

10 This is a very simple, commonly used design pattern. Perhaps Concurrency is Just Hard… Sutter and Larus observe: “humans are quickly overwhelmed by concurrency and find it much more difficult to reason about concurrent than sequential code. Even careful people miss possible interleavings among even simple collections of partially ordered operations.” H. Sutter and J. Larus. Software and the concurrency revolution. ACM Queue, 3(7), 2005.

11 If concurrency were intrinsically hard, we would not function well in the physical world It is not concurrency that is hard…

12 …It is Threads that are Hard! Threads are sequential processes that share memory. From the perspective of any thread, the entire state of the universe can change between any two atomic actions (itself an ill- defined concept). Imagine if the physical world did that…

13 Problems with the Foundations A model of computation: Bits: B = {0, 1} Set of finite sequences of bits: B  Computation: f : B   B  Composition of computations: f  f ' Programs specify compositions of computations Threads augment this model to admit concurrency. But this model does not admit concurrency gracefully.

14 Basic Sequential Computation initial state: b 0  B  final state: b N sequential composition b n = f n ( b n-1 ) Formally, composition of computations is function composition.

15 When There are Threads, Everything Changes suspend A program no longer computes a function. resume another thread can change the state b n = f n ( b n-1 ) b' n = f n ( b' n-1 ) Apparently, programmers find this model appealing because nothing has changed in the syntax.

16 Succinct Problem Statement Threads are wildly nondeterministic. The programmer’s job is to prune away the nondeterminism by imposing constraints on execution order (e.g., mutexes) and limiting shared data accesses (e.g., OO design).

17 Incremental Improvements to Threads Object Oriented programming Coding rules (Acquire locks in the same order…) Libraries (Stapl, Java 5.0, …) Transactions (Databases, …) Patterns (MapReduce, …) Formal verification (Model checking, …) Enhanced languages (Split-C, Cilk, Guava, …) Enhanced mechanisms (Promises, futures, …)

18 SCHEDULING

19 Responsibilities of a Microkernel (a small, custom OS) Scheduling of threads or processes –Creation and termination of threads –Timing of thread activations Synchronization –Semaphores and locks Input and output –Interrupt handling

20 A Few More Advanced Functions of an Operating System – Not discussed here… Memory management –Separate stacks –Segmentation –Allocation and deallocation File system –Persistent storage Networking –TCP/IP stack Security –User vs. kernel space –Identity management

21 Outline of a Microkernel Main: –set up periodic timer interrupts; –create default thread data structures; –dispatch a thread (procedure call); –execute main thread (idle or power save, for example). Thread data structure: –copy of all state (machine registers) –address at which to resume executing the thread –status of the thread (e.g. blocked on mutex) –priority, WCET (worst case execution time), and other info to assist the scheduler

22 Outline of a Microkernel Timer interrupt service routine: –dispatch a thread. Dispatching a thread: –disable interrupts; –save state (registers) into current thread data structure; –save return address from the stack for current thread; –determine which thread should execute (scheduling); –if the same one, enable interrupts and return; –copy thread state into machine registers; –replace program counter on the stack for the new thread; –enable interrupts; –return.

23 When can a new thread be dispatched? Under non-preemptive scheduling: –When the current thread completes. Under Preemptive scheduling: –Upon a timer interrupt –Upon an I/O interrupt (possibly) –When a new thread is created, or one completes. –When the current thread blocks on or releases a mutex –When the current thread blocks on a semaphore –When a semaphore state is changed –When the current thread makes any OS call file system access network access …

24 The Focus Today: How to decide which thread to schedule? Considerations: Preemptive vs. non-preemptive scheduling Periodic vs. aperiodic tasks Fixed priority vs. dynamic priority Priority inversion anomalies Other scheduling anomalies

25 Preemptive Scheduling Assume all threads have priorities either statically assigned (constant for the duration of the thread) or dynamically assigned (can vary). Assume further that the kernel keeps track of which threads are “enabled” (able to execute, e.g. not blocked waiting for a semaphore or a mutex or for a time to expire). Preemptive scheduling: –At any instant, the enabled thread with the highest priority is executing. –Whenever any thread changes priority or enabled status, the kernel can dispatch a new thread.

26 Rate Monotonic Scheduling Assume n tasks invoked periodically with: –periods T 1, …,T n (impose real-time constraints) –worst-case execution times (WCET) C 1, …,C n assumes no mutexes, semaphores, or blocking I/O –no precedence constraints –fixed priorities –preemptive scheduling Theorem: If any priority assignment yields a feasible schedule, then priorities ordered by period (smallest period has the highest priority) also yields a feasible schedule. RMS is optimal in the sense of feasibility. Liu and Leland, “Scheduling algorithms for multiprogramming in a hard-real-time environment,” J. ACM, 20(1), 1973.

27 Feasibility for RMS Feasibility is defined for RMS to mean that every task executes to completion once within its designated period.

28 Showing Optimality of RMS: Consider two tasks with different periods Is a non-preemptive schedule feasible? C1C1 T1T1 C2C2 T2T2

29 Showing Optimality of RMS: Consider two tasks with different periods Non-preemptive schedule is not feasible. Some instance of the Red Task (2) will not finish within its period if we do non-preemptive scheduling. C1C1 T1T1 C2C2 T2T2

30 Showing Optimality of RMS: Consider two tasks with different periods What if we had a preemptive scheduling with higher priority for red task? C1C1 T1T1 C2C2 T2T2

31 Showing Optimality of RMS: Consider two tasks with different periods Preemptive schedule with the red task having higher priority is feasible. Note that preemption of the blue task extends its completion time. preempted C1C1 C1C1

32 Showing Optimality of RMS: Alignment of tasks Completion time of the lower priority task is worst when its starting phase matches that of higher priority tasks. Thus, when checking schedule feasibility, it is sufficient to consider only the worst case: All tasks start their cycles at the same time. T1T1 C1C1

33 Showing Optimality of RMS: (for two tasks) It is sufficient to show that if a non-RMS schedule is feasible, then the RMS schedule is feasible. Consider two tasks as follows: C1C1 T1T1 C2C2 T2T2

34 Showing Optimality of RMS: (for two tasks) The non-RMS, fixed priority schedule looks like this: T2T2 C2C2 C1C1 From this, we can see that the non-RMS schedule is feasible if and only if We can then show that this condition implies that the RMS schedule is feasible.

35 Showing Optimality of RMS: (for two tasks) The RMS schedule looks like this: (task with smaller period moves earlier) T2T2 C2C2 C1C1 The condition for the non-RMS schedule feasibility: is clearly sufficient (though not necessary) for feasibility of the RMS schedule. QED.

36 Comments This proof can be extended to an arbitrary number of tasks (though it gets much more tedious). This proof gives optimality only w.r.t. feasibility. It says nothing about other optimality criteria. Practical implementation: –Timer interrupt at greatest common divisor of the periods. –Multiple timers

37 Deadline Driven Scheduling: 1. Jackson’s Algorithm: EDD (1955) Given n independent one-time tasks with deadlines d 1, …, d n, schedule them to minimize the maximum lateness, defined as where f i is the finishing time of task i. Note that this is negative iff all deadlines are met. Earliest Due Date (EDD) algorithm: Execute them in order of non-decreasing deadlines. Note that this does not require preemption.

38 Theorem: EDD is Optimal in the Sense of Minimizing Maximum Lateness To prove, use an interchange argument. Given a schedule S that is not EDD, there must be tasks a and b where a immediately precedes b in the schedule but d a > d b. Why? We can prove that this schedule can be improved by interchanging a and b. Thus, no non-EDD schedule is achieves smaller max lateness than EDD, so the EDD schedule must be optimal.

39 Consider a non-EDD Schedule S There must be tasks a and b where a immediately precedes b in the schedule but d a > d b ab fafa fbfb time ab

40 Deadline Driven Scheduling: 1. Horn’s algorithm: EDF (1974) Extend EDD by allowing tasks to “arrive” (become ready) at any time. Earliest deadline first (EDF): Given a set of n independent tasks with arbitrary arrival times, any algorithm that at any instant executes the task with the earliest absolute deadline among all arrived tasks is optimal w.r.t. minimizing the maximum lateness. Proof uses a similar interchange argument.

41 RMS vs. EDF? Which one is better? What are the pros and cons of each?

42 Comparison of EDF and RMS Favoring RMS –Scheduling decisions are simpler (fixed priorities vs. the dynamic priorities required by EDF. EDF scheduler must maintain a list of ready tasks that is sorted by priority.) Favoring EDF –Since EDF is optimal w.r.t. maximum lateness, it is also optimal w.r.t. feasibility. RMS is only optimal w.r.t. feasibility. For infeasible schedules, RMS completely blocks lower priority tasks, resulting in unbounded maximum lateness. –EDF can achieve full utilization where RMS fails to do that –EDF results in fewer preemptions in practice, and hence less overhead for context switching. –Deadlines can be different from the period.

43 Precedence Constraints A directed acyclic graph (DAG) shows precedences, which indicate which tasks must complete before other tasks start DAG, showing that task 1 must complete before tasks 2 and 3 can be started, etc.

44 Example: EDF Schedule Is this feasible? Is it optimal? C 1 = 1 d 1 = 2 C 3 = 1 d 3 = 4 C 2 = 1 d 2 = 5 C 4 = 1 d 4 = 3 C 5 = 1 d 5 = 5 C 6 = 1 d 6 = 6

45 EDF is not optimal under precedence constraints The EDF schedule chooses task 3 at time 1 because it has an earlier deadline. This choice results in task 4 missing its deadline. Is there a feasible schedule? C 1 = 1 d 1 = 2 C 3 = 1 d 3 = 4 C 2 = 1 d 2 = 5 C 4 = 1 d 4 = 3 C 5 = 1 d 5 = 5 C 6 = 1 d 6 = 6

46 LDF is optimal under precedence constraints The LDF schedule shown at the bottom respects all precedences and meets all deadlines C 1 = 1 d 1 = 2 C 3 = 1 d 3 = 4 C 2 = 1 d 2 = 5 C 4 = 1 d 4 = 3 C 5 = 1 d 5 = 5 C 6 = 1 d 6 = 6

47 Latest Deadline First (LDF) (Lawler, 1973) The LDF scheduling strategy builds a schedule backwards. Given a DAG, choose the leaf node with the latest deadline to be scheduled last, and work backwards C 1 = 1 d 1 = 2 C 3 = 1 d 3 = 4 C 2 = 1 d 2 = 5 C 4 = 1 d 4 = 3 C 5 = 1 d 5 = 5 C 6 = 1 d 6 = 6

48 Latest Deadline First (LDF) (Lawler, 1973) The LDF scheduling strategy builds a schedule backwards. Given a DAG, choose the leaf node with the latest deadline to be scheduled last, and work backwards C 1 = 1 d 1 = 2 C 3 = 1 d 3 = 4 C 2 = 1 d 2 = 5 C 4 = 1 d 4 = 3 C 5 = 1 d 5 = 5 C 6 = 1 d 6 = 6

49 Latest Deadline First (LDF) (Lawler, 1973) The LDF scheduling strategy builds a schedule backwards. Given a DAG, choose the leaf node with the latest deadline to be scheduled last, and work backwards C 1 = 1 d 1 = 2 C 3 = 1 d 3 = 4 C 2 = 1 d 2 = 5 C 4 = 1 d 4 = 3 C 5 = 1 d 5 = 5 C 6 = 1 d 6 = 6

50 Latest Deadline First (LDF) (Lawler, 1973) The LDF scheduling strategy builds a schedule backwards. Given a DAG, choose the leaf node with the latest deadline to be scheduled last, and work backwards C 1 = 1 d 1 = 2 C 3 = 1 d 3 = 4 C 2 = 1 d 2 = 5 C 4 = 1 d 4 = 3 C 5 = 1 d 5 = 5 C 6 = 1 d 6 = 6

51 Latest Deadline First (LDF) (Lawler, 1973) The LDF scheduling strategy builds a schedule backwards. Given a DAG, choose the leaf node with the latest deadline to be scheduled last, and work backwards C 1 = 1 d 1 = 2 C 3 = 1 d 3 = 4 C 2 = 1 d 2 = 5 C 4 = 1 d 4 = 3 C 5 = 1 d 5 = 5 C 6 = 1 d 6 = 6

52 Latest Deadline First (LDF) (Lawler, 1973) The LDF scheduling strategy builds a schedule backwards. Given a DAG, choose the leaf node with the latest deadline to be scheduled last, and work backwards C 1 = 1 d 1 = 2 C 3 = 1 d 3 = 4 C 2 = 1 d 2 = 5 C 4 = 1 d 4 = 3 C 5 = 1 d 5 = 5 C 6 = 1 d 6 = 6

53 Latest Deadline First (LDF) (Lawler, 1973) The LDF scheduling strategy builds a schedule backwards. Given a DAG, choose the leaf node with the latest deadline to be scheduled last, and work backwards C 1 = 1 d 1 = 2 C 3 = 1 d 3 = 4 C 2 = 1 d 2 = 5 C 4 = 1 d 4 = 3 C 5 = 1 d 5 = 5 C 6 = 1 d 6 = 6

54 Latest Deadline First (LDF) (Lawler, 1973) LDF is optimal in the sense that it minimizes the maximum lateness. It does not require preemption. (We’ll see that EDF does.) However, it requires that all tasks be available and their precedences known before any task is executed.

55 EDF with Precedences With a preemptive scheduler, EDF can be modified to account for precedences and to allow tasks to arrive at arbitrary times. Simply adjust the deadlines and arrival times according to the precedences C 1 = 1 d 1 = 2 C 3 = 1 d 3 = 4 C 2 = 1 d 2 = 5 C 4 = 1 d 4 = 3 C 5 = 1 d 5 = 5 C 6 = 1 d 6 = 6 Recall that for the tasks at the left, EDF yields the schedule above, where task 4 misses its deadline.

56 Optimality EDF with precedences is optimal in the sense of minimizing the maximum lateness.

57 Mars Rover Pathfinder The Mars Rover Pathfinder landed on Mars on July 4th, A few days into the mission, the Pathfinder began sporadically missing deadlines, causing total system resets, each with loss of data. The problem was diagnosed on the ground as priority inversion, where a low priority meteorological task was holding a lock blocking a high-priority task while medium priority tasks executed. Source: RISKS on the comp.programming.threads newsgroup, December 07, 1997, by Mike Jones

58 How do we fix this?

59 Priority Inheritance Protocol (PIP) (Sha, Rajkumar, Lehoczky, 1990) Task 1 has highest priority, task 3 lowest. Task 3 acquires a lock on a shared object, entering a critical section. It gets preempted by task 1, which then tries to acquire the lock and blocks. Task 3 inherits the priority of task 1, preventing preemption by task 2.

60 Deadlock #include... pthread_mutex_t lock_a, lock_b; void* thread_1_function(void* arg) { pthread_mutex_lock(&lock_b);... pthread_mutex_lock(&lock_a);... pthread_mutex_unlock(&lock_a);... pthread_mutex_unlock(&lock_b);... } void* thread_2_function(void* arg) { pthread_mutex_lock(&lock_a);... pthread_mutex_lock(&lock_b);... pthread_mutex_unlock(&lock_b);... pthread_mutex_unlock(&lock_a);... } The lower priority task starts first and acquires lock a, then gets preempted by the higher priority task, which acquires lock b and then blocks trying to acquire lock a. The lower priority task then blocks trying to acquire lock b, and no further progress is possible.

61 Priority Ceiling Protocol (PCP) (Sha, Rajkumar, Lehoczky, 1990) Every lock or semaphore is assigned a priority ceiling equal to the priority of the highest-priority task that can lock it. –Can one automatically compute the priority ceiling? A task T can acquire a lock only if the task’s priority is strictly higher than the priority ceilings of all locks currently held by other tasks –Intuition: the task T will not later try to acquire these locks held by other tasks –Locks that are not held by any task don’t affect the task This prevents deadlocks There are extensions supporting dynamic priorities and dynamic creations of locks (stack resource policy)

62 Priority Ceiling Protocol In this version, locks a and b have priority ceilings equal to the priority of task 1. At time 3, task 1 attempts to lock b, but it can’t because task 2 currently holds lock a, which has priority ceiling equal to the priority of task 1. #include... pthread_mutex_t lock_a, lock_b; void* thread_1_function(void* arg) { pthread_mutex_lock(&lock_b);... pthread_mutex_lock(&lock_a);... pthread_mutex_unlock(&lock_a);... pthread_mutex_unlock(&lock_b);... } void* thread_2_function(void* arg) { pthread_mutex_lock(&lock_a);... pthread_mutex_lock(&lock_b);... pthread_mutex_unlock(&lock_b);... pthread_mutex_unlock(&lock_a);... }

63 Brittleness In general, all thread scheduling algorithms are brittle: Small changes can have big, unexpected consequences. I will illustrate this with multiprocessor (or multicore) schedules. Theorem (Richard Graham, 1976): If a task set with fixed priorities, execution times, and precedence constraints is scheduled according to priorities on a fixed number of processors, then increasing the number of processors, reducing execution times, or weakening precedence constraints can increase the schedule length.

64 Richard’s Anomalies What happens if you increase the number of processors to four? tasks with precedences and the shown execution times, where lower numbered tasks have higher priority than higher numbered tasks. Priority-based 3 processor schedule: C 1 = 3 C 2 = 2 C 3 = 2 C 4 = 2 C 9 = 9 C 8 = 4 C 7 = 4 C 6 = 4 C 5 = 4

65 Richard’s Anomalies: Increasing the number of processors The priority-based schedule with four processors has a longer execution time tasks with precedences and the shown execution times, where lower numbered tasks have higher priority than higher numbered tasks. Priority-based 3 processor schedule: C 1 = 3 C 2 = 2 C 3 = 2 C 4 = 2 C 9 = 9 C 8 = 4 C 7 = 4 C 6 = 4 C 5 = 4

66 Greedy Scheduling Priority-based scheduling is “greedy.” A smarter scheduler for this example could hold off scheduling 5, 6, or 7, leaving a processor idle for one time unit tasks with precedences and the shown execution times, where lower numbered tasks have higher priority than higher numbered tasks. Priority-based 3 processor schedule: C 1 = 3 C 2 = 2 C 3 = 2 C 4 = 2 C 9 = 9 C 8 = 4 C 7 = 4 C 6 = 4 C 5 = 4

67 Greedy scheduling may be the only practical option. If tasks “arrive” (become known to the scheduler) only after their predecessor completes, then greedy scheduling may be the only practical option tasks with precedences and the shown execution times, where lower numbered tasks have higher priority than higher numbered tasks. Priority-based 3 processor schedule: C 1 = 3 C 2 = 2 C 3 = 2 C 4 = 2 C 9 = 9 C 8 = 4 C 7 = 4 C 6 = 4 C 5 = 4

68 Richard’s Anomalies What happens if you reduce all computation times by 1? tasks with precedences and the shown execution times, where lower numbered tasks have higher priority than higher numbered tasks. Priority-based 3 processor schedule: C 1 = 3 C 2 = 2 C 3 = 2 C 4 = 2 C 9 = 9 C 8 = 4 C 7 = 4 C 6 = 4 C 5 = 4

69 Richard’s Anomalies: Reducing computation times Reducing the computation times by 1 also results in a longer execution time tasks with precedences and the shown execution times, where lower numbered tasks have higher priority than higher numbered tasks. Priority-based 3 processor schedule: C 1 = 2 C 2 = 1 C 3 = 1 C 4 = 1 C 9 = 8 C 8 = 3 C 7 = 3 C 6 = 3 C 5 = 3

70 Richard’s Anomalies What happens if you remove the precedence constraints (4,8) and (4,7)? tasks with precedences and the shown execution times, where lower numbered tasks have higher priority than higher numbered tasks. Priority-based 3 processor schedule: C 1 = 3 C 2 = 2 C 3 = 2 C 4 = 2 C 9 = 9 C 8 = 4 C 7 = 4 C 6 = 4 C 5 = 4

71 Richard’s Anomalies: Weakening the precedence constraints Weakening precedence constraints can also result in a longer schedule tasks with precedences and the shown execution times, where lower numbered tasks have higher priority than higher numbered tasks. Priority-based 3 processor schedule: C 1 = 3 C 2 = 2 C 3 = 2 C 4 = 2 C 9 = 9 C 8 = 4 C 7 = 4 C 6 = 4 C 5 = 4

72 Richard’s Anomalies with Mutexes: Reducing Execution Time Assume tasks 2 and 4 share the same resource in exclusive mode, and tasks are statically allocated to processors. Then if the execution time of task 1 is reduced, the schedule length increases:

73 Conclusion Timing behavior under all known task scheduling strategies is brittle. Small changes can have big (and unexpected) consequences. Unfortunately, since execution times are so hard to predict, such brittleness can result in unexpected system failures.

74 WRAP UP

75 For next time Exam Review


Download ppt "MULTITASKING AND SCHEDULING EEN 417 Fall 2013. Layers of Abstraction for Concurrency in Programs."

Similar presentations


Ads by Google