Hvorfor trådning? Performance Responsivness

Succeskriterier Forbedring af performance –Opgaverne skal være uafhængige –Jo flere afhængige opgaver, jo mindre forbedring Forbedring af responsivness –Responsivness er et spørgsmål om oplevelse –Jo længere tid en opgave tager, jo mindre virksom opleves applikationen, hvis brugeren ikke har noget at lave eller se på

Fordele Overvågningssystemer med flere uafhængige opgaver Muliggør brugerinteraktion via BGF Muliggør serverhåndtering af flere samtidige klienter Udnytter flerprocessor-systemer optimalt

Ulemper Trådene afvikles uafhængigt af hverandre Afviklingsrækkefølgen synes vilkårlig Samspillet mellem tråde er ofte meget kompleks Problemer med safety og liveness

Trådskifte CPU’en skifter til en ny tråd … –Efter et givent tidsrum, eller –Når en tråd venter på færdiggørelsen af en opgave, fx en I/O-operation …

Processer vs. Tråde Der er mindst to former for samtidighed: –Multiprocessing –Multithreading

Multiprocessing Samtidighed på tværs af applikationer Til heavy-weight opgaver (IIS, SQL, Server, …) Hver proces eksekverer én enkelt tråd

Multithreading Samtidighed i applikationer –Forskellige tråde udfører forskellige opgaver –Perfekt til light-weight opgaver (Metodekald, UI-opdateringer, …)

Multithreading Samtidighed i.NET –Tråde håndteres af CLR –Tråde har deres egen stak (locals), men deler globals og heap

Instantiering af tråde Tråde kaldes ikke, de startes … –Man kan derfor ikke medsende parametre, modtage returværdi og fange exceptions på sædvanlig vis Trådet kode skal håndtere fejl … –Uhåndterede fejl vil terminere applikationen Gør designet simpelt … –Trådning er et minefelt – fælles ressourcer giver anledning til kritiske sektioner, race conditions, deadlock, …

Instantiering af tråde public static void Main() { Thread t; t = new Thread(new ThreadStart(Run)); t.Start() } public static void Run() { // kode }

Trådes livscyklus

Trådsikre klasser Problem –Hvis en tråd afbrydes, medens den arbejder på et objekt, er der risiko for, at objektet efterlades i en inkonsistent tilstand. Dette kan give problemer, når en anden tråd forsøger at få tilgang til objektet

Trådsikre klasser Løsning –Løsningen er at forhindre mere end én tråd ad gangen i at få tilgang til de kritiske områder i koden

Single Threaded Execution Vha. lock(obj) opnår en tråd eneret på et objekt – en lås Låsen frigives, når tråden forlader det kritiske område eller ved kald af metoden Monitor.Wait(obj) på objektet. Kritiske områder på samme objekt deler samme lås!

Liveness problemer Starvation (udhungring) –En tråd, som er i tilstanden ready, får aldrig lejlighed til at køre, fordi der findes andre tråde med højere prioritet Dormancy (dvale) –En tråd, som er i tilstanden blocked on wait, vækkes aldrig med Monitor.Pulse() Deadlock (hårdknude) –To eller flere tråde kæmper om flere fælles ressourcer, og hver tråd efterspørger på samme tid disse ressourcer Premature Termination (for tidlig død) –En tråd termineres for tidligt og hindrer derved andre tråde i at blive vækket. (Evig dvale)

Brug af lock() Nødvendig, hvis man vil lave "trådsikre klasser" Ej omkostningsfrit: Kræver CPU-kraft  langsommere programafvikling "Hellere for mange synkroniserede blokke end for få!" MEN - pas på deadlocks

lock vs. Monitor.Enter/Exit lock(obj) er et alias for: try { Monitor.Enter(obj); // kode... Monitor.Exit(obj); } catch { } finally { Monitor.Exit(obj); }

Monitor –indkapsler fælles ressourcer som private attributter og sikrer trådene enetilgang vha. lock() til de kritiske områder Formål –Overvågning af trådes adgang til fælles ressourcer

Monitor Objekt, hvor de fælles ressourcer er samlet som attributter Der er udelelig adgang til monitorens kritiske områder Én monitor-lock pr. kritisk område

Early notification Problem –Monitor.Pulse() sendes før betingelserne for Monitor.Wait er opfyldt Konsekvens – Wait -tråden vækkes før tid Løsning –Gentjek betingelserne for Monitor.Wait, når Wait -tråden vækkes Konklusion –Anvend altid while (i stedet for if ) i forbindelse med check af wait -betingelser

Early notification 1.Bufferen er tom! 2.C1-tråden er i Wait-tilstand 3.P-tråden generer et nyt element og kalder monitorens synkroniserede put-metode 4.C1-tråden underrettes via Pulse, og tråden går i ready-tilstand 5.P-tråden forlader monitorens put-metode og slipper objekt-låsen på monitoren 6.Bufferen indeholder nu ét element! 7.Trådskifte! 8.C2-tråden trækker et element fra bufferen ved at kalde monitorens get-metode 9.C2-tråden forlader monitorens get-metode og slipper objekt-låsen på monitoren 10.Der er ingen elementer i bufferen! 11.Trådskifte! 12.C1 fortsætter nu fra Wait i monitorens get-metode i forsøget på at trække endnu et element fra bufferen … Dette er ikke muligt!

Guarded Suspension public void Put(int data) { lock(this) { while (queue.Full) Monitor.Wait(this); if (queue.Empty) Monitor.PulseAll(this); this.queue.Enqueue(data); }

Guarded Suspension public void Get(int data) { lock(this) { while (queue.Empty) Monitor.Wait(this); if (queue.Full) Monitor.PulseAll(this); this.queue.Dequeue(data); }

Design af trådet applikation Anvend Producer-Consumer mønstret Anvend de 10 gode trådråd Husk den gyldne regel

10 gode trådråd Bestem tråde Bestem trådmetoder Bestem fælles ressourcer Bestem monitorer - Én monitor for hver uafhængig fælles ressource Bestem monitor-klasser Bestem kritiske sektioner Bestem Wait/Pulse – Et par for hver tilstand, som kræver, at en tråd venter på en anden Fordel Wait og Pulse (Husk ”Guarded Suspension”-mønstret) Lav pseudo-kode for monitor-klassernes metoder Lav pseudo-kode for tråd-klassernes run-metoder

Den gyldne UI-regel UI-baserede.NET-applikationer –Den tråd, som har skabt UI’en ejer UI’en – Ingen anden tråd må tilgå UI’ens kontrolelementer …

Delegater Delegater er objekter, der refererer til en metode – tænk ”funktionspointer” private void MinMethod(...) {. } private void MinMethod(...) {. } delegate - med delegater kan man kalde en underliggende metode på en typesikker måde - med delegater kan man arbejde med metodereferencer på en objektorienteret facon

Window Forms Hvordan ved en knap, hvilken metode den skal kalde ved et click-event? Det ved den heller ikke! Den kalder metoden bagved delegaten … Button Click: delegate private void btnAdd_Click(object sender, EventArgs e) { int i, j, k; i = int.Parse(this.txtNumber1.Text); j = int.Parse(this.txtNumber2.Text); k = i + j; System.Windows.Forms.MessageBox.Show("Sum = " + k); } private void btnAdd_Click(object sender, EventArgs e) { int i, j, k; i = int.Parse(this.txtNumber1.Text); j = int.Parse(this.txtNumber2.Text); k = i + j; System.Windows.Forms.MessageBox.Show("Sum = " + k); }

Delegat-baseret kode i VS. this.btnAdd = new Button(); this.btnAdd.Click += new System.EventHandler(this.btnAdd_Click);. this.btnAdd = new Button(); this.btnAdd.Click += new System.EventHandler(this.btnAdd_Click);