Realtidssystem. - Dödläge - EDAF85 - Realtidssystem (Helsingborg) Elin A. Topp. Föreläsning 5

Relevanta dokument
Deadlocks. detektera och undvik

Exam Concurrent and Real-Time Programming

Realtidssystem. - Semaforer, trådsynkronisering - EDAF85 - Realtidssystem (Helsingborg) Elin A. Topp. Föreläsning 2

Realtidssystem. - Semaforer, trådsynkronisering - EDA698 - Realtidssystem (Helsingborg) Elin A. Topp

Tentamen Lösningar EDA698 Realtidssystem

Tentamen EDA698 Realtidssystem (Helsingborg)

Realtidssystem. - Schemaläggning - EDA698 - Realtidssystem (Helsingborg) Elin A. Topp. Föreläsning 6

Realtidssystem. - Introduktion, jämlöpande exekvering - EDA698 - Realtidssystem (Helsingborg) Elin A. Topp. Föreläsning 1

Synkronisering. Föreläsning 8

Realtidssystem. - Monitorer, synkroniserade metoder - EDA698 - Realtidssystem (Helsingborg) Elin A. Topp

Realtidssystem. - Introduktion, jämlöpande exekvering - EDAF85 - Realtidssystem (Helsingborg) Elin A. Topp. Föreläsning 1

Tentamen EDA698 Realtidssystem (Helsingborg)

Realtidssystem. - Schemaläggning - EDAF85 - Realtidssystem (Helsingborg) Elin A. Topp. Föreläsning 6

Realtidssystem. - Meddelanden och händelsehantering - EDAF85 - Realtidssystem (Helsingborg) Elin A. Topp. Föreläsning 4

Trådar. Aktiva objekt

Concurrency Saker händer samtidigt. Process En instans av ett program

Mekanismer. (implementation)

Tråd C (ms) T (ms) A 4 16 B 3 10 C 4 25 D 2 12

Tung bakgrundsaktivitet t.ex. Aktiva objekt t.ex. Animering, simulering. DD2385 Programutvecklingsteknik Några bilder till föreläsning 9 6/5 2013

Objektorienterad Programkonstruktion. Föreläsning dec 2015

Deadlock. Deadlock uppstår när två eller flera processer hamnar i ett cirkelberoende. Resurs 1. Processen vill ha resursen. Processen äger resursen

Objektorienterad Programkonstruktion. Föreläsning 11 6 dec 2016

Institutionen för elektro- och informationsteknologi, LTH

Datorteknik. Föreläsning 5. Realtidssystem och realtidsprogrammering. Institutionen för elektro- och informationsteknologi, LTH.

Kompilering och exekvering. Föreläsning 1 Objektorienterad programmering DD1332. En kompilerbar och körbar java-kod. Kompilering och exekvering

Synkronisering. Ordning och reda

Föreläsning 15: Parallella subrutiner. Parallellitet. Varför parallella underprogram?

F4. programmeringsteknik och Matlab

Javas Exceptions. DD2385 Programutvecklingsteknik Fler bilder till föreläsning 7 23/ Kort om Javas Exceptions Trådar i Java

Objektorienterad Programkonstruktion. Föreläsning 2 2 nov 2016

Abstrakt klass. DD2385 Programutvecklingsteknik Några bilder till föreläsning 4 7/ Exempel: Implementation av Schackpjäser.

Trådar och Multiprocessorer. Föreläsning 6

Tentamen EDA698 Realtidssystem (Helsingborg)

Föreläsning 3: Booleans, if, switch

Tentamensskrivning Nätverksprogrammering (EDA095 - FED) , kl 8-13

Realtidsprogrammering Ordinarie tentamen

Tentamen i TDIU16 Process- och operativsystemprogrammering

Abstrakt klass. DD2385 Programutvecklingsteknik Några bilder till föreläsning 4 31/ Exempel: Implementation av Schackpjäser.

Objektinteraktion. Objektorienterad programmering Laboration 2. Syfte Att konstruera ett litet objektorienterat program med flera samverkande objekt.

a) Vad kallar vi den sorts fel som Hasse:s programvara är behäftad med? (1p)

Tentamen Nätverksprogrammering Lösningsförslag

Software Technology. Josef Svenningsson

Tentamen i Realtidsprogrammering

Trådar i Java. Johan Ånäs. Seminarieuppsats Institutionen för informationsbehandling Åbo Akademi

Tentamen. Datalogi I, grundkurs med Java 10p, 2D4112, Lördagen den 30 november 2002 kl , salar E33, E34

Försättsblad till skriftlig tentamen vid Linköpings Universitet Cover page for written exam at Linköping University

Summering av fält. Synkronisering. Summering av fält. Bounded Buffer. Bounded Buffer (get) Bounded Buffer (put)

FÖRSLAG TILL LÖSNINGAR FÖR TENTAMEN I INTERNETPROGRAMMERING MED JAVA, 5p för SY , kl

Mål. Datorteknik. Repetition av avbrott. Innehåll. Mätning och styrning. Datorer för mätning och styrning. timer. Datorsystem A/D. Analog insignal D/A

Synkronisering - Semaforen. Om att vänta men inte i onödan

Parallellism, återblick

Tentamen Nätverksprogrammering Lösningsförslag

Programmering med Java. Grunderna. Programspråket Java. Programmering med Java. Källkodsexempel. Java API-exempel In- och utmatning.

Föreläsning 5-6 Innehåll. Exempel på program med objekt. Exempel: kvadratobjekt. Objekt. Skapa och använda objekt Skriva egna klasser

Vad är viktigast? Sammanfattning. Processer och trådar. Processer och trådar. Flerprocessorsystem. Schemaläggning. Interprocesskommunikation.

EDAA20 Programmering och databaser. Mål komprimerat se kursplanen för detaljer. Checklista. Föreläsning 1-2 Innehåll. Programmering.

Föreläsning 5-6 Innehåll

1.1 Runnable och Thread

Tentamen i ID2206, ID2200 samt IS1350 Operativsystem

Objektorienterad Programkonstruktion, DD1346. Tentamen , kl

Tentamen, EDA501/EDAA20 Programmering M MD W BK L

Tentamen i Objektorienterad modellering och design

Föreläsning 1 & 2 INTRODUKTION

Realtidssystem HT03. Vad är realtidssystem? Inbyggda system. Att programmera, Tasks (Uppgifter) Realtidssystem kräver analys

Fö 5+6 TSEA81. Real-time kernel + Real-time OS

Program & programmering

Övning2. Variabler. Data typer

Trådar. Motivering. Många program måste kunna hålla på med flera saker samtidigt, till exempel. fleranvändarsystem.

2D1339 Programkonstruktion för F1, ht 2003

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU

Tentamensskrivning Nätverksprogrammering (EDA095) , kl 8-13

Tentamen. Datorteknik och realtidssystem

DI-institutionen Sid 1 av 6 Hans-Edy Mårtensson Sten Sundin

Klassdeklaration. Metoddeklaration. Parameteröverföring

Outline. Datorsystemtekni. Kravspecifikation. Kravspecifikation (forts.)

Tentamen i Objektorienterad modellering och design Helsingborg

Imperativ programmering. Föreläsning 2

Objektinteraktion. Objektorienterad programmering Laboration 2. Syfte Att konstruera ett litet objektorienterat program med flera samverkande objekt.

F5 Selektion och iteration. ID1004 Objektorienterad programmering Fredrik Kilander

Vem är vem på kursen. Objektorienterad programvaruutveckling GU (DIT011) Kursbok Cay Horstmann: Big Java 3rd edition.

OOP Omtenta

TDDIU81. Processer och trådar. Andreas Dahlberg, Jonathan Doherty, Tony Magnusson, Patrik Ottosson, Rasmus Siljedahl

Laboration A Objektsamlingar

Hjälpmedel: Inga hjälpmedel förutom penna, suddgummi och glatt humör.

Agenda (obs! halvdag)

Objektorienterad Programmering (TDDC77)

Lösningsförslag till tentamen i EDAF25 Objektorienterad modellering och design Helsingborg

I Skapa Hej.java och skriv programmet. I Kompilera med javac Hej.java. I Rätta fel och repetera tills du lyckas kompilera ditt program

Tentamen, EDA501 Programmering M L TM W K V

Översikt MERA JAVA OCH ECLIPSE. Uttryck och tilldelning. Uttryck och tilldelning. Uttryck och tilldelning. Uttryck och tilldelning

Tentamen, EDAA10 Programmering i Java

Classes och Interfaces, Objects och References Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

EDAA20 Programmering och databaser. Mål komprimerat se kursplanen för detaljer. Om att lära sig programmera. Föreläsning 1-2 Innehåll.

Tentamen i Introduktion till programmering

Grundkurs i programmering - intro

Föreläsning 3: Abstrakta datastrukturer, kö, stack, lista

Blockkedjor. en introduktion för datavetare. Rikard Hjort, 24 maj 2019

Grundkurs i programmering, 6 hp (725G61) Dugga 2 tillfälle 2

Föreläsning 13 Innehåll

Classes och Interfaces, Objects och References, Initialization

Transkript:

Realtidssystem - Dödläge - EDAF85 - Realtidssystem (Helsingborg) Elin A. Topp Föreläsning 5 Kursens innehåll motsvarar tidigare omgångar under beteckning EDA698 Stora delar baserad på: Föreläsningsmaterial EDA040 (Klas Nilsson, Mathias Haage) samt EDA698 (Mats Lilja) 1

Innehåll Dödläge Hold-wait Resource allocation graphs (Resursallokeringsgrafer) 2

Deadlock - dödläge För att få en anställning behövs ett personnummer För att få ett personnummer behövs ett uppehållstillstånd För att få uppehållstillstånd behövs en anställning 3

Deadlock - dödläge 4

Deadlock - dödläge Om det blir en cirkel i villkoren, eller snarare väntandet på att villkoren 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

Dödläge - definition och bakgrund 5

Dödläge - definition och bakgrund Ömsesidig uteslutning betyder att en tråd kan vara försenad (blockerad) pga 5

Dödläge - definition och bakgrund Ömsesidig uteslutning betyder att en tråd kan vara försenad (blockerad) pga En tråd får inte komma in i en kritisk sekvens (av en delad resurs) om den är upptagen av en annan tråd 5

Dödläge - definition och bakgrund Ömsesidig uteslutning betyder att en tråd kan vara försenad (blockerad) pga En tråd får inte komma in i en kritisk sekvens (av en delad resurs) om den är upptagen av en annan tråd För att systemet ( och all data) ska vara konsistent, för att beräkningar och resultat ska vara förutsägbara och för effektivitetens skull, kan tillgång till en sådan resurs inte bli avbruten, eller utsättas för en sk roll-back ( bakåt-behandling ) 5

Dödläge - definition och bakgrund Ömsesidig uteslutning betyder att en tråd kan vara försenad (blockerad) pga En tråd får inte komma in i en kritisk sekvens (av en delad resurs) om den är upptagen av en annan tråd För att systemet ( och all data) ska vara konsistent, för att beräkningar och resultat ska vara förutsägbara och för effektivitetens skull, kan tillgång till en sådan resurs inte bli avbruten, eller utsättas för en sk roll-back ( bakåt-behandling ) Vi har alltså ingen resource preemption (inget lov för avbrott på resurser annat än -OBS skillnaden! - beräkningstid, dvs processorn, som hanteras med preemptive scheduling - avbrytbar schemaläggning.) 5

Dödläge - definition och bakgrund Ömsesidig uteslutning betyder att en tråd kan vara försenad (blockerad) pga En tråd får inte komma in i en kritisk sekvens (av en delad resurs) om den är upptagen av en annan tråd För att systemet ( och all data) ska vara konsistent, för att beräkningar och resultat ska vara förutsägbara och för effektivitetens skull, kan tillgång till en sådan resurs inte bli avbruten, eller utsättas för en sk roll-back ( bakåt-behandling ) Vi har alltså ingen resource preemption (inget lov för avbrott på resurser annat än -OBS skillnaden! - beräkningstid, dvs processorn, som hanteras med preemptive scheduling - avbrytbar schemaläggning.) Om blockeringen inte tar slut, kan man konstatera ett dödläge (deadlock). 5

Dödläge - definition och bakgrund Ömsesidig uteslutning betyder att en tråd kan vara försenad (blockerad) pga En tråd får inte komma in i en kritisk sekvens (av en delad resurs) om den är upptagen av en annan tråd För att systemet ( och all data) ska vara konsistent, för att beräkningar och resultat ska vara förutsägbara och för effektivitetens skull, kan tillgång till en sådan resurs inte bli avbruten, eller utsättas för en sk roll-back ( bakåt-behandling ) Vi har alltså ingen resource preemption (inget lov för avbrott på resurser annat än -OBS skillnaden! - beräkningstid, dvs processorn, som hanteras med preemptive scheduling - avbrytbar schemaläggning.) Om blockeringen inte tar slut, kan man konstatera ett dödläge (deadlock). Wikipedia säger: Deadlock refers to a specific condition when two or more processes are each waiting for the other to release a resource, or more than two processes are waiting in a circular chain. 5

Dödläge med semaforer Två trådar vill komma åt två resurser och hamnar i ett speciellt läge (som kan bli dödläge), nämligen i ett hold - wait state T1 res 1 res 2 T2 take take take take...... 6

Dödläge med semaforer, kod-exempel T1 T2 T1 T2... S2.take(); S1.take();... S1.give(); S2.give();... S1.take(); S2.take();... S2.give(); S1.give(); S2.take(); S1.take(); S1.take(); S2.take(); blocked blocked 7

Dödläge med semaforer, kod-exempel T1 T2 T1 T2... S2.take(); S1.take();... S1.give(); S2.give();... S1.take(); S2.take();... S2.give(); S1.give(); S2.take(); S1.take(); S1.take(); S2.take(); blocked blocked Ett dödläge kan uppstå om en tråd utför take och blir sen avbruten av schemaläggaren (context switch, kontextbyte, trådbyte). 7

Dödläge med monitor, kod-exempel T1 T2 M1... M1 m1; m1.op1();...... M2 m2; m2.op1();... T1 M2 T2 class M1 { M2 m2; synchronized void op1() { m2.op2(); } class M2 { M1 m1; synchronized void op1() { m1.op2(); } } synchronized void op2() { wait(); } } synchronized void op2() { wait(); } 8

Färdiga lösningar (?) 9

Färdiga lösningar (?) Som så ofta finns det programmeringsspråk eller -verktyg som tvingar programmeraren att bygga säkra system 9

Färdiga lösningar (?) Som så ofta finns det programmeringsspråk eller -verktyg som tvingar programmeraren att bygga säkra system Concurrent Pascal (Hansen, 1979) är ett sådant språk som använder enbart monitorer för ömsesidig uteslutning och tillåter inga referenser framåt, från monitor till monitor. 9

Färdiga lösningar (?) Som så ofta finns det programmeringsspråk eller -verktyg som tvingar programmeraren att bygga säkra system Concurrent Pascal (Hansen, 1979) är ett sådant språk som använder enbart monitorer för ömsesidig uteslutning och tillåter inga referenser framåt, från monitor till monitor. Fördelen är såklart att man undviker problem, Concurrent Pascal påstås göra dödläge omöjligt... 9

Färdiga lösningar (?) Som så ofta finns det programmeringsspråk eller -verktyg som tvingar programmeraren att bygga säkra system Concurrent Pascal (Hansen, 1979) är ett sådant språk som använder enbart monitorer för ömsesidig uteslutning och tillåter inga referenser framåt, från monitor till monitor. Fördelen är såklart att man undviker problem, Concurrent Pascal påstås göra dödläge omöjligt...... nackdelen är dock att man förlorar flexibilitet och att det kan kosta mycket (resurser, beräkningstid, etc). 9

Färdiga lösningar (?) Som så ofta finns det programmeringsspråk eller -verktyg som tvingar programmeraren att bygga säkra system Concurrent Pascal (Hansen, 1979) är ett sådant språk som använder enbart monitorer för ömsesidig uteslutning och tillåter inga referenser framåt, från monitor till monitor. Fördelen är såklart att man undviker problem, Concurrent Pascal påstås göra dödläge omöjligt...... nackdelen är dock att man förlorar flexibilitet och att det kan kosta mycket (resurser, beräkningstid, etc). Dessutom kan man faktiskt fortfarande bygga ett dödläge med en egen enkel resurshantering med monitorer utan framåt-referenser: 9

Färdiga lösningar (?) Som så ofta finns det programmeringsspråk eller -verktyg som tvingar programmeraren att bygga säkra system Concurrent Pascal (Hansen, 1979) är ett sådant språk som använder enbart monitorer för ömsesidig uteslutning och tillåter inga referenser framåt, från monitor till monitor. Fördelen är såklart att man undviker problem, Concurrent Pascal påstås göra dödläge omöjligt...... nackdelen är dock att man förlorar flexibilitet och att det kan kosta mycket (resurser, beräkningstid, etc). Dessutom kan man faktiskt fortfarande bygga ett dödläge med en egen enkel resurshantering med monitorer utan framåt-referenser: class R { boolean occupied = false; } synchronized void request() { while( occupied) wait(); occupied = true; } synchronized void release() { occupied = false; notify(); } R R1, R2; class P1 extends Thread {... R1.request(); R2.request();... } class P2 extends Thread {... R2.request(); R1.request();... } 9

Krav för dödläge (Peterson / Silberschatz) 10

Krav för dödläge (Peterson / Silberschatz) Följande punkter måste vara uppfyllda för att det ska bli dödläge: 10

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. 10

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 sedan på en annan 10

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 sedan 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 10

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 sedan 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 10

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 sedan 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: 10

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 sedan 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 10

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 sedan 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 10

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 sedan 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 10

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 sedan 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 10

Dining philosophers - en klassiker... Philosopher while( true) { think(); preproto(); eat(); postproto(); } preproto() = take fork(s) postproto() = give fork(s) 11

Resursallokeringsgrafer 12

Resursallokeringsgrafer Ett verktyg för att upptäcka cirkulära hold-wait situationer, och för att förstå, vilka trådar och resurser kan inblandas i ett dödläge, 12

Resursallokeringsgrafer Ett verktyg för att upptäcka cirkulära hold-wait situationer, och för att förstå, vilka trådar och resurser kan inblandas i ett dödläge, 1. Rita resurserna (monitorer, semaforer...) 12

Resursallokeringsgrafer Ett verktyg för att upptäcka cirkulära hold-wait situationer, och för att förstå, vilka trådar och resurser kan inblandas i ett dödläge, 1. Rita resurserna (monitorer, semaforer...) 2. Rita alla hold-wait situationer. Pil från en upptagen resurs till en markör för tråden som håller i resursen (kan bli flera markörer för en tråd, en för varje hold-wait) och pil från trådmarkör till resursen den väntar på. 12

Resursallokeringsgrafer Ett verktyg för att upptäcka cirkulära hold-wait situationer, och för att förstå, vilka trådar och resurser kan inblandas i ett dödläge, 1. Rita resurserna (monitorer, semaforer...) 2. Rita alla hold-wait situationer. Pil från en upptagen resurs till en markör för tråden som håller i resursen (kan bli flera markörer för en tråd, en för varje hold-wait) och pil från trådmarkör till resursen den väntar på. 3. Cirkel i ritningen? Då är det risk för dödläge. Hold-wait förbindelserna i cirkeln visar hur många och vilka trådar kan orsaka ett dödläge. 12

Resursallokeringsgrafer Ett verktyg för att upptäcka cirkulära hold-wait situationer, och för att förstå, vilka trådar och resurser kan inblandas i ett dödläge, 1. Rita resurserna (monitorer, semaforer...) 2. Rita alla hold-wait situationer. Pil från en upptagen resurs till en markör för tråden som håller i resursen (kan bli flera markörer för en tråd, en för varje hold-wait) och pil från trådmarkör till resursen den väntar på. 3. Cirkel i ritningen? Då är det risk för dödläge. Hold-wait förbindelserna i cirkeln visar hur många och vilka trådar kan orsaka ett dödläge. 12

Resursallokeringsgrafer, exempel T1... A.take(); B.take(); C.take();... C.give(); B.give(); A.give(); T2... D.take(); C.take(); B.take();... B.give(); C.give(); D.give(); 13

Resursallokeringsgrafer, exempel T1... A.take(); B.take(); C.take();... C.give(); B.give(); A.give(); T2... D.take(); C.take(); B.take();... B.give(); C.give(); D.give(); Ett dödläge kan uppstå om T1 lyckas komma till B.take() och blir sen avbruten av T2, som då lyckas komma till C.take() och börjar vänta på B (som är upptagen av T1). När då T1 får exekvera igen, väntar den i sin tur på C (som är upptagen av T2). 13

Dödläge i cirkel - tåg på räls E F D A C B 14

Dödläge i cirkel - tåg på räls E F D A C B Även i system där ordningen av semafor.take()-anropen är samma för alla trådar, kan det bli problem (se programmet!) 14

Dödläge - svält - livelock 15

Deadlock (dödläge) Dödläge - svält - livelock 15

Deadlock (dödläge) Dödläge - svält - livelock 1. När flera trådar försöker komma åt samma resurs måste en av de lyckas någon gång - annars har vi ett dödläge. 15

Deadlock (dödläge) Dödläge - svält - livelock 1. När flera trådar försöker komma åt samma resurs måste en av de lyckas någon gång - annars har vi ett dödläge. 2. Ifall att ordningen av resursallokering är olyckligt gjort, eller antalet trådar går över en gräns, kan det bli dödläge, dvs ingen tråd lyckas exekvera eller få tillgång till resurserna den behöver. 15

Deadlock (dödläge) Dödläge - svält - livelock 1. När flera trådar försöker komma åt samma resurs måste en av de lyckas någon gång - annars har vi ett dödläge. 2. Ifall att ordningen av resursallokering är olyckligt gjort, eller antalet trådar går över en gräns, kan det bli dödläge, dvs ingen tråd lyckas exekvera eller få tillgång till resurserna den behöver. Starvation (svält) 15

Deadlock (dödläge) Dödläge - svält - livelock 1. När flera trådar försöker komma åt samma resurs måste en av de lyckas någon gång - annars har vi ett dödläge. 2. Ifall att ordningen av resursallokering är olyckligt gjort, eller antalet trådar går över en gräns, 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ält-läge 15

Deadlock (dödläge) Dödläge - svält - livelock 1. När flera trådar försöker komma åt samma resurs måste en av de lyckas någon gång - annars har vi ett dödläge. 2. Ifall att ordningen av resursallokering är olyckligt gjort, eller antalet trådar går över en gräns, 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ält-läge 2. Vi accepterar att det kan bli svält för mindre prioriterade aktiviteter, så att det som är viktigt kan utföras (jfr buffer-exemplet, föreläsning 3). 15

Deadlock (dödläge) Dödläge - svält - livelock 1. När flera trådar försöker komma åt samma resurs måste en av de lyckas någon gång - annars har vi ett dödläge. 2. Ifall att ordningen av resursallokering är olyckligt gjort, eller antalet trådar går över en gräns, 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ält-läge 2. Vi accepterar att det kan bli svält för mindre prioriterade aktiviteter, så att det som är viktigt kan utföras (jfr buffer-exemplet, föreläsning 3). Livelock (levande låsning) 15

Deadlock (dödläge) Dödläge - svält - livelock 1. När flera trådar försöker komma åt samma resurs måste en av de lyckas någon gång - annars har vi ett dödläge. 2. Ifall att ordningen av resursallokering är olyckligt gjort, eller antalet trådar går över en gräns, 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ält-läge 2. Vi accepterar att det kan bli svält för mindre prioriterade aktiviteter, så att det som är viktigt kan utföras (jfr buffer-exemplet, föreläsning 3). Livelock (levande låsning) 1. Om flera trådar försöker komma åt samma resurs(er) men träda tillbaka hela tiden innan de lyckas få tillgång till allt de behöver, hamnar man i ett slags zombie -läge; trådarna är vid liv, men gör ingen nytta. 15

Deadlock (dödläge) Dödläge - svält - livelock 1. När flera trådar försöker komma åt samma resurs måste en av de lyckas någon gång - annars har vi ett dödläge. 2. Ifall att ordningen av resursallokering är olyckligt gjort, eller antalet trådar går över en gräns, 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ält-läge 2. Vi accepterar att det kan bli svält för mindre prioriterade aktiviteter, så att det som är viktigt kan utföras (jfr buffer-exemplet, föreläsning 3). Livelock (levande låsning) 1. Om flera trådar försöker komma åt samma resurs(er) men träda tillbaka hela tiden innan de lyckas få tillgång till allt de behöver, 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 15

Övning 3 Resource allocation graphs, kort exempel Programmeringsuppgift på papper Kort introduktion laboration 3 (tvättmaskin) 16

Sammanfattning Dödläge Resource allocation graphs Man borde kunna rita RAGs och analysera ett system för att hitta risk för dödläge, både utifrån kod eller en systembeskrivning Man borde kunna skriva kod (sekvenser) när man har gjort ett system riskfritt med hjälp av en RAG. Lästips: e-bok: Kap 4, Deadlock (s 79-101) Artikel Resource Allocation Graphs, Roger Henriksson (länk på kursens materialsida, rekommenderas!) 17