prosessit voivat häiritä toisiaan!
DESCRIPTION
k=k+1; i=i-1;. k=k+1; i=i-1. Prosessit voivat häiritä toisiaan!. yhteinen muisti. prosessi j. prosessi i. i: 10. k:. 5. Prosessien tai säikeiden yhteistoiminta pitää varmistaa!. Liisa Marttinen. puskurin käsittely. kirjoittamisen ja lukemisen tahdistus. - PowerPoint PPT PresentationTRANSCRIPT
1 - 1Rio 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 - 2Rio 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 - 3Rio 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 - 4Rio syksy 2005 Auvo Häkkinen
Täysin Poissulkeminen erilliset Kilpailu Lukkiutuminen
prosessit Nälkiintyminen
Prosessit Poissulkeminen
epäsuorasti Yhteistyö Lukkiutuminen
tietoisia toisista Yhteinen muisti Nälkiintyminen
Datan ajantasaisuus
Prosessit
suorasti Yhteistyö Lukkiutuminen
tietoisia toisista Sanomanvälitys Nälkiintyminen
ks. Stallings Tab 5.1
• Suoritusjärjestys / ajoitus• Prosessin lopputulos
1 - 5Rio 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 - 6Rio 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
< kriittinen koodialue > # käytä (exclusive!)
Exit protocol # vapauta
1 - 7Rio syksy 2005
Halutut ominaisuudetPoissulkeminen
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 - 8Rio syksy 2005
Lukkomuuttujat, Spin LocksBoolean-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 - 9Rio syksy 2005
Test-and-Set-käsky
Oma konekielen käsky atominen laitetason suoritus (execute-vaihe) argumentti: lukkomuuttuja boolean paluuarvo
TS L merkitys: < temp=L; L=0; if (temp==1) jump *+2; > merkitään varatuksi!
Käyttö: LOOP: TS L
JUMP LOOP .......
Saa edetä!Jää odottamaan!
1 - 10Rio 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;
ei kriittistä koodia; }}
Tulkinta: L=1 yhdellä lupa edetä
LOCK(L); # varaa
< kriittinen alue > # käytä (exclusive!)
UNLOCK(L); # vapauta
1 - 11Rio 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 alueatomisia
semafori S
P(S)
V(S)
S.arvo
S.jono
public
public
private
private
alkuarvo
1 - 12Rio 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;
ei kriittistä koodia; }}
yksi semafori kullekin erilliselle kriittiselle alueellehuomaa oikea alkuarvo
P(mutex); # varaa
< critical section > # käytä (exclusive!)
V(mutex); # vapauta
1 - 13Rio 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 - 14Rio 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 - 15Rio 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 - 16Rio syksy 2005
Kilpailutilanne
V(arrive); P(continue); V(arrive);
P(continue);
koordinaattori
P(arrive) OK N kertaa! V(continue) N kertaa;
Mitä tässä voi tapahtua?
1 - 17Rio 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 - 18Rio 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 - 19Rio 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 - 20Rio 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 - 21Rio syksy 2005
PalvelujärjestysSemaforin 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 - 22Rio syksy 2005
Prosessien synkronointi monitorillapoissulkeminen (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 - 23Rio 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 - 24Rio syksy 2005
Kanavat (Andrews)
Yhteinen ’postilaatikko’ jono sanomia, FIFO kaikki kanavan sanomat rakenteeltaan samanlaisia
chan ch(type1 id1, …, typen idn) ch: kanavan nimi typei idi: 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 - 25Rio syksy 2005
Operaatiot
send kanava(lauseke1, … , lauseken) lähetä sanoma kanavaan
receive kanava(muuttuja1 , … , muuttujan) 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 - 26Rio 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 - 27Rio syksy 2005
Asiakkaat ja monen palvelun palvelija
PyyntökanavaAsiakkaiden tuntema julkinen kanava käytännössä: IP-osoite ja porttinumero
Yksi pyyntökanavasanoma kanavaan tulkitse tyyppi,
valitse palvelu tai dedikoitu kanava kullekin palvelulle
valitse palvelu lähetä sopivaan kanavaan
VastauskanavaPalvelijan 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 - 28Rio 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 - 29Rio 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 - 30Rio 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 - 31Rio syksy 2005
Arkkitehtuureja
liukuhihna, suodintuottaja – kuluttajaasiakas – palvelijavertaistoimijat (peer-to-peer,P2P)monipuolisemmat rakenteet: heartbeat yms.ryhmä: keskitetty, rengas, symmetrinen
1 - 32Rio syksy 2005
Evaluoi
Oikeellisuus Suorituspolkujen analyysi Tilamallit
Suorituskyky Yleisrasite Komponentti Kommunikointi / ryhmän kommunikointi Rinnakkaisuusaste
Selvitä aina, kuinka järjestelmä käyttäytyy!