PROCESSPROGRAMMERING Föreläsning ‏ Innehåll: Trådsäkerhet - Memory consitency error - Guarded blocks - Lock Objects - Immutable Objects - Atomiska variabler - Datastrukturer med inbyggd trådsäkerhet

Trådsäkerhet Kommunikation mellan trådar via gemensamma variabler kan dock ge upphov till problem, bl.a.: Trådkollision (”thread interference”)‏ ”Memory consitency error”

Memory consistency error Uppstår när olika trådar har olika ”uppfattningar” om vad som borde vara samma data. Tänk dej att en tråd skall spara data i minnet och en annan tråd skall visa innehållet av datat på bildskärmen I detta fall finns det ingenting som garanterar att det data som den första tråden sparade är synligt för den ”visande” tråden. Nyckeln till att förhindra ”memory consitency errors” är att förstå det såkallade ”happens- before” sambandet

Memory consistency error Detta samband garanterar att data som sparas i ett minne av en tråd blir synligt för en annan tråd. För mer detaljerad information se t.ex följande länk: Ett exempel som garanterar ”happens-before” samband är när en “master thread” väntar på att en eller flera “worker threads” skall avsluta med join() eller get() innan master tråden avläser värdet ur den variabel trådarna delar på Ett annat sätt att förhindra ”memory constency errors” är att använda sej av någon typ av synkronisering

Olika sätt att skapa trådsäker kod  Synkroniserade metoder *  Synkroniserade block *  Intrinsic locks *  Guarded blocks  Lock Objects  Immutable Objects  Atomiska variabler * = Dessa har vi behandlat tidigare i kursen

Guarded Blocks Trådar behöver ofta koordinera sina handlingar. Det vanligaste sätter för koordinering är ”guarded blocks” En ”guarded block” börjar med att undersöka ett tillstånd som måste vara ”true” innan blockeringsmekanismen kan fortsätta En massa steg måste gås igenom för att göra detta på rätt sätt.

Guarded Blocks Anta t.ex. att vi har en metod som ser ut enligt följande: public void guardedMethod { //En enkel ”guard” som loopar. Slösar processortid. Dålig lösning!! while(tillstand == false) { } System.out.println(”Nu får vi fotsätta!”); }

Guarded Blocks Ett effektivare sätt att göra ett ”guarded block” är att anropa metoden wait som finns i klassen Object som upphäver eller inaktiverar innevarande tråd. Metoden wait returnerar inte innan en annan tråd har skickat ett typ av meddelande om att en speciell händelse har uppstått. OBS! En händelse som uppstår behöver inte nödvändigtvis vara den händelse som en tråd väntar på! public synchronized guardedMetod() { //Denna guard loopar endast en gång och väntar på en händelse som inte nödv. är den rätta while(tillstand == false) { try { wait(); } catch (InterruptedException e) {} } System.out.println("Nu får vi fortsätta"); }

Guarded Blocks Varför är metoden på föregående slide synkroniserad?? Anta att d är objektet vi använder för att anropa wait. När en tråd anropar d.wait måste tråden vare ägare av intrinsic låset annars uppstår det ett ”error” Genom att anropa wait från en synkroniserad metod får vi den ifrågavarande tråden att ta över intrinsic låset för objektet d När wait anropas lösgör tråden låset och upphäver exekveringen

Guarded Blocks När någonting har hänt och vi som följd igen kan sätta tilsståndsvariabeln till true kommer en annan tråd att informera om detta genom att anropa Object.notifyAll public synchronized meddelaOmAndratTillstand { tillstand = true; notifyAll(); }

Guarded Blocks Låt oss nu använda oss av ”guarded blocks” för att skapa en klassisk producent- konsument applikation. Följande programkod simulerar en producent-konsument applikation som är osynkroniserad: Fundera på hur du kan använda dej av guarded blocks för att synkronisera produktion och konsumtionen. Dvs. konsumenten skall inte få konsumera innan producenten hunnit producera ett färskt slumptal och producenten skall heller inte få producera om inte konsumenten hunnit konsumera det föregående slumptalet.

Lock Objects Synkronisead kod baserar sej på enkla typer av låsmekanismer. Är lätt att anända men har många begränsningar Mer avancerade låsmekanismer finns inbakat i java.util.concurrent.locks paketet Det finns en mängd olika alternativ i detta paket, tillsvidare nöjer vi oss med att se på det vanligaste gränssnittet, Lock Lock-objekt fungerar i det stora hela väldigt lika som intrinsic locks som används av synkroniserad kod

Lock Objects Liksom intrinsic locks kan endast en tråd äga ett Lock-objekt åt gången. Lock-objekt stöder också wait/notify metoderna via sina associerade Condition objekt Den viktigaste fördelen med låsobjekt är dess förmåga att “ta tillbaka” ett försök att överta ett lås Metoden tryLock backar tillbaka om låset inte är tillgängligt (genast eller efter en timeout period)

Lock Objects Metoden lockInterruptibly backar tilbaka om en annan tråd sänt ett avbrott (interrupt) till låset för det objekt som innevarande tråd försöker ta över.

Immutable Objects Ett ”immutable object” eller omodifierbart objket är ett objekt vars status inte kan ändras efter att det skapats Omodifierbara objekt är speciellt användbara i parallellexekverande program Eftersom omodifierbara objekt inte kan ändra status så kan de inte utsättas för trådkollision (thread interference) eller ”avläsas” i ett inkonsitent tillstånd (”memory consistency error”)‏ Låt oss titta på ett exempel på en klass vars objekt är modifierbara (”mutable”), se

Immutable Objects I exemplet används synkroniserade metoder för att undvika memory consistency error (noggrannare beskrivning finns i exemplet)‏ En alternativ lösning är att använda ”immutable objects” se

Atomiska variabler Ett annat sätt att lösa trådkollision- och memory consistency error problemen är använding av atomiska variabler Är en variabel som inte tillåter samtidig access från flera trådar och möjliggör ”happens before ” samband mellan uppdatering och avläsning av variabeln Paketet java.util.concurrent.atomic definierar klasser som stöder atomiska operationer på enskilda variabler: Se föjande länk för mera information:

Synkronisering eller atomiska variabler? I program där vi endast behöver kontrollera åtkomst till en enskild variabel lönar det sej använda atomiska variabler i stället för synkroniserad kod efterom vi på det sättet undviker onödig synkronisering Användning av atomiska variabler är också snabbare och effektivare än synkronisering.

Datstrukturer med inbyggd trådsäkerhet I Java klassbiblioteket finns även datastrukturer där trådsäkerheten är färdigt inbyggd, dvs. där samtidig åtkomst till datastrukturen automatiskt förhindras. Exempel på sådana datastrukturer är: java.utl.Vectorjava.util.concurrent.BlockingQueue......