F¨ur die Analyse wird angenommen, dass der Prozess den Prozessor exklusiv belegt, der Prozessor lediglich eine skalare Funktionseinheit be-sitzt, keine Interrupts unterst¨utzt und kein B
Trang 1434 7 Software-Verifikation
rungsreihenfolge der Instruktionen zu einem bestm¨oglichen bzw schlechtestm¨ogli-chen Zeitverhalten f¨uhrt F¨ur die Analyse wird angenommen, dass der Prozess den Prozessor exklusiv belegt, der Prozessor lediglich eine skalare Funktionseinheit be-sitzt, keine Interrupts unterst¨utzt und kein Betriebssystem auf dem Prozessor aus-gef¨uhrt wird Weiterhin wird angenommen, dass das Programm keine rekursiven Funktionsaufrufe beinhaltet, keine dynamische Speicherallokation durchf¨uhrt und die Schleifen im Programm beschr¨ankt sind bzw beschr¨ankt werden Grundlage f¨ur
die Programmpfadanalyse bildet der Kontrollflussgraph GC = (VC ,E C) eines Prozes-ses Die Knoten in dem Kontrollflussgraphen stellen Berechnungen (Grundbl¨ocke) dar, w¨ahrend Kanten Kontrollflussabh¨angigkeiten darstellen Auf Basis des
Kontroll-flussgraphen eines Prozesses l¨asst sich die engl Worst Case Execution Time (WCET)
formal definieren:
Definition 7.4.1 (WCET) Ein Prozess besteht aus n Grundbl¨ocken, wobei jeder
Grundblock bi eine Ausf¨uhrungszeitδi hat und maximal xi mal ausgef¨uhrt wird Dann ist die WCET
Somit besteht die Aufgabe der Programmpfadanalyse darin, herauszufinden, wie oft jeder Grundblock auf einem Pfad, der zu einer maximal langen Ausf¨uhrungs-zeit geh¨ort, ausgef¨uhrt wird Die Bestimmung der BCET kann analog formuliert werden: Wie oft wird jeder Grundblock auf einem Pfad, der zu einer minimalen Ausf¨uhrungszeit geh¨ort, ausgef¨uhrt Aufgrund dieser Analogie wird im Folgenden lediglich das WCET-Problem weiter betrachtet Die zentrale Herausforderung bei der Programmpfadanalyse besteht allerdings darin, dass die Anzahl der m¨oglichen Ausf¨uhrungspfade exponentiell anw¨achst
Ohne weitere Beschr¨ankungen w¨urde Gleichung (7.6) beliebig anwachsen, d h
δmax→ ∞ Aus diesem Grund wird die Anzahl der Ausf¨uhrungen x i eines
Basis-blocks Bibeschr¨ankt Dabei werden zwei Arten von Beschr¨ankungen unterschieden:
1 Strukturelle Beschr¨ankungen ergeben sich aus der Struktur des
Kontrollflussgra-phen
2 Funktionale Beschr¨ankungen ergeben sich aus der Spezifikation des Prozesses Strukturelle Beschr¨ankungen werden auch als Flussbeschr¨ankungen bezeichnet Sie
besagen, dass jedes Mal, wenn der Kontrollfluss einen Grundblock erreicht, der Kon-trollfluss diesen Grundblock auch wieder verlassen muss
Sei d : EC → Z ≥0eine Funktion, die jeder Kante e ∈ E C im Kontrollflussgraph GC
einen Wert zuweist, der anzeigt, wie oft der Kontrollfluss w¨ahrend einer Ausf¨uhrung
¨uber diese Kante gegangen ist Sei weiterhin in(v) := {e | e = (˜v,v) ∈ EC } die Menge eingehender Kanten in den Kontrollflussknoten v ∈ V Cund out(v) := {e | e = (v, ˜v) ∈
EC } die Menge ausgehender Kanten Dann sieht die strukturelle Beschr¨ankung f¨ur Knoten vi ∈ V C der den Grundblock birepr¨asentiert wie folgt aus:
∑
e ∈in(v)
d(e j) = ∑
e ∈out(v)
Trang 27.4 Zeitanalyse 435
Beispiel 7.4.1 Gegeben ist das Programm in Abb 7.29a) mit dem in Abb 7.29b)
dargestellten Kontrollflussgraphen Die Flussgleichungen ergeben sich zu:
x1= d1= d2
x2= d2+ d8= d3+ d9
x3= d3= d4+ d5
x4= d4= d6
x5= d5= d7
x6= d6+ d7= d8
x7= d9= d10
3 2 1
9
11 b7
b6
b4 b5
b3
b2
b1
1
2
3 if (ok)
else {
j++;
j=0;
ok=true;
}
k++;
}
r=j;
4
5
6
7
8
9
10
11
s = k;
a) C-Programm
while (k<10) {
b) CFG:
d1
d2
d3
d8
d9
d10
Abb 7.29 a) Programm und b) Kontrollflussgraph
Obwohl der L¨osungsraum durch die Verwendung struktureller Beschr¨ankungen eingeschr¨ankt ist, k¨onnen immer noch unendliche große Ausf¨uhrungszeiten ent-stehen Durch die Verwendung funktionaler Beschr¨ankungen wird dies verhindert Funktionale Beschr¨ankungen ergeben sich aus der Spezifikation des Systems oder aus einer Programmanalyse Funktionale Beschr¨ankungen begrenzen somit die An-zahl an Schleifendurchl¨aufen
Beispiele f¨ur das Programm aus Abb 7.29 sind:
Trang 3436 7 Software-Verifikation
• Die while-Schleife wird maximal zehnmal durchlaufen: x3≤ 10 · x1
• Der Grundblock b5wird maximal einmal durchlaufen: x5≤ 1.
Durch funktionale Beschr¨ankungen werden unzul¨assige Ausf¨uhrungspfade aus der Betrachtung bei der Ermittlung der WCET herausgenommen
Mit Hilfe von strukturellen und funktionalen Beschr¨ankungen l¨asst sich die
WCET-Analyse als ganzzahliges lineares Programm (engl Integer Linear Program, ILP) formulieren:
δmax:= max ∑n
i:=1δi · x i | Bstruct∧ Bfunc
(
(7.8)
Dabei bezeichnet Bfunc die funktionalen Beschr¨ankungen Die strukturellen Be-schr¨ankungenBstructlauten wie folgt:
(d1= 1) ∧
n
i:=1
⎛
e j ∈in(v i)
d (e j) = ∑
e k ∈out(v i)
d (ek) = xi
⎞
⎠
Modellierung der Zielarchitektur
Der verwendete Prozessor, aber auch der Zustand in dem sich ein Prozessor bei der Prozessausf¨uhrung befindet, hat großen Einfluss auf die Ausf¨uhrungszeit ei-nes Grundblocks und somit des Prozesses Um diese Einfl¨usse ber¨ucksichtigen zu k¨onnen, ist es notwendig, eine Modellierung der Zielarchitektur vorzunehmen, und auf Basis dieser Modelle die Absch¨atzung f¨ur eine gegebene Mikroarchitektur durch-zuf¨uhren Besondere Schwierigkeiten werden dabei durch dynamische Effekte der Fließbandverarbeitung und der Caches, sowie durch Optimierungen der Compiler verursacht
Um die Ausf¨uhrungszeit eines einzelnen Grundblocks oder einer Sequenz von Grundbl¨ocken zu sch¨atzen, gibt es prinzipiell zwei M¨oglichkeiten:
1 ITA: (engl Instruction Timing Addition) ist eine Methode ¨ahnlich der statischen
Zeitanalyse von kombinatorischen Schaltungen (siehe Abschnitt 6.5) Dabei wird angenommen, dass jede Instruktion eine konstante Ausf¨uhrungszeit besitzt Durch Summation aller Instruktionen in einem Grundblock erh¨alt man somit die Ausf¨uhrungszeit f¨ur den gesamten Grundblock
2 PSS: (engl Path Segment Simulation) basiert auf der zyklenakkuraten
Simulati-on eines Basisblocks, wobei die zugrundeliegende Mikroarchitektur sehr genau modelliert werden kann
Um den Einfluss von Compiler-Optimierungen m¨oglichst klein zu halten, erfolgt die Zeitsch¨atzung auf compilierten Programmen
Die wesentlichen Architekturmerkmale bei der Modellierung der Zielarchitektur sind [154]:
Trang 47.4 Zeitanalyse 437
• Datenabh¨angige Ausf¨uhrungszeiten der Instruktionen: Datenabh¨angige Ausf¨uh-rungszeiten treten ¨uberwiegend in CISC-Architekturen (engl Complex Instruc-tion Set Computer) auf Aber auch Prozessoren, die manche InstrukInstruc-tionen als
Software-Funktionen realisieren, sind von diesem Aspekt betroffen Da die Aus-f¨uhrungszeit einer Instruktion in diesem Fall von den Operanden abh¨angt, ist auch die Ausf¨uhrungszeit des Grundblocks von den Eingabedaten abh¨angig W¨ahrend die ITA-Methode unterschiedliche Ausf¨uhrungszeiten einer Instruktion unterst¨utzen kann, ist dies in der PSS-Methode aufwendiger
• Fließbandverarbeitung: Die ITA-Methode kann Zeiteffekte durch die
verschr¨ank-te Ausf¨uhrung von Instruktionen nicht ber¨ucksichtigen Im Gegensatz dazu un-terst¨utzen die meisten PSS-Methoden die Modellierung von Pipelines (Fließ-bandverarbeitung) Problematisch ist allerdings, wenn die Pipeline-Tiefe so groß ist, dass selbst Grundbl¨ocke ¨uberlappend ausgef¨uhrt werden k¨onnen Dies ist ty-pischerweise bei nahezu allen aktuellen Prozessoren der Fall Aus diesem Grund sollte die PSS-Methode nicht lediglich auf Grundbl¨ocke, sondern auf l¨angere Pfadsegmente angewendet werden Dabei gilt: Je l¨anger das Pfadsegment, desto akkurater ist das Ergebnis
• Superskalare Architekturen: Bei superskalaren Mikroarchitekturen k¨onnen
meh-rere Grundbl¨ocke parallel berechnet und Instruktionen dynamisch geplant den Die Analyse basierend auf der ITA-Methode kann hier nicht eingesetzt wer-den Die Genauigkeit beim Einsatz der PSS-Methode h¨angt wiederum von der Pfadl¨ange ab
• Instruktionscaches: Bei Verwendung eines Instruktionscaches werden die In-struktionen eines Grundblocks bi auf li Cachezeilen abgebildet Jede
Cachezei-le f¨uhrt dann abh¨angig von der Cachearchitektur und der Verdr¨angungsstrategie entweder zu einem Cache-Hit oder einem Cache-Miss: Als Erweiterung des ILP aus Gleichung (7.8) kann dies wie folgt modelliert werden:
∀i : ∀1 ≤ j ≤ l i : xi = xi , j = x hit
i , j + x miss
Seiδhit
i , j die Ausf¨uhrungszeit einer Instruktion im Falle, dass ein Cache-Hit
vor-liegt, undδmiss
i , j die Ausf¨uhrungszeit, falls ein Cache-Miss auftritt Dann l¨asst sich
die Kostenfunktion des ILP wie folgt ¨andern:
δmax:= max ∑n
i:=1
l i
∑
j:=1
$
δhit
i , j · x hit
i , j+δmiss
i , j · x miss
i , j
%(
(7.10)
Aufgrund einer Konfliktanalyse k¨onnen Beschr¨ankungen f¨ur das Cache-Modell aufgestellt werden In Gegenwart von Instruktionscaches macht lediglich der Einsatz der PSS-Methode Sinn Bei der Verwendung der ITA-Methode m¨ussten Cache-Hits und Cache-Misses anderweitig ermittelt werden
• Datencaches: Bei der Verwendung von Datencaches hat die Zugriffsreihenfolge
auf Daten einen großen Einfluss auf die Ausf¨uhrungszeit einzelner Instruktionen und somit des Grundblocks Wie im Fall des Instruktionscaches ist die Anwen-dung der PSS-Methode sinnvoll
Trang 5438 7 Software-Verifikation
Somit ist die ITA-Methode lediglich f¨ur sehr einfache Mikroarchitekturen anwend-bar, w¨ahrend die PSS-Methode f¨ur komplexe Architekturen anwendbar ist, solange keine datenabh¨angigen Ausf¨uhrungszeiten zu ber¨ucksichtigen sind Typische Pro-zessoren kombinieren heutzutage viele dieser Architekturmerkmale, was die WCET-Analyse f¨ur moderne Prozessoren erschwert
7.4.2 Echtzeitanalyse f ¨ur Einprozessorsysteme
Auf Modulebene werden mehrere Software-Prozesse auf einem einzelnen Prozessor ausgef¨uhrt Um eventuelle Ressourcenkonflikte aufzul¨osen, muss eine Ablaufpla-nung der Prozesse vorgenommen werden Diese AblaufplaAblaufpla-nung kann statisch oder dynamisch erfolgen, wobei letzteres Vorgehen heutzutage ¨uberwiegt Dies gilt ins-besondere f¨ur Echtzeitsystemen Dies sind Systeme, bei denen die Antwortzeiten
durch sog engl Deadlines vorgegeben und garantiert werden m¨ussen Die
vorge-gebenen Deadlines stellen dabei nichtfunktionale Anforderungen an die Implemen-tierung dar Die Zeitanalyse solcher Echtzeitsysteme muss also in der Lage sein, zu bewerten, ob die vorgegebenen Deadlines unter allen Bedingungen eingehalten wer-den Im Folgenden werden Probleme und Analyseverfahren als Zusammenfassung aus [426] vorgestellt
Betrachtet wird im Folgenden das Modell eines Problemgraphen G (V,E) Die Knoten v ∈V modellieren Software-Prozesse, denen fr¨uheste Startzeitpunkte (Relea-sezeiten, Ankunftszeiten) und sp¨ateste Endzeitpunkte (Deadlines) zugewiesen wur-den Kanten e ∈ E entsprechen Datenabh¨angigkeiten Falls nicht anders bemerkt
gel-te, dass allen Prozessen die Ankunftszeit 0 und die Deadline∞ zugewiesen wurde.
Ferner gilt die Ressourcenbeschr¨ankung mit der vereinfachten Eigenschaft, dass
je-der Knoten v ∈ V auf dem einen verf¨ugbaren Prozessor abgearbeitet werden kann
und die Ausf¨uhrungszeitδi eines Knotens vi ∈ V als bekannt gilt, z B durch
Annah-me der WCET
Im Allgemeinen ben¨otigt der Algorithmus zur Ablaufplanung auf einem Prozes-sor selbst Rechenzeit, um festzulegen, welcher Prozess als n¨achstes den ProzesProzes-sor
belegen soll Diese Zeitspanne bezeichnet man im Allgemeinen als Dispatchlatenz.
Definition 7.4.2 (Dispatchlatenz) Die DispatchlatenzΛDbezeichnet die
maxima-le Zeitspanne zwischen dem Stoppen eines Prozesses vi ∈ V und dem Starten des n¨achsten Prozesses v j ∈ V auf dem Prozessor.
Offensichtlich sollte die Dispatchlatenz so klein wie m¨oglich sein Im Folgenden gelte die Annahme, dass die Dispatchlatenz null sei F¨ur die Latenz eines Ablauf-plans gelte die gleiche Definition wie f¨ur statische Ablaufplanungsverfahren (siehe Definitionen 6.5.3 auf Seite 349 bzw Gleichung (6.25) auf Seite 349)
Folgende Kriterien bei der Bewertung von Algorithmen zur dynamischen Ab-laufplanung zeigen sich als n¨utzlich:
Definition 7.4.3 (Ressourcenauslastung) Gegeben sei ein Problemgraph G (V,E) und ein Ablaufplan auf einem Prozessor der LatenzΛ Sei δi die Ausf¨uhrungszeit von Knoten vi ∈ V Dann bezeichnet
Trang 67.4 Zeitanalyse 439
U :=∑|
V | i:=1δi
die Ressourcenauslastung des Prozessors in Prozent.
Offensichtlich ist man bestrebt, die Ressourcenauslastung m¨oglichst bei 100%
zu halten Im Falle pr¨aemptiver Ablaufplanung kann die Ausf¨uhrung eines Prozes-ses unterbrochen werden, um zu einem sp¨ateren Zeitpunkt wieder aufgenommen zu werden F¨ur solche Verfahren ist es deshalb interessant, wie lange es dauert, bis ein Prozess endg¨ultig abgearbeitet ist
Definition 7.4.4 (Abarbeitungszeit) Gegeben sei ein Problemgraph G (V,E) Seiδi die Ausf¨uhrungszeit von Knoten vi ∈ V,τb(vi) der Zeitpunkt, an dem vi zum ersten Mal den Prozessor belegt, undτe(vi) der Zeitpunkt, an dem vi vollst¨andig abgear-beitet ist (Endzeitpunkt) Dann betr¨agt die AbarbeitungszeitδA(vi) von vi ∈ V:
δA(vi) :=τe(vi) −τb(vi) (7.12)
Im Weiteren definiert man die sog Wartezeit (engl waiting time) eines Prozesses
wie folgt:
Definition 7.4.5 (Wartezeit) Gegeben sei ein Problemgraph G (V,E) Sei δi die Ausf¨uhrungszeit von Knoten vi ∈ V,τr(vi) die Releasezeit von Knoten vi undτe(vi) der Zeitpunkt, an dem vi vollst¨andig abgearbeitet ist (Endzeitpunkt) Dann bezeich-netδW(vi) mit
δW(vi) :=τe(vi) −τr(vi) −δi (7.13)
die Wartezeit von Prozess i.
Die Wartezeit eines Prozesses ist damit die Dauer der Zeitspanne, die er ab dem Zeitpunkt seiner Ankunft (Releasezeit) den Prozessor nicht belegt hat, also
sozusa-gen auf seine (weitere) Abarbeitung wartet Ein ¨ahnliches Maß ist die sog Flusszeit,
die Summe von Ausf¨uhrungszeit und Wartezeit:
Definition 7.4.6 (Flusszeit/Antwortzeit) Gegeben sei ein Problemgraph G (V,E) Seiδi die Ausf¨uhrungszeit von Knoten vi ∈ V,τr(vi) die Releasezeit von Knoten vi undτe(vi) der Zeitpunkt, an dem vi vollst¨andig abgearbeitet ist (Endzeitpunkt) Dann bezeichnetδF(vi) mit
δF(vi) :=τe(vi) −τr(vi) (7.14)
die Flusszeit von Prozess i In der Literatur wird die Flusszeit auch h¨aufig als Ant-wortzeit (engl response time) bezeichnet.
Im Zusammenhang mit Echtzeitsystemen spielt die Einhaltung von Deadlines zur Beurteilung von Ablaufplanungsverfahren eine große Rolle, da bei diesen Sys-temen die Nichteinhaltung katastrophale Folgen haben kann Hier sind deshalb auch folgende Definitionen von Eigenschaften eines Ablaufplans von Interesse:
Trang 7440 7 Software-Verifikation
Definition 7.4.7 (Lateness, Tardiness) Gegeben sei ein Problemgraph G (V,E) Sei
τd(vi) die Deadline (sp¨atester Endzeitpunkt) von Knoten vi ∈ V undτe(vi) der Zeit-punkt, an dem vi vollst¨andig abgearbeitet ist (Endzeitpunkt) Dann bezeichnetδL(vi) mit
δL(vi) :=τe(vi) −τd(vi) (7.15)
die sog engl Lateness von Prozess i undδT(vi) mit
δT(vi) := max{τe(vi) −τd(vi),0} (7.16)
die sog engl Tardiness von Prozess i.
Aperiodische, dynamische Ablaufplanung
Ein Verfahren, das die Minimierung der maximalen Lateness der Prozesse zum Ziel hat, kann im Falle nichtpr¨aemptiver Ablaufplanung von Prozessen ohne Da-tenabh¨angigkeiten auf einem Prozessor mittels der Regel von Jackson angegeben werden [243]:
Theorem 7.4.1 (Jackson-Regel [243]) Gegeben sei ein Problemgraph G (V,{ }) F¨ur die Ankunftszeiten gelte ∀i = 1, ,|V| :τr(vi) = 0 Ferner sei f¨ur jeden Pro-zess eine Deadlineτd(vi) gegeben Dann ist der Algorithmus, der die Prozesse in der Reihenfolge nicht kleiner werdender Deadlines plant, ein exaktes Verfahren zur Minimierung der maximalen Lateness.
Ein Algorithmus, der gem¨aß der Jackson-Regel einen Ablaufplan bestimmt, heißt
auch Earliest-Due-Date-Algorithmus (EDD).
Man kann zeigen, dass bei von null verschiedenen Ankunftszeiten der EDD-Algorithmus nicht mehr exakt ist Allerdings f¨uhrt hier ebenfalls die Erlaubnis der Pr¨aemption zu einer einfachen exakten Erweiterung: Zu jedem Zeitpunkt wird unter allen Prozessen, deren Ankunftszeit kleiner oder gleich der aktuellen Zeit ist, der-jenige Prozess geplant, dessen Deadline am kleinsten ist Diese Strategie von Horn
[225] ist auch bekannt als Earliest-Deadline-First-Algorithmus (EDF) Bei
verbote-ner Pr¨aemption ist das Problem der Minimierung der maximalen Lateness im Falle ungleicher Ankunftszeiten bis auf wenige Spezialf¨alleN P-schwer.
Ber¨ucksichtigung von Datenabh¨angigkeiten
Der EDF-Algorithmus kennt keine Datenabh¨angigkeiten Im nichtpr¨aemptiven Fall bei gleichen Ankunftszeiten gibt es jedoch folgenden Algorithmus von Lawler [292],
der als Latest-Deadline-First-Algorithmus (LDF) bekannt ist Der Algorithmus baut
einen Ablaufplan, der die Datenabh¨angigkeiten erf¨ullt, wie folgt auf: Unter allen Prozessen ohne ungeplante Nachfolger selektiert der LDF-Algorithmus denjenigen Prozess zuerst, dessen Deadline am gr¨oßten ist Dieser Schritt wird so lange iteriert, bis alle Prozesse selektiert wurden Einen Ablaufplan, der die Datenabh¨angigkeiten erf¨ullt, erh¨alt man dann durch Ausf¨uhrung der Prozesse in umgekehrter Reihenfolge der Selektion, d h beginnend mit dem zuletzt selektierten Prozess und endend mit dem zuerst selektierten Prozess
Trang 87.4 Zeitanalyse 441
Beispiel 7.4.2 Betrachtet wird ein Problemgraph mit sechs Prozessen v1,v2,v3,v4,
v5,v6 und den in Abb 7.30a) dargestellten Datenabh¨angigkeiten F¨ur die Ausf¨uh-rungszeiten gilt δ1=δ2=δ3=δ4=δ5=δ6:= 1 und die Deadlines τd(v1) :=
2,τd(v2) := 5,τd(v3) := 4,τd(v4) := 3,τd(v5) := 5,τd(v6) := 6 Abbildung 7.30b) zeigt einen mit der LDF-Strategie gewonnenen Ablaufplan Unter den drei Prozessen
v4,v5und v6ohne ungeplante Nachfolger wird v6zuerst selektiert, da dessen
Dead-line am gr¨oßten ist Dann wird unter den drei Prozessen v3,v4und v5mit gleichem
Argument v5selektiert, usw Zuletzt wird v1selektiert Geplant wird dann in umge-kehrter Reihenfolge der Selektion Im Beispiel erf¨ullen alle Prozesse ihre Deadlines
v1
v3
v6
v2
v5
v4
CPU
τ
v1 v2 v3 v4 v5 v6
Abb 7.30 Ablaufplanung mit LDF-Strategie
Theorem 7.4.2 (LDF-Regel [292]) Gegeben sei ein Problemgraph G (V,E) F¨ur die Ankunftszeiten gelteτr(vi) = 0 ∀i = 1,··· ,|V| Ferner sei f¨ur jeden Prozess
ei-ne Deadliei-neτd(vi) gegeben Dann ist der Algorithmus, der die Prozesse nach der LDF-Regel plant, ein exaktes Verfahren zur Minimierung der maximalen Lateness.
Bei ungleichen Ankunftszeiten kann das Problem der Minimierung der maxi-malen Lateness nur dann exakt polynomiell gel¨ost werden, wenn man Pr¨aemption gestattet Chetto et al [90] haben hierzu eine Erweiterung des EDF-Algorithmus vorgestellt Da EDF keine Datenabh¨angigkeiten kennt, werden die Ankunftszeiten
τr(vi) und die Deadlinesτd(vi) im ersten Schritt in neue Ankunftszeitenτ∗
r(vi) und
neue Deadlinesτ∗
d(vi) transformiert und im n¨achsten Schritt die EDF-Strategie
an-gewendet Die folgende Transformation der Ankunftszeiten und Deadlines bewirkt dabei, dass kein Prozess vor Beginn all seiner Vorg¨anger starten und keine
Nachfol-ger unterbrechen kann Diese Modifikation heißt EDF ∗-Algorithmus [90] Man kann zeigen, dass ein Ablaufplan f¨ur das urspr¨ungliche Problem mit Datenabh¨angigkeiten genau dann existiert, wenn EDF* einen Ablaufplan f¨ur das transformierte Problem ohne Datenabh¨angigkeiten findet
Die Transformation lautet wie folgt:
τ∗
r(v j) := max{τr(v j), max
(v i ,v j)∈E {τ∗
r(vi) +δi }} (7.17)
Offensichtlich kann Prozess vjerst nach seiner Ankunftszeit und nicht fr¨uher als zum fr¨uhestm¨oglichen Endzeitpunkt aller seiner direkten Vorg¨anger starten
Trang 9442 7 Software-Verifikation
τ∗
d(vi) := min{τd(vi), min
(v i ,v j)∈E {τ∗
d(v j) −δj }} (7.18)
Weiterhin muss ein Prozess vivor seiner Deadline beendet sein, darf aber auch nicht sp¨ater als zum sp¨atestm¨oglichen Startzeitpunkt aller seiner direkten Nachfolger en-den
Beispiel 7.4.3 Betrachtet wird die Datenabh¨angigkeit (vi ,v j) in Abb 7.31a) mit
Ausf¨uhrungszeitenδi:= 5 und δj := 7 Die Ankunftszeiten betragen τr(vi) := 2,
τr(v j) := 0, die Deadlinesτd(vi) := 15, τd(v j) := 14 F¨ur die transformierte An-kunftszeit von vj erh¨alt man τ∗
r(v j) := max{0,2 + 5} = 7 F¨ur die transformierte Deadline von vierh¨alt manτ∗
d(vi) := min{15,14 − 7} = 7 Plant man anschließend
die Prozesse nach der EDF-Regel, so erh¨alt man den Ablaufplan in Abb 7.31b) Man vergewissere sich, dass eine Ablaufplanung nach EDF ohne Transformation der An-kunftszeiten und Deadlines die Datenabh¨angigkeiten nicht respektieren w¨urde
b)
v j
v i
a)
0
CPU
v j
v i
Abb 7.31 Ablaufplanung mit EDF∗-Strategie: a) Problemgraph und b) Ablaufplan mit
EDF-Strategie bei Verwendung der transformierten Zeiten
Periodische, dynamische Ablaufplanung
Wichtige Ergebnisse zur Theorie dieser Klasse von iterativen dynamischen Ablauf-planungsproblemen stammen von Liu und Layland [307], die im Folgenden zusam-mengefasst werden Deren Untersuchungen beziehen sich auf ein Modell von
pe-riodischen Prozessen, die sich durch einen iterativen Problemgraphen G(V,{ },−),
d h durch einen Problemgraphen ohne Datenabh¨angigkeiten und folglich ohne
In-dexverschiebungen darstellen lassen Den Prozessen vi ∈ V sind bekannte
Ausf¨uh-rungszeitenδizugewiesen Ferner wird angenommen, dass Pr¨aemption erlaubt sei
Im Gegensatz zu iterativen Ablaufplanungsproblemen mit Datenabh¨angigkeiten
ha-ben hier einzelne Prozesse meist unterschiedliche Perioden P (vi) Betrachtet wird
damit folgendes Ablaufplanungsmodell:
Definition 7.4.8 (Iteratives, dynamisches Ablaufplanungsmodell) Ein iteratives,
dynamisches Ablaufplanungsmodell besteht aus
• einem iterativen Problemgraphen G(V,{ },−),
• Ausf¨uhrungszeitenδi f¨ur Knoten vi ∈ V,
• Perioden P(v i) f¨ur Knoten vi ∈ V,
Trang 107.4 Zeitanalyse 443
• periodischen Releasezeitenτr(vi ,n) mit
∀n ≥ 0 :τr(vi ,n) :=τ∗
r(vi) + n · P(vi).
Dies bedeutet, dass die Releasezeiten neuer Iterationen eines Knotens vi immer
im Abstand des Iterationsintervalls (der Periode) P(vi) auftreten Die Release-zeitenτ∗
r(vi) werden auch als Phasen bezeichnet Ferner gibt es
• periodische Deadlinesτd(vi ,n) mit
∀n ≥ 0 :τd(vi ,n) :=τr(vi ,n) +τ∗
d(vi).
Dies bedeutet, dass sich die Deadlines ebenfalls im Abstand der Periode P (vi) eines Prozesses wiederholen Die periodische Deadlineτ∗
d(vi) ist hier keine ab-solute Zeitbeschr¨ankung, sondern als Zeitspanne relativ zur Releasezeit einer Iteration definiert.
Liu und Layland besch¨aftigten sich zun¨achst nur mit dem Spezialfall∀v i ∈ V :
td∗ (vi) = P(vi), d h die Deadline einer Iteration eines Prozesses ist immer gleich
der Dauer der Periode einer Iteration Zur Erl¨auterung der Begriffe soll folgendes Beispiel dienen
Beispiel 7.4.4 Gegeben ist ein Problemgraph mit zwei Knoten v1und v2, den Aus-f¨uhrungszeiten δ1:= 1,δ2:= 2,5 sowie den Perioden P(v1) := 2 und P(v2) := 5 F¨ur die Deadlines giltτ∗
d(v1) = P(v1),τ∗
d(v2) = P(v2), f¨ur die Ankunftszeiten der nullten Iteration giltτ∗
r(v1) =τ∗
r(v2) := 0 Abbildung 7.32 zeigt zwei periodische Ablaufpl¨ane Der Ablaufplan in Abb 7.32a) erf¨ullt beide Deadlines und wiederholt
sich periodisch nach zwei Iterationen von Knoten v2bzw f¨unf Iterationen von
Kno-ten v1 Der Ablaufplan in Abb 7.32b) erf¨ullt die Deadline der nullten Iteration von
Knoten v2nicht (τd(v2,0) =τr(v2,0) +τ∗
d(v2) = 0 + 5 < 5,5).
Liu und Layland betrachteten anschließend Algorithmen zur iterativen Ablauf-planung mit Echtzeitbedingungen und statischen Priorit¨aten Um hinreichende Kri-terien angeben zu k¨onnen, wann ein Algorithmus zur Ablaufplanung f¨ur
beliebi-ge Instanzen von Ablaufplanungsproblemen alle Deadlines erf¨ullen wird, muss man zeigen, dass der Algorithmus auch f¨ur den schlimmsten Fall angenommener Release-zeiten einen in diesem Sinn g¨ultigen Ablaufplan findet So zeigten Liu und Layland, dass dieser Fall immer durch die Phasen∀v i ∈ V :τ∗
r(vi) = 0 gegeben ist, d h wenn
alle Prozesse gleichzeitig ankommen Anschaulich beginnt in diesem Fall der Wett-lauf der Zeit mit den Deadlines aller Prozesse gleichzeitig, was offensichtlich nicht ung¨unstiger sein k¨onnte Dann zeigten sie, dass ein Algorithmus zur Ablaufplanung mit statischen Priorit¨aten eine Probleminstanz unter Erf¨ullung aller Deadlines immer dann planen kann, wenn f¨ur die Phasen∀v i ∈ V :τ∗
r(vi) = 0 alle Deadlines f¨ur die
nullte Iteration erf¨ullt werden
Um diese Ergebnisse anschaulicher zu machen, wird nun ein bekannter Algorith-mus zur iterativen Ablaufplanung mit statischen Priorit¨aten vorgestellt