1 / 30

Hajautettu laskenta Prosessien hallinta verkossa

Hajautettu laskenta Prosessien hallinta verkossa

joann
Download Presentation

Hajautettu laskenta Prosessien hallinta verkossa

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Hajautettu laskenta • Prosessien hallinta verkossa • Kun useita prosesseja tai säikeitä on suorituksessa samanaikaisesti – joko saman koneen eri prosessoreissa tai eri koneissa, jotka on liitetty toisiinsa verkon kautta – ollaan tilanteessa, joka eroaa prosessien käsittelyn kannalta merkittävästi von Neumannin arkkitehtuurista. • prosessien ajoitusta moniprosessorijärjestelmissä: ”milloin prosessi suoritetaan?” ja ”missä se suoritetaan?” • prosessien välisen kommunikoinin perusmenetelmiä • hajautetun prosessien hallinnan erityiskysymyksiä, hajautettua synkronointia ja lukkiutumista.

  2. Samanaikaisuus • Järjestelmä voi olla hajautettu usealla tasolla: • Tiiviissä järjestelmässä prosessorit ovat fyysisesti lähellä toisiaan ja usein kiinni samoissa väylissä. • Väljemmissä järjestelmissä kullakin prosessorilla voi olla omaa keskusmuistia. Siten ne muodostavat omat von Neumannin koneensa, mutta ovat yhteydessä toisiinsa nopeiden tiedonsiirtoväylien kautta. • Väljin tapaus on esimerkiksi suhteellisen hitaan Internetin varaan rakennettu hajautettu laskentajärjestelmä, josta käy esimerkkinä Seti@home projekti. • Kaikille näille on yhteistä, että reaaliajassa samanaikaisesti suoritetaan useita laskutoimituksia. • Väljästi liitetyssä järjestelmässä kannattaa suosia suuria ja riippumattomia eräajotyyppisiä prosesseja. Tiiviissä järjestelmissä, joissa prosessien välinen kommunikointi on nopeaa, yhtä aikaa suorituksessa olevat keskenään vuorovaikuttavat prosessit saavat lisätehoa, kun niitä ei tarvitse vaihtaa pois prosessorista kesken suorituksen. • samanaikaisuuden hallinnan peruskysymykset: ajoituksen ongelmat ja prosessien viestinvälitys jopa koneiden välillä • Avatessaan uuden ulottuvuuden laskennalle moniprosessorointi siis paitsi lisää laskutehoa myös monimutkaistaa perinteisten ongelmien kuten synkronoinnin ratkaisemista.

  3. Ajoitus moniprosessijärjestelmissä • Ajoitus moniprosessorijärjestelmissä (kolmenlaisia ja välimuotoja): • Klusterissa on joukko suhteellisen autonomisia järjestelmiä, joissa kullakin prosessorilla on oma loogisesti erillinen keskusmuistinsa ja I/O-kanavansa. • prosessorit voivat olla tehtäväkohtaisesti erikoistuneita, esimerkiksi omat prosessorinsa I/O-laitteiden ohjaamiseen. Tässä tapauksessa on yleensä yksi ohjaava prosessori, joka hallinnoi tilannetta. I/O-prosessoreja ei kuitenkaan käsitellä tässä yhteydessä. • Tiukasti kytketyssä moniprosessoroinnissa joukko prosessoreita jakaa saman keskusmuistin ja on käyttöjärjestelmän keskitetyssä ohjauksessa. Prosessoreille voi lisäksi olla osoitettuna keskusmuistista sellaisia osia, joihin sillä on nopeampi pääsy. Prosessorien ei tarvitse olla samanlaisia, mutta se auttaa asiaa.

  4. Kolme tärkeää näkökohtaa: • Prosessien osoittaminen prosessoreille, • Yksittäisten prosessorien moniohjelmointi ja • Prosessien vaihtaminen prosessorissa.

  5. Staattinen vs. dynaaminen tapa prosessien jakamiseen prosessoreille • staattinen • pieni yleisrasite • taakka saattaa olla hyvin epätasainen • dynaaminen • prosesseja siirrettäessä prosessorilta toiselle, välimuisti menettää merkitystään Missä päätetään miten prosesseja ohjataan? • master/slave –arkkitehtuuri (yksi ottaa käyttöjärjestelmän ydinosat hallintaansa • yksinkertainen, kontrolli keskitetty • yhden tärkeän solmun tuoma riski, mahdollinen pullonkaula • vertaisverkkoarkkitehtuuri (peer) (käyttöjärjestelmän toiminnot jaettu usean koneen kesken) • synkronointiongelmat

  6. Moniprosessoriympäristö tuo omat erikoisuutensa järjestelmään. Irrottavat menetelmät eivät ehkä enää olekaan oikea tapa hoitaa prosessien ajoitusta. Jo kahdella prosessorilla FCFS-algoritmit menestyvät yhtä hyvin kuin Round Robin. Seuraavassa neljä lähestymistapaa säikeiden ajoittamiseen

  7. Kuorman tasaaminen (load sharing). Järjestelmässä on yhteinen READY-jono, josta prosessit (tai säikeet) osoitetaan aina sille prosessorille, joka vapautuu. Vuorottamiseen voidaan käyttää yksinkertaista FCFS-algoritmiakin. • Hyviä puolia ovat: • Kuorma jakautuu tasaisesti. • Ei tarvita monimutkaista vuorontajaa. • READY-jono voidaan optimoida jollain edelläkuvatulla tavalla, esimerkiksi MFQ-menetelmällä. • Heikkouksia ovat: • Keskitetty jono vaatii poissulkemista ja synkronointia, mikä saattaa muodostua järjestelmän pullonkaulaksi. • Irrotetut säikeet eivät todennäköisesti palaa samalle prosessorille. Välimuistin tuoma etu menetetään. • Jos kaikkia säikeitä käsitellään omina suorituskokonaisuuk-sinaan, vuorovaikuttavat säikeet eivät todennäköisesti ole yhtä aikaa suorituksessa, mikä heikentää järjestelmän suorituskykyä. Potentiaalisista heikkouksistaan huolimatta tämä on yksinkertaisuutensa vuoksi yleisin käytetty tekniikka. Mach-käyttöjärjestelmässä on parannus toiseen kohtaan: jokaista prosessoria kohti on oma jononsa, johon prosessorissa suorituksessa olleet säikeet pannaan. Uusia prosesseja valittaessa katsotaan ensin paikallisesta jonosta ja vasta sitten järjestelmän yhteisestä jonosta.

  8. Jengiajoitus (Gang Scheduling). Idea on, että joukolle prosesseja (säikeitä) osoitetaan yhtä aikaa prosessorit. Järjestelmällä on seuraavat edut: • Jos säikeet riippuvat toisistaan, järjestelmän suorituskyky nopeutuu dramaattisesti, koska niitä ei tarvitse synkronoinnin takia pysäyttää. • Ajoituksen yleisrasitetta voidaan vähentää, koska samalla operaatiolla voidaan vaikuttaa useisiin säikeisiin ja prosessoreihin. Monimutkaisuudestaan huolimatta jengiajoituksen on havaittu olevan paljon kuormanjakotekniikoita tehokkaampi.

  9. Sitova prosessoriosoitus. Jengiajoituksen äärimuoto on sitoa joukko säikeitä tiettyihin prosessoreihin niiden koko elinajaksi. Kutakin prosessoria kohden on vain yksi säie. Vaikka tämä vaikuttaakin prosessoriajan tuhlaukselta (prosessori seisoo, kun säie on pysäytetty), kannattaa huomata kaksi näkökohtaa: • Järjestelmässä, jossa on kymmeniä tai jopa satoja prosessoreita yksittäisen prosessorin käyttöaste ei ole kovin kriittinen tekijä. • Se, ettei prosessia tarvitse koko elinaikanaan ottaa pois prosessorista voi nopeuttaa huomattavastikin ohjelman suoritusta. Useat tutkimukset tukevat tätä väitettä. Kokeiden perusteella tehokkain tapa on rajoittaa järjestelmässä olevien säikeiden määrä käytössä olevien prosessien määrään. Jos prosessoreja on suuri määrä, niiden hallinta alkaa muistuttaa muistinhallintaa. Ilmenee samankaltaisia ongelmia, esimerkiksi pirstaloitumista (prosessoreita on liian vähän tai ne ovat liian hajallaan tehokkaasti käytettäviksi). Myös samankaltaisia algoritmeja voi soveltaa, esimerkiksi käyttöjoukkoalgoritmia, johon tutustutaan muistinkäsittelyn yhteydessä.

  10. Dynaaminen ajoitus on neljäs lähestymistapa säikeistykseen. Kunkin työn säikeet osoitetaan mahdollisimman monelle prosessorille yhtä aikaa. Jos kaikille ei riitä prosessoria, jää osa säikeistä odottamaan järjestelmänlaajuiseen jonoon, kunnes ne voidaan suorittaa tai tehtävä tulee muutoin suoritettua. Jos vapaita prosessoreita ei ole, irrotetaan sellainen työltä, joka käyttää useampaa kuin yhtä prosessoria. • Kokeet viittaavat siihen, että sovelluksilla, jotka pystyvät hyödyntämään tätä ominaisuutta, dynaaminen ajoitus on edellä esitettyjä parempi. Suuri yleisrasite saattaa kuitenkin syödä saavutetun edun eikä asiasta saada varmuutta ennen kuin sitä on testattu todellisessa järjestelmässä.

  11. Dynaamisuus Jos päätetään, että järjestelmässä olevat prosessit voivat siirtyä prosessorista toisen, täytyy ottaa huomioon joitakin näkökohtia. Käyttöjärjestelmän kannalta kysymys on prosessin suorittamiseen tarvittavan datan siirtämisestä prosessorilta toiselle. Jos kyseessä on tavallinen moniprosessoriympäristö, tieto on jo yhteisessä keskusmuistissa. Muussa tapauksessa se täytyy siirtää joko käyttäen hajautetun keskusmuistin tekniikoita tai tarkoitukseen erikseen suunniteltuja menetelmiä.

  12. Jos prosessien siirtäminen on niin raskas operaatio, miksi niin kannattaisi tehdä? Yksi syy on edellä esitettyjen politiikkojen tehokas toteuttaminen, toinen on prosessien erityisvaatimukset: • Kuorman tasaaminen. Siirretään kuormaa koneille, joilla on vapaata kapasiteettia, jolloin kokonaissuorituskyky kasvaa yleisrasitteesta huolimatta. • Viestinnän tehostaminen. Jos kaksi prosessia, jotka toimivat yhteistyössä on suorituksessa eri koneissa, niiden viestintä on hidasta ja rasittaa verkkoa. Prosessien keskittäminen samaan koneeseen on usein mielekästä, vaikka kone olisi yksiprosessorinen. • Prosessien suorituksen turvaaminen. Jos prosessi vaatii jostain syystä paljon aikaa suoritusta varten, ja tiedetään, että kone, jolla sitä suoritetaan joudutaan jostain syystä sulkemaan tai eristämään, on usein mielekästä siirtää prosessi suoritukseen toiseen koneeseen. • Erityisominaisuudet. Prosessi voi jossain suorituksensa vaiheessa tarvita erityislaitteistoa tai ohjelmistoa, joka on tietyssä koneessa.

  13. Pohdittaessa kysymyksiä prosessien siirtämisestä, on tarkasteltava lähemmin kolmea näkökohtaa: • Kuka päättää prosessin siirrosta. • Mikä osa prosessista siirretään • Mitä tapahtuu viesteille ja signaaleille, jotka prosessi lähettää tai sen on määrä vastaanottaa. Kaikkiin näihin kysymyksiin on vastattava tilannekohtaisesti sen mukaan, mitä tarpeita prosessien siirtämisen on tarkoitus palvella • Jos päämääränä on esimerkiksi kuorman tasaaminen, siirrosta päättää järjestelmän prosessorien kuormia tarkkaileva prosessi. • Jos päämääränä on viestinnän tehostaminen, voi päätöksen tehdä edellisen tapaan prosessien viestiliikennettä tarkkaileva prosessi tai prosessi itse, joka huomaa asian. Prosessi voi päättää siirtää itsensä myös siinä tapauksessa, että se tarvitsee jollain koneella olevia erikoisresursseja. • Kolmas vaihtoehto prosessin siirtopäätöksen tekijälle on käyttäjä, joka haluaa esimerkiksi turvata prosessin suorituksen tai yrittää optimoida järjestelmän suorituskykyä käsin.

  14. Mitä itse asiassa siirretään? Mitä pitää siirtää kun prosessi siirretään prosessorilta toiselle? Prosessorin tila on kokoelma dataa, joka voidaan siirtää sellaisenaan. Jos muisti on yhteinen (tai käytössä virtuaalimuisti), riittää osoitteiden siirtäminen. Signaalien ja viestien käsittelyn pitää säilyä tuntumattomana. Voidaan hoitaa käyttöjärjestelmän viestikeskuksen avulla.

  15. Prosessien kommunikointi • viestit suunnilleen sama kuin yksiprosessorijärjestelmässä, mutta hajautus tuo joitain erityispiirteitä • yhteinen ’postitoimisto’ • send- ja receive –laajennukset • signaalien toteuttaminen ei ole yhtä suoraviivaista • jos joku prosessi odottaa signaalia, kaikkien koneiden pitää olla siitä tietoisia tai jokainen signaali lähetetään jokaiseen koneeseen • RPC (Remote Procedure Call) • kuten tavallinen aliohjelmakutsu

  16. Perusteluita RPC:n käytölle • Aliohjelmakutsu on yleisesti käytetty ja hyvin ymmärretty käsite • Aliohjelmakutsujen vakiintunut semantiikka tekee ohjelmien dokumentoinnin ja tarkastamisen helpoksi. • Koska rajapinta on standardinmukainen ja hyvin määritelty, voidaan verkkoa käsittelevät koodinpätkät tuottaa automaattisesti. • Standardien ansiosta on mahdollista kirjoittaa kirjastoja, joita on helppo siirtää käyttöjärjestelmästä ja laitteistosta toiseen.

  17. Perusajatus on, että aliohjelmana suoritettavat funktiot on jaettu kahteen osaan, joista osa – eräänlainen rajapinta – on kutsuvalla koneella, ja varsinainen ohjelma on toisella koneella. • Kutsuvaa konetta sanotaan asiakkaaksi ja aliohjelman suorittavaa konetta palvelimeksi. • Molemmissa koneissa on varsinaisen siirron toteuttavan RPC-mekanismin päälle rakennettu ”tynkä” (local stub), joka tulkitsee aliohjelmakutsun kutsuvasta koneesta RPC:n välitettäväksi, taas suoritettavaksi ja huolehtii arvon palauttamisesta. • Tynkä huolehtii myös sellaisista yksityiskohdista kuin parametrin arvon oikeellistamisesta, jos kutsuva ja kutsuttava ohjelma on kirjoitettu eri kielillä.

  18. Suunniteltaessa RPC-järjestelmiä täytyy ottaa huomioon joitain peruskysymyksiä, kuten syntaksi ja se, onko kutsu tuntumatonta vai ei. Toisaalta parametrien välitys voi olla ongelmallista, etenkin jos käytetään osoittimia. • Myös kysymys siitä, säilytetäänkö yhteys koneiden välillä senkin jälkeen, kun aliohjelma on palauttanut arvon, on tärkeä, erityisesti usein tehtävien kutsujen kohdalla. • Viimeksi on pohdittava kysymystä siitä, halutaanko toiminnan olevan synkronista vai asynkronista. Synkroninen toimii tavallisen aliohjelman tapaan, mutta asynkroninen sallii prosessin jatkaa suoritustaan, vaikka proseduuria ei olisikaan suoritettu loppuun, mikä voi nopeuttaa kokonaissuoritusta merkittävästikin.

  19. Nykyaikaisissa järjestelmissä pyritään usein tiedon kapselointiin ja kokonaisuuksien käsittelyyn olioajattelun avulla. • Jotkut järjestelmät onkin suunniteltu siten, että niiden perusyksiköitä ovat oliot, jolloin viestinvälitys ja kaikki muutkin toiminnot voidaan toteuttaa oliopohjaisesti. • Tällaisissa järjestelmissä on usein käytössä myös niinsanottu ORB – arkkitehtuuri (Object Request broker), joka huolehtii keskitetysti palveluiden välittämisestä asianmukaisille olioille ja vastausten palauttamisesta kutsuville ohjelmille tai olioille. Ideana on, että pyyntö lähetetään ORBille, joka tarkistaa listoistaan sen asianmukaisen olion osoitteen ja välittää sille tarpeelliset tiedot, ottaa vastaan vastauksen ja välittää sen.

  20. Tietojen yhtenäisyys • Hajautetussa järjestelmässä yhtenäisyyden perusongelma on, että kaikkin prosessien tilaa ei voida tuntea samanaikaisesti ellei keskusmuisti ole jaettu tasanopeuksisesti. Tämä johtuu siitä, että tiedon kulkemiseen kuluu aikaa. Tietyllä hetkellä toisesta koneesta saapuva tieto ei enää ole reaaliajantasaista, kun se saapuu koneeseen, jossa tietokoneen tilaa yritetään selvittää. • Ilmiö on sama kuin tutkittaessa tähtiä • Ongelma on erityisen pistävä, jos yritetään selvittää sellaisen järjestelmän tilaa, jossa eri koneissa olevat prosessit kommunikoivat keskenään. • Tällöin saattaa käydä niin, että jotain tietoa ei osata ottaa huomioon, koska se on matkalla toiseen koneeseen, mutta ei vielä saapunut sinne, joten yksi viesti hukkuu matkalla. • Toisaalta, jos päätetään odottaa kaikkien lähetettyjen viestien saapumista, ja kellot ovat epäsynkroniset, voi jokin viesti saapua, vaikka sitä ei oltu lähetetty kun lähettävän prosessin tila tarkastettiin.

  21. Järjestelmälle voidaan määritellä jollain tavalla ”yhteinen” virtuaalinen aika. Eräs tapa toteuttaa tämä on tarkastella järjestelmän tilaa ”heittolaukauksilla” (snapshot), jotka kuvaavat prosessien tilaa yksittäisissä koneissa tietyillä hetkillä. Stallings esittelee ratkaisun, jossa käytetään seuraavia termejä: • Kanava: Väylä, jonka kautta prosessi voi lähettää viestejä toiselle prosessille. Yksinkertaisuuden vuoksi oletetaan ne yksisuuntaisiksi. • Tila: Prosessin tila on sen lähettämien ja vastaanottamien viestien sarja. • Heittolaukaus tallettaa prosessin tilan tietyllä hetkellä. • Globaali tila: kaikissa koneissa olevien kaikkien prosessien yhdistetty tila. • Hajautettu heittolaukaus: kokoelma heittolaukauksia, yksi jokaisesta prosessista. Villakoiran ytimenä on saada hajautettujen heittolaukausten sarja, joka kuvaa koko globaalin tilan. Globaali tila on yhtenäinen, jos jokaista siinä esiintyvää vastaanotettua viestiä kohden on olemassa ”kuva” viestin lähettämisestä.

  22. Ongelma voidaan ratkaista esimerkiksi käyttämällä erikoista kontrolliviestiä, ”merkkiä” ja olettamalla, että viestit saapuvat perille siinä järjestyksessä kuin ne lähetetäänkin eikä viestejä katoa matkalla. Esimerkiksi TCP-protokolla takaa olettamukset. Jokin prosessi q käynnistää algoritmin tallentamalla paikallisen tilansa ja lähettämällä kaikilla kanavilla merkin ennenkuin lähettää mitään muita viestejä. Kun mikä tahansa prosessi p sitten saa kyseisen merkin ensimmäisen kerran, se tekee seuraavat toimenpiteet: • Tallentaa paikallisen tilansa • Merkitsee kanavan q:sta p:hen tyhjäksi • Levittää samaa merkkiä kaikille naapureilleen kaikille ulosmeneville kanaville.

  23. Nämä toimenpiteet täytyy tehdä atomaarisesti siten, ettei niiden välillä lähetetä tai vastaanoteta viestejä. Kun prosessi saa saman merkin uudestaan, joltain toiselta prosessilta r, se tekee seuraavat toimenpiteet: • p lisää tilaansa viestit, jotka ovat tulleet r:stä tulevasta kanavasta merkin saapumisen jälkeen ja merkitsee kanavan tyhjäksi. Kun merkki on palannut kaikista kanavista, on kuva valmiina koottavaksi. Algoritmin toiminnasta kannattaa huomata seuraavat seikat: • Mikä tahansa prosessi voi aloittaa algoritmin. Se toimii, vaikka useampi aloittaisi sen yhtä aikaa • Algoritmi suoriutuu äärellisessä ajassa, jos kaikki viestit toimitetaan äärellisessä ajassa. • Algoritmi on hajautettu – jokainen prosessi on vastuussa oman tilansa ja tulevien viestien kirjaamisesta. • Algoritmi ei vaikuta minkään muun hajautetun algoritmin toimintaan

  24. Poissulkeminen • Poissulkemisongelman ratkaisevan järjestelmän täytyy hajautetussakin järjestelmässä toteuttaa samat ehdot kuin yhteistä keskusmuistia käyttävässä järjestelmässä. • Hajautetussa järjestelmässä voidaan olettaa, että kunkin koneen sisällä on jonkinlainen prosessien ja resurssien hallinnasta ja poissulkemisesta huolehtiva ohjelmisto • Ongelman voi ratkaista esimerkiksi keskitetyllä resurssinjakajalla, joka myöntää yhdelle prosessille kerrallaan luvan käyttää resursseja, joita se hallinnoi. Toiselle prosessille lupa annetaan vasta kun edellinen käyttäjä on palauttanut resurssin. Ongelmana tietysti on, että resurssinjakajasta itsestään tulee kriittinen resurssi

  25. Näistä syistä ongelman ratkaisemiseksi onkin kehitetty hajautettuja algoritmeja. Niiden ominaispiirteitä: • Kaikilla solmuilla on keskimäärin saman verran tietoa. • Jokaisella solmulla on vain osittainen kuva järjestelmästä ja se joutuu tekemään päätöksiä tältä pohjalta. • Kaikilla solmuilla on yhtä suuri vastuu lopullisesta päätöksestä. • Kaikki solmut tekevät keskimäärin yhtä paljon työtä lopullisen päätöksen tekemiseksi. • Yksittäisen solmun vikatilanne ei yleisesti ottaen johda järjestelmän täydelliseen romahtamiseen. • Ei ole olemassa järjestelmänlaajuista kelloa, jolla tapahtumien ajoitusta voisi ohjata. Kohdat 2 ja 6 johtuvat vähintään siitä seikasta, että tiedonsiirtoon kuluu aikaa, joten kaikkialla ei voida taata olevan ajantasaista tietoa kaikesta tai edes yhteisestä ajasta. Aika tosin on joskus mahdollista jakaa kaikille luotettavasti, mutta se ei ole käytännöllistä eikä yleensä kustannustehokasta.

  26. Pohdittaessa poissulkemista ollaan usein kiinnostuneita siitä, missä järjestyksessä asiat tapahtuvat. Toisin sanoen halutaan, että kaikilla koneilla olisi yhteinen käsitys siitä, missä järjestyksessä eri koneilla olevat prosessit haluavat päästä kriittisille alueille tai pois niiltä. • Todellisen tapahtumajärjestyksen ei tarvitse olla sama, kunhan käsitys siitä on yhteinen. Eräs paljon käytetty tapa toteuttaa tämä on Stallingsin esittelemä aikaleimasinmenetelmä, jossa jokaiseen viestiin liitetään aikaleima, joka kertoo, montako viestiä se on lähettänyt tai vastaanottanut ja koneen numeerinen tunnus. • Laskuria kasvatetaan aina ennen viestin lähettämistä ja välittömästi sellaisen vastaanottamisen jälkeen. Viestiä vastaanotettaessa laskuri saa arvon: • Uusi arvo = 1+max[vanha arvo, viestin aikaleima] • Kullakin koneella viestin järjestys määräytyy seuraavasti: Jotta viesti x edeltäisi viestiä y on joko • aikaleima x < aikaleima y tai • aikaleima x = aikaleima y ja x:n koneen tunnus < y:n koneen tunnus • Menetelmä toimii riippumatta viestinvälityksen viiveistä tai koneiden suhteellisista nopeuseroista. Jos viestejä ei lähetetä kaikille koneille, muodostuu joukko osittaisia järjestyksiä. Poissulkemisen yhteydessä ollaan kuitenkin kiinnostuneita vain tapauksesta, jossa viesti lähetetään kaikille koneille.

  27. Tätä työkalua käyttäen voidaan toteuttaa hajautettu jono, jonka avulla eri koneissa suorituksessa olevat prosessit voivat päätellä, milloin ne voivat siirtyä kriittiselle alueelle. Stallings esittelee Lamportin algoritmin, joka vaatii seuraavat olettamukset: • Hajautettu järjestelmä koostuu N:stä solmusta, jotka on yksikäsitteisesti numeroitu 1:stä N:nään. Jokainen solmu käsittää yhden prosessin, joka tekee resurssipyyntöjä poissulkemista vaativaan resurssiin toisten prosessien puolesta. Tämä prosessi toimii myös välimiehenä, jonka tehtävä on selvittää tulevien resurssipyyntöjen järjestys. • Viestit prosessilta toiselle vastaanotetaan samassa järjestyksessä kuin ne lähetetäänkin. • Jokainen viesti pääsee perille äärellisessä ajassa. • Kaikki verkossa olevat prosessit voivat lähettää toisilleen viestejä suoraan ilman, että jonkin toisen prosessin tarvitsisi välittää niitä eteenpäin. • Olettamukset 2 ja 3 voi toteuttaa esimerkiksi sopivalla tiedonsiirtoalgoritmilla, esimerkiksi TCP:llä.

  28. Algoritmi yrittää jäljitellä keskitettyä ratkaisua, jossa yksi jono määrää sisäänpääsevien prosessien järjestyksen. • Ongelma: miten jonoa voidaan ylläpitää yhdenmukaisena kaikissa solmuissa? Aikaleimasimella voidaan taata järjestyksen yhdenmukaisuus, mutta mistä tiedetään, että se on kullakin hetkellä ajantasainen ja kaikilta solmuilta on saatu viimeisimmät viestit? Käy ilmi, ettei jonon tarvitse olla ajantasainen reaaliaikaan nähden, vaan riittää, että sen ajantasaisuus voidaan taata siihen hetkeen nähden, jolloin prosessi tekee resurssipyynnön. Tämä voidaan toteuttaa vaatimalla, että prosessi saa kaikilta muilta prosesseilta viestin, joka ei varaa resurssia aiemmin sen jälkeen, kun prosessi on esittänyt resurssipyyntönsä.

  29. Algoritmia varten tarvitaan tietorakenne, johon on talletettu tiedot viimeisimmästä sen saamasta viestistä (viesti, aika, lähteen tunnus), mukaanlukien viimeisin viesti, joka on lähetetty tästä solmusta. Lamport kutsuu tätä rakennetta jonoksi, vaikka se on itse asiassa taulukko, jossa on paikka jokaiselle solmulle. Taulukko on alustettu seuraavasti: • q[j] = (Vapauta,0,j), j=1, ..., N • Algoritmissa käytetään kolmenlaisia viestejä: • (Pyyntö, aika(i),i) – solmun i prosessin P(i) tekemä resurssipyyntö • (Lupa, aika(j),j) –prosessi P(j) osoittaa hallinnoimansa resurssin • (Vapautus, aika(k),k) – P(k) vapauttaa sille osoitetun resurssin

  30. Algoritmin toiminta on seuraava: • Kun P(i) haluaa resurssia, se lähettää kaikille prosesseille Pyynnön, johon on leimattu sen oma aikaleima. Pyyntö talletetaan myös sen paikalliseen jonoon. • Kun P(j) saa resurssipyynnön, se panee sen omaan taulukkoonsa paikkaan q[i] ja lähettää Luvan (Lupa, paikallinen aika, j), kaikille prosesseille. (Tämän toimenpiteen ansiosta voidaan tietää, ettei mikään aiempi resurssipyyntö ole jäänyt matkalle odottamaan.) • P(i) jää odottamaan ja saa edetä kriittiselle alueelleen vasta, kun molemmat seuraavista ehdoista pätevät: • P(i):n oma pyyntö on aikaisin Pyyntö jonossa. (Koska kaikissa solmuissa jonot ovat samassa järjestyksessä, ovat ne yhdenmukaisia) • Kaikki muut paikallisessa jonossa olevat viestit ovat myöhempiä kuin q[i] – tämä takaa, että P(i) on saanut tietää kaikista Pyynnöistä, jotka tulivat ennen sen omaa Pyyntöä. • P(i) vapauttaa resurssin lähettämällä kaikille prosesseille viestin Vapauta, jonka se panee myös omaan jonoonsa. • Kun P(i) saa viestin (Vapauta, paikallinen aika, j), se korvaa q[j]:n sisällön tällä viestillä. • Kun P(i) saa viestin (Lupa, paikallinen aika, j), se korvaa q[j]:n sisällön tällä viestillä. • Algoritmi toteuttaa poissulkemisen, on reilu, ei aiheuta lukkiutumista eikä nälkiintymistä.

More Related