Vorlesung Echtzeitsysteme - Thema 4: Ressourcenverwaltungrobge/ezs/vl/ezs-04-ress.pdf · Thema 4:...

Post on 19-Jun-2020

1 views 0 download

Transcript of Vorlesung Echtzeitsysteme - Thema 4: Ressourcenverwaltungrobge/ezs/vl/ezs-04-ress.pdf · Thema 4:...

Vorlesung EchtzeitsystemeThema 4: Ressourcenverwaltung

Robert Baumgartl

10. Juni 2020

1 / 45

Motivation

Bisherige Voraussetzung für Scheduling: Tasks wechselwirkennicht miteinander ; meist unrealistisch!Beispiele für Wechselwirkungen:I Kooperation: mehrere Tasks arbeiten gemeinsam an

einer Aufgabe:I SynchronisationI Kommunikation

I Konkurrenz um exklusiv nutzbare Betriebsmittel, d.h., zueinem beliebigen Zeitpunkt darf maximal 1 Task auf dieseBetriebsmittel zugreifen; Zugriffsoperation bildet einensogenannten kritischen Abschnitt (critical section)

2 / 45

Wechselseitiger Ausschluss

Beim Zugriff auf exklusiv nutzbare Betriebsmittel muß einwechselseitiger Ausschluß der Tasks garantiert werden, derZugriffskonflikte steuert. Eine Realisierungsform ist:

1. Anforderung der Ressource (Operation blockiert, fallsRessource belegt)

2. Nutzung der Ressource3. Freigabe der Ressource

Schritte 1. und 3. sind Dienste des Betriebssystems oder einerBibliothek.Problem für Echtzeitsysteme: Dauer der Blockierung

3 / 45

Prioritätsumkehrung (Priority Inversion)Beispiel

I 3 Jobs Ji(tr ,i , te,i , td ,i) mitJ1 = (6,5,14) J2 = (2,7,17) J3 = (0,6,18),

I Planung nach EDF,I Jeder der Jobs benötigt Zugriff auf ein und dieselbe

exklusiv nutzbare Ressource R: J1 zu t=8 für 2Zeiteinheiten, J2 zu t=4 für 4 Zeiteinheiten und J3 zu t=1für 4 Zeiteinheiten.

4 / 45

Beispiel für Prioritätsumkehrung (Priority Inversion)Ablauf

t=0 Nur J3 ist bereit, wird abgearbeitett=1 Zugriff auf R ; erlaubt, J3 arbeitet weiter (mit dieser Ressource)t=2 J2 wird bereit, unterbricht J3, da höhere Prioritätt=4 J2 versucht auf R zuzugreifen; dieses ist jedoch im Besitz von J3

⇒ J2 wird blockiert, J3 weiter abgearbeitett=6 J1 wird bereit, verdrängt J3

t=8 J1 versucht, auf R zuzugreifen, welche immer noch durch J3

gehalten wird, ; J1 blockiert, J3 abgearbeitett=9 J3 gibt R frei, R wird dem höchstpriorisierten anfordernden Job J1

zugeteilt, dieser wird abgearbeitett=11 J1 gibt R frei, arbeitet weiter, da höchste Prioritätt=12 J1 beendet ; J2 erhält R und arbeitet weitert=16 J2 gibt R frei, arbeitet weiter, da höchste Prioritätt=17 J2 beendet, J3 arbeitet weitert=18 J3 beendet.

5 / 45

Beispiel für Prioritätsumkehrung (Priority Inversion)Resultierender Plan

1J

J 2

J 3

0 2 4 6 8 10 12 14 16 18 t

Abbildung: Beeinflussung von Jobs durch Ressourcenkonflikte

Eine niedrigpriorisierte Task blockiert eine höherpriorisierteTask. Diese Phänomen wird Prioritätsumkehrung (priorityinversion) genannt (hier in den Intervallen [4,6] und [8,9]).

6 / 45

Prioritätsumkehrung (Priority Inversion)Anomalien

Konkurrenz um exklusive Ressourcen kann Anomalien imZeitverhalten bewirken.

Beispiel: Jobmenge aus dem vorangegangenen Beispiel.Modifikation: J3 benötigt die Ressource R anstatt für 4 nur noch für2.6 Zeiteinheiten (zu t=1).

1J

J 2

J 3

0 2 4 6 8 10 12 14 16 18 t

verletzt!

Deadline

Abbildung: Verkürzung des kritischen Abschnitts von J3 führt zurVerlängerung der Komplettierungszeit (und zur Verletzung derDeadline) von J1!

7 / 45

Ungesteuerte Prioritätsumkehrung

1J

J 2

J 3

0 2 4 6 8 10 12 14 16 18 t

...

Abbildung: Beispiel für ungesteuerte Prioritätsumkehrung

J2 kann J3 (und damit J1) verzögern. Schlimmer: alle Jobs Ji ,mit π(Ji) > π(J3) können den höchstpriorisierten Job J1blockieren.

8 / 45

Fazit

⇒ Strategien zur Zuteilung exklusiv nutzbarer Ressourcennotwendig.Zielstellung:I Verhinderung/Beschränkung von PrioritätsumkehrungI Minimierung der BlockierungszeitenI Verhinderung von Deadlocks

9 / 45

Nichtunterbrechbare kritische AbschnitteDirekte Blockierung

Definition: Ein Job Ji wird direkt blockiert durch einen niedrigerpriorisierten Job Jk , wenn Ji eine exklusive Ressource(vergeblich) anfordert, die Jk besitzt.

Anmerkungen:I Verdrängung (preemption) infolge zu niedriger Priorität ist

keine Blockierung (→ niedrigstpriorisierter Job kann nichtblockieren)

I bei komplexeren Protokollen weitere Varianten derBlockierung möglich (z. B. indirekte)

I Zeitspanne, die ein Job Ji an einer Ressource R blockiert,ist Blockierungszeit tb,i(R).

I Dauer des Zugriffs eines Jobs Ji auf eine Ressource R istta,i(R) (access time).

10 / 45

Nichtunterbrechbare kritische Abschnitte (NPCS)Algorithmus

Algorithmus: Ein Job, der auf eine exklusive Ressourcezugreift, wird nicht unterbrochen (z.B., indem er temporär diemaximale Priorität erhält).

Beispiel: 3 Jobs Ji(tr ,i , te,i , td ,i) π1 > π2 > π3J1 = (6,5,14) J2 = (2,7,17) J3 = (0,6,18),

1J

J 2

J 3

0 2 4 6 8 10 12 14 16 18 t

11 / 45

Nichtunterbrechbare kritische Abschnitte (NPCS)Analyse

I leicht zu implementieren

I ungesteuerte Prioritätsumkehrung unmöglich; maximaleBlockierungszeit durch Warten auf Ressource ist beschränkt:

tb,i (R) ≤ maxi+1≤k≤n

ta,k (R) ,

wenn Jobs nach absteigender Priorität geordnet sind.

I maximal mögliche Blockierungszeit ist die Dauer des größtenkritischen Abschnittes, der von Prozessen geringerer Prioritätdurchlaufen wird

I im Beispiel gilt: tb,3 = 0, tb,2 ≤ 4, tb,1 ≤ 4

I Nachteil: Jeder Job kann potentiell durch einen niedrigerpriorisierten Job blockiert werden, selbst wenn gar keinRessourcenkonflikt zwischen beiden vorliegt!

I sehr grober Eingriff in Priorisierungsschema, hochpriorisierteJobs benachteiligt

12 / 45

Prioritätsvererbung (Priority Inheritance)Prinzip

Idee: Wird ein Job infolge Ressourcenkonflikt blockiert, so vererbt er(temporär) seine Priorität an den Blockierer, damit dieser schnellerkomplettiert und die Ressource freigibt.

Algorithmus: (für konstante Prioritäten, z. B. RMS)

1. Zu t = tr ,i erhält ein Job Ji die aktuelle Priorität πi (t), die seinerzugeordneten Priorität entspricht. Diese bleibt konstant, außerwenn er eine höhere Priorität erbt bzw. verliert. (vgl. 4.).

2. Jeder Job Ji wird präemptiv entsprechend seiner aktuellenPriorität πi (t) geschedult.

3. Wenn ein Job Ji eine exklusive Ressource R anfordert, so istdiese entwederI belegt durch einen anderen Job Jk . Ji wird blockiert, Jk erbt

die Priorität von Ji , wie unter 4. beschrieben.I frei. Ji erhält R zugeteilt.

4. Wenn Ji blockiert wird, erbt der blockierende Job Jk die Prioritätπi (t). Sie sinkt auf das Niveau des Zeitpunktes, zu dem er dieRessource zugeteilt erhielt, wenn er R wieder freigibt.

13 / 45

Prioritätsvererbung (Priority Inheritance)Beispiel 1

3 Jobs Ji(tr ,i , te,i , td ,i) π1 > π2 > π3J1 = (6,5,14) J2 = (2,7,17) J3 = (0,6,18)

1J

J 2

J 3

0 2 4 6 8 10 12 14 16 18 t

3 3

2

2

1

1

11

2 2

3

Abbildung: Resultierender Schedule (aktuelle Prioritäten πi sind inden Fortschrittsbalken vermerkt)

14 / 45

Prioritätsvererbung (Priority Inheritance)Beispiel 2

5 Jobs, π1 > π2 > π3 > π4 > π5

2 exklusive Ressourcen: schwarz, grau

Ji tr ,i te,i krit. Abschnitte1

J1 7 3 [grau, 1, t=1]

J2 5 3 [schwarz, 1, t=1]

J3 4 2 –

J4 2 6 [grau, 4, t=1], [schwarz, 1.4, t=3]

J5 0 6 [schwarz, 4, t=1]

Tabelle: Jobparameter für Beispiel 2

1Notation des k. A.: [Ressource, Zugriffsdauer, Zugriffszeitpunkt innerhalb des Jobs]15 / 45

Prioritätsvererbung (Priority Inheritance)Beispiel 2 – Resultierender Plan

1J

J 2

J 3

J 4

J 5

0 2 4 6 8 10 12 14 16 18 20 t

16 / 45

Prioritätsvererbung (Priority Inheritance)Eigenschaften

I Mechanismus ist transitiv (im Beispiel Intervall [9,11] – J5 erbtdie Priorität von J4, welches seine aktuelle Priorität zu t=8 von J1geerbt hat)

I kein Ausschluß von Deadlocks (z. B., wenn J5 zu t=6 dieRessource grau fordern würde)

I 2 Arten Blockierung unterscheidbar:

a) direkte Blockierung zwischen um Ressourcenkonkurrierenden Jobs (z. B. J4 blockiert J1 zu t=8)

b) indirekte Blockierung ohne Ressourcenkonflikt als Folgeder Prioritätsanhebung (z. B. J3 wird durch J5 zu t=6blockiert)

I Blockierungszeit wird nicht minimiert (ohne Beweis).

Verbesserung: kürzere Blockierungszeiten, Ausschluß vonDeadlocks ; Verfahren mit Prioritätsobergrenze

17 / 45

Prioritätsobergrenze (Priority Ceiling)Voraussetzungen

Annahmen:

1. Zugeordnete Prioritäten der Jobs sind konstant.

2. Vor dem Systemstart ist bekannt, welche (exklusiven)Ressourcen jeder Job fordert (Zeitpunkte unbekannt).

(Neue) Parameter:I Aktuelle Priorität eines Jobs Ji zum Zeitpunkt t wird πi (t)

bezeichnet.I Die Prioritätsobergrenze Π(Ri ) einer Ressource Ri ist das

Maximum der Prioritäten aller Jobs, die diese Ressource(irgendwann) anfordern (a priori ermittelt).

I Die aktuelle Prioritätsobergrenze2 Π(t) des Systems zu einemZeitpunkt t ist das Maximum der Prioritätsobergrenzen allerRessourcen, die momentan zugeteilt sind.

I wenn keine Ressourcen zugeteilt, dann Π(t) = Ω, einnichtexistierender, niedrigster Level

2kurz: die Obergrenze18 / 45

Prioritätsobergrenze (Priority Ceiling)Basic Priority Ceiling Protocol3 (PCP)

1. Zu t = tr,i erhält ein Job Ji die aktuelle Priorität πi (t), die seiner zugeordnetenPriorität entspricht. Diese bleibt konstant, außer wenn er eine höhere Prioritäterbt oder verliert (vgl. 4.)

2. Jeder Job Ji wird präemptiv entsprechend seiner aktuellen Priorität πi (t)geschedult.

3. Wenn ein Job Ji eine exklusive Ressource R anfordert, so ist diese entwederI belegt durch einen anderen Job Jk . Ji wird blockiert, Jk erbt die Priorität

von Ji , wie unter 4. beschrieben.I frei. Fallunterscheidung:

• πi (t) > Π(t), d.h., die aktuelle Priorität πi (t) von Job Ji ist größer alsdie Obergrenze des Systems Π(t), so erhält Ji die Ressourcezugewiesen.

• πi (t) ≤ Π(t), dann erhält Ji nur dann die Ressource R zugeteilt,wenn Ji selbst die Ressource besitzt, deren Prioritätsobergrenzegleich Π(t) ist. Anderenfalls wird Ji blockiert.

4. Wenn Ji blockiert wird, erbt der blockierende Job Jk die Priorität πi (t). Sie sinktauf das Niveau des Zeitpunktes, zu dem er die Ressource zugeteilt erhielt, wenner R wieder freigibt.

3Lui Sha, Ragunathan Rajkumar und John P. Lehoczky. “Priority Inheritance Protocols: An Approach toReal-Time Synchronization”. In: IEEE Transactions on Computers 39.9 (Sep. 1990), S. 1175–1185.

19 / 45

Basic Priority Ceiling Protocol (PCP)Beispiel (Jobmenge aus Beispiel 2 der Prioritätsvererbung)

Ω

5

4

3

2

1

1J

J 2

J 3

J 4

J 5

(t)Π

0 2 4 6 8 10 12 14 16 18 20 t

20 / 45

Basic Priority Ceiling Protocol (PCP)Vergleich mit Prioritätsvererbung

Vergleich der Komplettierungszeiten:

Prioritätsvererbung PCPJi tc,i tc,iJ1 15 10J2 17 13J3 18 14J4 19 19J5 20 20

Das Verfahren der Prioritätsobergrenze reduziert dieKomplettierungszeiten hochpriorisierter Jobs auf Kostenniedrigpriorisierter Jobs.

Prioritätsvererbung teilt freie Ressource immer zu,Prioritätsobergrenze nicht!⇒ Prioritätsvererbung ist gierig (greedy).

21 / 45

Basic Priority Ceiling Protocol (PCP)3 Formen der Blockierung

a) direkte Blockierung: ein Job, der eine Ressource beansprucht,wird durch einen niederprioren Job, der diese Ressource besitzt,blockiert.

b) indirekte Blockierung: Ein Job wird blockiert, weil ein (eigentlich)niederpriorer Job momentan eine höhere Priorität „ererbt“ hat.

c) Blockierung durch Priority Ceiling (avoidance blocking): Ein JobJi wird blockiert, da er auf eine freie Ressource R zugreifenmöchte. Ein anderer Job besitzt eine (andere) Ressource S,deren Prioritätsobergrenze Π(S) höher ist als die aktuellePriorität πi (t) von Ji .

Form c) der Blockierung ist der Preis, der für die Vermeidung vonDeadlocks zu entrichten ist!

Satz: Wenn die Ressourcen eines Systems nach dem Verfahren derPrioritätsobergrenze zugeteilt werden, so sind Deadlocksausgeschlossen (ohne Beweis).

22 / 45

Stack-based Priority Ceiling ProtocolAlgorithmus

Baker4 formuliert eine einfachere Variante des Protokolls:1. Die Obergrenze Π(t) des Systems wird jedesmal (nach der

Regel im Basic PCP) aktualisiert, wenn eine Ressourcezugeteilt oder freigegeben wird.

2. Nachdem ein Job Ji bereit wurde, wird er geblockt, bisseine zugeordnete Priorität πi höher ist als Π(t).

3. Wenn ein Job eine Ressource anfordert, so erhält er diese.

4T.P. Baker. “Stack-Based Scheduling of Realtime Processes”. In: Real-Time Systems Journal 3.1 (März 1991),S. 67–99.

23 / 45

Stack-based Priority Ceiling ProtocolBeispiel (Jobmenge aus Beispiel 2 der Prioritätsvererbung)

Ω

5

4

3

2

1

1J

J 2

J 3

J 4

J 5

(t)Π

0 2 4 6 8 10 12 14 16 18 20 t

24 / 45

Stack-based Priority Ceiling ProtocolMerkmale

I einfachere Formulierung des ProtokollsI Wenn ein Job ausgeführt wird, sind die von ihm benötigten

Ressourcen frei und er wird nicht mehr blockiert(höchstens verdrängt).

I Es entsteht ein anderer Schedule als bei Basic PCP.I Die beteiligten Jobs könnten sich einen Stack teilen (Name

des Verfahrens!).I weniger Kontextwechsel als bei Basic PCPI hochpriorisierte Jobs komplettieren eher oder wenigstens

gleichzeitig als bei Basic PCPSatz: Im Worst Case sind die Blockierungszeiten beiStack-Based Priority Ceiling identisch zu denen bei BasicPriority Ceiling.

25 / 45

Ceiling-Priority ProtocolMerkmale

Eine alternative Formulierung des Stack-basedPriority-Ceiling-Protokolls ist das Protokoll Ceiling-Priority5.

Algorithmus:1. Jobs, die keine Ressource besitzen, werden nach ihrer

zugeordneten Priorität geplant.2. Die Priorität eines Jobs, der Ressource(n) besitzt, ergibt

sich aus dem Maximum der Prioritätsobergrenzen allerRessourcen, die er besitzt.

3. Eine Ressourcenanforderung wird stets befriedigt.

5um die Verwirrung zu maximieren26 / 45

Ermittlung der Blockierungszeiten

Definition6 Die Blockierungszeit tb,i eines Jobs Ji ist die Zeit,die Ji durch Zugriff auf eine exklusive Ressource verzögertwird, wenn diese Ressource durch einen niedriger priorisiertenJob gehalten wird.

Die Wartezeit, die infolge Verdrängung durch höher priorisierteJobs entsteht, ist keine Blockierungszeit! (Sie wird auch andersermittelt, vgl. die ratenmonotone Analyse).

Satz: Ein Job kann infolge eines Ressourcenkonfliktes durcheinen niederpriorisierten Job maximal für die Dauer eineskritischen Abschnitts blockiert werden, wenn das Verfahren derPrioritätsobergrenze zum Einsatz kommt.

6zur Wiederholung ,27 / 45

Ermittlung der BlockierungszeitenBeispiel

Es gelte π1 > π2 > π3 > π4 , sowie folgende kritische Abschnitte:

1J

2J

3J

4J

S

T

0.8

10.2

I J1 kann von J4 maximal für 1 Einheit blockiert werden. ; tb,1 = 1

I Obwohl J2 und J3 die Ressource S nicht benötigen, können sievererbungsblockiert (Fall b)) werden durch J4, da J4 die Prioritätvon J1 in dem Fall geerbt hat. ; tb,2 = tb,3 = 1 (!)

I J4 ist schon der niedrigstpriorisierte Job (kann nicht blockiertwerden). ; tb,4 = 0

28 / 45

Ermittlung der BlockierungszeitenBlockierungszeit und ratenmonotone Analyse

Da jeder Job maximal für die Dauer eines kritischen Abschnittesblockiert werden kann, erhöht sich die maximale Antwortzeit jedesJobs um die ermittelte Blockierungszeit.Für eine höchstpriorisierte Task T1 ergibt sich für RMS:

tmaxresp,1 = te,1 + tb,1

Sind alle Tasks nach absteigender Priorität geordnet (höchstePriorität bei T1), so ergibt sich für eine beliebige Task Ti :

tmaxresp,i = te,i + tb,i +i−1∑k=1

tmaxresp,k

Damit kann der Einplanungstest für RMS entsprechend erweitertwerden:

t (l+1) = te,i + tb,i +i−1∑k=1

⌈t (l)

tp,k

⌉· te,k

29 / 45

PCP und Dynamische PrioritätenEDF

EDF:I Jobs haben feste Priorität, Taskpriorität πi variiert

(Neuberechnung, wenn neuer Job Ji bereit wird)I Idee7: Π(Ri) ändert sich mit πi , muss ggf. ebenfalls neu

berechnet werden→ Π(t) muss ebenfalls neu berechnetwerden

I Positive Eigenschaften des Protokolls bleiben erhalten(Minimierung Blockierungszeit, Vermeidung vonDeadlocks)

(Verfahren ist unmöglich bei job-level-dynamic-priority)

7Min-Ih Chen und Kwei-Jay Lin. “Dynamic Priority Ceilings: A Concurrency Control Protocol for Real-TimeSystems”. In: Real-Time Systems 2.4 (Nov. 1990), S. 325–346. DOI: 10.1007/BF0199567.

30 / 45

Dynamische Speicherverwaltung9

Motivation

I Objekte haben häufig kürzere Lebensdauer als Prozess→Verschwendung von Speicherplatz, wenn statisch angelegt

I Verbesserung: zur Laufzeit anlegen, nutzen und wiederfreigeben

I ; klassische malloc()/free()-Schnittstelle derProgrammiersprache und des OS

I Implementierung der Speicherverwaltung basierend aufBitmap, Liste(n) oder als Buddy-Systeme8

8oder Kombinationen davon; vgl. LV Betriebssysteme 29aka Dynamic Storage Allocation (DSA)

31 / 45

Dynamische SpeicherverwaltungAnforderungen

Probleme (aus Echtzeitsicht):1. WCET von malloc() und/oder free() variabel oder schwer

zu ermitteln (Suchoperationen in Listen; O(n) oderO(log n))

2. Es kann passieren, dass Speicher erschöpft.Resultierende AnforderungenI Zeitaufwand für malloc() und free() konstantI geringe interne FragmentierungI geringe externe FragementierungI Zeitaufwand für malloc() und free() gering

32 / 45

Überblick

I relativ junges Teilgebiet der EchtzeitsystemeI Half-Fit10 (Ogasawara, 1995)I Two-Level-Segregated-Fit TLSF11 (Masmano, 2008)I Compact-Fit12 (Craciunas, 2008)

Alternative Ideen:I Echtzeitfähige Garbage Collection?!

10Takeshi Ogasawara. “An Algorithm with Constant Execution Time for Dynamic Storage Allocation”. In:Proceedings of the 2nd International Workshop on Real-Time Computing Systems and Applications (RTCSA’95).Tokyo, Okt. 1995, S. 21–25.

11Miguel Masmano u. a. “A Constant-Time Dynamic Storage Allocator for Real-Time Systems”. In: Real-TimeSystems 40.2 (Nov. 2008), S. 149–179.

12Silviu S. Craciunas u. a. “A Compacting Real-Time Memory Management System”. In: Proceedings of the 2008USENIX Annual Technical Conference. Boston, Juni 2008, S. 349–362.

33 / 45

Half-FitPrinzip

Prinzip: beliebige Segmentgröße, n Listen mit Größenklassen:I Liste mit Index i enthält alle freien Blöcke der Größe aus

dem Intervall [2i ; 2i+1 − 1]I somit sind für 0 ≤ i ≤ 31 Blöckgrößen zwischen 1 Byte

und 4 GiB -1 Byte verwaltbar (i sollte der Wortlänge desProzessors in Bit entsprechen)

I Segmentgröße r , zugehöriger Listenindex i = blog2 rc

34 / 45

Exkurs: Berechnung des dyadischen Logarithmus

Kann man i = blog2 rc effizient berechnen?I entspricht der Nummer des höchstwertigsten gesetzten

Bits von rBeispiel:I r = 9510 = 010111112

I i = blog2 95c = 6I Liste 6 enthält Segmente der Größe

[26 = 64; 27 − 1 = 127]ImplementierungI Intel-Architektur besitzt eigenen Maschinenbefehl: bsr („bit

scan reverse“)→ effizient, konstante Laufzeit: liefertPosition des ersten gesetzen Bits des Operandenbeginnend mit dem MSB

I naive Implementierung in Schleife benötigt maximal 32Iterationen; (obere Laufzeitschranke)

35 / 45

Half-Fitmalloc()

Ablauf von malloc():I Anforderung Größe r wird durch Block aus Liste der

nächstgrößeren Zweierpotenzen bedient (→ jeder Blockpasst; keine Suche nötig)

I Berechnung des Listenindex i :

i =

0, falls r = 1blog2(r − 1)c+ 1, sonst

→ konstante Zeit, O(1)I falls Segment zu groß, wird dieses geteilt und der Rest

wieder eingeordnet (beides in konstanter Zeit)I Wenn kein Block in Liste i vorrätig ist, dann müssen Listen

mit größeren Blocks (i + 1, i + 2, . . . ) betrachtet werden(maximal 32)

36 / 45

Half-Fitfree()

Ablauf von free():I bei Rückgabe eines Blocks wird versucht, diesen mit

seinen 2 Nachbarn zu vereinigen und den Resultatblockeinzuordnen

I Ermittlung Listenindex hat konstante Lz., Einordnung auchI keine Kaskadierung von Vereinigungen wie bei

Buddy-System möglichI Aufsuchen der Nachbarn erfolgt in konstanter Zeit, da die

Blöcke miteinander doppelt verkettet sind

37 / 45

Half-FitFazit

Fazit:1. Laufzeitkomplexität von malloc() und free() ist O(1).2. Nutzung von Bitscan-Maschineninstruktionen13 zur

effizienten Implementierung3. Ungünstig ist das Abschreiten von Listen, wenn diese leer.4. Es kann passieren, dass eine Anforderung fehlschlägt,

obwohl noch passende Segmente existieren (incompletememory usage).

13Die meisten Befehlssätze enthalten ähnliche Instruktionen, vgl.https://en.wikipedia.org/wiki/Find_first_set.

38 / 45

Two-Level-Segregated-Fit (TLSF)Konzept

I „Good-Fit“, d. h., ein vergleichsweise gut passendesSegment wird gesucht (aber nicht das beste)

I zweidimensionale DS zur Verwaltung der Listen1. Blöcke der Größe im Intervall [2i ,2i+1 − 1]2. lineare Unterteilung des Intervalls in 2L Subintervalle

(L ∈ (3 . . . 5))I bei Anforderung eines Segments mit Größe r wird

wiederum die Liste gesucht, deren Elemente die Größe rnicht unterschreiten

I Nutzung von Bitmaps in Wortgröße zum effizientenAufsuchen der passenden Liste

39 / 45

TLSFBeispiel

32 36 40 44 48 52 56

64 72 80 88 96 104 112

128 144 160 176 192 208 224

60

120

27+7*24

freefree

freefree free

216+0*213 216+1*213 216+2*213 216+3*213 216+4*213 216+5*213 216+6*213 216+7*213

. . . . . . . . . . . . .

. . . . . . . . . . . . .

free

free

1 2 3 4 5 6 7

5

6

7

16

231+1*228 231+2*228 231+3*228 231+4*228 231+5*228 231+6*228 231+7*22831

. .

. .

0

231+0*228

01000000

00000100

00000000

00100000

00000000

SL_bitmaps[]

110...1...0FL_bitmap

40 / 45

TLSFErmittlung der Liste für ein Segment mit Größe r

; 2 Indizes für Blockgröße r zu berechnen :

fl = blog2(r)c

und

sl =

⌊(r − 2fl)

2fl−L

⌋=⌊ r

sfl−L

⌋− 2L.

Berechnung hat konstante Laufzeit.

Beispiel: Blockgröße 201 Byte, Array aus vorangegangenemBeispiel

fl = blog2(201)c = 7 sl =

⌊201− 128

27−3

⌋=

⌊7316

⌋= 4

41 / 45

TLSFAblauf von malloc()

I Anforderung Größe r wird durch Block aus Liste bedient,die die kleinsten Elemente ≥ r enthält (→ jeder Blockpasst; keine Suche nötig)

I Berechnung der Listenindizes fl , sl :

fl = log2

(r + 2blog2(r)c−L − 1

)sl =

⌊r + 2blog2(r)c−L − 1− 2fl

2fl−L

I falls Segment zu groß, wird dieses geteilt und der Restwieder eingeordnet (beides in konstanter Zeit)

I Wenn kein Block in Liste i vorrätig ist, dann muss Liste mitnächstgrößeren Blocks betrachtet werden

42 / 45

TLSFWeitere Aspekte

I Suche von Liste mit freien Elementen mittelsBitmap-Operationen

I ähnlich Half-FitI relativ komplexe Datenstruktur zur VerwaltungI „Ist ein allgemeiner DSA-Algorithmus für Echtzeitsysteme

wirklich nötig?“

43 / 45

Zusammenfassung: Verwaltung von Ressourcenaka „Was haben wir gelernt?“

1. Phänomen der (ungesteuerten) Prioritätsumkehrung beiungünstiger Ressourcenzuteilung

2. Naive Lösung: Non-Preemptive Critical Section3. Mechanismus der Prioritätsvererbung4. Protokolle der Prioritätsobergrenze (Basic and

Stack-based Priority Ceiling)5. Bestimmung von Blockierungszeiten und Integration in

RMA6. echtzeitfähige(re) Allokatoren: Half-Fit, TLSF

44 / 45

Weiterführende Literatur

I Silviu S. Craciunas u. a. “A Compacting Real-Time MemoryManagement System”. In: Proceedings of the 2008 USENIXAnnual Technical Conference. Boston, Juni 2008, S. 349–362

I Jörg Herter. “Timing-Predictable Memory Allocation In HardReal-Time Systems”. Diss. Universität des SaarlandesSaarbrücken, März 2014

I Philippe Stellwag, Jakob Krainz undWolfgang Schröder-Preikschat. “A Wait-Free Dynamic StorageAllocator by Adopting the Helping Queue Pattern”. In:Proceedings of Parallel and Distributed Computing andNetworks (PDCN’10). Hrsg. von M. H.Hamza. Innsbruck, Feb.2010. DOI: 10.2316/P.2010.676-052

I David F. Bacon. “Realtime Garbage Collection”. In: ACM Queue5.1 (Feb. 2007), S. 42–49(https://queue.acm.org/detail.cfm?id=1217268)

45 / 45