1. No category

Realtidssystem
- Schemaläggning EDA698 - Realtidssystem (Helsingborg)
Elin A. Topp
2015-10-05
Stora delar baserad på: Föreläsningsmaterial EDA040 (Klas Nilsson, Mathias Haage) samt EDA698 (Mats Lilja)
1
Dagens agenda
•
•
Recap: Dödläge
Schemaläggning
•
•
•
•
Realtid - krav, garanti, exekveringstider
Schemaläggningsprinciper
Prioritetstilldelning
Prioritetsinvertering
2
Dagens agenda
•
•
Recap: Dödläge
Schemaläggning
•
•
•
•
Realtid - krav, garanti, exekveringstider
Schemaläggningsprinciper
Prioritetstilldelning
Prioritetsinvertering
3
dlock risk.
Deadlock
- dödläge
en several threads are waiting
for each other
we have a Deadlock.
circular
pears to
ted too
k:
DA040
F4b: Deadlock
September 19, 2011
3 / 18
Om det blir en cirkel i kraven, eller snarare väntandet på att kraven uppfylls, hamnar systemet i
ett dödläge (deadlock)
Om det är teoretiskt möjligt att aktörer (trådar, bilar, personer) måste vänta på varandra i en
cirkel, finns det en risk för dödläge (deadlock risk)
4
“Krav” för dödläge
(Peterson / Silberschatz)
Följande punkter måste vara “uppfyllda” för att det ska bli dödläge:
1. Ömsesidig uteslutning - enbart en tråd åt gången kan komma åt en resurs.
2. Hold and Wait (hålla och vänta) - en tråd kan “reservera” (ta) en resurs och vänta sen på
en annan
3. Ingen resource-preemption (avbrott under resursnyttjande) - en tråd kan inte tvingas att
lämna en resurs när den väl har kommit in
4. Cirkulärt vänteläge - när det finns en cirkel i tråd-resurs-beroenden
För Java - monitorer gäller följande:
1. Monitor - enbart en tråd kan komma in, ömsesidig uteslutning är uppfylld
2. Anrop av en metod i en annan monitor inifrån en monitor-metod är möjligt
3. En monitor friges enbart om en tråd lämnar den tillfälligt (wait()) eller lämnar efter
avslutad jobb, ingen resource-preemption, därmed kan det bli dödläge
4. “Cirkulärt vänteläge” är det som man måste åtgärda själv, allt annat KAN man inte ändra
5
esource allocation
graphs
Resursallokeringsgrafer,
allmänt
Tool for
detecting
circular
hold-wait
situations
and
to
determine
under
Ett verktyg för att upptäcka cirkulära “hold-wait” situationer, och för att förstå, vilka trådar
resurser kan deadlock
inblandas i ettcan
dödläge,
whichoch
conditions
occur.
1. Draw
1. Rita resources
resurserna (monitorer, semaforer ...)
2. Draw
all
hold-wait
situations
(arrows
from
each
held
resource
to
a
2. Rita alla hold-wait situationer. Pil från en “upptagen” resurs till en markör för tråden som
thread
arrows
thread
marker
waited
håller marker,
i resursen (kan
bli flerafrom
markörer
för en tråd,
en för to
varjeresource
hold-wait) och
pil från for)
trådmarkör till resursen den väntar på.
3. Circular?
Then risk for deadlock. The number of ’hold-wait’ links in
3. Cirkel
i ritningen?
Då är
det riskhow
för dödläge.
förbindelserna
visar
the
circular
chain
shows
many“Hold-wait”
and which
threadsi cirkeln
are required
fo
hur många och vilka trådar kan orsaka ett dödläge.
deadlock.
6
Dödläge - svält - “livelock”
Deadlock (dödläge)
1. När flera trådar försöker komma åt samma resurs måste dock en av de lyckas någon
gång.
2. Ifall att ordningen av resursallokering är olyckligt gjort, kan det bli dödläge, dvs ingen tråd
lyckas exekvera eller få tillgång till resurserna den behöver.
Starvation (svält)
1. Om en tråd vill ha en resurs så måste den lyckas någon gång för att inte hamna i svältläge
2. Vi accepterar att det kan bli svält för mindre prioriterade aktiviteter, så att det som är
viktigt kan utföras
Livelock (levande låsning)
1. Om flera trådar försöker komma åt samma resurs men avbryts hela tiden innan de lyckas
pga schemaläggningen, hamnar man i ett slags “zombie”-läge; trådarna är vid liv, men gör
ingen nytta.
2. Utifrån ser det ut som dödläge, men kollar man upp det, är trådarna aktiva, fast det
händer “ingenting”
7
Dagens agenda
•
•
Recap: Dödläge
Schemaläggning
•
•
•
•
Realtid - krav, garanti, exekveringstider
Schemaläggningsprinciper
Prioritetstilldelning
Prioritetsinvertering
8
Från parallellitet till realtid Realtidskrav
Concurrent computing
Ett realtidssystem måste
•
•
•
•
"0
utföra
beräkningar
alla
logiskt korrekt
"
reagera
på inmatningar
2
jämlöpande
"
alltid ha
konsistent data att
"0"5
arbeta med
5%$
producera
alla (del-)resultat
"
5+%
i tid +1&$!
""%
+5!
0"
För att uppnå
“realtids-korrekthet”
(real-time correctness) måste mjukvaran
%3
&%2!
säkerställa,
att det “jämlöpande-korrekta”
resultatet produceras pålitligt i tid.
6$
+0"""$
"##$%"$#
Ofta handlar det om att hantera både periodiskt upprepade aktiviteter parallelt med
händelsestyrda aktiviteter
9
Tidsfördröjningar och väntetider i
återkopplingsreglering
Software and timing
Scheduling principles
Bounded blocking
Worst-case execution time (WCET)
Latencies and delays in feedback control
1. Starttid för regleringen, önskad
början av perioden
2. Faktiska starten av
regleringsberäkning, efter
trådbyte (release time)
3. Givarens mätdata är tillgänglig
4. De beräknade regleringsvärden
blir utgivna
5. Reglering och exekvering är
avslutade, inkluderande
förberedelse för nästa
mätomgång
Control system | Software timing
Tidpunkterna i grafiken:
http://cs.lth.se/EDA040
sample delay
control delay
latency
execution time
control response time
response time
job execution
sensor data
control signal
sample
time
(1)
(2)
(3)
(4)
F5: Scheduling and bounded response times
(5)
September 30, 2011
9
Control delay och control response time är något som folk i reglerteknik tittar på, medans vi behandlar
execution time (exekveringstid) och response time (svarstid) från mjukvaruperspektivet.
10
Tiden som en aktivitet (tråd) förbrukar
Att hantera något i realtid betyder att garantera ett korrekt (användbart) svar inom en given tid
Vi måste då titta på två olika typer av tider som ingår i en tråds sammanlagda “arbetstid”, alltså
den maximala svarstiden (maximum response time, R) som vi vill garantera:
1. Exekveringstiden i värsta fall (Worst Case Execution Time, WCET), plus väntetider, ifall det finns
delade resurser och preemption.
2. Starttid (som hänger direkt ihop med andra trådars exekveringstid och trådbytestider).
Eftersom vi vill kunna ge garantier, kommer vi alltid utgå från det värsta möjliga läget,
Release time
(maximal starttid)
WCET
(maximal exekveringstid)
}R
Maximum response time
(Svarstid)
11
Svarstider och prioritet
Svarstiderna, dvs väntetider och fördröjningar beror också på trådens prioritet
Högst prioriterade tråden
Andra trådar
Tid för kontextbyte
(trådbyte)
Maximal exekveringstid av
själva koden i tråden
+ maximal blockeringstid
(vid gemensamma resurser)
}R
highP
Beräkningen av den maximala svarstiden
(Worst case response time) hänger alltså
ihop med den valda schemaläggningen och
trådarnas periodiska aktivitet
Tid för kontextbyte
(trådbyte)
+
WCET för alla högre / likt
prioriterade trådar
Maximal exekveringstid av
själva koden i tråden
+ maximal blockeringstid
(vid gemensamma resurser)
+
n* WCET för alla högre /
likt prioriterade trådar
(vid preemption, beror på
periodtider)
}
RlowP
12
Statisk schemaläggning
Fördelar
Används för extremt kritiska trådar och i enkla
styrsystem
•
•
Tiden blir delad i små intervall (slots)
•
Alla aktiviteter (trådars exekveringstid)
måste
små såprinciples
att de passar in
Software and
timing vara tillräckligt Scheduling
i ett intervall
Static scheduling
Garanterad schema, alla får köra, allt utförs
inom angivna tidsramar
•
Varje aktivitet kan alltid utföras färdigt, inga
avbrott, inga kritiska sekvenser
Bounded blocking time
Static
schedulingär– schemalagda
examples i passande
• Aktiviteterna
tidsintervaller innan systemet börjar köras
Fictive illustrative example
•
Lätt att beräkna den maximala svarstiden
Nackdelar
• Fragmentering, inget bra nyttjande av CPUTwo
T1: 50 exekvering
times/secondav schemat
T2: 25 times/second
Cyklisk upprepade
• threads;
tiden
Divide time into 10 ms slots (e.g., interrupt triggered).
Schedule accomplished by arranging the source code:
T1
•
Aktiviteter måste eventuellt delas upp i
onaturliga avsnitt för att få dem in i en
enstaka tidsintervall
•
Schemat kan bli ganska komplext, och måste
eventuellt göras om när programmet ändras
T2
Industrial
T1: 50examples
gånger / sek, 8ms WCET,
25 gånger
/ sek, 8ms
TheT2:
following
were presented
atWCET,
lecture by classic overheads:
I
I
10ms
tidsintervall
ABB Robotics:
DSP-based motor-control implementation
13
Dynamisk schemaläggning
Används i de flesta, inte helt så kritiska system, ofta också där resurserna måste utnyttjas till högsta
möjliga grad
•
•
Beroende på den valda schemaläggningsprincip hanteras trådarna dynamiskt allt eftersom de
startas up
•
Strict priority (Prioritetsbaserad) - trådarna sorteras i en väntekö enligt deras prioritet
•
Round robin - trådarna sorteras i en FIFO-kö
Vi måste anta dynamisk, prioritetsbaserad schemaläggning för att kunna bygga realtidssystem,
annars måste man känna till alla trådar i systemet (så att man kan räkna in dem i
schemaläggningsanalysen)
14
Prioritetsbaserad schemaläggning
Strict priority order - strikt prioritetsbaserad schemaläggning
•
Dynamisk schemaläggning bestämmer online vilken tråd (av de som är flaggad “ready”) ska köra
•
De flesta system-schemaläggare är baserad på prioriteter (som syns i Java-klasserna)
•
Vi antar interrupt-driven schemaläggning, dvs avrbytbar (med preemption), men detta kan kringgås
på program-nivå med java.lang.Thread.yield(), ifall en ny schemaläggning behövs
•
Om prioriteterna är fasta, alltså inte ändras efter att tråden har skapats, pratar vi om fixed priority
scheduling
•
Hur sätter man då en tråds prioritet?
•
Trådens prioritet påverkar schemaläggningen, dvs väljer man “fel” kan det bli omöjligt att hitta
ett fungerande schema
•
Både för att bestämma prioritet och för att sen kunna garantera en maximal svarstid, måste
man analysera värsta fallet - schemaläggningsanalys med WCET.
15
Prioritetstilldelning
Exempel: T1 exekverar 1ms varje 2ms, T2 exekverar 2ms varje 5ms. Trådarna måste exekveras färdigt en gång per period
Tidsintervallet vi måste titta på är minsta gemensamma multipeln av perioderna, dvs 2x5 = 10ms
A: T2 får högre prioritet än T1:
T2
T1
Det fungerar alltså om
T1 får inte köra i sin första period (FEL)
B: T1 får högre prioritet än T2:
T1
högst frekvens
får
högst prioritet
T2
T2 blir avbruten av T1 vid 2ms och 6ms, men får ändå köra inom den tänkte 5ms-perioden varje gång
16
RMS - Rate monotonic scheduling
RMS regel: välj prioritet i relation till perioden; Kort period motsvarar hög prioritet.
Fråga: Hur bra är denna tumregel? Kan vi
granskar ett system mera noggrant? Hur
exakt kan vi bestämma, om ett system
kommer att fungera?
Fråga: Hur mycket CPU-tid kan vi använda?
Går det att utnyttja CPUn till 100% om
flera trådar ska samsas om den, som var för
sig har en viss grad av nyttjande av CPUtid?
Scheduling analysis enligt RMS: Hur mycket
CPU-användning kan vi ha och fortfarande
garantera att det finns ett schema som
fungerar?
Förenklingar
Till en början antar vi:
• Periodiska trådar
• Ingen blockering på resurs
• Deadline = period
Notation
För varje tråd vet vi:
• T = Period
• C = Exekveringstid
• U = C/T = CPU-användning
17
Exempel (RMS)
Vi försöker med 100% CPU utnyttjande
T1: C=2ms, T=4ms, C/T=0.5
T2: C=5ms, T=10ms, C/T=0.5
T1
T2
Men med T2: C=2ms, T=4ms, C/T=0.5 hade det fungerat... problemet ligger alltså i relationen mellan perioderna
Värsta fallet som fortfarande går att schemalägga för två trådar utan blockering
Med T1: C=1ms, T=2ms (C/T=0.5) får man
T2: C=1ms, T=3ms som minsta U = C/T som fortfarande går att schemalägga.
Totalt blir U = C/T = 1/2 + 1/3 ≈0.83
18
EDF- earliest deadline first
Ett annat schemaläggningsprincip, som alltid ger CPUn till den tråden som är närmast sin deadline
T1: C=2ms, T=4ms
T2: C=5ms, T=10ms
T1
T2
Här kan man få 100% CPU användning,
men: dyrt att implementera (ligger ovanpå prioritetsbaserad schemaläggare)
samt leverar riktigt dåliga resultat när det blir fel någonstans, då kommer alla trådar missar sina
deadlines
19
Svarstider under tillfällig blockering
Trådar i ett realtidssystem borde exekveras med absolut prioritetsbaserad ordning, dvs en tråd med
hög prioritet ska inte behöva vänta på en tråd med lägre prioritet under en obestämt tidsperiod
Därför (i ett realtidssystem):
•
CPUn tilldelas alltid den högst prioriterade tråden som är “redo” (ready)
•
Semaforer och monitorer har prioritetskö
•
Det finns en “ingångskö” för nya och nyligen blockerade trådar till delade monitorer
Kan vi då garantera rätt exekveringstid för högt prioriterade trådar utan att känna till
exekveringstiden av mindre prioriterade trådar? Vad händer när det blir blockering på delade
resurser?
20
Prioritetsinvertering
Ett problematiskt
scenario:
Software and
timing
Scheduling principles
Bounded blocking time
Limiting max blocking despite multiple resources.
Tre trådar med H(ög), M(edel) och L(åg) prioritet, där H och L delar en resurs.
•
Priority Inversion
L exekveras och kommer in i en kritisk region (kommer in i resursen)
A problematic scenario
• M avbryter (preemption) och börjar exekvera
•
•
Three threads with H(igh), M(edium), and L(ow) priority:
H avbryter1.och
försökerand
komma
in ai den
delade
resursen, som L håller. H är blockerad.
L executes
enters
critical
region.
2. exekvera
M preempts
anden
starts
executing.
M fortsätter
under
obestämd
tidsperiod, och blockerar både L och H.
3. H preempts and tries to allocate the shared resource. H is blocked.
4. M continues executing for an arbitrary long period of time, blocking
both L and H!
http://cs.lth.se/EDA040
F5: Scheduling and bounded response times
September 30, 2011
26 / 31
21
Prioritetsarv
Ett “botemedel” mot prioritetsinvertering är prioritetsarv
Idé: Låt en tråd med låg prioritet som håller i resurser som behövs av högre prioriterade trådar
“ärva” den högre prioriteten, så att de blir klara så snart som möjligt och inte blockerar längre.
Det finns olika protokoll som implementerar prioritetsarv:
Dynamiskt prioritetsarv (basic inheritance protocol)
Prioritetstak (priority ceiling protocol)
Direkt prioritetsarv (immediate inheritance protocol)
22
I
Thread L and H share a resource/monitor.
I
Recall that thread M is for something else, not using the monitor, and
perhaps its existence in unknown.
Dynamiskt prioritetsarv
Det “problematiska
scenariot”F5:
räddad
med
(?)
http://cs.lth.se/EDA040
Scheduling
and prioritetsarv
bounded response times
September 30, 2011
28 / 31
•
L exekveras och kommer in i en kritisk region (kommer in i resursen)
•
M avbryter (preemption) och börjar exekvera
•
H avbryter
•
och försöker komma in i den delade resursen, som L håller. H är blockerad. L ärver Hs prioritet
och avslutar jobbet i den kritiska sekvensen. L får sen tillbaka “sin egen” prioritet och blir
avbruten av H.
•
H avsluter och M fortsätter exekveringen
•
Både H och M väntar enligt sina tidsperioder. L får avsluta.
23
WCET for the highest priority thread
Worst-case time to execute the code in the thread
Dynamiskt prioritetsarv
problem
+ For each used resource: maximum blocking time
Högst prioriterade tråden
Basic Inheritance Protocol:
Tid för kontextbyte (trådbyte)
}
RhighP
Maximal exekveringstid av själva
koden i tråden
Software and timing
Scheduling principles
+ maximal blockeringstid (vid
Limiting max blocking despite multiple resources.
gemensamma resurser)
Can block once
Bounded blocking time
for each used resource.
Enhanced priority inheritance to avoid multiple blocking
Det kan förekommer multipla blockeringer på olikahttp://cs.lth.se/EDA040
resurser av flera lägre prioriterade
(LP)
trådar,
Scheduling
and bounded
response times
Old baseline: Basic Inheritance Protocol – raise F5:
prio
for LP
temporarily,
som tillfälligt får hög prioritet enligt prioritetsarv. Detta kan man komma förbi med:
dynamically when HP blocked, locally for each resource.
Enhancements:
ceiling protocol): Enbart EN LP-tråd får komma åt någon av resurserna som
• Prioritetstak (priority
HP-tråden behöver Priority
vid ett tillfälle.
Ceiling
•
•
Properties
The e↵ect is, to the cost of managing
only one
LP to access
(and
registering
in the
source region
Direkt prioritetsarv Allow
(immediate
inheritance
protocol):
LP-tråden
somthem
innehar
en kritisk
the högste
resources
required som
by HP
code) multiple
resources
(sekvens) får alltid den
prioriteten
är förknippad
med den
aktuellatogether,
resursen.a
at any time.
fence around that set of resources.
Egenskaper: Det blir ett “staket” kring en grupp av
resurser, som då också garanterar att det hela är Immediate Inheritance
dödlägesfritt. Nackdelen är något högre prio ofman
the måste
LP is always
hanteringskostnader,The
eftersom
to the ceiling prio in
registrerar trådarnasraised
resursbehov.
critical region.
Extra benefit: Deadlock free!
24
Schemaläggning - begrepp
•
Schedulability (möjligt att schemaläggas):
•
•
•
Schedulability test (test för möjlig schemaläggning)
•
Givet ett antal trådar och kunskap om deras prioriteter (RMS - perioder räcker!), besvarar ett
sådant test frågan “Är detta system schemaläggningsbart?”
•
Svaret blir “ja” eller “nej”.
Scheduling analysis (schemaläggningsanalys)
•
•
Ett system är schemaläggningsbart (schedulable) när alla trådar håller sina deadlines
Arbetet att bedöma ett systems egenskaper när det gäller schemaläggningen, utfört under
systemets uppbyggande
Scheduling (schemaläggning)
•
Specialfall: statisk schemaläggning
•
Normalfall: dynamiskt schemaläggning (kan vara prioritetsbaserad eller “Round-robin”)
•
OBS: Prioriteter och deadlines är till för korrekt realtidshantering (realtime correctness),
medan den korrekta hanteringen av jämlöpande exekvering (concurrency correctness) INTE får
vara kopplad till prioriteter!
25
Övning 6 - periodiska trådar och mailbox
•
Ofta hamnar man i en situation där vissa aktiviteter i ett system ska utföras återkommande,
möjligen med en given tidsperiod som de ska upprepas i (jfr laboration 1, tidsräknaren)
•
Vissa aktiviteter har i sig ingen upprepning, de ska bara utföras en gång när någon händelse
inträffar: när användaren trycker på en knapp ska knapptrycken hanteras, men när det inte
händer något med knapparna behöver man inte göra något annat än att vänta (sporadiska
trådar) eller rent av “inte finnas” (transaktionstråd).
•
Det kan vara bra att skilja den egentliga aktiviteten från periodhanteringen (om en sådan nu
finns), så att man lättare kan komma åt tiden det ska ta för en aktivitet att utföras. En
implementering kan då t ex erbjuda en “perform”-metod, som beskriver trådens jobb, medan
run-metoden är redan implementerad i superklassen och implementerar loopen över
återkommande anrop till perform.
class Control extends PeriodicThread {
Control() {super(20);} // Sampling period 20ms
}
}
public void perform() {
// Perform ONE sample (i.e., no loop here!).
double yr = getSetPoint();
double y = sample();
double u = controlPID(yr,y);
setControlOutput(u);
26
Basklasser för periodiska uppgifter
se.lth.cs.realtime.* (och Javas grundutbud) tillhandahåller olika typer av trådklasser
som man kan bygga sina trådklassar på:
Cykliskt upprepade uppgift utan specifik period
PeriodicThread:
Cykliskt upprepade uppgift med specifik period
SporadicThread:
Cykliskt upprepade uppgift med en minimiperiod
RTThread:
Basklass för de tre klasserna ovan. Ingen subklass av java.lang.Thread
JThread:
Subklass av java.lang.Thread, som erbjuder en metod perform som
man ska implementera trådens uppgift i; perform kallas i en given
period från run. Erbjuder också en mailbox (RTEventBuffer). CyclicThread:
27
Tvättmaskiner och annan reglering
En tvättmaskin ska enligt sin specifikation håller en viss vattentemperatur, beroende på det
valda tvättprogrammet OCH steget i programmet.
Temperaturen måste alltså kontrolleras regelbundet och justeras enligt de ställda kraven, utan
att det hamnar under eller över en viss gräns (under gränsen är kanske inte farligt, men över
brukar inte vara bra för tvätten).
Värmeelementet går dock inte att slås på eller av med en gång, slår man av det, så ger det ju
fortfarande lite värme, precis som en spisplatta.
Man måste alltså räkna ut hur långt i förväg man måste slå av elementet innan man når önskad
temperatur, så att det inte går över gränsen, samtidigt som man måste veta när man måste slå
på igen innan vattnet blir för kallt.
Detta ger ramen för tidsperioden som den styrande tråden får sova innan den kontrollerar
temperaturen nästa gång efter att den ha tagit beslut om att slå på eller av elementet - man
måste kunna garantera att tråden kolla temperaturen i tid varje gång.
28
Dagens resultat
•
•
•
Introducerat begreppen exekveringstid, svarstid, blockeringstid
•
Ska kunna förklara dem introducerade begreppen och principer.
•
Lästips:
Introducerat schemaläggningsbegreppet och -principer (RMS, EDF)
Introducerat begreppen prioritetsinvertering och prioritetsarv
•
•
e-bok: del 2, kap 11 + 12, sida 263 - 294
Buttazzo, “Resource Access Protocols”
29