WEBVTT 00:00:00.410 --> 00:00:03.400 Suppose we have a real-time system supporting three devices: 00:00:03.400 --> 00:00:07.910 a keyboard whose interrupt handler has a service time of 800 us, 00:00:07.910 --> 00:00:15.389 a disk with a service time of 500 us, and a printer with a service time of 400 us. 00:00:15.389 --> 00:00:18.949 What is the worst-case latency seen by each device? 00:00:18.949 --> 00:00:24.140 For now we'll assume that requests are infrequent, i.e., that each request only happens once 00:00:24.140 --> 00:00:26.250 in each scenario. 00:00:26.250 --> 00:00:29.560 Requests can arrive at any time and in any order. 00:00:29.560 --> 00:00:34.730 If we serve the requests in first-come-first-served order, each device might be delayed by the 00:00:34.730 --> 00:00:37.170 service of all other devices. 00:00:37.170 --> 00:00:41.280 So the start of the keyboard handler might be delayed by the execution of the disk and 00:00:41.280 --> 00:00:46.710 printer handlers, a worst-case latency of 900 us. 00:00:46.710 --> 00:00:51.579 The start of the disk handler might be delayed by the keyboard and printer handlers, a worst-case 00:00:51.579 --> 00:00:54.449 latency of 1200 us. 00:00:54.449 --> 00:00:58.680 And the printer handler might be delayed by the keyboard and disk handlers, a worst-case 00:00:58.680 --> 00:01:02.090 latency of 1300 us. 00:01:02.090 --> 00:01:06.450 In this scenario we see that long-running handlers have a huge impact on the worst-case 00:01:06.450 --> 00:01:09.789 latency seen by the other devices. 00:01:09.789 --> 00:01:13.500 What are the possibilities for reducing the worst-case latencies? 00:01:13.500 --> 00:01:19.390 Is there a better scheduling algorithm than first-come-first-served? 00:01:19.390 --> 00:01:24.030 One strategy is to assign priorities to the pending requests and to serve the requests 00:01:24.030 --> 00:01:25.850 in priority order. 00:01:25.850 --> 00:01:30.140 If the handlers are uninterruptible, the priorities will be used to select the *next* task to 00:01:30.140 --> 00:01:33.470 be run at the completion of the current task. 00:01:33.470 --> 00:01:38.780 Note that under this strategy, the current task always runs to completion even if a higher-priority 00:01:38.780 --> 00:01:41.270 request arrives while it's executing. 00:01:41.270 --> 00:01:45.820 This is called a "nonpreemptive" or "weak" priority system. 00:01:45.820 --> 00:01:50.920 Using a weak priority system, the worst-case latency seen by each device is the worst-case 00:01:50.920 --> 00:01:55.340 service time of all the other devices (since that handler may have just started 00:01:55.340 --> 00:02:00.500 running when the new request arrives), plus the service time of all higher-priority 00:02:00.500 --> 00:02:02.800 devices (since they'll be run first). 00:02:02.800 --> 00:02:07.840 In our example, suppose we assigned the highest priority to the disk, the next priority to 00:02:07.840 --> 00:02:11.670 the printer, and the lowest priority to the keyboard. 00:02:11.670 --> 00:02:15.610 The worst-case latency of the keyboard is unchanged since it has the lowest priority 00:02:15.610 --> 00:02:20.590 and hence can be delayed by the higher-priority disk and printer handlers. 00:02:20.590 --> 00:02:24.850 The disk handler has the highest priority and so will always be selected for execution 00:02:24.850 --> 00:02:27.880 after the current handler completes. 00:02:27.880 --> 00:02:32.910 So its worst-case latency is the worst-case service time for the currently-running handler, 00:02:32.910 --> 00:02:34.840 which in this case is the keyboard. 00:02:34.840 --> 00:02:39.140 So the worst-case latency for the disk is 800 us. 00:02:39.140 --> 00:02:44.360 This is a considerable improvement over the first-come-first-served scenario. 00:02:44.360 --> 00:02:49.840 Finally the worst-case scenario for the printer is 1300 us since it may have to wait for the 00:02:49.840 --> 00:02:53.930 keyboard handler to finish (which can take up to 800 us) 00:02:53.930 --> 00:03:00.830 and then for a higher-priority disk request to be serviced (which takes 500 us). 00:03:00.830 --> 00:03:05.510 How should priorities be assigned given hard real-time constraints? 00:03:05.510 --> 00:03:12.240 We'll assume each device has a service deadline D after the arrival of its service request. 00:03:12.240 --> 00:03:17.640 If not otherwise specified, assume D is the time until the *next* request for the same 00:03:17.640 --> 00:03:18.640 device. 00:03:18.640 --> 00:03:22.460 This is a reasonably conservative assumption that prevents the system from falling further 00:03:22.460 --> 00:03:24.610 and further behind. 00:03:24.610 --> 00:03:29.790 For example, it makes sense that the keyboard handler should finish processing one character 00:03:29.790 --> 00:03:31.760 before the next arrives. 00:03:31.760 --> 00:03:36.709 "Earliest Deadline" is a strategy for assigning priorities that is guaranteed to meet the 00:03:36.709 --> 00:03:41.209 deadlines if any priority assignment can meet the deadlines. 00:03:41.209 --> 00:03:44.640 It's very simple: Sort the requests by their deadlines. 00:03:44.640 --> 00:03:49.459 Assign the highest priority to the earliest deadline, second priority to the next deadline, 00:03:49.459 --> 00:03:51.290 and so on. 00:03:51.290 --> 00:03:56.650 A weak priority system will choose the pending request with the highest priority, i.e., the 00:03:56.650 --> 00:04:00.270 request that has the earliest deadline. 00:04:00.270 --> 00:04:02.380 Earliest Deadline has an intuitive appeal. 00:04:02.380 --> 00:04:05.510 Imagine standing in a long security line at the airport. 00:04:05.510 --> 00:04:10.720 It would make sense to prioritize the processing of passengers who have the earliest flights 00:04:10.720 --> 00:04:16.738 assuming that there's enough time to process everyone before their flight leaves. 00:04:16.738 --> 00:04:20.500 Processing 10 people whose flights leave in 30 minutes before someone whose flight leaves 00:04:20.500 --> 00:04:25.200 in 5 min will cause that last person to miss their flight. 00:04:25.200 --> 00:04:30.060 But if that person is processed first, the other passengers may be slightly delayed but 00:04:30.060 --> 00:04:32.510 everyone will make their flight. 00:04:32.510 --> 00:04:37.070 This is the sort of scheduling problem that Earliest Deadline and a weak priority system 00:04:37.070 --> 00:04:39.360 can solve. 00:04:39.360 --> 00:04:43.130 It's outside the scope of our discussion, but it's interesting to think about what should 00:04:43.130 --> 00:04:47.090 happen if some flights are going to be missed. 00:04:47.090 --> 00:04:51.800 If the system is overloaded, prioritizing by earliest deadline may mean that everyone 00:04:51.800 --> 00:04:53.520 will miss their flights! 00:04:53.520 --> 00:04:57.970 In this scenario it might be better to assign priorities to the minimize the total number 00:04:57.970 --> 00:04:59.650 of missed flights. 00:04:59.650 --> 00:05:04.250 This gets complicated in a hurry since the assignment of priorities now depends on exactly 00:05:04.250 --> 00:05:08.150 what requests are pending and how long it will take them to be serviced. 00:05:08.150 --> 00:05:10.120 An intriguing problem to think about!