1 - 1 Rio syksy 2005 Liisa Marttinen Prosessit voivat häiritä toisiaan! yhteinen muisti k=k+1; i=i-1 k=k+1; i=i-1; i: 10 k: prosessi i prosessi j Prosessien.

1 - 1 Rio syksy 2005 Liisa Marttinen Prosessit voivat häiritä toisiaan! yhteinen muisti k=k+1; i=i-1 k=k+1; i=i-1; i: 10 k: prosessi i prosessi j Prosessien tai säikeiden yhteistoiminta pitää varmistaa! 5

1 - 2 Rio syksy 2005 Liisa Marttinen Prosessien toiminta pitää jotenkin synkronoida! Esim. tuottaja ja kuluttaja,joiden välissä on puskuri Mitä ongelmia voi syntyä? Mitä toimintoja tässä pitää synkronoida? tuottaja kirjoittaa puskuriin kuluttaja lukee puskurista puskurin käsittely kirjoittamisen ja lukemisen tahdistus

1 - 3 Rio syksy 2005 Auvo Häkkinen Rinnakkainen data  poissulkeminen Esim. yhteinen puskuri  datan ajantasaisuus read - update - write Rinnakkainen suoritus  synkronointi Esim. tuota - kuluta Resurssien jakelu  lukkiutuminen Joku huutaa lisää Vuorojen jakelu  nälkiintyminen Onneton prioriteetti Ratkottavien ongelmien aiheita antavat…

1 - 4 Rio syksy 2005 Auvo Häkkinen Täysin Poissulkeminen erilliset Kilpailu Lukkiutuminen prosessit Nälkiintyminen Prosessit Poissulkeminen epäsuorasti Yhteistyö Lukkiutuminen tietoisia toisista Yhteinen muistiNälkiintyminen Datan ajantasaisuus Prosessit suorasti Yhteistyö Lukkiutuminen tietoisia toisista SanomanvälitysNälkiintyminen ks. Stallings Tab 5.1 Suoritusjärjestys / ajoitus Prosessin lopputulos

1 - 5 Rio syksy 2005 Liisa Marttinen Atomisuus (atomic action) alkutila tilamuutos välitiloja ei näy tila muutoksen jälkeen yksittäinen konekäsky on atominen usean konekäskyn vaatima muutos = kriittinen alue (critical section) on tehtävä ’atomiseksi’ keskinäisellä poissulkemisella (mutual exclusion) muut prosessit eivät pääse käsittelemään tilamuutoksen muuttujia eli suorittamaan omaa kriittista aluettaan

1 - 6 Rio syksy 2005 Poissulkeminen Ohjelman perusmalli process CS[i=1 to n] { # n rinnakkaista prosessia while (true) { ei kriittistä koodia ei kriittistä koodia; } Ohjelmoi kriittiset alueet lyhyiksi! Vain välttämätön Entry protocol # varaa # käytä (exclusive!) Exit protocol # vapauta

1 - 7 Rio syksy 2005 Halutut ominaisuudet Poissulkeminen Vain yksi prosessi kerrallaan suorituksessa kriittisellä alueella Ei lukkiutumisvaraa, ei ‘elohiirtä’ Jos useita sisäänpyrkijöitä, jotain onnistaa Ei tarpeettomia viipeitä Jos alue vapaa, pääsy sallittava Lopulta onnistaa, ei ‘nälkiintymistä’ Kukaan ei joudu odottamaan ikuisesti 3 safety properties + liveness property deadlock livelock

1 - 8 Rio syksy 2005 Lukkomuuttujat, Spin Locks Boolean-muuttuja lock Lock== true kriittinen alue varattu (in1 V in2 V … V inN) lock==false kriittinen alue vapaa Entry protocol while (lock) ; # aktiivinen odotus, “pörrää” # check again if (!lock) # busy loop lock=true; Exit protocol lock=false;

1 - 9 Rio syksy 2005 Test-and-Set-käsky Oma konekielen käsky atominen laitetason suoritus (execute-vaihe) argumentti: lukkomuuttuja boolean paluuarvo TS L merkitys: merkitään varatuksi! Käyttö: LOOP: TS L JUMP LOOP....... Saa edetä! Jää odottamaan!

1 - 10 Rio syksy 2005 Poissulkeminen lukkomuuttujaa käyttäen lock L=1; # käytä lukitsemaan tiettyä kriittistä aluetta # sopimus prosessien kesken! process CS [i=1 to N] { # n rinnakkaista! while (true){ ei kriittistä koodia; } Tulkinta: L=1  yhdellä lupa edetä LOCK(L); # varaa # käytä (exclusive!) UNLOCK(L); # vapauta

1 - 11 Rio syksy 2005 Semaforit P() aka WAIT() aka Down() jos kriittinen alue vapaa, lukitse se ja jatka eteenpäin jos kriittinen alue varattu, odota V() aka SIGNAL() aka Up() jos joku odotusjonossa, päästä joku etenemään muuten vapauta kriittinen alue atomisia semafori S P(S) V(S) S.arvo S.jono public private alkuarvo

1 - 12 Rio syksy 2005 Poissulkeminen semaforia käyttäen sem mutex=1; # vain perinteinen muuttujan nimi process CS [i=1 to N] { # rinnakkaisuus! while (true){ ei kriittistä koodia; } yksi semafori kullekin erilliselle kriittiselle alueelle huomaa oikea alkuarvo P(mutex); # varaa # käytä (exclusive!) V(mutex); # vapauta

1 - 13 Rio syksy 2005 Ehtosynkronointi Tapahtuma: “mikä tahansa kiinnostava” puskuri_täynnä, io_valmis, laskenta valmis, kriittinen alue vapaa (Looginen) tapahtuma  semaforimuuttuja Kumpi ehtii ensin synkronointikohtaan?  tarvitsee paikan missä odottaa (~jonottaa) Prosessi P1 käskyjä… kerro tapahtumasta käskyjä… Prosessi P2 käskyjä… odota tapahtumaa käskyjä...

1 - 14 Rio syksy 2005 Synkronointi semaforia käyttäen sem A_Ready = 0; 0  ”ei ole tapahtunut”, 1  ”on tapahtunut” Kumpi ehtii ensin? Oikea alkuarvo? Tuottaja tuota A… V(A_ready); … Kuluttaja … P(A_ready); kuluta A…

1 - 15 Rio syksy 2005 Puomisynkronointi sem arrive1 = 0, arrive2 = 0; process Worker1 { …käsittele alkuosa 1… V(arrive1); # lähetä synkronointitapahtuma P(arrive2); # odota toista prosessia …käsittele loppuosa 1… } process Worker2 { …käsittele alkuosa 2… V(arrive2); # lähetä synkronointitapahtuma P(arrive1); # odota toista prosessia …käsittele loppuosa 2… } Huomaa järjestys!

1 - 16 Rio syksy 2005 Kilpailutilanne V(arrive); P(continue); koordinaattori P(arrive) OK N kertaa! V(continue) N kertaa; Mitä tässä voi tapahtua?

1 - 17 Rio syksy 2005 Halkaistu binäärisemafori (Split binary semaphore) semaforit empty ja full binäärisemaforeja, koska voivat saada vain arvoja 0 ja 1 koska aina toisella niistä on arvona 1 ja toisella 0, niin niiden voidaan katsoa olevan yhdestä semaforista halkaistuja osia voidaan halkaista myös useampaa osaan: N kappaletta semaforeja, joista aina yhdellä on arvona 1 ja muilla 0 halkaistu binäärisemafori huolehtii myös keskinäisestä poissulkemisesta: vain yksi kerrallaan pääsee suorittamaan sen suojaamaa kriittistä aluetta, jos yhdellä semaforilla alkuarvona 1, muilla 0 kaikilla prosesseilla koodissaan ensin P-operaatio semaforiinsa Se prosessi (yksi niistä prosesseista) aloittaa, jonka P- operaation kohteen semaforin arvo on 1.

1 - 18 Rio syksy 2005 Viestikapulan välitys (Baton passing) semafori ~ viestikapula; koska semaforit e, r ja w muodostavat jaetun binäärisemaforin, niin kulloinkin yhdellä niistä on arvo 1 ja muilla arvo 0 Vain yksi etenee kerrallaan kriittisillä alueilla pyydettävä etenemislupaa: P(e) se etenee, joka ‘saa’ haltuunsa semaforin e Muiden odotettava täysin uusi lukija tai kirjoittaja: P(e) vuoroaan jonottamaan jääneet lukijat ja kirjoittajat: Jos etenijän pyyntöön ei voi suostua: Lukijat: V(e); P(r) (jää odottamaan lukijan vuoroaan) Kirjoittajat: V(e); P(w) (jää odottamaan kirjoittajan vuoroaan)

1 - 19 Rio syksy 2005 Semaforin r jonossa odottavat lukijat Semaforin w jonossa odottavat kirjoittajat Entry- semaforin e jonossa odottavat Voiko mennä lukemaan / kirjoittamaan? Aina vapautetaan entry-semafori seuraavalle! tietokannan käsittely lopputoimet: poistutaan ja valitaan seuraava kriittiselle alueelle pääsijä. Päästetäänkö lukija, kirjoittaja vai uusi tulija? laskurit dr ja dw kertovat odottavien lukumäärän.

1 - 20 Rio syksy 2005 Resurssien hallinta, Yleinen ratkaisu (baton passing) pyydä(parametrit) P(mutex); # poissulkeminen if (pyyntöön ei voi suostua) DELAY; # odota semaforissa anna resurssi; SIGNALNEXT; vapauta(parametrit) P(mutex); palauta resurssi; SIGNALNEXT; DELAY ~ V(mutex), P(odotussemafori) SIGNALNEXT ~ V(odotussemafori) else V(mutex) DELAY: Älä jätä prosessia Blocked-tilaan tärkeä semafori kiinni! SIGNALNEXT: Herätä odottaja ja jätä kriittinen alue kiinni (baton passing). Vapauta semafori, jos ei ole odottajia!

1 - 21 Rio syksy 2005 Palvelujärjestys Semaforin jonot aina FCFS Ongelma? Jäljellä 10 sivutilaa, eka haluaa 12, toka 5! Voiko semaforiin liittää prioriteetin? Jonotusjärjestys? Baton passing- tekniikka: eri luokille omat jonot Montako erilaista? Dynaaminen vuorottelu? Kaikki mahdolliset varattavat sivutilakoot (1… N) Ratkaisu: yksityiset semaforit + oma jono Kullekin prosessille oma semafori, jossa odottaa yksin Vuoron antamiseen käytettävä tietorakenne (jono) erikseen alkiossa semafori ja yleensä tietoa, jonka perusteella valitaan Vuoron antaja valitsee sopivan semaforin vuorojonosta, ja päästää liikkeelle semaforissa odottavan asiakkaan

1 - 22 Rio syksy 2005 Prosessien synkronointi monitorilla poissulkeminen (mutual exclusion) implisiittistä vain yksi prosessi voi olla aktiivisena monitorissa eli suorittamassa jotain monitorin proseduuria ei useaa prosessia suorittamassa samaa proseduuria ei useaa prosessia suorittamassa eri proseduureja ohjelmoijan ei siis tarvitse huolehtia tästä ehtosynkronointi ohjelmoijan vastuulla; vain ohjelmoija tietää, millaista synkronointia prosessien välillä tarvitaan täytyy ohjelmoida eksplisiittisesti ehtomuuttujia (condition variables) käyttäen

1 - 23 Rio syksy 2005 (Odotusehto) WAIT(A); SIGNAL(A); Odotusehto ==false; P1, P3,P5 P2 P4 P5 while? if? A Condition passing: jätetään odotusehto ’päälle’ => uudet tarkastavat ja menevät odottamaan odotuksesta vapautettu ei enää tarkasta ehtoa (IF!!) Kilpailutilanne!

1 - 24 Rio syksy 2005 Kanavat (Andrews) Yhteinen ’postilaatikko’ jono sanomia, FIFO kaikki kanavan sanomat rakenteeltaan samanlaisia chan ch(type 1 id 1, …, type n id n ) ch: kanavan nimi type i id i : sanoman osien tyypit, ja nimet (saavat puuttua) Esim. chan input(char); chan disk_access (int cylinder, int block, int count, char* buffer); chan result[n] (int); # kanavien taulukko

1 - 25 Rio syksy 2005 Operaatiot send kanava(lauseke 1, …, lauseke n ) lähetä sanoma kanavaan receive kanava(muuttuja 1, …, muuttuja n ) vastaanota sanoma kanavasta empty(kanava) tarkista onko kanava tyhjä sanomista Esim. send disk_access(cylinder+2, block, count, buf) receive result[i](sum) empty(input) Ei ota kantaa minkä prosessin kanssa kommunikoi!

1 - 26 Rio syksy 2005 Monitori  palvelinprosessi monitor Mname { declaration of permanent variables; intialization code; procedure op (formals) { body of op; } process Server { int clientID; declaration of other permanent variables; initialization code; while (true) { receive request (clientID, input); code from body of operation op; send reply[clientID] (result) }

1 - 27 Rio syksy 2005 Asiakkaat ja monen palvelun palvelija Pyyntökanava Asiakkaiden tuntema julkinen kanava käytännössä: IP-osoite ja porttinumero Yksi pyyntökanava sanoma kanavaan  tulkitse tyyppi, valitse palvelu tai dedikoitu kanava kullekin palvelulle valitse palvelu  lähetä sopivaan kanavaan Vastauskanava Palvelijan tuntema (staattinen) [Tällä kurssilla] Jokaisella asiakkaalla oma yksityinen kerro oma identiteetti pyyntösanomassa Asiakas kertoo pyynnössä (dynaaminen) käytännössä: oma IP-osoite ja porttinumero

1 - 28 Rio syksy 2005 process philosofer[i=0 to 4] { while (true) { think(); send request(i); receive reply[i](); eat(); send release(I); } Aterioivat filosofit + sihteeri, dedikoidut kanavat chan request(int), release(int), reply[5]( ); sem mutex=1; process secretary { co while (true) { receive request(philo); P(mutex); state[philo]=HUNGRY; consider_allocation_to(philo); V(mutex); } // while (true) { receive release(philo); P(mutex); state[philo]=THINKING; consider_allocation_to(philo-1); consider_allocation_to(philo+1); V(mutex); } oc } Huomaa rinnakkaisuus! Miten odottaa yhtä aikaa kahdesta eri kanavasta?

1 - 29 Rio syksy 2005 Monitori vs. Palvelija proseduurikutsu vs. kanava & sanoma poissulkeminen monitori: implisiittisesti, ei semaforeja! palvelija: palvele yksi asiakas kerrallaan, uudet pyyntösanomat jäävät kanavaan synkronointi monitori: jos ei saa edetä, wait(ehtomuuttuja) kutsunut prosessi nukahtaa palvelija: jos ei saa edetä, laita sisäiseen jonoon palvelija ei voi nukahtaa!

1 - 30 Rio syksy 2005 Klassisia malleja Bounded buffer (tuottaja – kuluttaja, suodin) Resurssien allokointi (asiakas – palvelija) Lukijat/kirjoittajat (luokan vuorot) SJN-skedulointi (priority wait) Aikaviipaleet ja ajastimet (vuorottamispalvelu) Nukkuva parturi (prosessien kohtaaminen) Aterioivat filosofit (lukkiuma) (hajautettu resurssien jakelu)

1 - 31 Rio syksy 2005 Arkkitehtuureja liukuhihna, suodin tuottaja – kuluttaja asiakas – palvelija vertaistoimijat (peer-to-peer,P2P) monipuolisemmat rakenteet: heartbeat yms. ryhmä: keskitetty, rengas, symmetrinen

1 - 32 Rio syksy 2005 Evaluoi Oikeellisuus Suorituspolkujen analyysi Tilamallit Suorituskyky Yleisrasite Komponentti Kommunikointi / ryhmän kommunikointi Rinnakkaisuusaste Selvitä aina, kuinka järjestelmä käyttäytyy!

1 - 1 Rio syksy 2005 Liisa Marttinen Prosessit voivat häiritä toisiaan! yhteinen muisti k=k+1; i=i-1 k=k+1; i=i-1; i: 10 k: prosessi i prosessi j Prosessien.

Samankaltaiset esitykset

Esitys aiheesta: "1 - 1 Rio syksy 2005 Liisa Marttinen Prosessit voivat häiritä toisiaan! yhteinen muisti k=k+1; i=i-1 k=k+1; i=i-1; i: 10 k: prosessi i prosessi j Prosessien."— Esityksen transkriptio:

Samankaltaiset esitykset

Projektista

Palaute

Kirjaudu sisään

Kirjaudu sisään sosiaaliverkostojen kautta:

1 - 1 Rio syksy 2005 Liisa Marttinen Prosessit voivat häiritä toisiaan! yhteinen muisti k=k+1; i=i-1 k=k+1; i=i-1; i: 10 k: prosessi i prosessi j Prosessien.

Samankaltaiset esitykset

Esitys aiheesta: "1 - 1 Rio syksy 2005 Liisa Marttinen Prosessit voivat häiritä toisiaan! yhteinen muisti k=k+1; i=i-1 k=k+1; i=i-1; i: 10 k: prosessi i prosessi j Prosessien."— Esityksen transkriptio:

Samankaltaiset esitykset

Projektista

Palaute