Prosesser og Tråder. Ketil Danielsen January 16, en tråd arbeider sekvensielt gjennom program

Transkript

1 Prosesser og Tråder Ketil Danielsen January 16, 2005 Prosess og tråd en tråd arbeider sekvensielt gjennom program en prosess har minst en tråd i gang en tråd er Running (er tildelt CPU), Ready (venter på CPU) eller Blocked (venter data utenfra) hver prosess er tildelt et område i hurtigminnet (prosessens adresseområde) prosesser kan vanligvis ikke lese eller skrive til hverandres minne helt spesielle sharedmem finnes riktignok tråder innenfor en prosess kan lese prosessens minne En enkelt VB hovedtråd Imports System for WriteLine Class Test Shared Sub Main () Dim i as Integer For i = 1 To i = i + 1 Console.WriteLine("teller er " & i) End Class Ressursbehov i ProcExp ser en trådtallet ved å velge inn kolonne for Threads: View:Select Columns. i VB.NET observeres 2-3 admintråder + hovedtråd ved kjøring av Javaprogram ser en 6-7 admintråder og hovedtråd EnTraad trenger kun CPU (tar 100 prosent) la vi på utskrift i hver løkke tar den kun 30 prosent CPU: Console. WriteLine("teller er " & i) nå er det en annen prosess som ligger på prosent (csrss.exe som tar seg av utskrift til skjerm) 1

2 Typer arbeid interaktivt, stort sett I/O mot sluttbruker (tilstand Blocked) tjenester i nett (daemon) innholdsserver (fil, statisk web, epost): mye I/O mot nett og disk (tilstand Blocked) hvis innhold er mellomlagret i cache blir det mindre I/O mot disk, og raskere svar computeserver: lite I/O, mest tallknusing i CPU (tilstand Ready og Running) dynamisk webserver: mye I/O mot database og nett, noe beregning (mest Blocked, noe Ready og Running) printserver: mye I/O mot skriver, disk og nett kernelarbeid: mest bokholderi mot minnet for å koordinere og effektivisere overføring av data mellom ovennevnte tråder og ytre enheter en god del caching av data for å redusere I/O Trådadmin Tråder (i likhet med prosesser) skal forvaltes via admin-api kan en tråd påkalle create, exit, yield, wait, wakeup, setpriority en skal sikre god nok veksling mellom tråder hvis tråd trenger data utenfra må en eventuelt blokkere tråden en av de andre BØR da få overta (dét er hele poenget med tråder) to hovedtyper, userlevel eller kernellevel administrasjon user-level threads hver prosess har et administrativt apparat som kalles runtime system (RTS) trådadm ordnes internt i prosessen uten systemkall (raskt) kernels scheduler veksler mellom prosesser, ikke tråder prosessens RTS veksler grovkornet mellom trådene en blokkert tråd blokkerer hele prosessen kernel-level threads trådadm krever kostbart systemkall en kernel-level tråd kan blokkere uten å blokkere hele prosessen den inngår i kernels scheduler veksler presist mellom tråder Scheduler Activations ønsker at andre tråder i en prosess veksles inn når en gitt tråd venter på (kap ) 2

3 dataoverføring mot ytre enheter at en annen tråd skal komme til et visst stadium kernel varsler prosessens RTS hvis den ser at en tråd venter på hendelse hendelse har inntruffet RTS kan (fordi den ble varslet) foreta omveksling ikke pensum: og InterProcess Communication (IPC) Samarbeidende tråder må utveksle data shell pipeline: cat grep wc (to datakanaler) webleser og server VisualStudio og VB-kompilator Hvordan? mekanisme skrive og lese samme delte adresse (eller fil). Raskt, ingen kopiering atskilt minne, lokalt eller over nett: medfører kostbar kopiering hvordan forhindre forkludring hvordan sikre rekkefølgen Race Condition Forkludring av delt minne er mulig variabel x kan leses og skrives av trådene A og B (samme maskin, samme minne) i tid: B leser x, A leser x, B endrer x, A endrer x B kan komme til å lese og lagre x før A får lagret x fordi scheduler kjøres for hvert klokkeinterrupt og hvem vet når klokka slår? ikke et problem hvis kun én tråd skriver Spm.: Kan det samme skje med en fil (hint: skriverspool i UNIX)? Maskinkode (omtrent) x = x + 1 blir MOV x, R5 ; fra RAM til CPU INC R5 ; aritmetikk i CPU MOV R5, x ; fra CPU til RAM Ved eksekvering blir A avbrutt (se under): MOV x, R5 INC R5 (klokkeinterrupt) (scheduler veksler inn B) (A s registre legges til stack) 3

4 MOV x, R5 INC R5 MOV R5, x (resten) (blokkering) (A s registre hentes fra stack) MOV R5, x Og, x er en mindre enn den skulle vært Et flertrådet program i VB hovedtråd Main() lager trådene slave() alt (metoder, variabler) ligger i samme objekt hver slave henter endringer og oppdaterer en delt variabel beholdning (bank, lager) angsten ligger rundt beholdning: Kan den bli endret av en annen før jeg får lagret min endring? hver slave påkaller hentendring() og blokkerer i påvente ekstern datatilførsel Race Condition i VB uregulert bruk av delt variabel ide fra msdn.microsoft.com Imports System, System.Threading Class enkonto Dim beholdning as Integer = 0 Shared Sub Main() Dim i As Integer For i = 1 To 33 ant barn Dim t As New Thread(AddressOf slave) t.start() Private Shared Sub slave() Dim i As Integer For i = 1 To 100 ganger i KR oppdaterbeh() Private Shared Sub oppdaterbeh() inne i KR Dim endring as Integer endring = 1 eller sjekkinnutganglager() beholdning = beholdning + endring End Class Kritisk region (KR) tråd T s KR: kode der T oppdaterer delte variabler fire regler for mutual exclusion (gjensidig utelukkelse) til enhver tid: Kun en tråd i sin KR uavhengig av CPU s hastighet og antall CPU en som er inne i sin KR kan ikke blokkeres av en annen ingen tråder vil vente for evig på sin KR vanskelig å fremprovosere i eksperiment (men, de kan altså skje) Slå av interrupt (DisInt) scheduler kjøres for hvert hw-interrupt fra klokka 4

5 hvis A ikke kan veksles ut (mens A er i sin KR) er A trygg DisInt(c): CPU-instruksjon som masker ut interrupt fra h/w for CPU c kernel gjør DisInt forut for sine (mange) KR Spm.: Kan vi tillate DisInt fra usertråder? Spm.: Hva med de andre CPU? Låsevariabel l A og B kan lese og endre l inngang i sin KR kun hvis l == 0 (hvis ikke: spinlock, busywait: Les l, test, les l, test,... ) Sett l = 1 etter inngang, og l = 0 ved utgang Spm.: Hva er problemet her? TSL (Test-Set-Lock) en bedre lås CPU kan ha en instruksjon TSL, som i en operasjon leser l, setter l = 1 hvis l = 0 TSL er atomisk, kan ikke avbrytes av klokkeinterrupt funker, men betyr busywait for den som venter Strict Alternation (alltid annen-hver gang) tråd k gjør busywait mens den venter på tur ved utgang av KR: Sett tur til k + 1%N (N konkurrenter) en sikrer rekkefølgen og gjensidig utelukkelse Spm.: Er rekkefølgen viktig? Petersons løsning (for N = 2) k vil inn i KR, men vil først sette i(k) = 1 (sier seg interessert) og setter tur til k deretter: k skal vente med KR (les: busy wait) sålenge det er dens tur og den andre er interessert ved utgang av KR vil k sette i(k) = 0 (si seg uinteressert) unngår unødig venting Spm.: Hvordan vil dette virke med flere enn to interessenter? Priority Inversion noen schedulere gir CPU til høyeste prioritet (s. 108) H og L er to der L har lavere prioritet enn H 5

6 Spm.: Hva skjer hvis H ankommer mens L er i sin KR? Bort med busy wait! mange ideer er skissert med busy waiting (CPU-spoling) for de som må vente (OK for kortvarig venting) mer fornuftig å suspendere disse de blokkerer, men ikke i forbindelse med ekstern datatilførsel, men i påvente av at en annen tråd skal gi klarsignal en som venter gir opp CPU, med systemkall wait() og suspenderes den som er ferdig i KR vekker id med systemkall wakeup(id) Semafor oppfunnet av Edsgar Dijkstra (1965), først tilgjengelig i Algol68 lenge siden s = new Semafor(n) en semafor har privat teller N som i new settes til n public metode up: N++ og wakeup() public metode down: sleep() if N==0; N--; Dijkstra s brukte P() og V() (probieren og verhogen) for down og up Spm.: Hvor ligger race condition her, og hvordan kan forkludring forhindres? alle tråder skal ha tilgang til s gjøre s.down() før KR gjøre s.up() etter KR binær semafor: Semafor(1) Semafor i Java // Geir S. M. Gjersvoll s // semafor in240 H03! public class Semafor{ private int n; public Semafor(int x) { System.out.println ("ny semafor " + x); n=x; public synchronized void P(){ System.out.println ("P() entres!"); if (n==0){ try { System.out.println ("P() wait()!"); wait(); catch (InterruptedException e){ else { n=n-1; public synchronized void V() { n=n+1; System.out.println 6

7 ("P() notify()!"); notify(); Skriver-leser med semafor utgangspunkt K plasser i delt minne skriver kan ikke putte hvis alle plasser tatt leser kan ikke hente hvis ingen plasser fylt Kritisk region: Der skriver skriver og der leseren leser trenger tre semaforer en for mutex til KR: mutex = new semafor(1) en for fulltest: full = new semafor(0) en for tomtest: tom = new semafor(k) realisering Mutex leser tester tomhet med tom.down() og avslutter med full.up() for å eventuelt vekke skriveren skriver tester fullhet med full.down() og avslutter med tom.up() for eventuelt å vekke leseren en variabel som er låst eller ikkelåst (og, hvordan er det forskjellig fra lås eller TSL?) userspace realisering hvis TSL (og gjerne thread_yield) er tilgjengelig mutexex insp msdn.microsoft.com Imports System, System.Threading Class Test Private Shared mut As New Mutex() Shared Sub Main() Dim i As Integer For i = 1 To 7 Dim t As New Thread(AddressOf w) t.name = [String].Format(i) t.start() Private Shared Sub w() Dim i As Integer For i = 1 To 98 mut.waitone() delressurs() mut.releasemutex() Private Shared Sub delressurs() Dim t as Thread = Thread.CurrentThread Console.WriteLine("inn "& t.name) Thread.Sleep(500) liksom-kr Console.WriteLine("ut " & t.name) End Class 7

8 Risky semaforer feil bruk av semaforer kan gi vranglås P: empty.down; mutex.down; (KR) mutex.up; full.up; C: full.down; mutex.down; (KR) mutex.up; empty.up; feilkodet (s. 115) Monitor P: mutex.down; empty.down; (KR) mutex.up; full.up; vranglås hvis buffer er fullt. tråders skriving og lesing reguleres av en egen monitorklasse som låser objektet med egen låsevariabel i tillegg: condition variables som kan ta wait og signal scheduler bestemmer hvem som vekkes ved signal dropper signalet hvis ingen venter unngår programmererfeil, og er lettere i praksis enn i læreboken monitor krever delt minne, uaktuelt mellom maskiner Monitor i Java et objekt har metoder metode kan deklareres synchronized: ved inngang låses objektet et låst objekt legger nye metodekall i en kø ved utgang frigis objektet JVM velger neste tråd fra objektkøen Gjersvoll s semaforløsning er omtrent en monitor Message Passing istedetfor lesing og skriving til delt minne, sendes beskjeder mellom prosessene beskjedene kopieres flere ganger (kostbart) datakom (in115, in270) befrakteren tap av data underveis: ack, nack, timeout ack (retransmit data), timeout data (retransmit nack) sekvensnumre i tilfelle tap, duplikat og endret rekkefølge flytkontroll: unngå å sende mer enn mottaker kan ta unna opphopningskontroll: unngå å sende mere enn befrakteren kan ta unna. autentisering (mellom maskiner, stort Internett) 8

9 adressering (millioner av maskiner) Eksempel fig 2.29, s. 121 C lager N tomme konvolutter som sendes til P P lager meldinger, men blokkerer inntil tom konvolutt foreligger C blokkerer inntil melding foreligger fra P (i konvolutt), sender umiddelbart tom konvolutt tilbake Spm.: Drøft forskjell i arbeidshastighet mellom C og P, altså flytkontroll. Barrierer flere tråder skal starte neste fase samtidig en tråd må da vente til de andre er ferdig dette løses med et systemkall barrier() barrier() er i praksis en wait() der alle vekkes samtidig Spm.: Hva kreves for at dette skal virke? 9