Tråd-definition 2. XP-program: Dissektion af boldapplet (fortsat) En tråd er en separat programudførelse = separat "flow of control" = rækkefølge af programinstruktioner, der udføres En tråd kan mere konkret defineres som bestående af program + tilstand hvor tilstand = data (variables værdier) + instruktions-peger + procedurestak Flere tråde i samme proces: kan udføre instruktioner fra samme program kan dele data Formål med flertrådning: Samtidig udførelse af uafhængige delopgaver Samtidig udskrivning af to uafhængige talrækker (Xiaoping s. 370-374) 2 tråde udskriver hver sin talrække Hændelsesorienterede programmer 1 tråd lytter til input/hændelser, og udfører de udløste handlinger 1 tråd animerer (f.eks. gentagen flytning + udskrivning af bolde) Servere f.eks. webservere 1 tråd lytter efter nye forespørgsler fra klienter 1 tråd for hver klient-forespørgsel til at besvare forespørgslen Begrebet "en tråd" kan forstås ud fra at betragte et simpelt program: et enkelt kontrol flow sætningerne i programmet afvikles en ad gangen flowet følger dels den tekstlige rækkefølge dels hoppes der ved goto, procedurekald m.m. Definition af tråd? intuitivt kan man tegne en tråd som viser udførelses-rækkefølgen alm.sekv. goto? proc.kald
Eksempel på uafhængige delopgaver Udførelse af to uafhængige delopgaver (begge tråde udfører samme programdel) class Counter implements Runnable { // jf. Xiaoping s. 373 int count, inc, delay; Lad os sige vi vil have udført flg. to opgaver - samtidigt: 1) med 33/1000 sekunds mellemrum udskrive 0, 1, 2, etc. 2) med 100/1000 sekunds mellemrum udskrive 0, -1, -2, etc. public Counter(count, inc, delay) { this.count = count; // etc. public static void main(..){ new Thread(new Counter(0,1,33)).start(); new Thread(new Counter(0,-1,100)).start(); public void run() { while(..) {udskriv; inkrementer; vent JVM's trådskedulator sørger for at begge tråde kommer til Pauser er styret via sleep() Mere fleksiblet, f.eks. lettere at ændre pauselængde. Sammenligning: Flere samtidige kørende programmer (processer) Moderne cpu-er og operativsystemer understøtter afvikling af flere samtidig programmer, der løser hver sin opgave Editor, Java-oversætter, browser,.. Hver af disse programmer indeholder mindst en tråd. Operativsystemets scheduler fordeler cpu-tid imellem dem, således at det fremstår som om de har cpu-en for sig selv Uafhængighed mellem disse programmer betyder set fra programmørens side at de kan udvikles uafhængigt af de andre programmer, selv om de kommer til at køre samtidigt. Flere samtidige tråde i samme program Java-køretidssystemet fordeler køretid mellem trådene Det fremtræder som om den enkelte tråd har cpu-en for sig selv en fordel at udvikling af programdel til at løse delopgave kan ske så uafhængigt som muligt fra andre programdele f.eks., udskrivning af 1 talrække kan programmeres uden at tænke på om der samtidig skal udskrives en anden talrække Tråde der hører til det samme (Java-) program kan have adgang til samme data (f.eks. data om hvor en animeret bold befinder sig) dette skaber en indbyrdes afhængighed mellem trådene i programmet kan være svær at styre - er emnet næste uge (synkronisering) Tråde der hører til forskellige programmer har ikke adgang til de samme data (men alle kan adgang til filsystemet m.v.) bl.a. af sikkerhedsmæssige grunde er det nødvendigt med vandtætte skodder mellem forskellige programmer
Afrunding af trådbegrebet: samtidighed, parallelitet, distribution Samtidighed er pseudo-samtidighed hvis der kun er 1 cpu Ægte samtidighed kræver flere cpu-er, og at operativsystemer kan fordele trådene til hver sin cpu. Begrebet parallelitet (som i parallelle algoritmer) = normalt en form for samtidighed med ægte samtidighed vhja. flere cpu-er på samme eller tæt forbundne maskiner opdeling i delopgaver for at opnå hurtigere programafvikling Begrebet distribution (distribuerede systemer, distr. applikationer) = normalt en form for samtidighed med ægte samtidighed delopgaver løses på hver sin maskine, ofte geografisk adskilt opdeling i delopgaver "naturlig" (du browser hjemme, data er i USA) 2. XP-program: Dissektion af boldapplet (fortsat) class Thread (java.lang.thread) class Thread public Thread(Runnable r) public void start() public void run() public static void sleep() public Thread currentthread() public void interrupt()... En instans af Thread repræsenterer en Java-tråd hvor programmet er r.run() (men er ikke selve tråden) Thread.sleep() blokerer den aktuelt kørende tråd sleep() er statisk currentthread() giver reference til det "aktuelt kørende" Thread-objekt Samme effekt af Thread().sleep() og Thread.currentThread.sleep() Thread.sleep() class Counter implements Runnable { public Counter(..) {.. public static void main(..){.. public void run() { while (true) { System.out.print(count + " "); try {Thread.sleep(delay); catch (Interrupted Excetion e) { count += incr; Alternativ: for (int i=0; i < 1000000; i++); svær at styre pausens længde optager cpu-tid sleep() m.fl. kaster undtagelser af typen InterruptedException bruges til at håndtere program-genereret vækning af tråd (før tidsfrist)
Tilstande for tråde new Thread(..) Blocked waiting... sleeping wait() notify(), notifyall() sleep() (time out) Runnable skabt, men endnu ikke kørende start() Runnable-objektets run() returnerer død 2. XP-program: Dissektion af boldapplet (fortsat) interrupt() class Konto { Bankkonto - deling af variable int kontonummer; long saldo; Flere tråde kan dele de samme variable! boolean hæv(long hævebeløb) { if (hævebeløb <= saldo) { // "read" af saldo mhp. test long nysaldo = saldo - hævebeløb; // "read" af saldo mhp. subtraktion saldo = nysaldo; // "write" af ny værdi til saldo return true; Eksistensen af andre tråde er skjult f.eks. fordeles automatisk af JVMs skedulator Men hvis der rent faktisk er andre tråde så har disse samtidigt adgang til delt data: bl.a. saldo der kan opstå inkonsistens
To tråde hæver samtidigt: 1000 kr. forsvinder saldo er en delt variabel: begge tråde har adgang til den amount og nysaldo er lokale variable i hæve-metoden Før: saldo = 1000 Tråd 1 hæver 1000: (amount <= saldo) // OK: 1000 <= 1000 nysaldo = 0 // (saldo - amount) saldo = 0 // (saldo = nysaldo) Tråd 2 hæver 1000: (amount <= saldo) // OK: 1000 <= 1000 nysaldo = 0 // (saldo - amount) saldo = 0 // (saldo = nysaldo) Inkonsistens: saldo afspejler ikke hvad der rent faktisk er hævet tid class Konto { int kontonummer; long saldo; boolean hæv(long hævebeløb) { if (hævebeløb <= saldo) { long nysaldo = saldo - hævebeløb; saldo = nysaldo; return true; Atomicitet Metode hæv skal være atomisk (udelelig) for at sikre konsistens dvs. udførelsen skal afsluttes før andre tråde kommer til (nok at metodens betingede sætning af atomisk) Metode-kvalifikator: synchronized Implementation af synchronized synchronized boolean hæv(long hævebeløb) { if (hævebeløb <= saldo) { long nysaldo = saldo - hævebeløb; saldo = nysaldo; return true; Ethvert objekt kan beskyttes med synkronisering Implementation i class Object For at udføre s. kode: synchronized sikrer at maksimalt 1 tråd kan udføre metoden rækkevidde maks. 1 tråd kan udføre hæv-metoden i instansen (kontoen) maks. 1 tråd kan hæve/indsætte/.. på kontoen hvis disse metoder også er s. andre tråde kan udføre ikke-s. metoder i instansen f.eks. class Konto Er låsen ledig? Hvis NEJ: i kø hvis JA tag låsen udfør kode frigiv låsen
Begreber : hvad har vi opnået? class Konto { synchronized boolean hæv(long hævebeløb) { if (hævebeløb <= saldo) { long nysaldo = saldo - hævebeløb; saldo = nysaldo; return true; Metode hæv (dens betingede sætning): er en kritisk region er ikke tråd-sikker udførelse af koden skal være atomisk (må ikke deles/afbrydes) samtidig udførelse kan give racing / race conditions Med multitrådning har vi opnået samtidighed hvilket kan give 1. lettere programudvikling (hver delopgave udvikles med smal grænseflade til andre delopgaver) 2. bedre performance (mens 1 tråd venter på input, kan andre fortsætte) Med synchronized kan vi kontrollere/begrænse samtidigheden metode: tvinge tråde til at vente Vigtigt kun at begrænse samtidigheden når det er nødvendigt (jf. målsætning 2) Tråde og animering (XP 282ff) 2. XP-program: Dissektion af boldapplet (fortsat) 1. Hvor mange tråde er der brug for når programmet udvides til spilprogram? 2. Hvad sker når animatoren kalder repaint()..., repaint(), repaint(), repaint(),... 3. update() vs. paint() - hvorfor overskrive begge?
Hvor mange tråde er der brug for? Spilprogram på basis af boldappletten: 1. Hovedtråden Opretter applet/vindue, og lytter derefter til: kald af repaint() -> kald af update()/paint() hændelser -> kald af lyttermetoder hændelser -> kald af start(), init(), stop() FinalBouncingBall med delegering af animering + dobbeltbufring (XP s. 282) 2. Animeringstråden genererer "puls" til at bevæge + male 3. Flere tråde kan være nyttige hvis man laver objekter med "speciel bevægelse" f.eks. en bevægelse hvis hastighed kan reguleres uafhængigt af de andre objekters hastighed FinalBouncingBall update()/paint() (jf. XP s. 281) public class BouncingBallCanvas extends Canvas implements DBComponent { public void update(graphics g) { dbhandler.update(g); public void paint(graphics g) { //???? update(g); public void paintframe(graphics g) {.. update() vs. paint(): hvilke(n) skal overskrives i Applet-subklasser? Hvis subklasser overskriver update(): skal de selv sørge for at gentegne hele baggrunden men så slipper de for at vente på at appletkonteksten gentegner baggrunden. Hvis man bruger dobbelt-bufring: bør man overskrive update() fordi man alligevel selv skal tegne baggrunden (da man jo ikke tegner i det grafikobjekt der er skabt i konteksten, men tværtimod overskriver det med ens egen "buffer") Definitionen af paint() skal fange direkte kald af paint() fra konteksten, der sker uden om update(). paint() kaldes direkte af konteksten ved f.eks. window resizing dvs. en systemgenereret hændelse, modsat repaint(), der kommer fra applikationen selv
repaint() --> update(), paint() Når konsteksten kalder update() efter applikations-genereret repaint(): 0. Muligvis ventes der lidt først. 1. Graphics g = det nuværende billede (det sidst tegnede); 2. kald af update(g); // altid hele g! (svarende til components størr.) 3. tegn(g); // repaint(<rect>) => tegn(g,<rect>) Container superklasse opfanger kald af update()/paint() hvis ikke overskrivet i subklasser: public void update(grahpics g) { g.setcolor(getbackground()); // vælger baggrundsfarven g.clearrect(0, 0, width, height); // udfylder g med farven g.setcolor(getforeground()); // vælger forgrundsfarven paint(g); 2. XP-program: Dissektion af boldapplet (fortsat) public void paint(graphics g) { {stort set tom definition {men kan kalde paint() i alle subkomponenter class Ball { Kollision Diagram over animerings-cyklus (Thomas) static boolean Collide(Ball b1, Ball b2) { if (Ball.position.x...) return true; Kollision hvis afstand mellem centrum er mindre end 2*radius Afstand regnes ud med Pythagoras' formel for siderne i en retvinklet trekant: a 2 + b 2 = c 2 (x,y) (x-radius,y-radius)
Diagram over animerings-cyklus (Niels)