Real Time Scheduler
Zeitungsmeldung 2. Mai. 2015: In Labortest, alle 248 Tage schaltet der Computer den Stromgenerator in den Fail-Safe-mode um ihm zu schutzen APU: Prozedur zum Start: 30.. 60 Sek, und funktioniert nur unter 5 KM höhe (Bird alle 24,8 Tage...) (Ariane 5.01 : accelerometer 16 bit überlauf)
Scheduling Der Scheduler aktiviert tasks. Macht die CPU-Zeit Zuteilung. Er entscheidet nur wer an der Reihe ist, der Rest macht jemand anderes. Z.B. ich mache die Moderation und mein Helfer (Sheduler) sacht mir wer darf reden Ein Echtzeit-Scheduler muss dafür sorgen, dass jeder Task rechtzeitig aktiviert wird, damit er sein Reaktionszeitfenster trifft. Er soll wissen wann und wie lange jeder Task braucht. Oder jeder Task weiß, wie lange er braucht und sagt den Scheduler, wann er aktiviert werden soll. Alle Externe Aktionen müssen Zeit-Gestuert werden: Sensoren (R) und Aktuatoren (W) Wenn man dies weiß, kann man offline analysieren, ob das Scheduling möglich ist. In Run-Time: Der Scheduler wird sein bestes tun, unabhängig davon, ob es möglich ist. Vorsicht: Was tun bei Zeitkonflikte? Prioritäten (verschiedenen Kriterien)
Scheduling, Planung Anforderungen: - Alle zeitkritischen Tasks müssen so zuteilbar sein, dass auch mit einer Worst- Case-Ausführungszeit und mit der höchsten erwarteten Interruptrate jedes Reaktionszeitfenster getroffen wird. - Alle zeitempfindlichen Tasks müssen so zuteilbar sein, dass mit der mittleren Ausführungszeit und mittleren Interruptrate jedes Reaktionszeitfenster getroffen werden kann. - Es muss genügend Prozessor-Zeit frei bleiben, so dass die aperiodischen spontanen Tasks dynamisch zuteilbar sind, mit Worst-Case- oder mit mittlerer Ausführungszeit und Frequenz. Periodische & Aperiodische Tasks als zeitkritisch? wir spielen mit Feuer! Super schnelle Interrupt Bearbeitung - Das Timing von zeitkritischen Tasks darf nicht von den anderen Tasks beeinflußt werden (und was ist mit Zeitkritische Periodische und Aperiodische zusammen/gleichzeitig?)
Scheduling, Planung Benötigte Daten für die Schedulability Analysis - Worst-Case-Ausführungszeit aller zeitkritischen Tasks - Mittlere Ausführungszeit aller zeitempfindlichen Tasks - Frequenz (oder Periode) der periodischen Tasks - Höchstmögliche und mittlere Interruptrate - Höchstmögliche und mittlere Auftrittsrate der spontanen Tasks - Zeitaufwand vom Scheduler selbst und vom Task-Wechseln Je mehr man über das Laufzeitverhalten des Systems weiß, um so sicherer kann der Scheduler gemacht werden. (+ Margin, Reservezeit: 20.. 40 % CPU Zeit frei) Oft kennt man es nicht! Probieren, und der Scheduler wird sein besten tun.
Worst case Time Analyse if (a) { } else {. } for(...) {. } while(...) {.} new()... delete() malloc() free() MMU... page fault Caches entry fault Java: Gavage Collector IO Can Spi.
Handle Funkion Kontext save/restore // kann von einem Big-Loop Aufgerufen werden handle() { read sensors // typische: big switch/case compute // z.b. UART msg kodierung write aktuator (eigene Zustand retten) return; }
Handle Funkion Kontext save/restore (eigene Zustand Erfassen (Zustandmaschiene, in variablen...)); // mus selber sein Zustand ret // kann von einem Big-Loop Aufgerufen werden handle() { readcounter++; read sensors <Warten auf etwas?? Semaphore?? -> return, und dann ab hier weiter... Wie dann? > compute // z.b. UART msg kodierung write aktuator (eigene Zustand retten) return; } Siehe Daten auf den Stack Beispiel von Semaphoren??? diff ressource <-> protector? wc, kloh, tür /home/sem40wk/sergio/folien-samlung/cpp/010-cpp-b.odp ab folie 25
Handle Funkion Kontext save/restore // kann von einem Big-Loop Aufgerufen werden handle() { read sensors // typische: big switch/case compute // z.b. UART msg kodierung write aktuator (eigene Zustand retten) return; } // kontext save/restore: Aufgabe von Betriebssystem (RT-OS) run() { while(1) { a; b; c; suspenduntil(xxx); d; e; waitforsignalfrom(xxx); f; g; for(...) { h; yield();} suspenduntil(xxx); } } Kooperativ (gibt die CPU frei) aber auch preemtion alle stack variablen bleiben erhalten!
Statischer Scheduler Das Zuteilungsprogramm schreibt der Programmierer, und es wird während der Laufzeit nicht geändert. z.b. at 12:00 A(); at 12:10 B(); at 13:59 C();... aber es muss ein Loop haben! (oder?) Der Programmierer muss alle Tasks und ihre Zeitcharakteristiken kennen. Dies geht gut bei den periodischen Tasks. Bei den aperiodischen Tasks muss man überall dort freie Zeit-Slots lassen, wo diese Tasks eintreten könnten. Daraus ergibt sich eine schlechte Prozessor-Auslastung.
Statischer Scheduler Erste Wahl bei sicherheitskritischen Aufgaben deterministisch und man weiß im Voraus, was er machen wird. keine Autonomie, aber besser für sicherheitskritische Aufgaben aber bei Anomalien: keine Flexibilität
(Determinismus versus Autonomie) in Klammern (meine Meinung)
(Determinismus versus Autonomie) R o b u s t h e i t ~ B a n d b r e i t e N o m i n a l e O p e r a t i o n N o r m a l e P a r a m e t e r D e s i g n e d P a r a m e t e r E r w a r t e t e U m g e b u n g E r w a r t e t e F u n k t i o n a l i t ä t K o m p l e x e S y s t e m e n k ö n n e n v i e l e n Ü b e r r a s c h u n g e n v e r s c h r e c k e n R o b u s t h e i t U n g e w i s s h e i t + A n o m a l i e n ( w e r d e n i m m e r d a b e i s e i n ) E i n f a c h e S y s t e m e n s i n d b e s s e r v o r h e r s e h b a r
(Determinismus versus Autonomie) > > R o b u s t h e i t < < R o b u s t h e i t aber deterministisch
(Determinismus versus Autonomie) R o b u s t h e i t ~ B a n d b r e i t e E r w a r t e t e F u n k t i o n a l i t ä t G e w i s s h e i t E r w a r t e t e u n d g e t e s t e t e U m g e b u n g - > G e w i s s h e i t W i r w i s s e n w i e w i r d d i e M a s c h i n e r e a g i e r e n U n g e w i s s e n R e a k t i o n M a s c h i n e B e s t G u e s s R o b u s t h e i t
(Determinismus versus Autonomie) Klammer zu
Statischer Scheduler Vorteile + Man weiß genau, was in der Laufzeit des Systems passiert. + höhere Sicherheit + deterministisch + Man kann die Zeitfenster garantieren. + Der Scheduler ist einfach (Dynamischer Scheduler kann auch einfach sein) + Kann schnell programmiert und getestet werden. + Der Laufzeit-Aufwand des Schedulers ist minimal. + Wenn es nur periodische Tasks gibt, kann man die höchstmögliche Prozessor- Auslastung erreichen und trotzdem die Zeitfenster garantieren.
Statischer Scheduler Nachteile: - Aperiodische Tasks sind ein Problem. - Wenn man ihre Zeitfenster garantiert, ergibt sich eine niedrige Prozessor-Auslastung. - Er kann sich nicht an neue Bedingungen während der Laufzeit anpassen. - Alle Task-Zeitcharakteristiken müssen im Voraus bekannt sein. - Tasks mit (relativ) langen Perioden verursachen einen großen major cycle und vergrößern damit das Zuteilungsprogramm (Scheduler). (z.b. Perioden: 17 & 31 ms...)
Statischer Scheduler Die Methode: zuerst eine übergeordnete Periode (major cycle) zu finden, die das kleinste gemeinsame Vielfache von allen Perioden der Tasks ist. (das ist der Loop) major cycle: wird in minor Scheiben aufgeteilt: Die kleinste Periode in jedem major cylcle werden alle periodischen Tasks mindestens einmal aufgerufen.
Unser kleinstes gemeinsames Vielfaches von allen Perioden (major cycle) ist 100 ms, die kleinste Periode ("minor cycle") ist 25 ms.
(50 ms) (100 ms) (25 ms) (100 ms) (25 ms) >0
Vorsicht: Jitter!
Problem Task 27 ms 1 ms Unser kleinstes gemeinsames Vielfaches von allen Perioden (major cycle) ist 100 ms, die kleinste Periode ("minor cycle") ist 25 ms.
sleep oder waituntil?
Warnung: grosses Jitter abhängig von der Laufzeit der vorherigen Tasks Aufgabe: Jitter minimieren (in C++)
/*** Zeit in nanosekunden ***/ #define SECONDS 1000000000LL #define MILLISECONDS 1000000LL #define MICROSECONDS 1000LL #define NANOSECONDS 1LL int64_t time0 = 0; Statischer Scheduler Für Linux int64_t NOW() { struct timespec tp; int64_t timenow; clock_gettime(clock_realtime, &tp); timenow = (tp.tv_sec * SECONDS + tp.tv_nsec) time0; return timenow; } void waituntil(int64_t time) { while(now() <= time) ; } Auf der Tafel void waitfor(int64_t deltatime) { waituntil(now() + deltatime); } void a() { printf("a: jede Sekunde, time = %lld\n", NOW()); } void b() { printf("b: jede Sekunde, time = %lld\n", NOW()); } void c() { printf("c: alle 2 Sekunden, time = %lld\n", NOW()); } void d() { printf("d: alle 4 Sekunden, time = %lld\n", NOW()); } void e() { printf("e: fast 4 Sekunden, time = %lld\n", NOW()); } Absolute Relative Zeit Was ist besser? bool econdition = true;
main() { time0 = now(); int64_t mayorcyclebegin = 1*SECONDS; while(1) { /*** 1. minor cycle ***/ waituntil(mayorcyclebegin); a(); b(); c(); d(); /*** 2. minor cycle ***/ waituntil(mayorcyclebegin + 1*SECONDS); if(econdition) e(); a(); b(); /*** 3. minor cycle ***/ waituntil(mayorcyclebegin + 2*SECONDS); c(); a(); b(); /*** 4. minor cycle ***/ waituntil(mayorcyclebegin + 3*SECONDS); a(); b(); Statischer Scheduler } } printf(" \n"); mayorcyclebegin += 4*SECONDS;
main() { time0 = now(); int64_t mayorcycle = 1*SECONDS; while(1) { /*** 1. minor cycle ***/ waituntil(mayorcycle); a(); b(); c(); d(); Statischer Scheduler kann besser sein... /*** 2. minor cycle ***/ waituntil(mayorcycle + 1*SECONDS); if(econdition) e(); a(); b(); // verbessern?? /*** 3. minor cycle ***/ waituntil(mayorcycle + 2*SECONDS); c(); a(); b(); // verbessern?? Und wenn ich hier NOW() + 1*SECONDS nehme? } } /*** 4. minor cycle ***/ waituntil(mayorcycle + 3*SECONDS); a(); b(); printf(" \n"); mayorcycle += 4*SECONDS;
main() { time0 = now(); int64_t mayorcycle = 1*SECONDS; while(1) { /*** 1. minor cycle ***/ waituntil(mayorcycle); a(); b(); c(); d(); /*** 2. minor cycle ***/ waituntil(mayorcycle + 1*SECONDS); a(); b(); if(econdition) e(); /*** 3. minor cycle ***/ waituntil(mayorcycle + 2*SECONDS); a(); b(); c(); /*** 4. minor cycle ***/ waituntil(mayorcycle + 3*SECONDS); a(); b(); Statischer Scheduler } } printf(" \n"); mayorcycle += 4*SECONDS;
Dynamischer Scheduler Wenn der Scheduler nicht nur für eine Applikation dienen soll, oder (die Tasks entstehen und terminieren während der Laufzeit) oder wenn die Laufzeit-Charakteristiken der Tasks nicht im voraus ermittelbar sind, Dynamischer Scheduler Tasks bestimmen selbst, wann sie laufen sollen, sie müssen aber kooperativ sein (oder Preemtion!) Für Sicherheit Schedulability- & Timing-Analyse Laufzeitananalyse Maximale Laufzeit (worst case) Analyse Caches? Interrupts?
Dynamischer Scheduler Beim dynamischen Scheduling sind die Tasks-Timings nicht (im Scheduler) vorprogrammiert, sondern sie werden während der Laufzeit an- und abgemeldet (beim Scheduler) Der Scheduler versucht dann, die Tasks so zu aktivieren, dass sie ihre Zeitfenster treffen, aber er kann nur wenig garantieren. Dieser Scheduler empfiehlt sich nicht für zeitkritische Tasks bei einer hohen Prozessor-Auslastung (Erfahrungswert: nur unter 69%, allerhöchstens 80%).
Beispiel...
Dynamischer Scheduler struct Executable { int64_t nexttime; int64_t periode; virtual void handle() { printf("undef\n"); } }; struct A : Executable { A() { nexttime = 1*SECONDS; periode = 2*SECONDS; } void handle() { printf("a \n"); } }; struct B : Executable { B() { nexttime = 1*SECONDS; periode = 3*SECONDS; } void handle() { printf("b \n"); } }; struct C : Executable { C() { nexttime = 1*SECONDS; periode = 4*SECONDS; } void handle() { printf("c \n"); } };
Dynamischer Scheduler struct Executable { int64_t nexttime; int64_t periode; virtual void handle() { printf("undef\n"); } }; main() { time0 = NOW(); A a; B b; C c; Executable* list[] = {&a, &b, &c, 0}; } while(1) { for(int i = 0; list[i]!= 0; i++) { if(list[i] >nexttime <= NOW()) { list[i] >handle(); list[i] >nexttime += list[i] >periode; } } }
main() { time0 = NOW(); A a; B b; C c; Executable* list[] = {&a, &b, &c, 0}; Dynamischer Scheduler } while(1) { for(int i = 0; list[i]!= 0; i++) { if(list[i] >nexttime <= NOW()) { list[i] >handle(); list[i] >nexttime += list[i] >periode; } } } Gibt es Hier Prioritäten?
main() { time0 = NOW(); A a; B b; C c; Executable* list[] = {&a, &b, &c, 0}; Dynamischer Scheduler while(1) { for(int i = 0; list[i]!= 0; i++) { if(list[i] >nexttime <= NOW()) { list[i] >handle(); list[i] >nexttime += list[i] >periode; } } } while(1) { Und hier?? for(int i = 0; list[i]!= 0; i++) { if(list[i] >nexttime <= NOW()) { list[i] >handle(); list[i] >nexttime += list[i] >periode; break; } } }
Prioritäten Falls mehrere Task gleichzeitig CPU-Zeit brauchen (falsche Planung?, unerwartete Ereignisse? aperiodische Ereignisse?) kann die Reihenfolge der Ausführung durch Prioritäten bestimmt werden. Und was wenn die kollidierten Taks die selbe Priorität haben? struct Executable { int64_t nexttime; int64_t periode; int32_t priority; virtual void handle() { printf("undef\n"); } }; while(1) { for(int i = 0; list[i]!= 0; i++) { if(list[i] >nexttime <= NOW()) { Ausführen? oder was soll ich hier machen? } } }
Planung
Prioritäten Falls mehrere Task gleichzeitig CPU-Zeit brauchen (falsche Planung?, unerwartete Ereignisse? aperiodische Ereignisse?) kann die Reihenfolge der Ausführung durch Prioritäten bestimmt werden. Höhere Priorität zuerst (von -10 bis +10, von 0 bis 100, von 0 bis 2G, etc.) (bei RODOS von 0 bis 2G) Vorsicht: Bei einigen ist 1 die höchste Priorität und 100 die niedrigste. Dies ist nur für dynamisches Scheduling (statische Scheduling braucht so was nicht). Merke: Zeitkritische Aufgaben und Überwachung: hohe Priorität Zeitempfindliche Aufgaben: mittlere Priorität Aufgaben ohne Zeitanforderungen: niedrigste Priorität Watchdog: höchste oder kleinste prio? (Trigger HW Watchdog) z.b. in der Mensa: Eingestellten dürfen überholen : Warum? Nettigkeit zu den Eingestellte? Sparmaßnahme
Prioritäten & Preemtion Erinnerung: Preemption: Wie virtuelles yield(), nicht programmiertes yield() Das OS kann jeden Task zu yield zu fast jeder Zeit erzwingen. Ausnahme: ununterbrechbare Stellen: Atomarität Niedrige Prioritäten Taks müssen unterbrochen werden um Anderen wichtigeren dran zu lassen In der Mensa: Nicht nur meine Position in der Schlange, Auch, ich darf beim Kassiererin mittendrin bei anderen bedient werden, danach macht sie Mit den anderen weiter.
Dynamischer Scheduler: feste Prioritäten Die Priorität der Tasks wird vom Programmierer festgelegt. Von allen Tasks, die auf den Prozessor warten, wird der mit der höchsten Priorität aktiviert Vorsicht: Prioritäten-Inversion mit Semaphoren u.ä. Prioritätsübertragung Bei einer gute Timinganalyse kann verhindert werden, dass mehrere Tasks gleichzeitig die CPU. brauchen. Dann sind die Prioritäten egal. (Dies ist in RODOS)
Dynamische Prioritäten Prioritätsanpassungen Je nach Situation können die Tasks ihre Priorität ändern. System-Phase Reentry Fahrzeuge: Launch, Orbit, Reentry, Landen, Rollen (Taxiing). Solar Sail: Sail Deployment, Segeln, Mission Andockingfahrzeug: Passiver Orbit, Andocking, Trennung,... Flugzeug: Start, Cruise, Landung,... Kampf-Flugzeug: Start, Air-to-Air Combat, Air-Boden-Combat,... System-Zustand: Ausnahme: Flug zu tief >> Priorität: Höhenregelung, Pull-Up, Ausnahme: Temperatur kritisch >> Priorität: Temperaturregelung (RODOS erlaubt es, ich habe es aber noch nie gebraucht.) z.b. Mitarbeiter die späht an Projekt sind, sollen mehr arbeite, in dieser Zeit Haben Sie vorfahrt in der Mensa.
Dynamische Prioritäten Prioritätsvererbung Wenn ein Task A einen Service von einem Task B braucht (Remote Procedure Call) und A wird blockiert, bis B antwortet, dann soll B mindestens dieselbe Priorität wie A haben, wenn nicht, dann soll B die Priorität von A erben, bis der Service beendet Ist. Prioritätsübertragung Wenn ein Task A Ressourcen blockiert, die Task B braucht, und B eine höhere Priorität als A besitzt, dann soll B seine Priorität an A übertragen, bis die Ressourcen freigegeben worden sind. Prioritäts-Ceiling Um gemeinsame Daten sicher zugreifen zu können oder für thread Atomarität. Vorsicht mit Multicore! (Auch in RODOS) Beispiel: FIlm-Direktor & Auftrag Film-Direktor & Fahrrad?
Alternativen zum Prioritäten
Dynamischer Scheduler: Rate Monotonic (RM) Die Priorität der Tasks ist umgekehrt proportional zu ihrer Zykluszeit (Periode). : Proportional zu Frequenz. Der Task mit der höchsten Frequenz - mit der kürzesten Zykluszeit - hat die höchste Priorität. Von allen Tasks, die auf den Prozessor warten (ready-queue), wird der mit der kürzesten Periode aktiviert.
Dynamischer Scheduler: Earliest Deadline First (EDF) Die Priorität der Tasks wird dynamisch geändert. Der Task, der als nächstes seine Deadline erreichen muss, hat die höchste Priorität. Von allen Tasks, die auf den Prozessor warten, wird der mit der nächsten Deadline aktiviert.
Scheduling bei nicht RT OS Time-Slices First in First Out Round Robin (mit Time-Slices) Der den am längsten Wartet Der der am meistens CPU benutzt hat muss am längsten warten Shortest Job Next Fair Sharing Highest Response Ratio.. Optimieren: Durchsatz Wartezeit Beendete Tasks etc etc etc + die ganze Qeue Theorie Aber für uns nicht interessant... aber komplexer als RT RT verschwenden viel CPU Ziet (Warten auf den richtigen Zeitpunkt)
Preemption Die preemptiven Betriebssysteme und/oder Laufzeitsysteme können Tasks ohne ihre aktive Beteiligung unterbrechen, um andere fortzusetzen oder zu aktivieren, um eingetroffene Ereignisse (Zeitereignisse oder externe Ereignisse) zu behandeln. Die nicht preemptiven Laufzeitsysteme sind darauf angewiesen, daß jeder Task den Prozessor freiwillig freigibt: yield(), suspend(), suspenduntil(time), semaphore.enter() Die preemptiven Systeme sind aufwendiger zu implementieren, (CPU-abhängige Register retten & laden, Context-Switch, getriggert von Interrupts) ++ unkooperative Tasks können andere Tasks nicht blockieren. ++ Schnellere Reaktion auf Ereignisse (Zeit und externe) - - Undeterminismus und Laufzeit der Tasks - - Benötigt semaphoren oder Atomarität für gemeinsame Daten (sogar cnt++) - - Komplett-Test ist nicht möglich (alles kann zwischendurch passieren) Reihenfolge der Outputs kann variieren, z.b. mit 5 nicht-preemptiven Tasks hat man 120 mögliche Permutationen für die Outputs. Mit 5 preemptiven Tasks hat man vielleicht einige Millionen von richtigen Permutationen für die Outputs + Timing-Verhalten.
Preemption Nicht Preemtive: Nicht alle OS sind Preemptive Sie können Tasks nicht mittendrin suspendieren und reaktivieren die Tasks müssen die CPU freiwillig freigeben yield(), wait(), semaphore.enter()... kooperative Tasks Preemption: Wie virtuelles yield(), nicht programmiertes yield() Das OS kann jeden Task zu yield zu fast jeder Zeit erzwingen. Ausnahme: ununterbrechbare Stellen: Atomarität Vorsicht: Konsistänz- Racing- Kritische Bereiche - Probleme wozu denn??
Preemption & Sicherheit Für sicherheitsrelevante eingebettete Systeme lieber nicht Preemptive. (Siehe Time Space Partioning) Aus demselben Grund wird davon abgeraten, mit externen Interrupts zu arbeiten. Ein Interrupt soll nur zugelassen werden, wenn es eine gefährliche Ausnahme signalisiert, sonst lieber periodisch polling. Aber: Ein Task kann nur von einem mit höherer Priorität verdrängt werden. Eine vorsichtige Prioritätsvergabe kann Sicherheit bringen. Bei nicht RT-OS: Taks mit selbem Priorität bekommen Zeitscheiben. Niedrigen Prioritäten auch, aber seltener als die hoch priorisierten... (RODOS benutzt Preemption mit Prioritäten und Timinganalysen.)
Atomarität... Bei Multitasking, Multi Threading, Preemption und für Interrupts: z.b. a = 0; 2x Threads: for(int i = 0; i < 1000000; i++) { a++; } Siehe Beispiel Schutz von gemeinsamen Daten Interrupt locks Atomar Scheduling lock Thread Atomar (nicht für interrupts) Priority Ceiling (nicht für interrupts) Semaphoren/Mutex (nicht für Interrupts) Aber: Vorsicht mit Multicore CPUs! hier funktionieren Semaphore/Mutex, aber es gibt keine Atomarität
Analysen Für statisches Scheduling und für manche schlauen dynamischen Scheduler muss man die Ausführungszeit der Tasks kennen. Zeitempfindliche Tasks: Mittlere Ausführungszeit: Messungen Zeitkritische Tasks: Worst-Case (höchstmögliche) Ausführungszeit: Simulation & komplexe Analyse: Prozessor, Caches, Pipelines (goto), Speicher, etc... (sehr aufwendig) if() { } else { } while() { } new / delete? Ausführungszeit? Schleifenlänge? if oder else?, busy waiting? waiting auf IO? virtueller Speicher? Task ausgeswapt? Alles dies verbieten? Schleifen nur mit bekannten Längen?
Analysen Caches: Gut für mittlere Laufzeit, schlecht für Worst Case (lieber kein Cache?) Pipeline: Worst Case geht von leerer Pipeline aus -> schlechtes Bild von CPU Änderung der Befehlsequenz große Änderung der Leistung OS Overhead, Thread/Task wechseln MMU Rekonfiguration Lösung: Komplexe (sehr schwierige & teure) reale Modelle der Hardware.
Analysen Realität: Selten macht man eine Timinganalyse, höchstens Messungen (mittlere Ausführungszeit). Die Analyse wird nur bei der Entwicklung gemacht, der Scheduler benutzt sie nicht.
Siehe Stack /home/sem40wk/sergio/folien-samlung/cpp/010-cpp-b.odp ab folie 25