6.1 Motivation. Fixed Priorities. 6.2 Context Switch. Real-time is about predictability, i.e. guarantees. Real-Time Systems

Transcription

1 Real-Time Systems Summer term Motivation 6.1 Motivation Real-Time Systems 6 th Chapter Practical Considerations Jafar Akhundov, M.Sc. Professur Betriebssysteme Real-time is about predictability, i.e. guarantees The stated guarantees, and the reasoning, respectively, rely on assumptions, such as... Standard assumptions Periodic task model Known runtime... Considering actual implementations, assumptions are not always realistic Thus, we discuss some practical issues SoSe 2017 J. Akhundov 2 / 24 osg.informatik.tu-chemnitz.de Standard assumption: Jobs are preemptive at any time and at no cost no realistic assumption, depending on operating system Ramifications 1. Avoid unnecessary context switch Out of two jobs with the same priority, select always the job that introduces less context switches, even if the theory states that it doesn t matter. 2. Safety margin, e.g. U 1 3. Expand theory to consider context-switch times Fixed Priorities Be t CX the context-switch times, i.e. the (worst-case) amount of time the operating system spends per context switch Consider first fixed-priority policies without self-suspension or dependencies (blocking) Each job preempts at most one other job This introduces two context switches: start and completion of the job that preempts The job with the lowest priority introduces two context switches, too (from/to idle) Approach: adaption of the job execution times i, e i = e i + 2t CX SoSe 2017 J. Akhundov 3 / 24 osg.informatik.tu-chemnitz.de SoSe 2017 J. Akhundov 4 / 24 osg.informatik.tu-chemnitz.de

2 Impact of Resource Protocols Dependencies between jobs may change the number of context switches NPCS: no additional context switch HLP: no additional context switch PIP: Two additional context switches for each resource a job shares with other low-priority jobs PCP: two additional context switches for any job that accesses at least one resource Please note The cases discussed here are worst cases. E.g., it is possible that NPCS avoids some context switches. EDF Since we have dynamic priorities, it is harder to predict the number of context switches However, a job J 2 can only preempt a job J 1, if the deadline of J 1 is later that J 2 ones, and J 1 is running at arrival of J 2 P 2 < P 1 Thus, EDF introduces context switches only in cases, that belong to worst cases of RMS EDF will never introduce more context switches than RMS in worst case By using the same assumptions as for RMS, one gets conservative results (with overestimation of context-switch times) SoSe 2017 J. Akhundov 5 / 24 osg.informatik.tu-chemnitz.de EDF (cont.) RMS vs. EDF: number of context switches [But05] SoSe 2017 J. Akhundov 6 / 24 osg.informatik.tu-chemnitz.de Real-time systems are embedded systems; they interact with environment I/O has to be considered Two fundamental approaches: 1. Polling: (sensor) values are read on regular basis 2. Event-driven: an interrupt is raised, if an external event occurs Driver polling can be implemented as normal periodic task Communication with hardware may be required to be atomic consider blocking times Event-based IO (interrupts) is a bit more elaborate SoSe 2017 J. Akhundov 7 / 24 osg.informatik.tu-chemnitz.de SoSe 2017 J. Akhundov 8 / 24 osg.informatik.tu-chemnitz.de

3 Interrupts Interrupts preempt immediately invalidates priority assumption Servicing interrupts (ISR, interrupt service routine) requires usually very little time negligible However, what if not so? Consider ISR as blocking time In case of priority-based scheduling: consider ISR as job with highest priority (e.g., to apply TDA) Optionally, divide ISR into two parts: 1. Real ISR: acknowledge interrupt, activate part 2 as job 2. Job: longer work is done here Result: generation of sporadic/aperiodic Jobs Sporadic/Aperiodic Jobs Recap: Jobs of aperiodic tasks have a minimal inter-arrival time; no assumptions are made for sporadic tasks For sporadic jobs, no guarantees can be given two alternatives: Give up guarantees allow for missed deadlines, or reject jobs Low-pass filter for events (i.e. higher arrival rate = lower inter-arrival times will be ignored) change sporadic tasks into aperiodic tasks Low-pass filtering may be realized by means of hardware (e.g. debouncing of switches by capacitors), or by disabling of interrupts SoSe 2017 J. Akhundov 9 / 24 osg.informatik.tu-chemnitz.de Scheduling of Aperiodic Jobs Worst case: tasks generates jobs with highest possible frequency periodic task Feasible, if periodic case is feasible Sometimes, aperiodic jobs have no deadline, but should run as soon as possible Increases feasibility Different approaches: Simple approach: use of idle times only may lead to larger delay Slack-time stealing: (maximum) delay of jobs requires knowledge of execution times Server for aperiodic jobs: schedule of a periodic task, that is replenished by aperiodic/sporadic jobs SoSe 2017 J. Akhundov 11 / 24 osg.informatik.tu-chemnitz.de SoSe 2017 J. Akhundov 10 / 24 osg.informatik.tu-chemnitz.de Some scheduling algorithms and feasibility criteria are based on known execution time of tasks Measurement is not sufficient provide one (or several) result(s), but not the highest Instead: We need estimation of worst case execution time, (WCET) Objectives: Prediction should never be lower than measurement Overestimation should be as low as possible WCES depends on: Program code, compiler, libraries Path through the program, which in turn depends on state and input Hardware used: CPU, memory, cache, busses,... Interdependencies among those parameters SoSe 2017 J. Akhundov 12 / 24 osg.informatik.tu-chemnitz.de

4 Problem High-level Analysis We distinguish two generic problems: What is the longest path through a program? high-level analysis How to calculate the longest possible execution time for a given path through a program? low-level analysis Given: source code of a program Assumption: runtime of single statements is known Problem: What is the (maximum) time to execute that code longest path It is not trivial to identify the longest path Even more: impossible in general case! Consider following problems SoSe 2017 J. Akhundov 13 / 24 osg.informatik.tu-chemnitz.de Problem: Loops SoSe 2017 J. Akhundov 14 / 24 osg.informatik.tu-chemnitz.de Problem: Termination Example: Calculate WCET of the following program 1 int i=0,k=0; 2 int j = readsensor(); 3 while(i<j) 4 { 5 k+=sensorfunction(i); 6 i++; 7 } Problem: How often is this loop executed? Solution: Define bounds Example: Calculate WCET of the following program 1 int i=0,k=0; 2 int j = readsensor(); 3 while(i<j) 4 { 5 k+=sensorfunction(i); 6 i++; 7 } Problem: Does this loop terminate at all? Solution: As the halting problem is not decidable in general, we have to ensure total correctness e.g. HOARE logic SoSe 2017 J. Akhundov 15 / 24 osg.informatik.tu-chemnitz.de SoSe 2017 J. Akhundov 16 / 24 osg.informatik.tu-chemnitz.de

5 Assumptions for High-level Analysis Concept Special assumptions make the problem decidable:: For each loop, maximum number of iterations is known No recursion (or only recursion with restricted depth) No dynamic data structures (or only dynamic data structures with bounded resource usage) Implication: Restriction of allowed program constructs in hard RT-programs Support by programming language is possible Basic Block Block of machine instructions with exactly one entry point and exactly one exit point and no branches Analysis tool constructs control flow graph consisting of basic blocks Calculating WCET of all basic blocks using low-level analysis Calculation of the longest path ( graph theory) SoSe 2017 J. Akhundov 17 / 24 osg.informatik.tu-chemnitz.de Timing Scheme SoSe 2017 J. Akhundov 18 / 24 osg.informatik.tu-chemnitz.de Optimization: Data Dependency WCET on base of longest path analysis tends to overestimate W (X) = W CET (X) if X is basic block W (X; Y ) = W (X) + W (Y ) W (if Z then X else Y ) = W (Z) + max {W (X), W (Y )} W (for Z loop X) = (n + 1) W (Z) + n W (X) Loop iterations are restricted by n Execution time W CET (X) of basic blocks is given by low-level analysis Recursive calculation for each part of the syntax tree Application to program gives theoretical WCET Feasibility is not considered optimization Consider following code 1 if ( a>b) { 2 c = 2*a; /* BLOCK A */ 3... /* : */ 4 } else { 5 c++; /* BLOCK B */ 6... /* : */ 7 } 8 if ( ( c%2)==0 ) { 9... /* BLOCK C */ 10 } else { /* BLOCK D */ 12 } Path A D is not feasible! Such data dependencies can sometimes be traced by approaches as used for compiler; however not in general SoSe 2017 J. Akhundov 19 / 24 osg.informatik.tu-chemnitz.de SoSe 2017 J. Akhundov 20 / 24 osg.informatik.tu-chemnitz.de

6 Low-level Analysis Manufacturers usually describe timing behavior of all instructions For hard real-time, this information is essential Such times can be used to calculate WCET By means of fine-granular models and tool support, one can get complexity under control Example: Modeling of PowerPC Problem: Simple worst case assumptions are not sufficient Worst case of cache: Always cache miss Pipeline flush after each instruction Would result in WCET that over-estimates by several 100% Solution: Include the effects of modern processor enhancements into analysis New problem: complexity 1 Markus Mergner. Evaluation von pwcet.. Diplomarbeit. Humboldt University of Berlin, 2006 SoSe 2017 J. Akhundov 21 / 24 osg.informatik.tu-chemnitz.de 6.5 What Else? 6.5 What Else? SoSe 2017 J. Akhundov 22 / 24 osg.informatik.tu-chemnitz.de Appendix A: Bibliography Appendix A: Bibliography There are further implementation aspects to be considered, e.g.: Tick scheduling, i.e., scheduling at discrete times invalidates preemption assumption mapping to blocking times; possibly scheduler as periodic task Multicore processors invalidates single processor assumption subject of research (chapter of this course, if we have sufficient time) Different timing requirements/task models a.o., see chapter on soft real time [But05] Giorgio C. Buttazzo. Rate Monotonic vs. EDF: Judgment Day. In: Real-Time Systems 29.1 (2005), pp [Liu00] Jane W. S. Liu. Real-Time Systems. Prentice Hall, 2000, Section 6.8 [Kop97] [PK89] Hermann Kopetz. Real-Time Systems Design Principles for Distributed Embedded Applications. Kluver Academic, 1997, Section 4.5 P. Puschner and Ch. Koza. Calculating the maximum, execution time of real-time programs. In: Real-Time Systems 1.2 (Sept. 1989), pp SoSe 2017 J. Akhundov 23 / 24 osg.informatik.tu-chemnitz.de SoSe 2017 J. Akhundov 24 / 24 osg.informatik.tu-chemnitz.de