Distribuovaná sdílená pam

Transkript

1 Distribuovaná sdílená pam Základní pedpoklad distribuovaného stránkování je, že žádný procesor nemže pímo pistupovat do pamti jiného (cizího) procesoru. Takovýmto systémm se íká NORMA - No Remote Memory Access (bez vzdáleného pístupu do pamti). Oproti tomu systém NUMA - No Uniform Memory Access spoívá v tom, že procesor pímo adresuje položky v pamovém prostoru, piemž jednotlivé stránky mohou být libovoln distribuovány mezi pammi rzných procesor, aniž je tím njak ovlivnn výsledek programu. V okamžiku pístupu na vzdálenou stránku má systém možnost volby. Bu stránku nate, nebo ji používá vzdálen, což má vliv na výkon systému, ale ne na správnost. Vše je ešeno na hardwarové úrovni. Takto pracují multiprocesory, u nichž je pístup k pamti zajištn bez pomoci softwaru. Úkolem systému distribuované sdílené pamti (DSM) je doplnit jisté softwarové vybavení tak, aby na multipoítaích mohly bžet multiprocesorové aplikace. Protože není možnost pístupu do vzdálené pamti (NORMA), je jen jediná možnost pi pístupu na stránku, která se nachází u jiného procesoru - naíst ji. Prvotní snahy tedy vedly k modifikaci programového vybavení, které bylo psáno pro multiprocesory, na programové vybavení pro multipoítae, a to pokud možno s minimálními zmnami tohoto softwaru. Protože jsou multiprocesorové aplikace zvyklé na pam sekvenn konzistentní, byla tedy zpoátku snaha, aby DSM také splovala podmínku sekvenní konzistence. Další zjištní vedlo k tomu, že není poteba tak silný konzistenní model, a že jeho oslabením se programy zrychlí. Distribuovaná sdílená pam (DSM) je abstrakce používaná pro sdílení dat mezi procesy v poítaích, kde není sdílená fyzická pam. Uživatelé nemusí explicitn ešit problém penosu dat mezi uzly. Základním problémem je dobrá propustnost komunikaního subsystému, která by nemla záviset na rozlehlosti systému a potu procesor. DSM je prostedek pro ešení paralelních aplikací, distribuovaných aplikací nebo skupinových aplikací, ve kterých jsou individuální sdílené datové položky pístupné pímo. Jedná se o model typu peer-to-peer, nikoliv model klient/server. Data jsou vymována komunikaním systémem V každém uzlu je z dvodu rychlého pístupu lokální kopie dat, systém musí zajistit konzistentnost dat v jednotlivých uzlech. ešení problému souvisí s realizací replik i cacheováním sdílených soubor. Z technického hlediska mžeme problém ešit v prostedí tsn vázaných multiprocesor se spolenou (sdílenou) pamtí, nebo voln vázaných multiprocesor komunikujících posíláním zpráv. Tsn vázané multiprocesory se sdílenou pamtí propojení pomocí sbrnice dovoluje propojit max. 10 až 20 procesor. Realizace architektura NUMA (Non-Uniform Memory Access) s max. 64 procesory hierarchická architektura, kde jsou procesorové desky se 4 procesory propojeny rychlou sbrnicí nebo pepínaem. Procesory vidí jeden adresní prostor obsahující všechny pamti na všech deskách. Doba pístupu k lokální pamti je však menší než doba pístupu ke vzdálené pamti nejedná se o transparentní pohled na pam. Voln vázané multiprocesory s distribuovanou (sdílenou) pamtí nemají spolený pamový prostor, ale jsou propojeny velmi rychlou sítí s pepínai. Poet procesor mže být vyšší než 64. Otázkou je, zda-li mohou být algoritmy pro sdílenou pam pímo peneseny do distribuované pamové architektury. 1 Systém posílání zpráv versus distribuovaná sdílená pam Distribuovaná sdílená pam je porovnatelná se systémem posílání zpráv používá asynchronní komunikaci. Jiný možný model je komunikace synchronní, založená na komunikaci typu dotaz odpov. 1.1 Programový model V systému výmny zpráv má každá promnná své místo v lokální pamti, a pokud je teba zmnit její hodnotu, pak se musí vyslat zpráva. V pípad sdílené pamti je promnná sdílena nemusí se penášet. Sdílená pam je použitelná pouze v homogenních systémech, kde je shodná reprezentace dat. Systém výmny zpráv dovoluje pracovat v heterogenním prostedí, protože není problém provádt konverze zobrazení dat. Dále v systému se sdílenou pamtí nejsou jednotlivé procesy vzájemn chránny, porucha jednoho mže zpsobit zhroucení jiného procesu, nap. píinou mže být píliš astá zmna dat. Synchronizace mezi procesy je zajištna v modelu posílání zpráv pomocí komunikaních primitiv ve spolupráci s dalšími prvky nap. lock serverem. Synchronizace ve sdílené pamti je zajištna zámky a semafory.

2 1.2 Efektivnost Dosud nelze íci, je-li model sdílené pamti lepší než model posíláni zpráv nebo naopak. Hodn záleží na potu procesor a na dané aplikaci. 2 Pístupy k implementaci distribuované sdílené pamti Distribuovaná sdílená pam mže být realizována specializovaným hardware, konvenní stránkovou sdílenou pamtí, middleware, nebo jejich kombinací. Speciální hardware Architektura NUMA PLUS (No Uniform Memory Access) vychází ze specializovaného hardware, zajišujícího konzistentní pohled procesor na pam. Zpracovávají operace LOAD a STORE. Pro komunikaci se vzdálenou pamtí využívají rychlého propojení, které je analogické síovému propojení. Stránková virtuální pam V mnoha systémech je sdílená pam realizována jako oblast virtuální pamti obsazující tentýž rozsah adresního prostoru ve všech procesech. Toto uspoádání je použitelné pouze v systému s homogenními poítai se stejným formátem dat. Middleware Nkteré programové prostedky, jako JavaSpaces nebo TSpaces podporují distribuovanou sdílenou pam bez podpory stránkování nebo speciálního hardware, cestou nezávislou na platform. Sdílení je realizováno komunikací mezi instancemi na úrovni podpory uživatele v klientech i serverech. Procesy pi pístupu k datm ve sdílené pamti volají služby této vrstvy. Instance této mezilehlé vrstvy umístné v rzných poítaích pistupují k lokálním datovým položkám a vzájemnou komunikací zajišují jejich konzistentnost. Efektivnost komunikace mže být ovlivnna vhodnou podporou hardwarem. Pístup založený na stránkách má tu výhodu, že nepotebuje žádnou zvláštní strukturu nad sdílenou pamtí, jejíž data chápe jako posloupnost slabik. V principu to dovoluje programm navrženým pro multiprocesory se sdílenou pamtí pracovat na poítaích bez sdílené pamti s minimální nebo žádnou úpravou. Takovou podporu nabízí nap. Mach, zajišující pirozenou podporu sdílené pamti. Distribuovaná sdílená pam realizovaná na bázi stránkování je nejastji implementovaná a její výhoda je v její pizpsobitelnosti. Implementace je zajištna vytvoením podpory jádra pro uživatelské zpracování výpadk stránek. Dovoluje sdílení promnných umístných ve sdílené pamti. ešení problému pomocí middleware dovoluje vytvoení abstrakcí vysoké úrovn tj. nejen sdílení pamových míst, ale i sdílení objekt. 3 Návrh a prostedky realizace 3.1 Struktura Jednotlivé systémy sdílené pamti se liší mimo jiné tím, jak chápou objekty se kterými pracují, a jak jsou tyto objekty adresovány. Slabikov (bytov) orientované Jsou pístupné jako uspoádané pole slabik ve virtuální pamti. Podporované operace jsou typu read (LOAD) nebo write (STORE). Objektov orientované Sdílená pam je strukturovaná jako soubor objekt na úrovni jazyka se sémantikou vyšší úrovn. Obsah sdílené pamti je mnn pouze pi pístupu k objektm a nikdy pímým pístupem k jednotlivým promnným. Výhodou tohoto pístupu je, že sémantika objekt mže být využita pi vynucené konzistentnosti. Nap. systém Orca vidí sdílenou pam jako soubor sdílených objekt a automaticky serializuje operace nad danými objekty. Nemnitelná data Sdílená pam je vidna jako soubor nemnitelných datových položek, které mohou procesy íst, pidávat a rušit. Píkladem je Linda, JavaSpaces a TSpaces. Systémy typu Linda zavádí prostor n-tic, který obsahuje jeden

3 nebo více typ datových polí. V tomtéž prostoru dvojic mohou existovat rzné typy n-tic. Procesy sdílí data pistupováním k témuž prostoru n-tic. Umístní n-tice do prostoru n-tic se dje operací write, tení nebo vybrání se dje pomocí operace read nebo take. Operace write pidá n-tici bez ovlivnní stávajících n-tic. Operace read vrátí hodnotu jedné n-tice bez modifikace ostatních. Operace take vrátí n-tici, ale navíc ji z prostoru odstraní. K pístupu do prostoru n-tic se používá asociativní adresování. V parametrech se neuvádí adresa n-tice, ale její specifikace. Systém vrátí ty n-tice, které odpovídají specifikaci. Aby mohl proces synchronizovat své aktivity, jsou operace read a take blokované dokud v prostoru n-tic existuje njaká n-tice, odpovídající specifikaci. Specifikace n-tice obsahuje poet polí a požadované hodnoty nebo typy polí. 3.2 Model synchronizace Mnoho aplikací zavádí omezení týkající se hodnot ukládaných do sdílené pamti. To platí jak o aplikacích založených na DSM, tak i o aplikacích psaných pro multiprocesory se sdílenou pamtí. Nap. jestliže a a b jsou dv promnné uložené v DSM, pak omezením mže být to, že vždy platí a=b. Pi manipulaci s tmito promnnými mže dojít ke vzniku nekonzistentnosti, omezení mže být porušeno. Nap. v pípad, že dva procesy inkrementují ob promnné soubžn. ešením je synchronizovat tyto procesy tak, aby manipulaci s promnnými mohl v daném okamžiku provádt pouze jeden z nich. Pi použití DSM musí být realizovány distribuované synchronizaní služby, zahrnující konstrukce známé jako zámky a semafory. Synchronizace je realizována posíláním zpráv. Speciální instrukce používané v tsn vázaných multiprocesorech se spolenou sdílenou pamtí, jako je TestAndSet mohou být použity i v DSM, avšak jejich použití je velmi neefektivní. Realizace DSM proto musí poskytnout jiné efektivní prostedky pro synchronizaci úlohám na aplikaní úrovni. 3.3 Modely konzistentnosti V systémech se spolenou pamtí vtšinou pedpokládáme striktní synchronizaci, podporovanou operacemi nebo funkcemi, které využívají znalosti globálního stavu systému. Tak lze využít nap. operací nad semafory, kritické sekce nebo sequencery. V distribuovaném prostedí není globální stav znám. Proto musí být pro koordinaci výpotu použity jiné metody, nepedpokládající znalost globálního stavu a mající pípustnou míru režie. Tyto metody mají spolenou vlastnost, oznaovanou jako consistency, kterou je možno chápat jako soudržnost, ili soudržnost pamti a program pi manipulaci s daty. Model konzistentnosti je smlouva uzavená mezi softwarem a pamtí. Když se software zaváže pracovat s pamtí podle daných pravidel, pam bude fungovat korektn. Pokud pravidla poruší, pam nic negarantuje. Pi popisu model konzistentnosti budeme používat následující symboliku. Operace R(x)v pedstavuje operaci tení z místa x a vracená hodnota je v. Operace W(x)v pedstavuje operaci zápisu hodnoty v do pozice x Striktní konzistence (strict consistency) Jakékoliv tení z pamti z adresy x vrátí hodnotu uloženou pi posledním zápisu na adresu x. Striktní konzistence je nejsilnjší, je pirozen zajištna na jednoprocesorových systémech. P.: a=1; a=2; print(a); // vytiskne vždy 2 Všechny zápisy jsou okamžit všude viditelné, musí existovat pesný globální as ve všech uzlech. Ideální pro programování, v distribuovaném systému však nedosažitelné. P1: W(x)1 P1: W(x)1 P2: R(x)1 P2: R(x)0 R(x)1 Striktní konzistence Pam, která není striktn konzistentní P2. Pedchozí obrázek vpravo ilustruje pípad, kdy aktualizovaná hodnota x není okamžit viditelná v procesu Sekvenní konzistence (sequential consistency)

4 Výsledek jakéhokoliv výpotu je stejný jako kdyby všechny operace všech procesor byly vykonávány v njakém sekvenním uspoádání a operace každého jednotlivého procesoru jsou vykonávány v poadí specifikovaném programem. Sekvenní konzistence je o nco slabší model, avšak je snadno implementovatelná a píjemná pro programování. Jestliže procesy bží na rzných procesorech, je povoleno libovolné prokládání jejich instrukcí, avšak s podmínkou, že všechny procesy vidí stejné poadí zmn pamti. Zmny nejsou propagovány okamžit, je pouze zarueno poadí (následek nepedchází píinu). P1: W(x)1 P1: W(x)1 P2: R(x)1 R(x)1 P2: R(x)0 R(x)1 Dvakrát spuštný tentýž program P1: P2: P3: a=1; b=1; c=1; print(b,c); print(a,c); print(a,b); šest instrukcí - 6!=720 možných sekvencí, pouze 3*(5!/4)=90 nenarušuje kauzalitu a=1; a=1; b=1; b=1; print(b,c); b=1; c=1; a=1; b=1; print(a,c); print(a,b); c=1; print(a,c); print(b,c); print(a,c); print(a,c); c=1; c=1; a=1; print(b,c); print(a,b); print(a,b); print(b,c); print(a,b); Výstup: Signatura: Jestliže spojíme výstupy proces P1, P2 a P3 (v tomto poadí), dostaneme signaturu - etzec charakterizující konkrétní proložení instrukcí jednotlivých proces, a tím i poadí pamových referencí. Celkem mže existovat 2^6=64 možných signatur, avšak ne všechny odpovídají sekvenní konzistenci - nap , neodpovídají žádnému sekvennímu proložení instrukcí P1: W(a)1 R(b)0 R(c)0 P2: W(b)1 R(a)1 R(c)0 P3: W(c)1 R(a)0 R(b)1 Signatura je nemožná v sekvenn konzistenním modelu Sekvenní konzistence je píjemný model pro programování, avšak jeho výkonnost není píliš velká. Bylo dokázáno (Lipton & Sandberg, 1988) že je-li as tení r, as zápisu w a as penosu zprávy (paketu) t, pak vždy platí r+w t. Jinak eeno - optimalizace protokolu pro tení znamená delší as pro zápis a naopak Kauzální konzistence (causal consistency) Zápisy, které jsou potenciáln kauzáln vázané, musí být vidny všemi procesy ve stejném poadí. Konkurenní zápisy mohou být vidny v rzném poadí. Rozlišuje události, které jsou potenciáln závislé a které nikoliv. Pokud jeden proces W(x)a a druhý proces R(x) W(y)b pak W(y)b je kauzáln závislý na W(x)a. Operace, které nejsou kauzáln závislé jsou konkurenní. P1: W(x)1 W(x)3 P2: R(x)1 W(x)2

5 P3: R(x)1 R(x)3 R(x)2 P4: R(x)1 R(x)2 R(x)3 Kauzální konzistence Poslední píklad zobrazuje situaci, kdy W(x)2 a W(x)3 jsou konkurenní (tj. nejsou kauzáln závislé). Procesy P3 a P4 mohou potom zmnu x íst v opaném poadí. Tato sekvence spluje podmínku kauzální konzistence, nespluje sekvenní a striktní. P1: W(x)1 P1: W(x)1 P2: R(x)1 W(x)2 P2: W(x)2 P3: R(x)2 R(x)1 P3: R(x)2 R(x)1 P4: R(x)1 R(x)2 P4: R(x)1 R(x)2 PRAM konzistence Kauzáln konzistentní sekvence Na druhém obrázku píkladu 7 není W(x)2 kauzáln závislý na W(x)1 a proto obrácené tení R(x)1 a R(x)2 je vzhledem ke kauzální konzistenci korektní. Na prvním obrázku je W(x)2 kauzáln závislé na W(x)1 (pes R(x)1) a proto obrácené poadí tení porušuje kauzální konzistenci. Implementace kauzáln konzistentní pamti vyžaduje udržování grafu závislostí zápis na tení PRAM konzistence (PRAM consistency) Zápisy provádné jedním procesem jsou vidny ostatními procesy v tom poadí, ve kterém byly provádny, avšak zápisy rzných proces mohou být vidny rznými procesy rzn. PRAM (Pipelined RAM) konzistence je snadná na implementaci - nezáleží na poadí, v nmž rzné procesy vidí pístupy k pamti. Jediné, co je teba dodržet, je poadí zápis z jednoho zdroje. Jinak eeno - všechny zápisy generované rznými procesory jsou konkurenní. P1: P2: a=1; b=1; if(b==0) kill(p2); if(a==0) kill(p1); V pípad PRAM konzistence je možný výsledek, že oba procesy budou zabity, a to v pípad, že P1 pete b díve, než uvidí jeho zápis a P2 pete a díve, než uvidí jeho zápis. Tento výsledek není možný pi libovolném uspoádání instrukcí, neodpovídá tedy sekvenní konzistenci, avšak vzhledem k PRAM konzistenci je korektní Slabá konzistence (weak consistency) Výše uvedené konzistenní modely jsou stále pro mnoho aplikací velmi restriktivní (a tedy málo efektivní), nebo vyžadují propagaci všech zápis všem procesm. Ne všechny aplikace vyžadují sledování všech zápis, natož pak njaké jejich poadí. Nap. proces v kritické sekci mže v rychlé smyce íst a zapisovat hodnoty njakých promnných. Ostatní procesy nemají dvod (nebo ani možnost) jednotlivé zápisy vidt, proto není nutné, aby byly všechny propagovány. Pam však nemá možnost vdt, že njaký proces je v kritické sekci a tudíž musí propagovat všechny zápisy. ešením je nechat proces ukonit kritickou sekci a poté zajistit rozeslání zmn všem ostatním procesm. Toho mže být dosaženo použitím speciálního druhu promnné - synchronizaní promnné, která bude použita pro synchronizaní úely. 1. Pístup k synchronizaním promnným je sekvenn konzistentní. 2. Pístup k synchronizaní promnné není povolen dokud neskoní všechny pedchozí zápisy. 3. Pístup k datm není povolen dokud nebyly dokoneny všechny pedchozí pístupy k synchronizaním promnným

6 Bod 1 íká, že všechny procesy vidí všechny pístupy k synchronizaní promnné ve stejném poadí. Bod 2 zaruuje, že ped pístupem k synchronizaní promnné budou dokoneny všechny pedchozí zápisy. Bod 3 íká, že pi pístupu k obyejným promnným jsou dokoneny všechny pedchozí pístupy k synchronizaním promnným. Provedením synchronizace ped tením dat proto zajistí jejich aktuální verzi. P1: W(x)1 W(x)2 S P1: W(x)1 W(x)2 S P2: R(x)2 R(x)1 S P2: S R(x)1 P3: R(x)1 R(x)2 S Slabá konzistence Porušení slabé konzistence V levé ásti obrázku jsou události odpovídající slabé konzistenci - procesy P2 a P3 mohou ped synchronizací vidt pam v libovolném poadí. Pravý obrázek ukazuje porušení slabé konzistence - proces P2 po synchronizaci vidí neaktuální hodnotu promnné x Uvolovací konzistence (release consistency) Slabá konzistence má tu nevýhodu, že pam pi pístupu k synchronizaní promnné nepozná, zda se jedná o vstup nebo o výstup z kritické sekce. Pokaždé proto musí vykonat akce potebné pro oba pípady. K rozlišení tchto pípad používá uvolovací konzistence dv operace - acquire (požadavek) a release (uvolnní). 1. Ped bžným pístupem ke sdílené promnné musí být úspšn ukoneny pedchozí požadavky procesu. 2. Ped provedením uvolnní musí být ukoneny všechny pedchozí zápisy i tení provádné procesem. 3. Požadavky a uvolnní musí být PRAM konzistentní. Jestliže proces vydá požadavek, pak je zarueno, že poté jsou všechny lokální kopie aktuální. Po uvolnní jsou propagovány všechny zmny ostatním procesm. Jestliže jsou všechny podmínky splnny a požadavky a uvolnní se používají správ spárované, výsledek jakéhokoliv výpotu je ekvivalentní sekvenn konzistentní pamti. P1: Acq W(x)1 W(x)2 Rel P2: Acq R(x)2 Rel P3: R(x)1 Uvolovací konzistence Eager release consistency - po release se propagují zmny všem procesm. Lazy release consistency - po release se nic nepropaguje, až pi acquire jiného procesu - asové znaky Pístupová konzistence (entry consistency) 1. Požadovaný pístup procesu k synchronizaní promnné není povolen dokud nebyly provedeny všechny aktualizace chránných sdílených dat procesu. 2. Exklusivní pístup procesu k synchronizaní promnné je povolen pouze v pípad, že žádný jiný proces nepistupuje k synchronizaní promnné, a to ani neexklusivn. 3. Po exkluzivním pístupu k synchronizaní promnné si píští neexkluzivní pístup libovolného procesu k synchronizaní promnné musí vyžádat aktuální kopii dat od vlastníka synchronizaní promnné. Všechna sdílená data jsou vázána na synchronizaní promnnou. Pi pístupu k synchronizaní promnné jsou synchronizována pouze ta data, která jsou vázána na synchronizaní promnnou. Každá synchronizaní promnná má v každém okamžiku vlastníka - proces, který k ní naposledy pistupoval. Vlastník mže opakovan vystupovat do a vystupovat z kritické sekce bez nutnosti komunikace. Proces, který není vlastníkem, musí požádat o vlastnictví. Pi penosu vlastnictví se aktualizují hodnoty dat vázaných na synchronizaní promnnou. Pístup k datm a synchronizaním promnným mže být exkluzivní (read & write) nebo neexkluzivní (read only).

7 3.3.8 Shrnutí konzistenních model Konzistence a Striktní Sekvenní Kauzální PRAM b Slabá Uvolovací Pístupová Vlastnosti Absolutní asové uspoádání Všechny události jsou vidt ve stejném poadí Kauzáln vázané události jsou vidt ve stejném poadí Události jednoho procesu vidt ve stejném poadí Sdílená data jsou konzistentní po synchronizaci Sdílená data jsou konzistentní po opuštní kritické sekce Sdílená data vázaná na kritickou sekci jsou konzistentní pi vstupu do kritické sekce Pehled základních konzistenních model (a) bez synchronizaních operací (b) se synchronizaními operacemi 3.4 Možnosti aktualizace Existují dv základní možnosti jak propagovat aktualizaci dat z jednoho procesu ostatním. Jsou to writeupdate a write-invalidate. Je možné je aplikovat na rzné modely konzistence. Write-update Aktualizace dat se provádí lokáln a pomocí skupinového adresování se rozesílá všem managerm replik, udržujícím kopie datových položek. Ti okamžit modifikují data tená lokálními procesy. Procesy tou kopie lokálních dat bez poteby komunikace. Krom toho že mže existovat více tená, mže také nkolik proces zapisovat tatáž data ve stejnou dobu. Model konzistentnosti pamti, který je realizován s metodou write-update závisí na mnoha faktorech, zejména na vlastnostech skupinového protokolu. Sekvenní konzistentnosti mže být dosaženo použitím skupinového protokolu s úplným uspoádáním, kdy se všechny procesy dohodnou na poadí aktualizací. Výhodou jsou laciné operace tení, které probíhá lokáln. Nevýhodou je relativn vysoká cena implementace uspoádaného multicastu programov. Proto v konkrétních realizacích se používají skupinové protokoly s technickou podporou na pístupové úrovni. Write-invalidate Je obecn realizovaná v systémech typu multiple-reader/single-writer sharing. Data mohou být bu zpístupnna více procesm najednou pro tení, nebo jednomu procesu pro tení i zápis. Položka, která je zpístupnná pouze pro tení mže být libovoln kopírována do ostatních proces. Pokud se proces pokusí zapsat do položky, pošle se nejprve do všech proces zpráva, která ji zneplatní a teprve po potvrzení zprávy mže proces položku aktualizovat. Tím jsou procesy ochránny ped tením starých dat. Všechny procesy, které se ve stejnou dobu pokusí aktualizovat položku jsou blokovány do doby, než je aktualizace vybraným procesem dokonena. Výsledkem je, že procesy pistupují k položce pi zápisu uspoádan podle pravidla první pijde, první je obsloužen. Toto pístupové schéma zajišuje sekvenní konzistentnost. Pokud se použije zneplatnní zpoždné, dosáhneme release-consistency. 3.5 Granularita ( zrnitost, krystalinost) Otázka, která je spojena se strukturou DSM je zrnitost sdílení. Obecn sdílí všechny procesy celý obsah sdílené pamti. Bhem innosti program je však teba sdílet pouze nkteré ásti sdílené pamti bhem njakého asu. Proto by bylo pro sdílenou pam zahubující vždy penášet celý obsah sdílené pamti jakmile proces k ní pistupuje a aktualizuje ji. Nyní se zamíme na implementace založené na stránkách. V page-based DSM podporuje hardware zmny v adresním prostoru na úrovni stránek v podstat zmnou odkazu na stránku v tabulce stránek. Velikost stránek je typicky do 8 kb, takže to je to množství dat, které je teba penést sítí k zajištní konzistentnosti. Nezáleží pitom na tom, byla-li aktualizována celá stránka nebo jen jedna slabika.

8 Použití menších velikostí stránek nevede ke zlepšení. V mnoha pípadech aktualizuje proces velké množství dat, což by vedlo k penosu nkolika stránek po sob. S více penosy je spojena vtší administrativa. Použití menších stránek vede k k velkému potu jednotek, o které se musí systém starat. Záležitost komplikuje i to, že procesy zápasí s tím, aby byla aktualizovaná data umístna v jedné stránce, k emuž pispívá vtší rozsah stránky. Pedpokládejme dva procesy, které pistupují do jedné stránky, kdy první proces pouze te data A, zatímco druhý proces pouze aktualizuje data B. Na aplikaní úrovni v tomto pípad neexistuje žádný konflikt. Avšak pesto musí být celá stránka penášena, protože DSM implicitn neví, která místa ve stránce byla zmnna. Tento jev je znám jako falešné sdílení dva nebo více proces sdílí ásti stránky, ale ke každé ásti ve skutenosti pistupuje pouze jeden. V pípad write-invalidate protokolu mže vézt falešné sdílení k zbyteným zneplatnním. V pípad write-update protokolu, kdy nkolik pisatel falešn sdílí datové položky, mže zpsobit jejich pepsání staršími verzemi. V praxi je volba jednotky sdílení volena na základ fyzikální velikosti stránek. Pokud je velikost stránky malá, mže být základní jednotka brána jako souvislá posloupnost stránek. Návrh vhodné délky stránky respektující hranice stránek je urující pro poet stránkových penos za bhu programu. 3.6 Thrashing (porážka, mlácení, bytí) Potenciálním problémem write-invalidate protokol je trashing. íkáme, že se objeví trashing, jestliže DSM tráví nadmrný množství asu rušením platnosti a penášením sdílených dat, v porovnání s asem stráveným aplikaním procesem vykonáváním užitené práce. To se stane tehdy, jestliže nkolik proces dokonuje aktualizaci týchž dat nebo pi falešn sdílených datových jednotkách. Jestliže nap. jeden proces opakovan te datovou položku a druhý proces ji pravideln aktualizuje, pak je tato položka neustále penášena od zapisujícího a zneplatována tenáem. Toto je pípad sdílení dat, kdy write-invalidate je nevhodný a write-update je lepší. 4 Sekvenní konzistentnost a Ivy Popis metod pro implementaci sekvenn konzistentní, stránkové DSM. 4.1 Model systému Základní model je uvažován tak, že soubor proces sdílí segment DSM. Segment je mapován do téhož adresního prostoru v každém procesu. Hodnoty významných pointer mohou být ukládány v segmentu. Procesy jsou spouštny na poítaích s podporou stránkování. Budeme pedpokládat, že existuje pouze jeden proces na poítai, který má pístup do DSM segmentu. Pokud existuje v uzlu více proces pistupujících do sdílené pamti, pak využívají sdílenou pam pímo pomocí tabulky stránek, kdy jeden segment sdílené pamti mže být zapsán do více tabulek stránek. Jedinou komplikací je koordinace vybírání a rozšiování aktualizací do stránky, pi pístupu dvou nebo více proces Tento popis tyto detaily ignoruje. Pro aplikace je stránkování transparentní, mohou íst i zapisovat data do DSM. Avšak aby DSM udržela sekvenní konzistentnost pro zapisující a toucí procesy, omezuje práva pístupu do stránek. Jednotka pro ízení pístupu do stránkové pamti dovoluje nastavit pístupová práva na none, R/O a R/W. Pokud se proces pokusí nastavená práva porušit, vrátí se mu chybové hlášení podle typu pístupu. Jádro pesmruje chybu do ovladae specifikovaného v DSM pro každý proces. Ovlada pro zpracování chyby stránky zpracuje chybu speciálním zpsobem. Problém aktualizace zápisu Pokud je DSM založeno na stránkování, pak pro sdílení se používá technika write-update pouze tehdy, mohou-li být zápisy bufferovány. Je to proto, že standardní systém zpracování chyb stránek není použitelný pro zpracování každého zápisu do pamti. Pedpokládejme, že je stránka chránna proti zápisu. Pokud se proces pokusí do stránky zapsat, vznkne výpadek stránky a je volán píslušný ovlada. Tento ovlada v principu mže zjistit chybující instrukci i adresu a hodnotu, která mla být zapsána. Mže poslat multicast zprávu s aktualizací ješt pedtím, než obnoví pístup pro zápis a ukoní perušenou instrukci. Ale nyní když byl zápisový pístup obnoven, nezpsobí další aktualizace ve stránce její výpadek. Aby každý zápis zpsobil výpadek stránky, je nutné aby ovlada nastavil proces do tracovacího režimu, ve kterém procesor generuje perušení pi každé instrukci. Ovlada trasování vypne práva zápisu do stránky a zase vypne

9 trasovací režim. Celé se opakuje pi další chyb zápisu. Metoda je náchylná být velmi drahá. Bhem provádní procesu vzniká mnoho výjimek. V praxi se write-update používá ve spojení se stránkovou pamtí pokud stránka není chránna proti zápisu po poátení chyb stránky a navíc je povoleno provézt nkolik zápis pedtím, než je aktualizovaná stránka rozšíena. Používá se technika bufferování zápisu. Navíc je možné proces propagace stránky zefektivnit tím, že si zapamatujeme kopii stránky ped prvním zápisem a pak porovnáním pvodního stavu s aktualizovaným rozešleme pouze zmny. Ostatní procesy generují aktualizovanou stránku také z kopie ped aktualizací a ze seznamu odlišností. 4.2 Write invalidation Algoritmus založený na neplatných datech využívá ochranu stránky k vynucení sdílení konzistentních dat. Pokud proces aktualizuje stránku, má pouze lokální práva íst a zapisovat. Ostatní procesy nemají k této stránce pístup. Pokud jeden nebo více proces stránku te, mají práva tení. Ostatní procesy nemají ke stránce pístup. Proces s nejaktuálnjší verzí stránky p je oznaen jako její vlastník owner(p). Je to bu jeden zapisující, nebo jeden ze toucích. Soubor proces, které vlastní kopii stránky p je nazýván copy-set a oznaován copyset(p). Pokud proces P w se pokusí zapsat do stránky p, pro kterou nemá pístupová práva nebo pouze práva R/O, objeví se výpadek stránky, který je zpracován následovn: Stránka je penesena do P w, pokud dosud nemá aktualizovanou R/O kopii U všech ostatních kopií je zrušena platnost, práva pístupu jsou nastavena na no-access u všech len copyset(p). Do všech len copyset(p) se dosadí P w Vlastník p owner(p) se nastaví na P w DSM nastaví P w pro proces p na práva R/W a spustí instrukci, která zpsobila výjimku. Poznamenejme, že mže nastat pípad, kdy dva nebo více proces s R/O kopiemi mohou vyvolat chybu zápisu ve stejném ase. R/O kopie stránky mže být zastaralá pokud je vlastnictví je nakonec pipouštt. K detekci kdy je souasná R/O kopie stránky zastaralá mžeme použít sekvenní ísla spojená s každou stránkou. Tato ísla se inkrementují kdykoliv je vlastnictví pesunuto. Proces, který požaduje pístup pro zápis vloží sekvenní íslo své kopie R/O, pokud ji vlastní. Souasný vlastník mže pak íct zda byla stránka modifikována a proto je teba, aby bylo poslána. Toto schéma je nazýváno shrewd algorithm mazaný algoritmus. Pokud proces PR se pokouší íst stránku p ke které nemá pístupová práva nastane výpadek stránky pi tení. Procedura pro zpracování výpadku pracuje následovn Stránka je kopírována od vlastníka owner(p) do PR. Jestliže souasný vlastník je jediný zapisující, pak zstane jako vlastník p a jeho pístupová práva pro p jsou nastavena na R/O. Ponechaná práva pístupu pro tení jsou potebná v pípad, že se proces pokusí íst stránku pozdji. bude mu ponechána souasná verze stránky. Avšak, jak vlastník bude muset zpracovat následující požadavky pro stránku i když nebude pistupovat ke strance znovu. Takže mže být vhodnjší redukovat práva na no access a penést vlastnictví na PR. Pidá PR do copyset(p) DSM v PR umístí stránku s právy R/O na vhodné místo v svém adresním prostoru a restartuje perušenou instrukci. Je možné pro, že se bhem algoritmu penesení objeví druhý výpadek stránky. Aby byly pesuny zpracovány konzistentn, je nový požadavek na stránku zpracován až je probíhající penos ukonen. Daný popis dosud vysvtloval co musí být provedeno. Dále se budeme zabývat problémem jak realizovat zpracování výpadku stránky. 4.3 Invalidation protocols K realizaci protokolu pro zrušení platnosti dat je teba vyešit následující problémy 1. jak vybrat owner(p) pro danou stránku p 2. kde ukládat copyset(p) V literatue je popsáno nkolik architektur a protokol které dávají rzné pístupy k tmto problémm. Nejednodušší je centralizovaný algoritmus. K uložení umístní vlastník owner(p) pro každou stránku p se použije jeden server nazývaný manager. Mže to být jeden z proces bžících s aplikací, nebo to mže být jakýkoliv jiný proces. V tomto algoritmu se množina copyset(p) ukládá v owner(p). Jsou tedy uloženy identifikátory a transportní adresy len copyset(p). Pokud se objeví výpadek stránky, lokální proces pošle zprávu manageru, který obsahuje

10 íslo stránky a požadovaný typ pístupu. Pak proces eká na odpov. Manager zpracuje požadavek vyhledáním adresy vlastníka owner(p) a posláním požadavku vlastníku. Pokud dojde k výpadku stránky pro zápis, nastaví manager nového vlastníka klienta, který vyslal požadavek. Následující požadavky jsou azeny do fronty na klientu dokud není dokonen penos vlastnictví do nj. Pedchozí vlastník pošle stránku do klienta. V pípad výpadku stránky pro zápis pošle také copyset(p) pro danou stránku. Klient provede zneplatnní dat jakmile pijme copyset. Posílá multicast požadavek lenm copyset a oekává potvrzení od všech proces že zneplatnní bylo provedeno. Multicast nemusí být uspoádaný. Pvodní vlastník nemusí být zahrnut v seznamu cíl, protože zneplatní sám sebe. Manager je úzké místo pro výkonnost systému a kritické místo pro chyby. Byly navrženy ti alternativy které dovolují aby zátž spojená s managementem stránek byla rozdlena mezi poíta. 1. Fixní distribuovaný management stránek, kde existuje nkolik manager, z nichž každý je funkn ekvivalentní centrálním manageru, ale stránky jsou mezi managery statisticky rozdleny. Klienti pomocí hashovací funkce vypotou index, urující manager, který se o stránku stará. Dle indexu pak z tabulky vyhledají adresu odpovídajícího managera. Toto schéma zlepší problém zatížení obecn, ale má nevýhodu v tom, že mapuje stránky na managery fixn, což nemusí být vhodné. Pokud není pístup ke stránkám rozložen rovnomrn, jsou nkteí managei zatíženi více než jiní. 2. Distribuovaný algoritmus založený na multicastech. Multicast mže být použit k eliminaci manager kompletn. Pokud proces vyvolá výjimku, posílá pomocí multicastu požadavek na stránku všem ostatním procesm. Odpoví pouze proces, který stránku vlastní. Starost musí být vnována pípadu, kdy dva nebo více klient požaduje tutéž stránku v tutéž dobu. Každý klient musí nakonec obdržet stránku, i když jeho požadavek je multicast bhem penosu vlastnictví. Uvažujme dva klienty C1 a C2, kteí použijí multicast pro nalezení stránky vlastnné O. pedpokládejme, že O pijme nejdíve požadavek od C1 a penáší do nj vlastnictví. Díve než stránka dorazí, obdrží O i C1 požadavek od C2. O zruší požadavek C2 protože již nevlastní stránku. C1 pozdrží zpracování požadavku od C2 dokud C1 neobdrží stránku jinak odhodí požadavek, protože není vlastníkem a požadavek C2 se ztratí úpln. Avšak problém zstává. Požadavek C1 bude zaazen do fronty na C2 prozatím. Po té, co C1 má nakonec stránku C2, pijme C2 požadavek od C1, ale ten je nyní zastaralý. ešením je použít úpln uspoádaný multicast, tak že klienti mohou bezpen zahazovat požadavky které pijdou ped jejich vlastními (požadavky jsou doruovány jim samým tak jako ostatním procesm. Jiné ešení, které používá lacinjší neuspoádaný multicast, ale které spotebuje širší pásmo, je spojit každou stránku s vektorem asových razítek, jedno pro každý proces. Pokud je penášeno vlastnictví stránky, tak je to asové razítko. Pokud proces obdrží vlastnictví, inkrementuje položku v asovém razítku. Pokud proces požaduje vlastnictví, pibalí poslední asové razítko pro danou stránku. V našem pípad C2 mže zrušit požadavek C1, protože položka C1 v asovém razítku požadavku je menší než ta, která pijde se stránkou. A se použije uspoádaný nebo neuspoádaný multicasty, má toto schéma nevýhodu multicast schémat procesy které nejsou vlastníky stránek jsou perušovány bezvýznamnými zprávami, které nií as procesoru. 3. Dynamický distribuovaný management 4.4 Dynamický distribuovaný algoritmus ízení Algoritmus dynamického distribuovaného ízení dovoluje aby bylo vlastnictví stránky možno penášet mezi procesy ale s využitím možnosti muticastu jako metody pro lokalizaci vlastníka stránky. Myšlenka je založena na rozdlení zátže lokalizovaných stránek mezi ty poítae, které k nim pistupují. Každý proces udržuje pro každou stránku p píznak - tip jako by byl vlastníkem stránky pedpokládaný vlastník p, nebo probowner(p). na zaátku je každý proces seznámen s pesným umístním stránky. Obecn jsou však tyto hodnoty pouze tipy, protože stránky mohou být penášeny kdykoliv v libovolný okamžik. Tak jako v pedchozím algoritmu, je vlastnictví penášeno pouze tehdy, jestliže se objeví výpadek stránky z dvodu zápisu. Vlastník stránky je umístný v etzcích tip, které jsou nastaveny když je vlastnictví stránky penášeno z poítae do poítae. Délka etzce, která je dána potem forwardovaných zpráv nutných k lokalizaci vlastníka se mže prodlužovat neomezen. Algoritmus tomu brání aktualizací tip. Jakmile je dostupných více aktualizovaných hodnot. Tipy jsou aktualizovány a požadavky dále posílány následovn: Jakmile proces posílá vlastnictví ke stránce p jinému procesu, aktualizuje probowner(p) na píjemce Když proces zpracuje individuální požadavek na stránku p, aktualizuje probowner(p) na požadujícího Jestliže proces, který požadoval pístup pro tení ke stránce p ji pijme, aktualizuje probowner(p) na vykonavatel Jestliže proces pijme požadavek na stránku p, kterou nevlastní, pošle požadavek na probowner(p) a nuluje probowner(p) jako požadujícího.

11 První ti aktualizace vychází z protokolu pro penos vlastnictví stránky a za pedpokladu R/O kopírování. Odvodnní pro aktualizaci pokud posílá dále požadavek je v tom, že pro požadavky zápisu bude požadující brzy vlastník, pokud jím není již nyní.proto probowner aktualizace je provádna pro požadavek pístupu tení i zápisu. Prmrná délka etzce ukazatel mže být redukována periodickým vysíláním broadcast s umístním aktuálních vlastník do všech proces. Výsledkem je zhroucení všech etz až na délku jedna. 4.5 Trashing (porážka) Omezení ztrát vzniklých zbyteným pesunováním vlastnictví stránek mže ešit programátor vhodným uspoádáním píkaz. ešení, které je vzhledem k programm transparentní je následující. Každá stránka je pidlována s malým asovým úsekem. Chce-li proces pistupovat ke stránce, je dovoleno zadržet pístup pro daný interval, který slouží jako typ asového okna. Ostatní požadavky na stránku jsou zadržovány. Velkou nevýhodou je stanovení délky asového úseku. ešením je volba délky asového úseku dynamicky, pozorováním doby pístupu nebo sledováním délky front, ve kterých procesy ekají na stránku. 5 Release consistency a Munin Pedchozí algoritmus byl navržen pro dosažení sekvenní konzistentnosti. Výhodou sekvenní konzistentnosti je, že DSM zachovává pedstavu sdílené pamti. Nevýhodou je, že je drahé ji realizovat. DSM systémy asto vyžadují využití multicastu v realizaci a jsou založeny na write-upddate nebo write-invalidate. Pro zneplatnní staí neuspoádaný multicast.lokalizace vlastníka zprávy má tendenci být drahá. Centrální manager, který zná umístní vlastníka každé stránky se jeví jako úzké místo. Pospojované ukazatele vyvolávají v prmru mnoho zpráv. Navíc algoritmus založený na zneplatnní mže vézt k thrashing (tžká porážka, výprask). Release consistency byla poprvé pedstavena v datech multiprocesoru, který realizoval DSM hardwareov, pvodn využívaje write-invalidation protokol. Release consistency je volnjší než sekvenní konzistentnost a levnjší z hlediska realizace, ale má rozumnou sémantiku, která je tvárná pro programátory. Myšlenka release consistency je redukovat režii DSM využitím faktu, že programátoi používají synchronizaci objekt jako je semafor, zámk a barier. Realizace DSM mže využít znalosti o pístupech k tmto objektm k povolení, aby byla pam nekonzistentní v nkolika bodech, piemž použití synchronizaních objekt nicmén udržuje konzistentnost na aplikaní úrovni. 5.1 Pístupy do pamti Abychom pochopili release consistency nebo jakýkoliv jiný model pamti, který bere v úvahu synchronizaci zaneme s kategorizací pístup do pamti podle jejich pravidel, pokud existují, v synchronizaci. Krom toho budeme diskutovat o tom, jak má být provádn asynchronní pístup do pamti aby získal na výkonnosti a dával jednoduchý operaní model jaký efekt má pístup do pamti. Jak jsme pedtím íkali, DSM implementace v distribuovaných systémech pro obecné použití používá pro synchronizaci spíše penos zpráv než sdílené promnné, a to z dvodu efektivnosti. Ale mže pomoci v následujících diskusích k pochopení synchronizace založené na sdílených promnných. Následující pseudokód realizuje zámky s využitím funkce testandset. funkce nastaví zámek na 1 a vrací 0 nalezla-li nulu, jinak vrací 1. To dlá automaticky. Typy pístup do pamti Hlavní rozdíl je mezi protikladným pístupem a neprotikladným, normálním pístupem. Dva pístupy jsou protikladné jestliže: Mohou se objevit soubžn Alespo jeden je zápis Takže dv operace tení nemohou být nikdy protikladné, tení a zápis do téhož místa vytváený dvma procesy které se mezi operacemi synchronizují je neprotikladný. Dále dlíme protikladný pístup na synchronizovaný a nesynchronizovaný: Synchronizovaný pístup jsou operace tení nebo zápisu které pispjí k synchronizaci Asynchronní pístup jsou operace tení a zápisu, které jsou konkurenní ale které nepispívají k synchronizaci. Synchronizovaný pístup je protikladný, protože potenciáln synchronizované procesy musí být schopné pistupovat k synchronizaním promnným soubžn a musí je aktualizovat. Naopak operace tení nemusí

12 dosáhnout synchronizace. Ale ne všechny protichdné pístupy jsou synchronizaní pístupy existují tídy paralelních algoritm ve kterých procesy vytváí protichdný pístupy ke sdíleným promnným aby je aktualizovaly a etly jiné výsledky a ne synchronizovaly. Synchronizaní pístup je dále dlen na pístup získat a pístup uvolnit, související s jejich rolí v potenciálním blokování procesu vytváejícího pístup, nebo odblokování njakých jiných proces. Provádní asynchronních operací Operace write mohou být realizovány asynchronn. Zapisovaná hodnota je bufferována ped jejím propagováním a efekty zápisu jsou ostatními procesy pozorovány až pozdji. DSM realizace mohou pedem vybírat hodnoty v oekávání jejich tení, aby pedešly pozastavení procesu v dob kdy potebuje data. Procesory mohou provádt instrukce mimo poadí. ekají-li na ukonení provádného pístupu do pamti, mohou vyvolat další instrukci pokud nezávisí na provádné instrukci Z pohledu asynchronních operací musíme rozlišovat mezi okamžikem kdy je operace read nebo write vyvolána a okamžikem, kdy je provedena nebo dokonena. Budeme pedpokládat že DSM je alespo koherentní. To znamená, že každý proces souhlasí s poadím operací zápis do téhož místa.za tohoto pedpokladu mžeme mluvit jednoznan o uspoádání operací zápisu do daného místa. íkáme, že operace zápisu W(x)v byla provedena co se týe procesu P jestliže od tohoto okamžiku operace tení procesu P vrátí hodnotu v zapsanou operací zápisu, nebo hodnotu njakého následujícího zápisu do x. Podobn íkáme, že operace tení R(x)v byla provedena co se týe procesu P, pokud žádná následující operace zápisu vložená do téhož místa mže pípadn nahradit hodnotu v kterou P te. Nap. P mže mít pedem vybranou hodnotu kterou bude íst. Nakonec operace o byla provedena jestliže je provedena s ohledem na všechny procesy. 5.2 Release consistency Požadavky, se kterými se pejeme seznámit jsou: Udržovat synchronizaní sémantiku objekt jako jsou zámky a bariery K získání výkonnosti povolujeme pimené množství asynchronnosti pro operace s pamtí K omezení pekrývání mezi pístupy k pamti abychom garantovali provádní, které je ekvivalentní sekvenní konzistentnosti Release consistency je definována následovn: 1. ped bžnou operací tení nebo zápisu je povoleno provézt s respektováním ostatních proces, všechny pedchozí získané pístupy musí být provedeny 2. pedtím než je povoleno provedení operace release s respektováním ostatních proces, všechny pedchozí operace read a write musí být provedeny 3. operace acquire a release jsou sekvenn konzistentní pi vzájemném respektování. Pravidla 1 a 2 garantují, že pokud se provádí operace release, žádný jiný proces požadující lock nemže starou verzi dat modifikovaných procesem, který provádí release.to je konzistentní s oekáváním programátora, který uvoluje zámek, potvrzuje, že proces skonil modifikací dat uvnit kritické sekce. 5.3 Munin Munin je DSM systém založený na programových "objektech", ale který mže umístit každý objekt na samostatné stránce tak, aby mohl být použit MMU hardware pro detekování pístupu ke sdíleným objektm. Munin používá model s nkolika procesory, z nichž každý má stránkovaný lineární adresový prostor, ve kterém jedno nebo více vláken provádjí nepatrn modifikovaný multiprocesorový program. Cílem projektu Munin je, aby multiprocesorové programy po minimálních zmnách efektivn bžely na multicomputerových systémech s použitím DSM. Zmny spoívají v oznaení deklarací sdílených promnných klíovým slovem shared, aby je kompilátor rozpoznal. Pi tom mže být také dodána informace, jak bude sdílená promnná používána, což dovoluje provádní uritých optimalizací. Implicitn kompilátor ukládá každou sdílenou promnnou na samostatnou stránku, akoliv rozsáhlé sdílené promnné (jako jsou pole) mohou obsadit nkolik stránek. Programátor však mže urit, že nkolik

13 sdílených promnných se stejným typem sdílení bude uloženo v jedné stránce. Pro promnné rzných typ to není dovoleno, protože protokol používaný pro konzistenci stránek závisí na typu na nich uložených promnných. Spuštním zkompilovaného programu je spuštn koenový proces (root process) na jednom z procesor. Tento proces mže vytváet další procesy na jiných procesorech, které s ním pak pobží paraleln a budou s ním a mezi sebou komunikovat prostednictvím sdílených promnných tak, jako to dlají normální multiprocesorové programy. Je-li proces spuštn na jednom procesoru, bží na nm po celou dobu (procesy nemigrují). Pístup ke sdíleným promnným je realizován normálními instrukcemi CPU pro tení a zápis. Nejsou použity žádné zvláštní metody ochrany. Pi pokusu o použití sdílené promnné, která není pítomná, dojde k výpadku stránky a ízení pevezme systém Munin. Zpsob synchronizace pro vzájemné vylouení je úzce svázán s modelem pamové konzistence. Lze deklarovat promnné typu zámek, jejichž zamykání a odemykání se provádí pomocí knihovních funkcí. Dále jsou podporovány bariéry, podmínné promnné (condition variables) a další synchronizaní promnné. 5.4 Release Consistency Munin je založen na softwarové implementaci release consistency. Munin dává uživatelm prostedky k tomu, aby mohli strukturovat své programy s použitím kritických oblastí (critical regions), definovaných dynamicky pomocí volání žádostí (acquire) a uvolnní (release). Zápisy do sdílených promnných se musí provádt uvnit kritických oblastí, tení mohou být uvnit i venku. Pokud je proces aktivní uvnit kritické oblasti, systém negarantuje jakoukoliv konzistenci sdílených promnných, ale v okamžiku, kdy je kritická oblast opuštna, jsou sdílené promnné modifikované od posledního uvolnní (release) zaktualizovány na všech poítaích. Programm, které dodržují tento model, se distribuovaná sdílená pam jeví jako sekvenn konzistentní. Munin rozlišuje ti tídy promnných: 1. Obyejné promnné 2. Sdílené datové promnné 3. Synchronizaní promnné. Obyejné promnné nejsou sdíleny a mohou být teny a zapisovány pouze procesem, který je vytvoil. Sdílené datové promnné jsou viditelné více procesm a jeví sekvenn konzistentní, pokud je všechny procesy používají pouze uvnit kritických oblastí. Musí být deklarovány jako sdílené, ale pistupuje se k nim pomocí obvyklých instrukcí pro tení a zápis. Synchronizaní promnné jako jsou zámky a bariéry, jsou zvláštní a pístupné pouze prostednictvím systémových volání (lock, unlock pro zámky, increment a wait pro bariéry). Tyto procedury zajišují, že distribuovaná sdílená pam vbec pracuje. P.: Release consistence v Muninu pro ti kooperující procesy, každý bžící na vlastním poítai. V uritém okamžiku chce proces 1 vstoupit do kritické oblasti chránné zámkem L (všechny kritické oblasti musí být chránny stejnou synchronizaní promnnou). Píkaz Lock zajistí, že žádný správn se chovající proces není práv ve stejné kritické oblasti. Potom je proveden pístup ke tem sdíleným promnným (a, b, c) použitím obvyklých instrukcí. Nakonec je zavolán píkaz Unlock, který zpsobí propagaci výsledk všem poítam, které vlastní kopie promnných a, b, c. Tyto zmny jsou zabaleny do minimálního potu zpráv. Pístupy k tmto promnným na jiných poítaích, zatímco je proces 1 uvnit kritické oblasti, dají nedefinované výsledky. 5.5 Protokoly Muninu Krom používání release consistency, používá Munin další techniky ke zvýšení výkonu. Mezi nimi je nejdležitjší to, že programátor mže zaadit každou sdílenou promnnou do jedné ze 4 kategorií: 1. Read-only (pouze ke tení) 2. Migratory (migraní) 3. Write-shared (sdílená pro zápis) 4. Conventional (konvenní).

14 Pvodn Munin podporoval i další kategorie, ale zkušenost ukázala, že mají pouze okrajový význam, a proto se od nich upustilo. Každý poíta spravuje adresá obsahující odkazy na všechny promnné, kde se mimo jiné íká o každé promnné, do které kategorie patí. Pro každou kategorii je použit jiný protokol. Read-only promnné jsou nejsnadnjší. Když odkaz na read-only promnnou zpsobí výpadek stránky, Munin vyhledá promnnou v adresái, najde kdo ji vlastní a požádá vlastníka o kopii potebné stránky. Protože se stránky obsahující read-only promnné nemní (poté co byly inicializovány), nedochází k problémm s konzistencí. Readonly promnné jsou chránny MMU hardwarem. Pokus o zápis do takové promnné zpsobí závažnou chybu (fatal error). Migratory sdílené promnné používají protokol acquire/release. Ten je vidt napíklad u zámk na p1. Jsou používány uvnit kritických oblastí a musí být chránny synchronizaními promnnými. Myšlenka spoívá v tom, že tyto promnné migrují z poítae na poíta, když procesy vstupují a vystupují z kritických oblastí. Nejsou replikovány. Ped použitím migraní promnné je nutné nejprve pro sebe získat zámek. Jestliže je promnná tena, vytvoí se kopie její stránky na poítai, kde se tení provádí a pvodní kopie se smaže. Optimalizací tohoto zpsobu komunikace mže být, že zámek svázaný s migraní promnnou se zašle spolu s ní v jedné zpráv, ímž se eliminují zprávy navíc. Jestliže programátor usoudí, že je bezpené, aby více proces najednou zapisovalo do téže promnné, použijí se promnné sdílené pro zápis. Napíklad více proces mže paraleln zapisovat do pole tak, že každý proces pistupuje pouze do urité oblasti pole. Na zaátku jsou stránky obsahující write-shared promnné oznaeny jako read-only. Mohou už v této chvíli být replikované. Dojde-li k zápisu, obsluha výjimky (zápis do read-only stránky) vytvoí kopii stránky nazývanou "dvoje" (twin), oznaí stránku jako "dirty" a umožní, aby MMU mohlo provádt zápisy do stránky. Když dojde k uvolnní (pozn.: z textu není jasné, kdy to je, protože tady není kritická sekce!), Munin provede srovnání dirty stránky s jejím dvojetem slovo po slovu a pošle zmny (spolu se všemi migraními stránkami) všem procesm, které je potebují. Pak nastaví ochranu stránky zpt na read-only. Když píjemce obdrží seznam zmn, zkontroluje každou stránku, zda ji nemnil také. Jestliže ji nemnil, akceptuje zmny, které pišly. Jestliže byla stránka zmnna také lokáln, provede se porovnání lokální stránky, jejího dvojete a píchozího seznamu slovo po slovu. Jestliže bylo slovo zmnno lokáln a píchozí mnn nebyl, pak píchozí slovo pepíše lokální. Jestliže byly zmnny ob slova (lokální i píchozí), je signalizována bhová chyba. Jestliže neexistují žádné konflikty, výsledek slévání stránek pepíše lokální stránku a bh procesu pokrauje. Se sdílenými promnnými, u kterých není uvedena žádná ze ty kategorií, se zachází stejným zpsobem jako v konvenních DSM systémech založených na stránkování. Existuje pouze jedna kopie každé zapisované stránky, která je pesouvána z procesu do procesu na požádání. Read-only stránky jsou replikovány dle poteby. P.: Chování systému s ryze sekvenní konzistencí. Nejprve se oba procesy zastaví na bariée. Bariéra mže být implementována pomocí správce bariéry (barrier manager), kterému každý proces zašle zprávu a je blokován, dokud nedostane odpov. Správce bariéry nepošle žádnou odpov, dokud všechny procesy nedorazí k bariée. Po minutí bariéry, mže proces 1 zaít zápisem do prvku a[0]. Pak se proces 2 pokusí zapsat do a[1], což zpsobí výpadek stránky následovaný natením stránky se sdíleným polem. Potom se proces 1 pokusí o zápis do prvku a[2], ímž zpsobí další výpadek a tak dál. Pi troše smly mže každý zápis znamenat penos celé stránky, což zpsobí velký provoz na síti. P.: Použití release consistency. Opt oba procesy nejprve minou bariéru. První zápis do a[0] zpsobí vytvoení dvojete (twin page) pro proces 1. Podobn první zápis do a[1] zpsobí vytvoení dvojete pro proces 2. V této chvíli nejsou potebné žádné penosy stránek mezi poítai, každý proces ukládá do své kopie pole a bez jakýchkoliv výpadk stránek. V moment, kdy každý z proces dorazí na druhou bariéru, jsou nalezeny rozdíly mezi jeho aktuálními a pvodními (uloženy ve dvojeti) hodnotami pole a. Rozdíly jsou poslány všem procesm, o kterých se ví, že mají o tyto stránky zájem. Tyto procesy pak mohou poslat rozdíly všem dalším procesm, které se o n zajímají a o kterých nevdl zdroj zmn. Každý píjemce slije zmny se svou vlastní verzí stránky. Konflikty koní bhovou chybou. Poté co proces zveejnil tímto zpsobem zmny, pošle zprávu správci bariéry a eká na odpov. Ve chvíli, kdy všechny procesy rozeslaly své zmny a dorazily k bariée, správce bariéry rozešle odpovdi a všichni mžou pokraovat. Pi této metod je peprava stránek potebná pouze pi dosažení bariéry.

15 5.6 Adresáe Munin používá adresáe k nalezení stránek obsahujících sdílené promnné. Když je vyvolána výjimka zpsobená odkazem na sdílenou promnnou, Munin zakóduje virtuální adresu, která zpsobila výjimku, tak aby našel záznam o promnné v adresái sdílených promnných. Ze záznamu zjistí, do které kategorie promnná patí, zda je pítomná její lokální kopie a kdo ji pravdpodobn vlastní. Write-shared stránky nemusí mít nutn jen jednoho vlastníka. Pro konvenní sdílené promnné je to poslední proces, který požadoval pístup pro zápis. Pro migraní promnné, je vlastníkem proces, který v této chvíli promnnou drží. Pro nalezení pravdpodobného vlastníka je použit následující algoritmus. Po startu procesu v Mininu vlastní všechny sdílené promnné koenový proces (root process). Když pak proces P1 pistoupí ke sdílené promnné, zpsobí výpadek, který zašle rootu zprávu se žádostí o tuto promnnou. Root mu dá stránku, kterou požaduje, a poznamená si, že P1 je nyní vlastník. Jestliže potom P2 žádá tutéž stránku, root mu odpoví, že P1 je pravdpodobný vlastník. Když P2 požádá proces P1 o promnnou, dostane ji. Jestliže P2 chce do promnné psát nebo stránka je migratory, stane se P2 novým vlastníkem a P1 si to poznamená. Nyní mžeme pedpokládat, že P3 a P4 úspšn žádají o stránku. etz proces se tím prodlouží. Nyní P1 vyžaduje promnnou znova. Protože si myslí, že vlastník je stále proces P2, pošle zprávu procesu P2 a dozví se od nj, že promnnou vlastní proces P3. Dále P1 pokrauje v dotazech podle etízku proces, až požadovanou stránku dostane a etz se zmní jako na obrázku Takto nakonec každý proces získá njakou pedstavu o tom, kdo by pravdpodobn mohl promnnou vlastnit, a prohledáním etízku najde skuteného vlastníka. Adresáe se také používají k udržování množin kopií (copysets). Množina kopií však nemusí být zcela konzistentní. Pro píklad pedpokládejme, že každý z proces P1 a P2 drží njakou write-shared promnnou a každý ví o tom druhém. Pak si P3 vyžádá od vlastníka P1 svou vlastní kopii a dostane ji. P1 si poznamená, že P3 má kopii, ale neekne to P2. Pozdji P4, který si myslí, že P2 je vlastník, získá kopii, což zpsobí, že do copyset u procesu P2 je pidán P4. V tomto okamžiku žádný z proces nemá kompletní seznam vlastník dané stránky. Nicmén je možné udržovat konzistenci. Pedstavme si, že P4 nyní uvolní zámek, tím pošle zmny procesu P2. Potvrzovací zpráva od P2 procesu P4 obsahuje upozornní, že P1 má také kopii. Když P4 kontaktuje P1, dozví se také o procesu P3. Tímto zpsobem si nakonec P4 zkonstruuje celý copyset tak, aby mohl zaktualizovat všechny kopie. Ke snížení režie, aby se nemusely posílat aktualizace procesm, které se již dále nezajímají o konkrétní writeshared stránky, se používá algoritmus založený na asování. Když proces drží stránku, nepistupuje k ní po daný asový interval a dostane aktualizaní stránku, stránku zahodí. Píšt, když dostane zprávu o aktualizaci pro zahozenou stránku, ekne procesu, který mu aktualizaci poslal, že už kopii nevlastní, a ten ho vyadí ze své copyset. etz pravdpodobných vlastník se používá k oznaení poslední kopie, která nemže být odhozena bez nalezení nového vlastníka nebo zápisu na disk. Tento mechanismus zajistí, že stránka nemže být zahozena všemi procesy a tím ztracena. 5.7 Synchronizace Munin si udržuje druhý adresá pro synchronizaní promnné. Tyto promnné jsou rozmístny analogickým zpsobem jako obyejné sdílené promnné. Zámky fungují jako by byly centralizované, ale v praxi je použita distribuovaná implementace, aby se vyhnulo píliš velké komunikaci s jedním poítaem. Když chce proces získat zámek, nejprve zjistí, zda jej nevlastní sám. Pokud ano a zámek je volný, požadavek je splnn. Jestliže zámek není lokální, je nalezen prostednictvím adresáe pro synchronizaní promnné, kde je uložen odkaz na pravdpodobného vlastníka. Je-li zámek volný, požadavek je uspokojen. Jestliže není volný, žádající proces je zaazen na konec fronty. Takto každý proces zná identitu procesu, který jej ve front následuje. Když je zámek uvolnn, vlastník ho pedá dalšímu procesu v seznamu. Bariéry jsou implementovány centrálním serverem. Pi vytvoení bariéry je nutné zadat, na kolik proces se bude na bariée ekat. Proces, který ukonil uritou ást svého výpotu, zašle bariérovému serveru zprávu s požadavkem o ekání (wait). Když eká požadovaný poet proces, všem z nich jsou zaslány zprávy, které je uvolní. 5.8 Midway Midway je systém pro distribuované sdílení pamti založený na sdílení jednotlivých datových struktur. V nkterých rysech je podobný Muninu, ale má i nkteré vlastní zajímavé rysy. Jeho cílem je umožnit, aby stávající multiprocesorové programy efektivn bžely na multicomputeru po provedení pouze malých zmn v kódu. Programy v Midway jsou obyejné konvenní programy psané v jazyce C, C++ nebo ML vybavené uritými pídavnými informacemi, které poskytuje programátor. Paralelismus je v programech pro Midway vyjáden pomocí

16 balíku cékových funkcí pro implementaci multithreadingu v Machu (Mach C-threads package). Vlákno mže vytvoit jedno nebo více dalších vláken. Vlákna potomk bží paraleln s jejich rodiem a mezi sebou. Potenciáln mže každé vlákno bžet na jiném stroji, tedy každé vlákno jako samostatný proces. Všechna vlákna sdílejí stejný lineární adresový prostor, který obsahuje jak privátní, tak i sdílená data. Úkolem Midway je efektivním zpsobem udržovat konzistenci sdílených dat. 5.9 Entry Consistency Konzistence je udržována na základ požadavku, aby všechny pístupy ke sdíleným promnným a datovým strukturám byly provádny uvnit zvláštního druhu kritických sekcí, o kterých ví runtime systém Midway. Každá z tchto kritických sekcí je strážena zvláštní synchronizaní promnnou, obecn zámkem, ale možná také bariérou. Každá sdílená promnná, ke které se pistupuje uvnit kritické sekce, musí být explicitn svázána se zámkem (bariérou) strážící tuto kritickou sekci prostednictvím volání procedury. Potom vstupuje-li nebo vystupuje-li proces do (z) kritické sekce, Midway pesn ví, které sdílené promnné potenciáln mohly být použity. Midway podporuje entry consistency, která pracuje následujícím zpsobem. Aby proces mohl pistupovat ke sdíleným datm, normáln vstoupí do kritické sekce voláním knihovní funkce "lock", jejímž parametrem je promnná typu zámek. Pi volání se také urí, zda proces požaduje exkluzivní nebo neexkluzivní pístup. Exkluzivní uzamknutí je teba, bude-li jedna nebo více sdílených promnných aktualizováno. Pokud bude proces sdílené promnné pouze íst, staí neexkluzivní uzamknutí, které umožní, aby více proces vstoupilo najednou do stejné kritické oblasti. Protože hodnota žádné sdílené promnné se nebude mnit, nemže takto dojít k žádné škod. Pi volání "lock" Midway runtime systém zajistí zámek a navíc zaktualizuje hodnoty všech sdílených promnných spojených s tímto zámkem. Aby to zajistil, bude pravdpodobn potebovat poslat zprávy ostatním procesm, aby získaly novjší hodnoty. Když dostane všechny odpovdi, poskytne zámek volajícímu procesu (za pedpokladu, že nejsou další konflikty) a ten zane provádt kritickou oblast. Když proces dokoní kritickou sekci, uvolní zámek. Narozdíl od release consistency se pi uvolnní neuskuteuje žádná komunikace, modifikované sdílené promnné nejsou poslány na ostatní poítae. Pouze až další proces následn získá zámek, jsou nová data penesena. Aby entry consistency mohla fungovat, požaduje Midway, aby programy splovaly ti charakteristiky, které multiprocesorové programy nemají: 1. Sdílené promnné musí být deklarovány pomocí klíového slova "shared". 2. Každá sdílená promnná musí být svázána se zámkem nebo bariérou. 3. Pístup ke sdíleným promnným musí být pouze uvnit kritických sekcí. Tyto vci vyžadují zvláštní úsilí od programátora. Jestliže tato pravidla nejsou pln dodržována, není generováno žádné chybové hlášení, ale program mže dojít k chybným výsledkm. Protože programování tímto zpsobem je ponkud náchylné k chybám, zvlášt v pípad, že upravujeme staré multiprocesorové programy, kterým už vlastn nikdo nerozumí, podporuje Midway také sekvenní konzistenci a release konzistenci. Tyto modely požadují mén detailní informace pro korektní provádní operací. Na dodatené informace požadované Midway by mlo být pohlíženo jako na souást smlouvy mezi softwarem a pamtí Implementace Pi vstupu do kritické sekce musí runtime systém Midway nejprve získat patiný zámek. K získání exkluzivního pístupu je nutné nalézt vlastníka zámku, což je poslední proces, který jej uzamknul exkluzivn. Každý proces si udržuje pravdpodobného vlastníka, stejn jako to dlá IVY a Munin, ímž vzniká etz následných vlastník konící aktuálním vlastníkem. Jestliže tento proces práv nepoužívá zámek, je vlastnictví zámku peneseno na proces, který vznesl požadavek. Je-li zámek práv používán, žádající proces je blokován, dokud zámek nebude uvolnn. K neexkluzivnímu uzamknutí staí kontaktovat libovolný proces, který zámek zrovna vlastní. Bariéry jsou spravovány centralizovaným bariérovým správcem. Souasn s uzamknutím zámku jsou žádajícímu procesu aktualizovány hodnoty všech sdílených promnných. V nejjednodušším protokolu pouze starý vlastník všem rozešle kopie. Midway však používá optimalizace ke snížení objemu dat, která musí být penesena. Pedpokládejme, že požadavek o zámek byl uskutenn v ase T1 a pedchozí požadavek stejného procesu byl v ase T0. Pak jsou peneseny pouze ty promnné, které byly modifikovány od okamžiku T0, protože ostatní proces už má. Tato strategie s sebou pináší otázku, jak si má systém zjistit, která data byla modifikována a kdy. K udržování informace, které sdílené promnné byly mnny, je teba použít zvláštní kompilátor, který generuje kód, jež za bhu programu udržuje tabulku s položkami pro všechny sdílené promnné v programu. Kdykoli je aktualizována

17 sdílená promnná, zmna je zaznamenána v tabulce. Jestliže není k dispozici tento specializovaný kompilátor, je k detekci zápis do sdílených dat použit MMU hardware jako v Muninu. as každé zmny je udržován pomocí protokolu asových známek (timestamp protocol) založeném na Lamportov algoritmu (1978). Každý poíta si udržuje logické hodiny, které jsou zvyšovány, kdykoliv je poslána zpráva, a jejich hodnota je vložena do zprávy. Když pijde zpráva, píjemce nastaví své logické hodiny na vtší z dvojice hodnot: as v pijaté zpráv, aktuální as na lokálních hodinách. Použitím tchto hodin je as efektivn rozdlen do interval definovaných pomocí zasílání zpráv. Pi požadavku na získání zámku, zadá žádající procesor as pedchozího uzamení a zeptá se na všechny relevantní sdílené promnné, zda od této doby byly modifikovány i nikoliv. Použitím takto implementované entry consistency dává potencionáln výborný výkon, protože komunikace je teba pouze, když proces provádí zamykání. Dále pouze ty promnné, jejichž hodnoty jsou neaktuální, musí být penášeny. Obzvlášt vstoupí-li proces do kritické sekce, opustí ji a opt do ní vstoupí, není teba žádná komunikace. Tento vzor chování je obvyklý v paralelním programování, proto potenciální zisk je zde podstatný. Cena zaplacená za tento výkon je programátorský interface, který je komplexnjší a více náchylný k chybám než pi používání jiných model konzistence. 6 Ostatní modely konzistentnosti (dslednost) Modely pamové konzistentnosti mohou být rozdleny na uniform models, které nerozlišují mezi typy pístup do pamti a hybridní modely, které rozlišují mezi normálním a synchronizovaným pístupem. Krom volné a sekvenní konzistentnosti existují následující modely. Causal consistency ( píinná konzistence) tení a zápisy mohou být spojeny pedchozími vztahy. To je definováno k udržení mezi pamovými operacemi kdy bu jsou provádny jedním procesem nebo proces te hodnotu zapsanou jiným procesem, nebo existuje posloupnost takových operací spojujících dv operace. Omezení modelu je to, že hodnota vrácená tením musí být konzistentní s se vztahem který se stal pedtím. Processor consistency Nejjednodušší cesta k myšlené procesorové konzistentnosti je ta, že pam je souvislá a že všechny procesy souhlasí s uspoádáním libovolných dvou zápisových pístup vytvoených jedním procesem tj. dohoda s jejich programovými píkazy. Pipelined RAM Všechny procesory souhlasí s požadavky zápis vložených libovolným z procesor. Entry consistency V tomto modelu je každá sdílená promnná spojena se synchronizaním objektem jako je zámek, který ídí pístup k promnné. Každý proces, který nejdíve požaduje zámek má zajištno, že te poslední hodnotu promnné. Proces, který chce zapisovat, musí nejdíve získat zámek v exkluzivním režimu tak, aby k promnné ml pístup pouze tento proces. Soubžn mže íst nkolik proces tak, že si požádají o pidlení zámku v neexkluzivním režimu. Falešnému sdílení v release konzistency je pedcházeno za cenu zvýšení složitosti programu. Scope consistency Pokouší se zjednodušit programový model entry consistency. Promnné jsou spojeny se synchronizaními objekty vtšinou automaticky namísto spoléháním se na programátora že spojí s promnnými explicitn zámky. Nap. systém mže monitorovat které promnné jsou aktualizovány v kritických sekcích. Weak consistency Nerozlišuje mezi synchronizaními pístupy acquire osvojit a release uvonit. Zaruuje, že všechny obvyklé pedchozí pístupy se ukoní ped ukonením jakéhokoliv typu synchronizovaného pístupu.