Realtidssystem - Monitorer, synkroniserade metoder - EDA698 - Realtidssystem (Helsingborg) Elin A. Topp 2015-09-14 Stora delar baserad på: Föreläsningsmaterial EDA040 (Klas Nilsson, Mathias Haage) samt EDA698 (Mats Lilja) 1
Dagens agenda Recap: Synkronisering / ömsesidig uteslutning med hjälp av semaforer Monitorer Monitorprincipen - objekt med inbyggd ömsesidig uteslutning Monitorer i Java - synchronized, wait & notify 2
Dagens agenda Recap: Synkronisering / ömsesidig uteslutning med hjälp av semaforer Monitorer Monitorprincipen - objekt med inbyggd ömsesidig uteslutning Monitorer i Java - synchronized, wait & notify 3
Semafor - basfakta Semaforer utgör en minimal mekanism för ömsesidig uteslutning En semafor är egentligen bara en integer-variabel med två metoder, take() och give(): class SemaphorePrinciple { int count; public void take() { while( count < 1) suspend executing thread // here, currentthread() is used! --count; public void give() { if( any thread suspended ) resume the first one in queue ; count++; OBS 1: take och give är odelbara (atomic) operationer, som kräver systemsupport när de ska implementeras (t ex deaktivera hårdvaruinterrupts). OBS 2: take blockerar den anropande tråden sålänge count == 0. Detta kan inte implementeras i vanlig Java-kod. 4
Typer av semaforer I LJRT-paketet finns basklassen Semaphore, med subklasser MutexSem och CountingSem. MutexSem - MutualExclusion semaphor: Den som tar flaggan får jobba med gemensamma resurser, den som vill ha den samtidigt, får vänta (blockeras). MutexSem har ett test inbyggt så at det säkerställs att samma tråd anropar take och give i följd. Det finns bara en flagga att ta från början. CountingSem - Counting semaphor, signaling: Den som gör plats / en resurs tillgänglig, signalerar genom att lägga en flagga på högen, den som vill utnyttja en resursplats tar en flagga från högen. Finns inga fria flaggor, måste den som vill ha en vänta. Antalet flaggor kan variera eller vara 0 från början. 5
Semaforer - användning i kod Tråd A: Tråd B: Mutual exclusion (ömsesidig uteslutning)... mutex.take(); *** mutex.give();...... mutex.take(); *** mutex.give();... Signaling (signalering)... buffer.give();...... buffer.take();... Rendezvous... entry.give(); *** exit.take();...... entry.take(); *** exit.give();... 6
Java, LJRT och andra språk Semafor-mekanism finns på ett eller annat sätt tillgänglig i ALLA programmeringsspråk som har stöd för concurrency se.lth.cs.realtime.* används i kursen dels av kompatibilitetsskäl (t ex väckarklockan), dels av historiska skäl Numera erbjuder också Standard -Java ett eget concurrency-paket som fungerar på ett sätt väldigt likt vårt Metoder, taggar eller tillämpningsmekanismer kan vara olika, men den underliggande principen är samma för alla - Java och ljrt-paketet används som praktiskt exempel 7
Signalera med en sorts signal Patienten på rummet behöver hjälp och trycker på signalknappen - lampan utanför rummet tänds och larmet i expeditionen går. (signal.give()) Sjuksköterskan kommer in i rummet och slår av signalen - lampan och larmet släcks och alla utanför vet att problemet åtgärdas - ingen annan behöver eller ska komma och hjälpa. (signal.take()) Detta kan hända på flera rum samtidigt, eller med korta mellanrum. Sålänge det finns sjuksköterskor kan de ta över rum efter rum, sen måste kanske en patient vänta lite längre. Om ingen larmar, måste sjuksköterskorna vänta på nästa problem att lösa. (signal.give() + signal.give() + signal.take() + signal.give() + signal.take() + signal.take()) X
Signalera med två olika signaler Chefen och Sekreteraren har ett postfack för att överlämna dokument till varandra, egentligen är det dock bara Sekreteraren som lägger dit dokument, och chefen som hämtar ut dem därifrån. I facket får det enbart ligga ett dokument åt gången. Sekreteraren ser att facket är tomt genom att en tom -lampa lyser på hennes kontor. Han går till facket, lägger dit ett dokument som chefen måste signera, och trycker på en knapp som släcker tom -lampan och sedan slår på en det finns ett dokument -lampa på chefens kontor. (free.take() + avail.give()) Chefen ser lampan, kommer till facket, tar dokumentet, släcker det finns ett dokument - lampan och slår på tom -lampan hos sekreteraren. (avail.take() + free.give()) X
Dagens agenda Recap: Synkronisering / ömsesidig uteslutning med hjälp av semaforer Monitorer Monitorprincipen - objekt med inbyggd ömsesidig uteslutning Monitorer i Java - synchronized, wait & notify 8
Semaforer och komplexa program Tråd A Tråd B Tråd C Tråd D take / give take / give take / give take / give Mutex Data / resurs Give / Take sprids över alla trådar, anknytningar blir många, det hela blir komplext och svårt att genomskåda för att hitta fel eller verifiera. (Jfr övning 1, uppgift 1 + 3). 9
Från semafor till monitor / The buffer. / class Buffer { Semaphore free; Semaphore avail; String buffdata; // For buffer full blocking. // For blocking when no data is available. // The actual buffer. Buffer(){ free = new CountingSem(1); avail = new CountingSem(); void putline( String input) { free.take(); buffdata = new String(input); avail.give(); String getline(){ avail.take(); String line = buffdata; free.give(); return line; // Wait for buffer empty. // Store copy of object. // Allow others to get line. // Wait for data available. // Store copy of object. // Allow others to put line. Buffer är ett passivt objekt (ingen tråd), som skyddar sina metoder / attribut för hantering genom olika trådar - i princip en monitor (jfr övning 1, uppgift 2, och labb1) 10
Monitor - koncept I OOP använder vi oss av klasser, dvs datastrukturer som tillhandahåller egna metoder för hanteringen av interna data-attributer, för att garanterar kapsling och korrekt hantering. Klasser, som inte bara har metoder, men implementerar metoder så att attributer / kritiska sekvenser blir skyddade vid hantering genom olika trådar, kallas för monitor Metoder som class Account { //... void deposit(int a){ mutex.take(); balance += a; mutex.give(); implementerar monitor-konceptet genom användning av semaforer 11
Monitorer och komplexa program Tråd A Tråd B Tråd C Tråd D metod X metod X metod X metod X Data / resurs metod X { take / give Mutex Give / Take hanteras inuti det passiva objektet. Trådarna anropar metoden som de behöver utan att behöva bry sig om den gemensamma hanteringen av data / resurser. 12
Programmeringsspråk - stöd för monitorer Problem: Att använda semaforer i en monitor kräver fortfarande (för mycket) disciplin. Idé: Erbjuda stöd genom speciella språk-konstruktioner Olika grader av stöd i olika språk: Inget stöd (C / C++): Direkta anrop till biblioteksfunktioner. Objekt-orientering kan förenkla användningen. Explicit per metod ( Java): Deklarerade egenskaper av metoder ( med både språkoch run-time stöd) Implicit per task ( Ada): Deklarerade egenskaper av klasser, som överförs implicit till alla attributer och metoder i klassen Inget stöd resulterar i mera komplicerade programmering. Implicit språk-stöd är säkrast och enklast, men kan leda till begränsningar ( resurser...). Java-ansatsen ( explicit och optional deklaration av metoder med inbyggd ömsesidig uteslutning) är en pragmatisk lösning till problemet. 13
Monitorer i Java - synchronized Kritisk sekvens / kod-block / metod är markerad med nyckelordet synchronized Ett litet bakslag: Vare sig klasser eller attribut can deklareras synchronized, det krävs alltså lite disciplin när man implementerar metoderna i en klass! Monitor-konceptet uttryckt med Javas monitor-mekanism: class Account { //... public synchronized void deposit( int a){ balance += a; 14
Objektkategorier Enkelt passivt objekt Trådsäker genom att ha metoder som är reentrant (dvs, som inte hanterar klassattribut, t ex java.lang.math) Explicit icke trådsäker; får bara användas av en enda tråd (java.util.hashset) Implicit icke trådsäker; måste antas om inte dokumenterad Monitor-objekt Metoder som implementerar ömsesidig uteslutning, t ex genom synchronized Borde vara passivt; blanda INTE monitorer och trådar! Tråd-objekt Aktivt objekt ( efter start(), innan det avslutas); driver exekveringen av metoder i passiva objekt Don t call me, I ll call you! (bortsett från meta-metoder som t ex start() och join()) 15
Detaljer (för specialistbruk ;-) Nämns här, men mera förklaring finns i kompendiet! Atomic access: Vissa datatyper kan förväntas hanteras med odelbara operationer, detta betyder dock inte att det är säkert att hantera dem utan synkronisering! Nyckelordet volatile: används för att visa att (osynkroniserade) attribut i en klass kan hanteras från flera trådar och som då inte får producera skräp i registerna private och final borde användas när man vill hantera osynkroniserade attribut någorlunda trådsäker - annars vet man inte vad en subklass kommer att göra monitor-egenskapen (synchronized) blir inte nedärvd! Man kan lämna ut ett internt lås-objekt för extern synkronisering X
Användningsregler Blanda INTE tråd och monitor i samma klass!!! I en monitor: ALLA metoder som deklareras public borde vara synchronized Tråd-osäkra klasser kan och BORDE paketeras i en monitor (wrapper class) Använd INTE (utspridda) synchronized kod-sekvenser (detaljer i kompendiet!) 16
Samtidigt, men med olika krav synchronized erbjuder ömsesidig uteslutning - räcker det för resurshantering? Cafeteria Pasta Nu finns är tillfälligt det Pasta! slut Mums, jag kan gå, då Tog en macka, kan gå ändå! Vi vill beställa Jag vill ha... Idag: - mackor - pasta Vi Bra, väntar då på går pasta vi och hämta maten 17
synchronized - wait - notify synchronized wait notify Condition queue (krav-kö) Objektet ska inte bara låsas < för exklusivt tillgång genom en tråd (mutex), 2 det ska också öppnas tillfälligt för att kolla om vissa krav uppfylls, alltså att #6 någon meddelar (signal) att tillståndet har förändrats./ 3#1 Låset hanteras med synchronized, 45 signalering med hjälp av wait och notify #+ En tråd #6 som väntar # på monitorn efter wait / notify måste dock inte vara den första som faktiskt får tillgång (kolla krav igen!) Tråden som är i monitorn slängs inte ut genom ett avbrott, den får parkera sig där. synchronized(.){ * & & ()(!!"# "! D wait notify * &# * & & & 18
Cafeteria med synchronized, wait och notify synchronized wait notify Kö för att kunna beställa eller hämta beställt mat - synchronized ordnar med ömsesidig uteslutning, bara en kan prata med personalen. < 2 #6 Den som står vid./ disken frågar om 3#1 maten hon vill ha 45 finns, dvs beställer #+ #6 # Den som vill ha mat som är tillgängligt får det och kan gå synchronized(.){ * & & ()(!!"# "! D wait notify * &# * & & & Pasta finns inte just nu och personen får en röd väntebricka (wait()). När brickorna blir gröna (notify()) kan man ställa sig i kö igen för att hämta ut maten De med röda brickor väntar på att brickorna blir gröna 19
Exempel: Hiss Personer kommer till hissen slumpmässigt Exercises and Lab Preparations RTP med knapptryck meddelar de hissen, att de vill åka från ett ställe hissen rymmer enbart ett visst antal personer personer väntar på att hissen kommer, och har plats i hissen trycker man på en knapp för att visar vart man vill åka personer i hissen väntar på att hissen når rätt våning den enkla hissen åker från våning 0 till våning 6 och tillbaka hela tiden, med uppehåll vid varje våning hissen väntar vid varje våning på att alla som vill kan gå av och (i mån av plats) på. Lab 2 Lift In this lab you are going to implement the lift simulation prepared in the previous exercise. Preparation It is generally a good idea to start programming before the lab occasion. The handout code is available on the course homepage as a zipped Eclipse workspace (it is part of the same zip you downloaded for lab 1). 20
Exempel: Hiss - många med olika krav, en resurs, en motor - På våningarna: kö för att kunna trycka på knappen På våningen, framme vid + kö för att kunna kliva på när hissen är på rätt våning hissen: Trycka synchronized på wait notify knappen, kolla om I hissen: vänta tills man kan lämna (dörren är fri) hissen är där och det < * & finns plats i den synchronized(.){ 2 I hissen: #6 trycka på./ Hissen: När den knappen för våningen 3#1 kommer till en ny man vill åka till, kolla om * & 45 våning, meddelas & hissen är där man vill åka till #+ detta till de som notify #6 # väntar wait & & På våningen: vänta * &# I hissen: har man tills hissen kommer nått våningen man vill åka till, kliver man av (när dörren är fri) ()(!!"# "! D På våningen: Hissen är inte där, eller har inte plats I hissen: rätt våning är inte nått I hissen: vänta på att hissen når rätt våning 21
Exekveringstillstånd (tredje gången gilt!) Due to scheduler / kernel / OS Running Priority, time-sharing Ready Due to application By this : wait, synchronized call Blocked By other: notify, synchronized return Schemaläggningstillstånd (scheduling state) Running Ready (annan tråd returnerar från synchronized metod, eller anropar notify() / notifyall()) Blocked (tråden själv anropar synchronized metod, eller wait() i metoden) 22
notify glöms bort Semaforer har tillstånd Notification har INGET tillstånd Jämför Jämför P1 P2 P1 P2 * s.take(); * * * * s.give(); * * wait(); * * * * notify(); * med med P1 P2 P1 P2 * * s.take(); * * s.give(); * * * * wait(); * * notify(); * * P1 fortsätter i båda fallen, då s interna tillstånd förändras med give P1 väntar tills nästa notify... och väntar...; notify glöms bort om det inte finns någon tillstånds-variabel i monitorn (dvs, i den egna koden) 23
notify() Vem ska väckas? notify() eller notifyall() Väcker upp en tråd åt gången, dvs den som är nästa tråd att köra Nästa tråd att köra avgörs från schemaläggaren efter prioriteter, turordning, osv beroende på schemaläggningspolicyn Svårt att avgöra om man faktiskt väcker rätt tråd, om man vet att en viss sådan väntar på en viss update i monitorn Borde användas enbart om man verkligen behöver det för att dra upp prestationen notifyall() Väcker alla trådar som väntar på att ett krav uppfylls Trådarna sorteras för CPU-tillgång och får sen tävla om tillgång till monitorn, som ju också är skyddad med synchronized Enkelt och säkert att använda, alla som behöver det får en notify Borde väljas som standard, framförallt i den här kursen! 24
Den ursprungliga monitorn (Hoare, 1974) Hoare definierade en monitor med följande egenskaper: Immediate resumption: Direkt återupptagande av väntande tråd - tråden som väcks tar kontrollen med en gång notify måste vara sista operation, bara en tråd väcks Kravtestet kunde formuleras som: if (!ok) wait(); Tråden som gör notify garanterar att kraven som andra väntar för uppfylls Det går enkelt att bevisa att det inte kan förekomma svält (starvation) Hanterar inte prioriteter för blockerade trådar Monitor-kö kan vara FIFO eller (att föredra) prioritetsbaserad X
Vår realtids-monitor Vi antar följande egenskaper: Högt prioriterade trådar borde hanteras först, också om andra har väntad längre (det blir en accepterad risk för svält, dock) Det är inte garanterad att tråden som väcks får exekveras direkt (beror på OS/ schemaläggaren) Kravet som en tråd väntar för måste inte nödvändigtvis uppfyllas när tråden väl kommer fram till exekvering och också monitorn Kravtestet måste formuleras som: while(!ok) wait(); notifyall() ska användas för att undvika problem (väcker alla, helt enkelt) notify måste inte vara sist i metoden När en tråd efter wait() / notify() går före dem med samma prioritet + notify kommer sist + det finns bara en prioritet: Likvärdigt med Hoare-monitor! X
En (riktigt) dålig buffer class MyBuffer { //... public synchronized void post( String text){ if( bufferfull) wait(); buffdata[nexttoput] = new String( text); bufferempty = false; if( ++numoftextbits >= maxnumoftexts) bufferfull = true; if( ++nexttoput == maxnumoftexts) nexttoput = 0; notifyall(); public synchronized String fetch(){ if( bufferempty) wait(); String res = buffdata[nexttoget]; buffdata[nexttoget] = null; bufferfull = false; if( --numoftextbits < 1) bufferempty = true; if( ++nexttoget == maxnumoftexts) nexttoget = 0; notifyall(); return res; if (...) wait(); gör det hela väldigt ostabilt, om någon annan tråd kommer emellan kan eventuellt kravet inte vara uppfyllt efter wait() ändå, eftersom alla (producers) väcks! X
Mycket bättre class MyBuffer { //... public synchronized void post( String text){ while( bufferfull) wait(); buffdata[nexttoput] = new String( text); bufferempty = false; if( ++numoftextbits >= maxnumoftexts) bufferfull = true; if( ++nexttoput == maxnumoftexts) nexttoput = 0; notifyall(); public synchronized String fetch(){ while( bufferempty) wait(); String res = buffdata[nexttoget]; buffdata[nexttoget] = null; bufferfull = false; if( --numoftextbits < 1) bufferempty = true; if( ++nexttoget == maxnumoftexts) nexttoget = 0; notifyall(); return res; while (...) wait(); gör buffer robust ifall någon annan tråd kommer emellan och ändrar tillståndet i monitorn, men det är lite onödigt ofta att notify anrops! X
class MyBuffer { Riktigt bra (och effektivt) //... public synchronized void post( String text){ while( bufferfull) wait(); buffdata[nexttoput] = new String( text); if( bufferempty) { notifyall(); bufferempty = false; if( ++numoftextbits >= maxnumoftexts) bufferfull = true; if( ++nexttoput == maxnumoftexts) nexttoput = 0; public synchronized String fetch(){ while( bufferempty) wait(); String res = buffdata[nexttoget]; buffdata[nexttoget] = null; if( bufferfull) { notifyall(); bufferfull = false; if( --numoftextbits < 1) bufferempty = true; if( ++nexttoget == maxnumoftexts) nexttoget = 0; while (...) wait(); gör buffer robust ifall någon annan tråd kommer emellan och ändrar tillståndet i monitorn, samt är effektivt - kan dock leda till svält! X
För special(ist)bruk (_kan_ fungera bra!) class MyBuffer { //... public synchronized void post( String text){ if( bufferfull) wait(); buffdata[nexttoput] = new String( text); if( bufferempty) { notify(); bufferempty = false; if( ++numoftextbits >= maxnumoftexts) bufferfull = true; if( ++nexttoput == maxnumoftexts) nexttoput = 0; public synchronized String fetch(){ if( bufferempty) wait(); String res = buffdata[nexttoget]; buffdata[nexttoget] = null; if( bufferfull) { notify(); bufferfull = false; if( --numoftextbits < 1) bufferempty = true; if( ++nexttoget == maxnumoftexts) nexttoget = 0; if (...) wait(); gör buffern instabil ifall någon annan tråd kommer emellan och ändrar tillståndet i monitorn, notify istf notifyall fångar upp det till en viss grad, men man måste känna sitt system väldigt bra! X
Synchronized, wait() & notifyall() class Cafeteria { int awaitingfood[]; //... synchronized void refillfood( FoodPortion freshfood, int foodtype){ while( foodsupply[foodtype].portionsleft() >= awaitingfood[foodtype]) { wait(); if( foodsupply[foodtype].isempty()) notifyall(); foodsupply[foodtype].add( freshfood); //... synchronized FoodPortion orderandfetch( int foodtype){ awaitingfood[foodtype]++; // whenever there is a state change, call notifyall() notifyall(); while( foodsupply[foodtype].isempty()) { wait(); if( foodsupply[foodtype].portionsleft() < awaitingfood[foodtype]) notifyall(); awaitingfood[foodtype]--; return foodsupply[foodtype].takeportion(); 25
Monitor == Semafor (?) Semaforer och monitorer är likvärdiga! Semaforer (åtminstone på programtråd-nivå) kan bli (och är i standard-java) implementerade genom att använda en monitor med metoderna give() och take() Monitorer kan implementeras med hjälp av semaforer, åtminstone för ett känt antal trådar, genom att använda en MutexSem på monitor-objektet och en CountingSem för varje tråd som vill ha tillgång till monitor-objektet. Därmed kan man alltid överföra den ena mekanism i den andra (om än möjligen på ett ganska krångligt sätt). Beroende på problemet man vill lösa, ska man välja rätt ansats. Pragmatiskt här i kursen: Väckarklocka - använd semaforer, Hiss - använd monitor (synchronized - wait - notify) 26
Övning 3 Behandlar monitorer - en uppgift har liknande moment som laboration 2, testa gärna vid datorn innan övningstillfället - övningsuppgifterna bearbetas av er under övningstiden - introduktion lab 2 27
Dagens resultat Semaforer på återseende Monitor-begreppet monitorer i Java: synchronized - wait - notify Exempel för användning av monitorer Regler och tips för monitorer och mekanismerna synchronized, wait, notify Kunna hantera övning 3 och 4, samt laboration 2 Kunna använda både semaforer och monitorer i enkla program (matkö - jfr buffer) Lästips: e-bok: Kap5 (avsnitt 5.6 och 5.7, s 130-140, Monitors / Summary) kompendium: Kap 2-3 ( Monitors) 28