elementet e organizimit 2 - · pdf filekapitulli 2 elementet e organizimit të sistemit...

PRINCIPET E PROJEKTIMIT TË SISTEMEVE KOMPJUTERIKE Autorë: Jerome H. Saltzer, M. Frans Kaashoek Instituti për Teknologji i Masaçusetsit – MIT, SHBA Përktheu dhe përshtati në shqip: Dr. Fisnik Dalipi

Elementet e Organizimit

Të Sistemit Kompjuterik PËRMBAJTJA E KAPITULLIT

Përmbledhje ....................................................................................................................... 45

2.1 TRE ABSTRAKSIONET THEMELORE ............................................................................. 46

2.1.1 Memoria ............................................................................................................. 46

2.1.2 Interpretuesit ...................................................................................................... 54

2.1.3 Lidhjet komunikuese ........................................................................................... 61

2.2 EMËRTIMI TE SISTEMET KOMPJUTERIKE .................................................................... 62

2.2.1 Modeli i Emërtimit .............................................................................................. 63

2.2.2 Referencat e Paradefinuara dhe Eksplicite të Kontekstit ...................................... 68

2.2.3 Emrat e rrugës, Rrjeti Emërtues, dhe Vendosja Rekursive e Emrave ................... 73

2.2.4 Kërkimi i Shumëfishtë: Kërkimi nëpër Kontekste të Shtresuara ........................... 75

2.2.5 Krahasimi i Emrave .............................................................................................. 77

2.2.6 Zbulimi i Emrave .................................................................................................. 78

2.3 ORGANIZIMI I SISTEMIT KOMPJUTERIK ME EMRA DHE SHTRESA ............................... 80

2.3.1 Shtresa Harduerike: Magjistralja.......................................................................... 82

2.4 SHIKIMI PRAPA DHE PËRPARA .................................................................................... 92

2.5 RAST STUDIMOR: EMËRTIMI DHE SHTRESËZIMI NË SISTEMIN E FAJLLAVE NË UNIX® . 93

2.5.1 Ndërfaqja për Programimin e Aplikacioneve për Sistemin e Fajllave të UNIX ....... 94

2.5.2 Shtresa e Bllokut ................................................................................................. 95

2.5.3 Shtresa e Fajllit .................................................................................................... 97

KAPITULLI

2

KAPITULLI 2 Elementet e Organizimit të Sistemit Kompjuterik

44

2.5.4 Shtresa e Numrit të i-nyjes .................................................................................. 98

2.5.5 Shtresa e Emrit të Fajllit....................................................................................... 98

2.5.6 Shtresa e Emrit të Rrugës .................................................................................. 100

2.5.7 Lidhjet ............................................................................................................... 101

2.5.8 Riemërtimi ........................................................................................................ 103

2.5.9 Shtresa e Emërtimit të Rrugës Absolute ............................................................ 104

2.5.10 Shtresa e Lidhjeve Simbolike ........................................................................... 106

2.5.11 Implementimi i Sistemit të Fajllave API ............................................................ 109

2.5.12 Shelli dhe Kontekstet e Vetëkuptuara, Rrugët e Kërkimit, dhe Zbulimi i Emrave .................................................................................................................................. 112

2.5.13 Sugjerime për Lexim Plotësues ........................................................................ 114

USHTRIME ......................................................................................................................... 114


45

Përmbledhje

Edhe pse numri i abstraksioneve potenciale për komponentët e sistemit kompjuterik është i pakufizuar, pjesa më e madhe e atyre që shfaqen në praktikë i takon njërës nga tri klasëve të mirë definuara: memories, interpretuesti, dhe lidhjes (linkut) komunikuese. Këto tre abstraksione janë aq themelore, saqë teoricienët i krahasojnë algoritmet kompjuterike në bazë të numrit të të dhënave që duhen ruajtur, numrit të hapave që interpretuesi i tyre duhet t’i ekzekutojë, dhe numrit të porosive (mesazheve) që duhet t’i komunikojë.

Dizajnuesit i përdorin të tre abstraksionet për të organizuar strukturat fizike të harduerit, jo për arsye se ato janë e vetmja mënyrë për t’i ndërlidhur portat, por sepse:

Ato i japin funksionet themelore për rithirrjen, procedimin, dhe komunikimin. Deri më tani, këto mbeten të vetmet abstraksione harduerike që janë dëshmuar se

përdoren gjerësisht dhe që kanë semantikë të thjeshtë dhe të kuptueshme të ndërfaqeve.

Me qëllim të plotësimit të disa kërkesave të aplikacioneve të ndryshme, dizajnuesit e sistemeve ndërtojnë shtresa në bazën themelore, por duke mos krijuar abstraksione plotësisht të ndryshme. Ata i përpunojnë të tre abstraksionet e njëjta, duke i rishpërndarë dhe ripaketuar, për të krijuar tipare që janë të dobishme dhe ndërfaqe që janë të përshtatshme për çdo aplikacion. Si rrjedhim, për shembull, dizajnuesi i sistemit për qëllim të përgjithshëm, siç është kompjuteri personal apo serveri i rrjetit, zhvillon ndërfaqe që shfaqin forma me përmirësim të lartë të tre abstraksioneve të njëjta. Shfrytëzuesi mund ta shoh memorien në formë të një fajlli të organizuar apo sistemi të bazës së të dhënave; interpretuesin në formë të proceduesit të tekstit, sistemit për luajtjen e lojërave, apo si një gjuhë programuese të nivelit të lartë, dhe lidhjen e komunikimit në formë të porosive/mesazheve të çastit apo si World Wide Web. Duke vazhduar më tej me ekzaminimin do të konkludojmë se, ndërmjet këtyre abstraksioneve ndodhen seri të shtresave të ndërtuara me versionet bazike të harduerit të abstraksioneve të njëjta. Metoda e parë me të cilën ndërveprojnë komponentët e abstraktit të sistemit kompjuterik është referenca. Kjo nënkupton se mënyra e zakonshme që një komponent të lidhet me tjetrën është mënyra e lidhjes sipas emrit. Emrat shfaqen te ndërfaqet e të tre abstraksioneve themelore, si dhe ndërfaqet e homologëve të tyre me shtresa më të larta. Memoria i ruan dhe i nxjerr objektet sipas emrit, interpretuesi i manipulon objektet e emëruara, dhe emrat identifikojnë lidhjet komunikuese. Emrat, pra janë ngjitëse që i ndërlidhin abstraksionet. Ndërlidhjet e emëruara, me dizajn të duhur, mund të ndryshohen lehtë. Emrat poashtu mundësojnë ndarjen e objekteve, dhe ato lejojnë që të gjendet më vonë objekti i krijuar prej më përpara. Ky kapitull do të shqyrtojë shkurtimisht arkitekturën e organizmit të sistemeve kompjuterike nga pikëpamja e abstraksionit, emërtimit dhe shtresëzimit. Disa pjesë të këtij shqyrtimi do të jenë të njohura për lexuesin që ka njohuri paraprake për harduerin apo softuerin kompjuterik, por perspektiva sistemore mund të ofrojë disa ide të reja për ato koncepte të njohura, duke formuar bazën për kapitujt pasues. Seksioni 2.1 i përshkruan tre


46

aplikacionet themelore, Seksioni 2.2 prezanton modelin e emërtimit dhe shpjegon sesi përdoren emrat tek sistemet kompjuterike, dhe Seksioni 2.3 diskuton mënyrën sesi dizajnuesi i kombinon abstraksionet, duke përdorur emra dhe shtresa, për të krijuar sistem kompjuterik të zakonshëm, nëpërmjet prezentimit të sistemit të fajllave, si shembull konkret të përdorimit të emërtimit dhe shtresëzimit për abstraksionin e memories. Seksioni 2.4 pasqyron sesi pjesa tjetër e librit do të përbëhet nga dizajnimi i disa versioneve të shtresës të lartë, të një apo më shumë abstraksioneve themelore, duke përdorur emrat për ndërlidhje. Seksioni 2.5 është rast studimor që tregon sesi abstraksioni, emërtimi, dhe shtresëzimi janë aplikuar në sistemin e real të fajllave.

2.1 TRE ABSTRAKSIONET THEMELORE Po fillojmë duke ekzaminuar, një nga një, tre abstraksionet themelore. Çka kryen

abstraksioni? Si e kryen, ndërfaqen e tij? Mënyrat e përdorimit të emrrave për ndërlidhje.

2.1.1 Memoria

Memorja, disa herë e quajtur si depo, është komponenti sistemor që i mban mend vlerat e të dhënave për përdorim në llogaritje. Megjithëse teknologjia e memorjes është e një intervali të gjerë, ashtu siç na sugjeron lista e shembujve në Figurën 2.1., të gjitha pajisjet memorike përbëjnë një model abstrakt me dy operacione, të emëruara WRITE dhe READ :

WRITE(emri,vlera) vlera ← READ (emri)

Operacioni WRITE e specifikon në vlerë, vlerën që duhet mbajtur mend dhe në emri, emrin me të cilin ri-thirret ajo vlerë në të ardhmen. Operacioni READ e specifikon në emri, emrin e ndonjë vlere të mëparshme, ndërsa pajisja memorike e kthen atë vlerë. Një thirrje e mëvonshme e WRITE, që specifikon emrin e njëjtë, e ndryshon (përditëson) vlerën e atij emri.

Pajisjet harduerike memoruese: RAM çipi FLASH memoria Kaseta magnetike Disku magnetik CD-R dhe DVD-R

Sistemet me memorie të nivelit të lartë: RAID Sistemi i fajllave Sistemi për menaxhimin e bazave të dhënave


47

Memorjet mund të jenë ose të qëndrueshme ose të paqëndrueshme. Memoria e qëndrueshme është, ajo

memorie mekanizmi i ruajtjes së informacionit i së cilës konsumon energji. Nëse furnizuesi i saj i rrymës është i ndërprerë për ndonjë arsye, harrohet përmbajtja e informacioneve. Kur të shkyçet rryma te memoria e qëndrueshme (disa herë quhet edhe “depo stabile”), ajo e ruan përmbajtjen, dhe kur të kyçet përsëri rryma, operacioni READ i kthen vlerat e njëjta si më parë. Duke e lidhur memorien e paqëndrueshme me bateri ose me furnizues të pandërprerë të rrymës, ajo mund të bëhet e qëndrueshme. Kjo nënkupton se ajo është e dizajnuar të mbajë mend gjërat për të paktën një periudhë të caktuar, fenomen ky që nënkupton qëndrueshmërinë. Madje edhe memoriet e paqëndrueshme janë subjekt prishjesh eventuale, të njohura si dobësim, pra ato kanë një qëndrueshmëri të caktuar, ndoshta të matur me vite.

Ne do ta rishikojmë qëndrueshmërinë në Kapitullin 8 [onlajn] dhe 10 [onlajn], ku do t’i shohim metodat e arritjes së shtresave të ndryshme të qëndrueshmërisë. Shiriti anësor 2.1 krahason kuptimin e qëndrueshmërisë me dy fjalë tjera të përafërta. Në nivelin fizik, sistemi i memories zakonisht nuk emëron, lexon (READ) apo shkruan (WRITE) vlera me madhësi. Në vend të kësaj, pajisjet memoruese, në shtresën harduerike, lexojnë (READ) dhe shkruajnë (WRITE) vargje të puthitura të bitëve, zakonisht me gjatësi të caktuar, të njohura me terme të ndryshme si bajte (zakonisht 8 bite, por mund të kemi edhe arkitektura me 6, 7, apo 9 bite); fjalë (një numër i vogël, i plotë, i përbërë prej bajteve, zakonisht prej 2, 4, apo 8) ; rreshtave (disa fjalë), dhe blloqeve (një numër bajtesh, zakonisht, fuqi me bazë 2, që shkon deri me mijëra). Çfarëdoqoftë madhësia e vargut, (fushës), njësia e memories shtresëzuese harduerike e shkruar apo lexuar, njihet si celulë e memories (apo depos). Në të shumtën e rasteve, argumenti i emrit në thirrjet READ dhe WRITE paraqet emrin e celulës. Sistemet memoruese me shtresë të lartë, poashtu lexojnë (READ) dhe shkruajnë (WRITE) vargje të puthitura të bitëve, por këto vargje zakonisht mund të kenë çdo gjatësi, dhe quhen si regjistrime, segmente, apo fajlle.

FIGURA 2.1

Disa shembuj memorieve të njohura

Shiriti anësor 2.1 Terminologjitë Qëndrueshmëria, Stabiliteti, dhe Ngulmimi Në praktikën e përgjithshëme në anglisht dhe në literaturën profesionale, termet qëndrueshmëria (ang. Durability), stabiliteti (ang. Stability), dhe ngulmimi (ang. Persistence) në sumë rasze përkojnë dhe disa herë përdoren pothuajse si të këmbyeshëm. Në këtë libër ato, do t’i definojmë dhe përdorim në atë mënyrë që të theksohen disa dallime. Qëndrueshmëria është një veçori e mediumit ruajtës: kohëzgjatja e kujtesës Stabiliteti është një veçori e objektit: është i pandryshueshëm. Ngulmimi është një veçori e agjentit aktiv: vazhdon të përpiqet. Kapitulli vijues sugjeron se fajllet ruhen në mediume të qëndrueshme ruajtëse – pra, ato duhet t’i mbijetojnë shkyçjes së sistemit dhe të mbesin të padëmtuara, për sa kohë që nevojiten. Kapitulli 8 [onlajn] i rishikon specifikimet e qëndrueshmërisë dhe i klasifikon aplikacionet sipas kërkesave të qëndrueshmërisë së tyre. Ky kapitull paraqet konceptin e lidhjeve stabile për emrat, të cilat pasi të caktohen, nuk do të ndryshojnë më përsëri. Kapitulli 7 [onlajn] paraqet konceptin e dërguesit ngulmues, që është pjesëmarrës në shkëmbimin e porosive, që ritransmeton një porosi derisa të marrë një konfirmim se porosia u pranua me sukses, dhe Kapitulli 8[onlajn] përshkruan dështimet ngulmuese, që e bëjnë sistemin të dështojë.


48

2.1.1.1 Koherenca READ/WRITE dhe Atomiciteti

Dy tipare të dobishme për memorien janë koherenca read/write dhe atomiciteti before-or-after. Koherenca read/write nënkupton që rezultati i operacionit READ i një celule të emëruar është gjithmonë i njëjtë si i shumicës së operacioneve WRITE për atë celulë. Atomiciteti before-or-after nënkupton se rezultati i çdo operacioni READ apo WRITE merret nëse operacioni READ apo WRITE është kryer plotësisht, para apo plotësisht pas, çdo operacioni tjetër READ apo WRITE. Megjithëse mund të hetohet (FJALA HETOHET) se dizajnuesi duhet të jetë i aftë t’i supozojë këto dy tipare, ai supozim është riskant dhe shpesh herë i gabuar. Ekzistojnë një numër i çuditshëm i kërcënimeve për koherencën read/write dhe atomicitetin before-or-after:

Konkurrenca. Tek sistemet ku aktorë të ndryshëm mund të ekzekutojnë në mënyrë konkurente operacionet READ apo WRITE, ato mund të startojnë dy operacione të tilla mbi celulën me emër të njëjtë për kohë të njëjtë. Nevojitet një lloj gjykimi që vendos se cili do të shkojë i pari dhe të sigurojë se njëri operacion përfundon përpara se të fillojë tjetri.

Depoja nga largësia. Atëherë kur pajisja memoruese ndodhet larg fizikisht, përsëri shfaqen brengat e njëjta, por ato përforcohen me vonesa, gjë që na bën të shtrojmë pyetjen: “Cili operacion WRITE ishte më i fundit?” (PJESA NË VIJIM E KËSAJ FJALIE TË RISHIHET, MBASE EDHE DERI NË FUND TË PARAGRAFIT) dhe forma plotësuese të dështimeve të paraqitura te lidhjet komunikuese. Seksioni 4.5 e paraqet depon nga largësia, dhe Kapitulli 10 [onlajn] i hulumton zgjidhjet për problemet mbi atomicitetin before-or-after, dhe koherencën read/write që shfaqen me sistemet e depove nga largësia.

Zmadhimi i performancës. Zgjedhja e duhur e kompajlerëve dhe procesorëve me performancë të lartë, mund të rivendos radhën e operacioneve të memories, ndoshta duke ndryshuar kuptimin e plotë të “operacioni më i fundit WRITE në atë celulë” dhe duke prishur, në këtë mënyrë, koherencën read/write për operacionet konkurrente READ dhe WRITE. Për shembull, kampaljeri mund ta vonojë operacionin WRITE të një deklarimi, derisa regjistri që e ka atë vlerë që duhet të shkruhet është i nevojshëm për ndonjë qëllim tjetër. Nëse dikush tjetër ekzekuton operacionin READ të asaj ndryshoreje, ai mund të fitojë një vlerë të vjetër. Disa gjuhë programuese dhe arkitektura me procesor të performancës së lartë, kanë direktiva speciale programuese, që i mundësojnë programuesit që ta kthejë koherencën read/write në secilin rast. Për shembull, gjuha Java ka një deklarim të quajtur SYNCHRONIZED që e mbron bllokun e kodit nga moskoherenca read/write. Edhe arkitektura e procesorit Alfa nga kompania Hewlett-Packard ka një instruksion për barrierë memoruese (MB) që i bën të gjitha operacionet paraprake READ dhe WRITE të realizohen përpara se të vazhdohet te instruksioni i radhës. Për fat të keq, të dy këto konstrukte krijojnë mundësi që programuesit të bëjnë gabime të vogla.

Madhësia e celulës nuk është adekuate me madhësinë e vlerës. Vlera e madhe mund të zë shumë celula të memories, me ç’rast atomiciteti before-or-after kërkon vëmendje të posaçme. Problemi qëndron aty se edhe leximi edhe shënimi i vlerës së ndodhur në


49

më shumë celula bëhet për një kohë të caktuar, vetëm për një celulë. Lexuesi që ekzekuton në konkurrencë me shënuesin që është duke ndryshuar të njëjtën vlerë shumë celulare në përfundim mund të mbetem me grumbull të përzier celulash, nga të cilat vetëm një pjesë e tyre është ndryshuar. (TË QARTËSOHET PAK MË MIRË MENDIMI) Arkitektët kompjuterik këtë rrezik e quajnë shënimi i vrullshëm. Dështimet e ndodhura në mes të shënimit të vlerave në shumë celula munden edhe më shumë ta komplikojnë situatën. Për ta kthyer atomicitetin before-or-after, lexuesit dhe shënuesit konkurentë, duhet që në një farë mënyre të koordinohen, dhe dështimi në mes të një përditësimi (ndryshimi) duhet që patjetër ta lë të pandryshuar ose të tërë ndryshimin e paramenduar ose asnjë nga ndryshimet e paramenduara. Kur të plotësohen këto kushte, atëherë themi se operacionet READ apo WRITE janë atomike. Risku në këto raste ka të bëjë me momentin kur vlera e vogël e ndanë celulën e memories me ndonjë vlerë tjetër të vogël. Risku qëndron aty se nëse dy shënues konkurrent ndryshojnë vlera të ndryshme që ndajnë celulën e njëjtë, njëri prej tyre mund ta mbishkruaj (ang. Overwrite) ndryshimin e tjetrit. Atomiciteti mund po ashtu ta zgjidh këtë problem. Kapitulli 5 e fillon këtë studim të atomicitetit duke eksploruar metodat e koordinimit të aktiviteteve konkurrente. Kapitulli 9 [onlajn] zgjeron studimin e atomicitetit për të fiksuar poashtu edhe dështimet.

Depo e replikuar (kopjuar). Ashtu si edhe Kapitulli 8 [onlajn] do të eksplorojë në detale. (TË RISHIKOHET FJALIA E PARË) Siguria e depos mund të rritet duke bërë më shumë kopje të vlerave dhe duke i vendosur ato kopje në celula të veçanta të depove. Depoja mundet të replikohet edhe për rritjen e performancës, ashtu që disa lexues mund të operojnë në mënyrë konkurrente. Por replikimi e rrit numrin e mënyrave sipas të cilave operacionet konkurrente READ dhe WRITE mund të ndërveprojnë dhe ndoshta në këto raste e humbin ose koherencën read/write ose atomicitetin before-or-after. Gjatë kohës që i duhet shënuesit të ndryshojë disa kopje, lexuesit e kopjes së ndryshuar mund të marrin përgjigje të ndryshme nga lexuesit e kopjes që shënuesi akoma nuk i ka ndryshuar. Kapitulli 10 [onlajn] i diskuton teknikat e realizimit të koherencës read/write dhe atomicitetit before-or-after te depot e kopjuara.

Shpesh, dizajnuesi i sistemit duhet të ballafaqohet jo vetëm me një por me disa nga këto kërcënime të përnjëhershme. Kombinimi i replikimit dhe largësisë është veçanërisht sfiduese. Mund të jetë çuditërisht e vështirë të dizajnohen memorie që janë edhe të efektshme edhe koherente me read/write, edhe atomike. Për të thjeshtësuar dizajnin ose për të arrirë performancë të lartë, dizajnuesit disa herë ndërtojnë sisteme memoruese që kanë specifikime të dobëta të koherencës. Për shembull, sistemi me shumë procesorë mund të specifikojë: “Rezultati nga operacioni READ do të jetë vlera e operacionit të fundit WRITE, nëse ai operacion WRITE është ekzekutuar nga procesori i njëjtë”. Ekziston një literaturë e tërë me “modele për konsistencën e të dhënave” që eksplorojnë veçoritë e detajuara të specifikimeve të ndryshme të koherencës së memorieve. Tek sistemi me memorie të shtresëzuar, është me rëndësi se dizajnuesi i shtresës e di saktësisht specifikimin për koherencën dhe atomicitetin, për secilën shtresë të ulët të memories që e shfrytëzon. Edhe siç duhet, nëse shtresa që dizajnohet ka memorie për shtresat e mësipërme, dizajnuesi duhet që të specifikojë saktësisht këto veçori, në mënyrë që që shtresat e mësipërme të mund t’i presin apo të varen nga ato. Po


50

të mos merret ndryshe, (KJO) do të supozojmë se pajisja e memories fizike ka koherencën read/write për celulat e veçanta, por që atomiciteti before-or-after për vlerat në shumë celula, (për shembull, fajllet) arrihet ndaras nga shtresa që i implementon ato.

2.1.1.2 Vonesa e Memories

Një karakteristikë e rëndësishme e memories është koha që i duhet operacionit READ apo WRITE që të ekzekutohet, që njihet edhe si vonesë (shpesh quhet koha e qasjes, edhe pse ai term ka një definicion më të saktë i cili do të sqarohet në Shiritin anësor 6.4). Te disku magnetik (Shiriti anësor 2.2) vonesa e një sektori të caktuar, varet nga gjendja mekanike e pajisjes në çastin kur shfrytëzuesi kërkon qasje. Pasi të lexohet sektori, mund të matet edhe koha e nevojshme për të lexuar sektorë të ndryshëm dhe jo të afërt, e cila matet me mikrosekonda, por vetëm nëse shfrytëzuesi e pret leximin e dytë dhe e kërkon atë përpara se rrotullimi i diskut ta kalojë atë sektor të dytë. Kërkesa me vonesë prej disa mikrosekondave mund të

Shiriti anësor 2.2 Si punojnë disqet magnetike Disqet magnetike përbëhen nga pjata rrotulluese cilindrike të mbuluara në të dyja anët me material magnetik, siç është oksidi hekurit. Elektromagneti i quajtur koka e diskut i regjistron informacionet duke bashkuar fushën magnetike të grimcave, në një regjion të vogël në sipërfaqen e pjatës. Koka e diskut i lexon të dhënat, duke ditur polaritetin e grimcave të bashkuara, gjatë rrotullimit të pjatave. Disku rrotullohet në vazhdimësi me ritëm të njëjtë, dhe koka e diskut kalon vetëm disa nanometra mbi sipërfaqen e diskut. Nga një pozitë e vetme mbi pjatë, e quajtur si trase, që ndodhet në distancë të njëjtë nga qendra koka e diskut mund të lexojë apo shkruaj një tërësi me bite. Në figurën e mëposhtme, regjioni i hijezuar paraqet trasenë. Trasetë janë formatuar në blloqe me madhësi të njëjtë, të quajtura sektorë, (TË RISHIKOHET) duke shkruar shënime të veçanta periodikisht rreth trasesë. Pasi që të gjithë sektorët janë të një madhësie të njëjtë, traseja e jashtme ka më shumë sektor sesa ato të brendshmet.

Moduli tipik i diskut modern, i njohur si “disku i ngurtë” ,sepse pjatat e tij janë të bëra nga një material i fortë, përmban disa pjata që rrotullohen në një bosht të përbashkët i quajtur bosht, siç është paraqitur në figurën e sipërme. Një kokë disku për secilën hapësirë të pjatës është ngjitur në një strukturë si të krehësit që i lëviz kokat bashkë rreth pjatave. Kalimi deri te një trase e caktuar quhet kërkim (ang. Seeking), dhe struktura si e krehësit quhet krahu i kërkimit (ang. Seek arm). Tërësia e traseve që mund të lexohet dhe shkruhet, atëherë kur krahu i kërkimit është në një pozitë (për shembull, regjionet e hijezuar të pamjes anësore), quhet cilindër. Trasetë, pjatat, dhe sektorët janë të numëruara. Sektori është i adresuar me koordinata gjeometrike: numri i trasesë, numri i pjatës, dhe pozita rrotulluese. Kontrolluesit e disqeve modern zakonisht e bëjnë planifikimin gjeometrik në brendësi dhe klientëve iu japin një hapësirë adresimi që përbëhet nga disa renditje sektorësh të numëruar. Për të lexuar apo shkruar një sektor të caktuar, kontrolluesi i diskut, së pari e kërkon trasenë e dëshiruar. Pasi që krahu i kërkimit të jetë në pozitë, kontrolluesi pret që fillimi i sektorit të dëshiruar të rrotullohet nën kokën e diskut, dhe pastaj e aktivizon kokën e pjatës së dëshiruar. Të dhënat që kodohen fizikisht në domenet magnetike analoge, zakonisht kërkojnë që kontrolluesi t’i shkruaj të gjitha sektorët. Koha e duhur për qasje në disk quhet vonesë, një term i definuar më saktësisht në Kapitullin 6. Lëvizja e krahut të kërkimit merr ca kohë. Shitësit caktojnë vlera prej 5 deri 10 milisekonda për kërkim, por kjo është një mesatare për të gjitha lëvizjet e krahut të kërkimit. Lëvizja, nga një cilindër, te tjetri mund të kërkojë 1/20 e kohës së lëvizjes nga traseja më e brendshme, te traseja


51

shkaktojë vonesë që është mijëra herë më e gjatë, e kjo bën që të presim që sektori i dytë përsëri të rrotullohet nën kokën e lexuesit. Si rrjedhim, vlera maksimale me të cilën mund të transferohen të dhënat deri te ose nga disku është shumë më e madhe, sesa vlera që mund të arrihet nëse bëhet përzgjedhje rastësore e sektorëve. Memoria me qasje rastësore (RAM) është njëra nga ato, ku vonesa për celulat e memories të zgjedhura rastësisht, është përafërsisht e njëjtë me vonesën për celulat e zgjedhura në mostrën më të mirë për atë pajisje memoruese. Një çip elektronik i memories zakonisht konfigurohet për qasje rastësore. Pajisjet memoruese që përfshijnë lëvizje mekanike, siç janë (CD dhe DVD), kasetat magnetike dhe disqet, nuk janë të tilla.

Është ide e mirë që për pajisjet që nuk janë me qasje të rastit, të paguhet kostoja me vonë sesa vendosja e komponentëve mekanikë në pozitë për të lexuar (READ) apo shënuar (WRITE) një bllok të madh me të dhëna. Operacionet READ dhe WRITE, te blloqet e mëdha disa herë rietiketohen si GET dhe PUT, respektivisht, dhe ky libër e përdor këtë konventë. Tradicionalisht, termet e pakualifikuara si memoria nënkuptojnë memorie të paqëndrueshme me qasje rastësore dhe termi depo ishte përdorur për memorien e qëndrueshme që është

Po ashtu duhet kohë që sektori i caktuar të rrotullohet nën kokën e diskut. Disku i zakonshëm ka një vlerë rrotullimi prej 7200 rpm, ku pjata rrotullohet një herë në 8.3 milisekonda. Koha për transferimin e të dhënave varet nga dendësia e regjistrimit magnetik, vlera e rrotullimit, numri i cilindrit (cilindrat e jashtëm mund të transferojnë në vlera më të larta), dhe numri i biteve që lexohen apo shkruhen. Pjata që mban 40 gigabajt i transferon të dhënat në vlera prej 300 deri 600 megabit për sekondë; kështu që 1 kilobaj,t sektori e transferon për një apo disa mikrosekonda. Koha e kërkimit dhe vonesa e rrotullimit kufizohen nga faktorët mekanik-inxhinierik dhe kanë prirje të përmirësohen ngadalshëm, por densiteti i regjistrimit magnetik varet nga teknologjia e materialeve, e cila ka përparuar vendosmërisht dhe në mënyrë rapide gjatë disa viteve.

Sistemet e hershme të diskut depononin 20 dhe 80 megabajt. Gjatë viteve 1970 Kenneth Haughton, një shpikës i IBM, përshkroi një teknikë të re të vendosjes së pjatave të diskut në një kuti të mbyllur për t’u shmangur papastërtia. Implementimi fillestar nxëni 30 megabajt në të dy boshtet, në një konfiguracion të njohur si disku 30-30. Haughton e quajti atë “Winchester”, sipas pushkës Winchester 30-30. Për disa vite me rradhë disqet e ngurta njiheshin si disqe Winchester. Gjatë viteve, disqet Winchester u zvogëluan fizikisht edhe më shumë, kurse njëkohësisht kapaciteti i tyre bëhej më i madh.


52

lexuar dhe shënuar në blloqet e mëdha me GET dhe PUT. Në praktikë, ekzistojnë shumë përjashtime për këto rregulla emërtimi, aq sa fjalët “memorie” dhe “depo” janë bërë të këmbyeshme.

2.1.1.3 Emrat dhe Adresat e Memories

Implementimi fizik i pajisjeve memoruese pothuajse gjithmonë emëron celulën e memories, sipas koordinatave gjeometrike të lokacionit të saj fizik në depo. Kështu, për shembull, çipi elektronik i memories është i organizuar si fushë (varg) dydimensionale me shoshone (flip-flop), ku secili ka një bit të emëruar. Ky mekanizëm i qasjes e ndan emrin e bitit në dy pjesë. Normalisht ai kalon te çifti i multiplekserëve (shumëfishuesve). Një multiplekser e zgjedh koordinatën x, kurse tjetri atë y, dhe që të dyja koordinatat e zgjedhin shoshonen e caktuar që e zotëron atë bit. Ngjashëm, te disku magnetik, një komponentë e emrit në mënyrë elektrike e zgjedh njërin nga pjatat regjistruese, kurse komponenti i veçantë i emrit e zgjedh pozicionin e krahut të kërkimit, duke zgjedhur një trase specifike të asaj pjate. Komponenti i tretë e emrit zgjedh një sektor të caktuar të asaj traseje, që mund të identifikohet duke numëruar sektorët, duke kaluar nën kokën e lexuesit, duke filluar nga indeksi i cili shënon sektorin e parë.

Është lehtë të dizajnohet harduer që i pasqyron koordinatat gjeometrike deri te dhe nga tërësia e emrave që përbëhen nga numra të plotë të njëpasnjëshëm (0,1,2, etj). Këto emra të numrave të njëpasnjëshëm quhen adresa, dhe ato formojnë hapësirën e adresimit të memories. Sistemi i memories që përdor emra që janë tërësi e numrave të plotë të njëpasnjëshëm, quhet memoria me lokacion të adresuar. Pasi që adresat janë të njëpasnjëshme, madhësia e celulës së memories të emëruar nuk duhet të jetë e njëjtë me madhësinë e celulës që është lexuar apo shkruar. Në disa arkitektura të memories secili bajt ka adresë të veçantë, por leximet dhe shënimet (në disa raste duhet që patjetër) ndodhin në njësi të mëdha, siç janë fjala apo rreshti.

Për shumicën a aplikacioneve, numrat e plotë të njëpasnjëshëm nuk janë, saktësisht, emrat që mund të zgjidheshin për ti ri-thirrur të dhënat. Zakonisht preferohet që të lejohet zgjedhja e emrave më pak të kufizuara. Sistemi i memories që i pranon emrat e pakufizuara quhet memorie asociative. Meqë memoriet fizike janë në përgjithësi me lokacion të adresuar, dizajnuesi krijon një memorie asociative, duke ndërfutur një shtresë asociative, e cila mund të implementohet edhe me harduer edhe me softuer, e që pasqyron emrat e pakufizuara të nivelit të lartë, në emra të kufizuar që ndodhen në memorien me lokacion të adresuar, si në Figurën 2.2. Shembujt me memorie asociative softuerike, të ndërtuara mbi një apo më shumë memorie me lokacion të adresuar, përfshijnë fjalorin personal telefonik, sistemin e fajlleve, dhe sistemet e përbashkëta të bazave të dhënave. Keshi, një pajisje që i mban mend rezultatet e një llogaritje ekstensive, me shpresën se do të rikthehet ose nuk do të rikthehet ajo llogaritje,


53

FIGURA 2.2

Një memorie asociative e implementuar me dy shtresa. Shtresa asociative i pasqyron emrat e pakufizuar të argumenteve të tij deri te adresat intexher që pasojnë e të cilat kërkohen nga memoria fizike e adresuar sipas lokacionit të shtresës

nëse është e nevojshme përsëri, disa herë është e implementuar si një memorie asociative, qoftë në softuer apo harduer. (Dizajni i keshit është diskutuar në Seksionin 6.2)

Shtresat që e mundësojnë shoqërimin (asociativitetin) dhe pasqyrimin e emrave ilustrohen fuqishëm te dizajni i të gjitha sistemeve të memories apo depove. Për shembull, Tabela 2.2 në faqen 93 i liston shtresat e sistemit të fajlleve të UNIX-it. Një shembull tjetër të shtresëzimit të abstraksioneve të memories e sqaron Kapitulli 5, ku sqarohet se si memoria mund të virtualizohet, duke shtuar shtresa për pasqyrimin e emrave.

2.1.1.4 Shfrytëzimi i Abstraksionit të Memories: RAID

Të kthehemi te tema e abstraksionit. Sistemi i njohur RAID na jep një ilustrim të fuqisë së modularitetit dhe si abstraksioni i depos mund të aplikohet me efektshmëri. RAID është një shkurtesë për Redundant Arraz of Independent (ose Inexpensive) Disks. Sistemi RAID përbëhet nga një tërësi e disqeve dhe kontrolluesve të konfiguruar me një ndërfaqe programuese dhe elektrike që është identike me ndërfaqen e një disku të vetëm, siç është treguar në Figurën 2.3. Kontrolluesi RAID i ndërpret kërkesat READ dhe WRITE që vijnë te ndërfaqja e tij, dhe i drejton ato te një apo më shumë disqe. RAID ka dy qëllime:


54

Përforcimin e performancës, duke lexuar

ose shkruar disqet në mënyrë konkurrente Përforcimin e qëndrueshmërisë, duke

shkruar informacion në më shumë se një disk.

Konfiguracione të ndryshme të RAID ofrojnë ekuilibrime të ndryshme në mes këtyre qëllimeve. Cilindo ekuilibrim që ta zgjedh dizajnuesi, pasi abstraksioni i ndërfaqes është me një disk, programuesi mund të përfitojë nga përforcimi i performancëës dhe qëndrueshmërisë, pa pasur nevojë të ri-programojë. Disa nga konfigurimet e RAID tradicionalisht identifikohen me (disa herë në mënyrë arbitrare) numra. Në kapitujt pasues, do të hasim disa nga këto konfiguracione me numra. Konfigurimi i njohur si RAID 0 (në Seksionin 6.1.5) mundëson përforcimin e performancës duke lejuar lexim dhe shënim konkurrent. Konfiguracioni i njohur RAID 4 (i paraqitur në Figurën 8.6 [onlajn]) e përmirëson sigurinë e diskut, duke aplikuar kode për eliminimin e gabimeve.

Konfiguracioni tjetër i njohur si RAID 1 (në Seksionin 8.5.4.6 [onlajn]) ofron qëndrueshmëri, duke bërë kopje identike të të dhënave në disqe të ndryshme. Ushtrimi 8.8 [onlajn] e eksploron një përshtatje të thjeshtë, por elegante të performancës, e njohur si RAID 5. Këto dhe disa konfiguracione tjera të RAID kanë qenë fillimisht të përshkruara në thellësi në artikullin e Randy Katz, Garth Gibson, dhe David Patterson, të cilët po ashtu ua shtuan numrat tradicionalë konfiguracioneve të ndryshme [shiko Sugjerime për Literaturë Plotësuese 10.2.2].

2.1.2 Interpretuesit

Interpretuesit janë elemente aktive të sistemit kompjuterik; ato i ekzekutojnë veprimet që e përbëjnë llogaritjen. Figura 2.4 i liston disa shembuj të interpretuesve të njohur. Ashtu si edhe me memorien, interpretuesit po ashtu vijnë në një interval të gjerë të paraqitjes fizike. Megjithatë, ato munden edhe të përshkruhen me një abstraksion të vetëm, që përbëhet vetëm nga tre komponentë:

1. Referenca për instruksion, e cila i tregon interpretuesit ku ta gjejë instruksionin vijues,

FIGURA 2.3

Abstraksioni në RAID. Ndërfaqja elektrike dhe programuese read/write e sistemit RAID, shigjetat tregojnë se është identik me diskun e veçantë.


55

2. Repertori, i cili definon një bashkësi të veprimeve, të cilat interpretuesi është i gatshëm t’i ekzekutojë kur do ta marrë instruksionin nga lokacioni i emëruar nga referenca për instruksion.

3. Referenca e mjedisit, e cila i tregon interpretuesit ku ta gjejë mjedisin e tij, gjendja aktuale në të cilën interpretuesi duhet ta ekzekutojë veprimin e instruksionit aktual.

Operacioni normal i një interpretuesi është të vazhdojë punën në sekuencë nëpër ndonjë

program, si është sugjeruar nga diagrami dhe pseudokodi i Figurës 2.5. Duke përdorur referencën e mjedisit, për të gjetur mjedisin aktual, interpretuesi e merr nga ai mjedis instruksionin e programit i cili është shënuar në referencën e instruksionit.

Nëse përdoret përsëri referenca e

mjedisit, interpretuesi e ekzekuton veprimin e drejtuar nga instruksioni i programit. Ai aksion, si zakonisht, e përfshin përdorimin dhe ndoshta edhe ndryshimin e të dhënave të mjedisit, dhe po ashtu një ndryshim të duhur të referencës së instruksionit.

Kur do të mbaroj së ekzekutuari instruksionin, interpretuesi vazhdon ta marrë, si instruksion vijues, atë që tani e ka emëruar referenca e instruksioneve. Disa ndodhi, të quajtura ndërprerje, mund ta tërheqin vëmendjen e interpretuesit, duke shkaktuar që ta furnizojë instruksionin vijues dhe jo programin. Programi origjinal tashmë nuk e kontrollon interpretuesin, por janë programet e ndryshme si, manovruesi (mbajtësi) i ndërprerjeve, që merr

kontrollin dhe e manovron ndodhinë. Interpretuesi po ashtu mund ta ndryshojë referencën e mjedisit, duke e transformuar ashtu si i duhet manovruesit të ndërprerjeve.

FIGURA 2.3

Disa shembuj të interpretuesve. Shembulli me kontrolluesin e diskut është sqaruar në Seksionin 2.3 dhe shembulli me shfletuesin e web faqeve do të sqarohen te Ushtrimi 4.5

Harduer: Pentium 4, PowerPC 970, UltraSPARC T1 Disk kontrolluesi Kontrolluesi i ekranit Softuer: Alice, AppleScript, Perl, Tcl, Scheme LISP, Python, Forth, Java bytecode, Javascript, Smalltalk TeX, LaTeX Safari, Internet Explorer, Firefox


56

1 procedure INTRERPRET() 2 do forever 3 instruksioni←READ (referenca_e_instruksionit) 4 ekzekuto instruksioni në kontekst të referenca_e_mjedisit 5 if sinjali_ndërprerje = TRUE then 6 referenca_e_instruksionit ← pika hyrëse e MANOVRUESI_I_NDËRPRERJEVE 7 referenca_e_mjedisit ← referencë mjedisore e MANOVRUESI_I_NDËRPRERJEVE

FIGURA 2.5

Struktura dhe pseudokodi për abstraktin e interpretuesit. Shigjetat e plota tregojnë rrjedhën e kontrollit, dhe shigjetat e ndërprera e tregojnë rrjedhën e informacionit. Shiriti anësor 2.3 i sqaron konventat e librit për përdorimin e pseudokodit.

Shiriti anësor 2.3 Paraqitje: Pseudokodi dhe Mesazhet Ky libër paraqet disa shembuj të pjesëve programore. Shumica janë të paraqitur në pseudokod, një gjuhë programuese imagjinare që i përdor veçoritë e njohura nga shumë gjuhë ekzistuese programore, duke ndërfutur edhe ndonjë fjalë tjetër për të karakterizuar disa hapa te të cilat detajet e sakta nuk janë aq të rëndësishme. Pseudokodi i ka disa veçori standarde, disa prej të cilave i tregon ky shembull i shkurtër. 1 procedure SUM(a,b) // Mbledhja e dy numrave 2 shuma ← a + b 3 return shuma Numrat e rreshtave në anën e majtë nuk janë pjesë e pseudokodit; ato vendosen që teksti jonë t’u referohet vijave të programit. Procedurat deklarohen në mënyrë eksplicite (si në rreshtin 1), dhe grupet me blloqe deklarimesh shkruan bashkë. Ndryshoret e programit shkruhen me italik (pjerrtas), fjalët kyçe të programit me bold (të theksuara) dhe fjalët si emrat e procedurave dhe konstanteve të rezervuara me shkronja të mëdha.

(Sihiriti anësor vazhdon)


57

Shumë sisteme kanë më shumë se një interpretues. Interpretuesit e shumëfishtë janë shpesh herë asinkron, që nënkupton se ato ekzekutojnë në orë të ndara dhe të pakoordinuar. Si rezultat, ato mund të avancojnë në vlera të ndryshme, edhe nëse janë formalisht identik dhe e ekzekutojnë të njëjtin program. Te algoritmet e dizajnuara që koordinojnë punën e interpretuesve të shumëfishtë, mund të supozohet se nuk ka raport të fiksuar ndërmjet vlerave avancuese dhe për këtë nuk është mundur që të parashikohet koha, për shembull, e instruksioneve LOAD dhe STORE që ato i përmbajnë. Supozimi që një interpretues është asinkron, është njëri nga arsyet që koherenca read/write dhe atomiciteti before-or-after mund ta sfidojnë problemet e dizajnimit.

2.1.2.1 Procesorët

Procesori për punë të përgjithshme është një implementim i interpretuesit. Për qëllime të diskutimit konkret në këtë libër, do të përdorim procesorin tipik RISC. Referenca e instruksionit të procesorit quhet numërues i programit, i vendosur në regjistrin e shpejtë memorues, brenda procesorit. Numëruesi i programit përmban adresën e lokacionit të memories, e cila përmban instruksionin pasues të numëruesit të programit. Referenca mjedisore e procesorit përbëhet nga një sasi e vogël me memorie, me lokacion të adresuar në

Shigjeta e kthyer majtas simbolizon zëvendësimin apo caktimin (rreshti 2) dhe simboli “=” simbolizon barazimin në shprehjet e kushtëzuara. Pas dy vijve të pjerrta (//) mund të vendosen komente që nuk janë pjesë e pseudokodit. Forma të ndryshme të iteracioneve (while, until, for each, do occasionally), të kushteve (if), operacioneve me bashkësi (is in), dhe deklarimet me shumë alternativa, (do case) shfaqen nëpër shembuj sipas nevojës. Formulimi for j from 0 to 3 përsëritet katër here. Treguesi i fushës fillon te 0 dhe mbaron deri te 3. Formulimi y.x nënkupton elementi me emrin x në strukturën me emër y. Për të minimizuar këtë rrëmujë, pseudokodi i anashkalon deklarimet ku kuptimi është i arsyeshëm sipas kontekstit. Parametrat e procedurës janë me kalim sipas vlerës, nëse nuk shfaqet deklarimi reference. Seksioni 2.2.1 i këtij kapitulli e diskuton dallimin ndërmjet përdorimit sipas referencës dhe sipas vlerës. Atëherë kur më shumë ndryshore e përdorin strukturën e njëjtë, mund të përdoret deklarimi struktura_emri instance emri_ndryshores. Shënimi a(11. . . 15) nënkupton nxjerrjen e biteve nga 11 deri 15 nga vargu a (ose nga ndryshorja a e cila konsiderohet varg). Bitet numërohen nga e majta në të djathtë duke filluar nga zeroja, ku më i rëndësishmi vendoset i pari (duke përdorur shënimi big-endian, i sqaruar në Shiritin anësor 4.3). Operatori _ nëse përdoret në vargje atëherë i bashkon ato. Disa shembuj janë paraqitur në repertorin e instruksionit të një kompjuteri imagjinarë RISC (Reduced Instruction Set Computer). Pasi që programet e tilla janë të rënda, ata do të shfaqen vetëm atëherë kur nevojitet të tregohet sesi softueri ndërvepron me harduerin. Gjatë përshkrimit dhe përdorimit të lidhjeve, shënimi

x � y: {M} paraqet një mesazh me M përmbajtje nga dërguesi x deri te pranuesi y. Shënimi {a,b,c}paraqet mesazh që përmban të tre fushat e emëruara, të renditura në atë mënyrë që të supozohet se pranuesi e kupton si ta prish atë renditje.


58

formë të regjistrave të emëruar (me numra) për qasje të shpejtë deri te rezultatet e përkohshme të llogaritjes.

Procesori jonë për punë të përgjithshme mund të lidhet direkt me memorien, e cila poashtu është pjesë e mjedisit. Adresat në numëruesin e programit dhe në instruksione, pastaj, bëhen emra në hapësirën e adresimit të asaj memorie. Pra, kjo pjesë e referencës së mjedisit lidhet me të, duke mos ndryshuar. Kur do diskutojmë virtualizimin në Kapitullin 5, do ta zgjerojmë procesorin për t’iu referuar memories tërthorazi, nëpërmjet një apo më shumë regjistrave. Me këtë ndryshim, referenca e mjedisit ruhet në ato regjistra, dhe si rrjedhim edhe adresat e dala nga procesori për pasqyrimin në emra të ndryshëm të hapësirës së adresimit të memories.

Repertori i procesorit tonë për punë të përgjithshme, përfshin instruksione për shprehjen e llogaritjes siç janë mbledhja e dy numrave (ADD), zbritja e një numri nga një numër tjetër (SUB), krahasimi i dy numrave (CMP), dhe kalimi i numëruesit të programit te adresa e instruksionit tjetër (JMP). Këto instruksione operojnë me vlera të ruajtura në regjistrat e emrave të procesorit. Kjo përbën arsyen që nëpër biseda ata quhen “op-kode”.

Repertori përmban edhe instruksione për zhvendosjen e të dhënave ndërmjet regjistrave të procesorit dhe memories. Për të dalluar instruksionet programore nga operacionet e memories, do ta përdorim emrin LOAD për instruksione që lexon (READ) vlerën nga celula e emëruar e memories në regjistrin e procesorit dhe STORE për instruksionin që shkruan (WRITE) vlerën nga regjistri në celulën e emëruar të memories. Këto instruksione marrin dy argumente si numra të plotë, emrin e celulës së memories dhe emrin e regjistrit të procesorit.

Procesori për përdorim të përgjithshëm ka stek, që nënkupton një strukturë të dhënash që ruhet në memorie dhe përdoret për implementimin e thirrjeve procedurale. Kur të thirret procedura, thirrësi i shtyn argumentet e procedurës së thirrur në stek. Atëherë kur i thirruri kthehet, thirrësi e nxjerr stekun në madhësinë paraprake. Ky implementim i procedurave i mbështet thirrjet rekursive, sepse çdo përfshirje e procedurës, gjithmonë do të gjejë argumentet e saj në fillim të stekut. Një regjistër i kushtohet implementimit të operacioneve të stekut. Ky regjistër, i njohur si treguesi i stekut, e mban adresën e memories së majës së stekut.

Si pjesë e interpretimit të instruksionit, procesori e rrit numëruesin e programit, ashtu që kur ai instruksion të kompletohet, numëruesi i programit e përmban adresën e instruksionit pasues të programit. Nëse instruksioni që interpretohet është JMP, ai instruksion do të ngarkojë një vlerë të re, te numëruesi i programit. Në të dyja rastet, rrjedhja e interpretimit të instruksionit është nën kontrollin e programit që është duke u ekzekutuar.

Procesori implementon edhe ndërprerjet. Një ndërprerje mund të ndodh sepse procesori ka zbuluar ndonjë problem me programin që ekzekutohet (p.sh., programi ka tentuar të ekzekutojë instruksion që interpretuesi nuk e implementon apo nuk mund ta implementojë, siç është pjesëtimi me zero). Një ndërprerje mund të ndodhë edhe nëse sinjali


59

arrin jashtë procesorit, duke dëshmuar se disa pajisje të jashtme kanë dashur t’u kushtohet vëmendje (p.sh., sinjalet e tastierës, se shtypja e butonit është e mundshme). Në rastin e parë, mekanizmi i ndërprerjes mund ta zhvendos kontrollin te manovruesi i përjashtimeve tjetërkund në program. Në rastin e dytë, manovruesi i ndërprerjes mund të kryejë ndonjë punë dhe pastaj e kthen kontrollin te programi origjinal. Do t’i kthehemi kësaj teme për ndërprerjet dhe për dallimet ndërmjet manovruesve të ndërprerjeve dhe manovruesve të përjashtimeve, te diskutimet e fijeve në Kapitullin 5.

Përveç procesorëve me përdorim të gjerë, sistemet kompjuterike kanë edhe procesorë me përdorim special, të cilët kanë repertor të kufizuar. Për shembull, çipi i orës është i thjeshtë, si një interpretues që vetëm numëron: në ndonjë frekuencë të caktuar, ekzekuton instruksionin ADD, i cili i shton diçka përmbajtjes së regjistrit apo lokacionit memorik që korrespondon me orën. Të gjithë procesorët, qofshin ato me përdorim të gjerë apo special, janë shembuj të interpretuesve. Megjithatë, ato munden të ndryshojnë dukshëm sipas repertorit që kanë. Patjetër duhet të konsultohet manuali i shitësit të pajisjes që të mësohet më shumë për repertorin.

2.1.2.2 Shtresat e Interpretuesit

Interpretuesit janë pothuajse të organizuar çdoherë në shtresa. Shtresa më e fundit paraqet zakonisht makinën harduerike që ka një repertor primitiv të instruksioneve, dhe pastaj shtresat pasuese ofrojnë një rritje të sasisë së repertorit. Një sistem aplikativ mund të ketë katër apo pesë shtresa të interpretimit. Përgjatë çdo ndërfaqeje të caktuar të shtresës, shtresa e mëposhtme i paraqet ndonjë repertor me instruksione të mundshme, shtresës së mësipërme. Figura 2.6 e ilustron këtë model.

FIGURA 2.6

Modeli për interpretuesin e shtresëzuar. Secila ndërfaqe e shtresës, e paraqitur me vija të ndërprera, paraqet një barrierë të abstraksionit, te të cilat një procedurë e shtresës së sipërme, kërkon ekzekutimin e instruksioneve nga repertori i shtresës më të poshtme. Procedura e shtresës së poshtme implementon një instruksion ,duke ekzekutuar disa instruksione nga repertori i ndërfaqes së shtresës së poshtme që pason.

Le të shohim shembullin e programit për menaxhimin e kalendarit. Personi që bën kërkesa, duke lëvizur dhe klikuar mausin e shikon programin e kalendarit si një interpretues të gjesteve të mausit. Referenca e instruksionit i tregon interpretuesit që ta pranojë instruksionin e tij vijues nga tastiera apo miu. Repertori i instruksioneve është tërësi e kërkesave të mundshme: për të shtuar një ndodhi të re, për të futur ndonjë tekst përshkrues, për të ndryshuar orën, ose për të printuar listën e ndodhive të ditës. Mjedisi është një tërësi fajllesh që mbajnë mend kalendarin ditë për ditë.


60

Programi i kalendarit e implementon secilin aksion të kërkuar nga shfrytëzuesi, duke thirrur deklarime në disa gjuhë programore siç është Java. Këto deklarime, siç janë deklarimet e iteracionit, deklarimet kushtëzuese, deklarimet zëvendësuese, thirrjet e procedurave, përbëjnë repertorin e instruksionit të shtresës së poshtme që vijon. Referenca e instruksionit mban llogari se cili deklarim duhet të ekzekutohet në vijim, dhe mjedisi paraqet koleksionin e ndryshoreve të emëruara që i përdor programi. (Po supozojmë këtu se Java nuk kompaljon direkt në gjuhën e makinës. Nëse përdorej kompajluesi, atëherë do të kishim një shtresë më pak.) Aksionet e gjuhës programuese janë të implementuara nga instruksionet e gjuhës së makinës të harduerit, të ndonjë procesori me përdorim special, me referencën e vet të instruksionit, repertorin e tij dhe referencën e vet të mjedisit. Figura 2.7 i ilustron të tri shtresat e sapo përshkruara. Në praktikë, struktura e shtresëzuar mund të jetë më e thellë. Programi i kalendarit mund të organizohet me një shtresë të sipërme e të brendshme që interpreton veprime grafike dhe shtresë të poshtme që i manipulon të dhënat e kalendarit. Interpretuesi i Java mund të ketë shtresë interpretuesi të ndërmjetëm byte-code, dhe disa gjuhë të makinës janë të implementuara me shtresë mikrokod, të interpretuesit mbi shtresën e portave të harduerit.

FIGURA 2.7

Një sistem aplikativ i cili ka tre shtresa të interpretimit, secili me repertorin e vet të instruksioneve.

Njëri nga qëllimet e dizajnimit të interpretuesit të shtresëzuar është që të sigurohet se dizajnuesi i secilës shtresë mund të ketë vetëbesim, se shtresa e mëposhtme ose do ta kryej secilin instruksion me sukses ose nuk do ta kryejë fare. Instruksionet gjysmë të kryera nuk duhet të paraqesin brengosje asnjëherë, madje edhe nëse ndodh dështim i madh. Ai qëllim është një shembull tjetër i atomicitetit, dhe arritja e të cilit është relativisht e vështirë. Për momentin, ne thjesht supozojmë se interpretuesit janë atomikë, dhe e shtyjmë diskutimin e arritjes së atomicitetit për te Kapitulli 9 [onlajn].


61

2.1.3 Lidhjet komunikuese Lidhja komunikuese është një mënyrë që informacioni të lëviz ndërmjet komponentëve të ndarë fizikisht. Lidhjet komunikuese, për të cilat disa shembuj janë listuar në Figurën 2.9, shfaqen me teknologji të ndryshme, por te memoriet dhe interpretuesit ato mund të përshkruhen me abstraksion të thjeshtë. Abstraksioni i lidhjes komunikuese ka dy operacione:

SEND (emri_lidhjes, buferi_mesazhit_dalës) RECEIVE (emri_lidhjes, buferi_mesazhit _hyrës)

Operacioni SEND specifikon një fushë me bite, të quajtur mesazh, që duhet të dërgohet përgjatë lidhjes komunikuese, të identifikuar me emri_lidhjes (për shembull, teli). Argumenti buferi_mesazhit_dalës identifikon mesazhin që duhet dërguar, zakonisht duke e dhënë adresën dhe madhësinë e buferit, në memorien që e përmban mesazhin. Operacioni RECEIVE e pranon një mesazh që vjen, përsëri duke e përcaktuar adresën dhe madhësinë e buferit të memories, për ta ruajtur mesazhin hyrës. Pasi që shtresa më e ulët e sistemit të ketë pranuar mesazhin, shtresat më të larta mund ta kapin mesazhin duke thirrur ndërfaqen RECEIVE të shtresës së ulët, ose shtresa e ulët mund ta thërrasë në shtresën më të lartë, e në këtë rast ndërfaqja mund të karakterizohet më mirë si DELIVER (mesazhi_hyrës).

Emrat i lidhin sistemet me lidhjet komunikuese në dy mënyra të ndryshme. E para, argumentet emri_lidhjes të SEND dhe RECEIVE identifikojnë njërën nga shumë lidhjet e mundshme komunikuese të bashkangjitur me sistemin.

E dyta, disa lidhje komunikuese janë rrjeta të shumëfishta të lidhjeve, dhe nevojiten metoda plotësuese për të emëruar se cili nga pranuesit e shumët do ta pranojë mesazhin. Emri i pranuesit të paramenduar është një nga komponentët e mesazhit.

Në shikim të parë duket se dërgimi dhe pranimi i mesazheve është vetëm një shembull i kopjimit të fushës së biteve nga një memorie në tjetrën, nëpërmjet telit, duke përdorur operacionet READ dhe WRITE, ashtu që nuk do ketë nevojë për abstraksion të

tretë. Megjithatë, lidhjet komunikuese përmbajnë më shumë se një kopjim – ato kanë komplikime, siç është brezi i gjerë i parametrave operues që e bën të paparashikuar kohën e kryerjes së operacioneve SEND apo RECEIVE, një mjedis jo i favorshëm që e kërcënon integritetin e transferimit të dhënave; operacione asinkrone që çojnë deri te arritja e mesazhit madhësia dhe koha e shpërndarjes e të cilit nuk mund të dihet prej më përpara, dhe çka është më kryesorja mesazhi mund edhe të mos shpërndahet. Për shkak të këtyre komplikimeve,

FIGURA 2.8 Disa shembuj të lidhjeve komunikuese

Teknologjia harduerike: çifti i përdredhur kablloja koaksale fijet optike Nivel më të lartë Eternet Universal Serial Bus (USB) Internet sistemi telefonik tubi në UNIX


62

semantika e SEND dhe RECEIVE është shumë e ndryshme nga ajo që kanë të bëjë me READ dhe WRITE. Programet që përmbajnë SEND dhe RECEIVE duhet t’i marrin parasysh këto semantika të ndryshme. Nga ana tjetër, disa implementime të lidhjeve komunikuese ofrojnë një shtresë që bën të pamundurën për të fshehur ndërfaqen SEND/RECEIVE, prapa ndërfaqes READ/WRITE.

Ashtu si edhe me memorien dhe interpretuesit, dizajnuesit organizojnë dhe implementojnë lidhje komunikuese nëpër shtresa. Në vend që të vazhdojmë diskutimin e detajuar për lidhjet komunikuese këtu, do ta shtyjmë të njëjtin për diskutim te Seksioni 7.2 [onlajn], i cili përshkruan modelin me tre shtresa që i organizon lidhjet komunikuese në sisteme të quajtura rrjeta. Figura 7.18 [onlajn] e ilustron modelin e rrjetës me tri shtresa, e cili përbëhet nga një shtresë për lidhje, një shtresë të rrjetit, dhe një shtresë end-to-end.

2.2 EMËRTIMI TE SISTEMET KOMPJUTERIKE

Sistemet kompjuterike, shpesh i përdorin emrat në ndërtimin, konfigurimin dhe operacionin e tyre. Seksioni paraprak i përmendi adresat e memories, regjistrat e procesorit, dhe emrat e lidhjeve, dhe Figura 2.9 i listoi disa shembuj plotësues, disa prej të cilëve janë të njohur, e shembujt e tjerë do të përmendën në kapitujt pasues. Disa emra të sistemit iu ngjajnë atyre të gjuhës programues, kurse të tjerat janë shumë të ndryshme. Gjatë ndërtimit të sistemeve nga nënsistemet, është esenciale që të mund të përdoret nënsistemi pa ditur detajet sesi ai nën sistem iu referohet komponentëve të tij. Si rrjedhim emrat për të arrirë modularitet, dhe në të njëjtën kohë, modulariteti duhet që disa herë t’i fsheh emrat.

Do t’iu qasemi emrave nga një këndvështrim i objektit: sistemi kompjuterik i manipulon objektet. Interpretuesi i ekzekuton manipulimet nën kontrollin e programit apo ndoshta nën drejtimin e shfrytëzuesit njeri. Objekti mund të jetë i strukturuar, që nënkupton se ai përdor objekte tjera si komponentë. Në analogji të drejtpërdrejtë me dy mënyrat ku procedurat mund ti kalojnë argumentet, ekzistojnë dy mënyra që bëjnë që njëri objekt ta përdor objektin tjetër si komponentë:

Krijo kopje të objektit të komponentit dhe përfshije kopjen në përdorimin e objektit (përdorim sipas vlerës), ose

Zgjidhe emrin për objektin e komponentit dhe përfshije vetëm atë emër në përdorimin e objektit (sipas referencës). Objekti i komponentit thuhet se e eksporton emrin.

R5 (regjistri i procesorit) 174FFFhex (adresa e memories) pedantic.edu (emri i pikës së lidhjes së rrjetit) 18.72.0.151 (adresa e pikës së lidhjes së rrjetit) alice (emri i shfrytëzuesit) [email protected] (e-mail addresa) /u/alice/startup_plan.doc (emri i fajllit) http://pedantic.edu/alice/home.html (WWW URL)

FIGURA 2.9 Shembuj të emrave të përdorur në sisteme.


63

Kur argumentet kalojnë në procedura, përdorimi sipas vlerës e përforcon modularitetin, sepse nëse i thirruri aksidentalisht e ndryshon argumentin, kjo nuk do të ketë ndikim te origjinali. Por, përdorimi sipas vlerës mund të jetë problematik pasi që nuk e lejon lehtë që dy apo më shumë objekte të ndajnë objekt të komponentit, vlerat e të cilit ndryshojnë. Nëse edhe objekti A edhe objekti B e përdorin objektin C sipas vlerës, atëherë ndryshimi i vlerës së C-së, është koncept që ose është i pakuptimtë ose vështirë implementohet – mund të kërkojë kontrollimin e dy kopjeve të C-së të përfshira te A dhe B, për t’i ndryshuar ato. Njëlloj, në thirrjet procedurale, disa herë është e dobishme t’i mundësohet të thirrurit, modifikimi i objektit origjinal, pra shumica e gjuhëve programuese ofrojnë mënyra të kalimit të emrit (pseudokodi në këtë libër e përdor për këtë qëllim deklarimin reference) e jo të vlerës. Një qëllim i emrave, pastaj, është që të mundësohet përdorimi sipas referencës dhe kështu të thjeshtëzohet ndarja e objekteve të ndryshueshme.

Ndarja ilustron një qëllim themelor për emrat, si një vegël komunikuese dhe organizuese. Pasi që përdorimi i dyfishtë i emrit të njëjtë mund të referoj te objekti i njëjtë, nëse ato përdorime janë nga përdorues të ndryshëm apo nga përdoruesi i njëjtë në kohëra të ndryshme, emrat janë të pavlershëm edhe për komunikimin edhe për organizimin e gjërave, ashtu që mund të gjinden më vonë.

Përdorimi tjetër themelor i emrave është që t’ju mundësojë dizajnuesve të sistemit ta shtyjnë më vonë një vendim të rëndësishëm: kujt objekti duhet ti referoj emri? Emri po ashtu e lehtëson ndryshimin e mëvonshëm të vendimit. Për shembull, programi aplikativ mund të referoj në një tabelë me të dhëna sipas emrit. Mund të ketë disa versione të asaj tabele, dhe vendimi se cili version do të përdoret mund të pres deri kur programi realisht të ketë nevojë për tabelën.

Ndarja e një objekti nga tjetri duke përdorur emrin si ndërmjetësues, paraqet veprim të tërthortë. Mënyra e vendosmërisë për korrespodencën ndërmjet emrit dhe objektit është një shembull i lidhjes. Ndryshimi i lidhjes mekanikisht, është mënyrë e lehtë për të zëvendësuar një objekt me objektin tjetër. Modulet janë objekte, kështu që emërtimi është gurthemel i modularitetit.

Ky seksion paraqet një model të përgjithshëm për përdorimin e emrave te sistemet kompjuterike. Disa pjesë të këtij modeli duhet të jenë të njohura; diskutimin për tre abstraksionet themelore në seksionin paraprak shtjelloi emrat dhe teknologjinë e emërtimit. Modeli është vetëm një pjesë e rrëfimit. Kapitulli 3 diskuton më në thellësi vendimet e shumta që dalin gjatë dizajnit të skemave të emrave.

2.2.1 Modeli i Emërtimit Është e dobishme që të kemi model se si emrat janë të asocuar me objektet e caktuara.

Dizajnuesi i sistemit e krijon skemën e emërtimit, e cila përbëhet nga tri elemente. Elementi i parë është hapësira e emrit, e cila përbëhet nga një alfabet me simbole, që bashkë kanë rregulla sintaksore të cilat përcaktojnë se cilat emra janë të pranueshëm. Elementi i dytë është algoritmi i pasqyrimit të emrave, që asocon disa (jo patjetër të gjitha) emra të hapësirës së emrit, me disa (përsëri, jo patjetër të gjitha) vlera në universin e vlerave, i cili paraqet


64

elementin e tretë dhe të fundit i skemës së emërtimit. Vlera mund të jetë një objekt, ose mund të jetë emër tjetër nga hapësira origjinale e emrave ose nga hapësira e ndryshme e emrit. Pasqyrimi emër-vlerë është një shembull i lidhjes, dhe kur një pasqyrim i tillë ekziston, emri thuhet se është i lidhur për vlerën. Figura 2.10 e ilustron këtë.

Te shumica e sistemeve, zakonisht disa skema të veçanta të emërtimit janë në operacion njëkohësisht. Për shembull, sistemi mund të përdorë një skemë për emërtim për emrat e kutisë postare (mailbox) të e-mailit, skema tjetër e emërtimit për konferencierët (host) e Internetit, e treta për fajllet, dhe e katërta për adresat e memories virtuale. Kur një interpretues i programit has një emër, duhet ta dijë se cilën skemë të emërtimit ta kërkojë. Përdorimi i emrit në mjedis rrethues jep informata të mjaftueshme për gjetjen e skemës së emërtimit. Për shembull, në programin aplikativ, autori i atij programi e di se programi duhet të pres emra fajllesh që duhet të interpretohen vetëm nga sistemi i fajlleve dhe emrat e konferencierëve të Internetit duhet të interpretohen vetëm nga disa shërbime të rrjetit.

Interpretuesi që e has emrin e ekzekuton algoritmin për pasqyrimin e emrit të skemës përkatëse të emërtimit. Algoritmi për pasqyrimin e emrit e vendos emrin, që nënkupton se e zbulon atë dhe e kthen vlerën asocuese (për këtë arsye, algoritmi për pasqyrimin e emrit quhet edhe vendosës). Algoritmi për pasqyrimin e emrit zakonisht kontrollohet nga një parametër plotësues; i njohur si kontekst. Për një skemë të dhënë të emrave, mund të ekzistojnë kontekste të ndryshme, dhe emri i vetëm i hapësirës së emrit mund të pasqyrojë në vlera të ndryshme, atëherë kur vendosësi përdor kontekste të ndryshme. Për shembull, në një diskutim të përditshëm, kur personi iu referohet emrave “ti”, “këtu”, ose ”Alice”, kuptimi i secilit nga emrat, varet nga konteksti se përse i përdor personi. Skema të tilla të emërtimit japin të ashtuquajturat hapësirat universal të emrave, dhe ato kanë veçorinë e mirë se emri gjithmonë ka kuptimin e njëjtë brenda skemës së emërtimit, pavarësisht se kush e përdor atë. Për shembull, në SHBA, numri social i sigurimit, që identifikon pensionin qeveritar dhe llogaritë e taksave, përbën një hapësirë universale të emrit.

FIGURA 2.10 Modeli gjeneral i operacionit të skemës së emërtimit. Algoritmi për pasqyrim të emrave e merr emrin dhe kontekstin, dhe e kthen një element nga universi i vlerave. Shigjetat tregojnë se me kontekstin A algoritmi ia vendos emrin N4 vlerës 13.

Kur kemi të bëjmë me më shumë se një kontekst, interpretuesi mund t’i tregojë vendosësit se cilin duhet ta përdorë ose nga ana tjetër vendosësi mund të përdor një kontekst të paradefinuar.

Modelim e emërtimit mund ta përmbledhim, duke definuar operacionin konceptual të emrave si vijon:

vlera ← RESOLVE (emri, konteksti)


65

Kur një interpretues has një emër në një objekt, fillimisht e kupton se çfarë skeme të emërtimit është përdorur dhe cili version i RESOLVE duhet të thirret. Pastaj e identifikon kontekstin përkatës, e vendos emrin në atë kontekst, dhe e zhvendos emrin me vlerën e vendosur, përderisa interpretimi është duke vazhduar. Ndryshorja kontekst i tregon RESOLVE se cilin kontekst ta përdorë. Ajo ndryshore përmban emrin e njohur si referenca e kontekstit.

Tek procesori, emrat paraqesin numrat e regjistrit. Në procesorin e thjeshtë, tërësia e emrave të regjistrit, dhe regjistrat, emrat e të cilëve janë të lidhura, janë të fiksuar në kohën e dizajnit. Te shumica e sistemeve tjera që përdorin emra (përfshirë këtu skemën skemën e emërtimit të regjistrit të disa procesorëve me performancë të lartë), është e mundur që të krijohen lidhje të reja dhe të fshihen të vjetrat, të numërohet hapësira e emrit për të ditur listën e lidhjeve ekzistenciale, dhe të krahasohen të dy emrat. Për këto qëllime do të definojmë katër operacione tjera konceptuale:

status ← BIND (emri, vlera, konteksti) status ← UNBIND (emri, konteksti) list ← ENUMERATE (kontekst) result ← COMPARE (emri1, emri2)

Operacioni i parë e ndryshon kontekstin, duke shtuar lidhje të reja; rezultati nga statusi raporton nëse ndryshimi ka pasur ose jo sukses (mund të dështoj nëse emri i propozuar i shkel rregullat e sintaksës së hapësirës së emrit). Pas thirrjes të suksesshme të BIND, RESOLVE do të kthej vlerën e re për emrin.* Operacioni i dytë UNBIND, e fshin lidhjen aktuale nga konteksti, me statusin, përsëri duke raportuar sukses apo dështim (ndoshta sepse nuk ka ekzistuar lidhje e tillë). Pas thirrjes së suksesshme të UNBIND, RESOLVE nuk do të kthejë më vlerë për emrin. Operacionet BIND dhe UNBIND mundësojnë përdorimin e emrave për formimin e lidhjeve ndërmjet objekteve dhe ndryshimin e atyre lidhjeve më vonë. Dizajnuesi i një objekti, duke përdorur emrin për të referuar te objekti i komponentit, mund të zgjedh objektin te i cili lidhet emri, qoftë atëherë dhe qoftë më vonë, duke thirrur BIND, dhe mund të eliminojë lidhjen që nuk është më përkatëse duke thirrur UNBIND, duke mos e modifikuar objektin që e përdor emrin. Kjo aftësi e vonesës dhe ndryshimit të lidhjeve është një alternativë e fuqishme e përdorur në dizajnin e pothuajse të gjithë sistemeve. Disa implementime të emërtimit kanë operacionin ENUMERATE, i cili kthen një listë me të gjitha emrat që për momentin janë të lidhur në kontekst. Së fundmi, operacioni COMPARE raporton (TRUE apo FALSE) nëse emri1 dhe emri2 janë apo nuk janë të njëjtë. Kuptimi i “saktë” është një pyetje interesante e adresuar te Seksioni 2.2.5, dhe mund të kërkojë furnizimin e argumenteve plotësues të kontekstit.

Skemat e ndryshme të emërtimit kanë rregulla të ndryshme për unikalitetin e pasqyrimit emër-vlerë. Disa skema emërtuese kanë rregull që emër duhet të pasqyrohet saktësisht te një vlerë, në një kontekst të dhënë dhe një vlerë duhet të ketë vetëm një emër,

* Operacioni WRITE i abstraksionit të memories krijon asocim të emri-vlera, dhe mund të shihet si instancë e specializuar e BIND. Ngjashëm, operacioni READ mund të shihet si instancë speciale e RESOLVE.


66

kurse në skemat e tjera emërtuese, një emër mund të pasqyrojë disa vlera ose një vlerë mund të ketë disa emra, madje edhe në kontekstin e njëjtë. Një tjetër lloj i rregullës së unikalitetit është ai i hapësirës unike të identifikimit të emrit, që ka një tërësi emrash të cilët asnjëherë nuk do të ripërdoren për kohën e hapësirës së emrit dhe, pasi të lidhen, gjithmonë do të mbeten të lidhur me vlerën e njëjtë. Emri i tillë thuhet se ka lidhje stabile. Nëse hapësira unike e identifikimit të emrit, gjithashtu ka si rregull që vlera mund të ketë vetëm një emër, emrat unike bëhen të dobishme për të vëzhguar objektet gjatë një periudhe kohore të gjatë, për krahasimin e referencave me qëllimin që të shihet nëse i përkasin objektit të njëjtë, dhe për koordinimin e kopjeve të shumëfishta, te sistemet ku objektet janë replikuar për performancë apo siguri. Për shembull, llogaria e klientit te shumica e sistemeve llogaritare përbën një hapësirë unike të identifikimit të emrit. Numri i llogarisë gjithmonë do të tregohet te adresa e klientit, numri i telefonit, madje edhe te emri personal. Nëse llogaria e klientit fshihet, numri i llogarisë i klientit nuk do të përdoret përsëri për ndonjë llogari tjetër. Fushat e emëruara brenda llogarisë, siç është bilanci, mund të ndryshojnë nga koha në kohë, por lidhja ndërmjet numrit të llogarisë së klientit dhe llogarisë është stabile.

Algoritmi për pasqyrimin e emrit, plus konteksti nuk është e domosdoshme t’i pasqyrojë të gjitha emrat e vlerave të hapësirës së emrit. Kështu, rezultati i mundshëm pas ekzekutimit të RESOLVE mund të jetë not found (nuk u gjet), të cilin RESOLVE mund ta komunikojë deri te thirrësi, qoftë si vlerë e rezervuar apo si përjashtim. Nga ana tjetër, nëse skema e emërtimit lejon që një emër të pasqyrohet në disa vlera, rezultati i mundshëm mund të jetë një listë vlerash. Në atë rast, operacioni UNBIND mund të kërkojë një argument plotësues që përcakton se cila vlerë duhet të lirohet. Më në fund, disa skema emërtimi kanë kërkim të kundërt, që nënkupton se thirrësi mund ta furnizojë një vlerë si një argument për algoritmin e pasqyrimit të emrit, dhe të zbulojë se cili emër apo cilat emra janë të lidhura me atë vlerë.

Figura 2.10 e ilustron modelin e emërtimit, duke treguar hapësirën e emrit, universin korespondues të vlerave, algoritmin e pasqyrimit të emrit, dhe kontekstin që e kontrollon algoritmin e pasqyrimit të emrit.

Në praktikë, mund të hasim tre algoritme për pasqyrimin e emrit:

Kërkimi i tabelës Kërkimi i kundërt Kërkimi i shumëfishtë

Implementimi më i zakonshëm i kontekstit është një tabele me çiftet {emri, vlera}. Nëse implementimi i kontekstit është tabelë, algoritmi për pasqyrimin e emrit paraqet kërkim të emrit në atë tabelë. Vetë tabela mund të jetë komplekse, duke pasur B-pemë apo hash funksione, por ideja themelore akoma mbetet e njëjtë. Lidhja e emrit të ri me vlerën përbëhet nga mbledhja e çiftit {emri, vlera} në tabelë. Figura 2.11 e ilustron këtë implementim të zakontë të modelit të emërtimit. Nuk ekziston tabelë e tillë për çdo kontekst, dhe kontekstet e ndryshme mund të përmbajnë lidhje të ndryshme për emrin e njëjtë.


67

Shembujt realë të modelit të përgjithshëm të emërtimit dhe implementimit të kërkimit tabelor janë me shumicë: 1. Libri telefonik është kontekst me kërkim tabelor që i lidh emrat e njerëzve dhe organizatave me numrat e telefonit. Ashtu si edhe te shembulli i rrjetës së komunikimit të dhënave, numrat telefonikë, janë emra në vete që kompania e telefonit i vendos në forma të rreshtave fizike, duke përdorur algoritmin e pasqyrimit të emrit i cili përfshin kodin e thirrjes, shkëmbimet, dhe mekanizmin e ndërrimit. Librat telefonik për qytetet Boston dhe San Francisko janë dy kontekste me skemë të njëjtë emërtimi. Çdo emër i caktuar mund të shfaqet në të dyja librat telefonik, por nëse ndodh kjo, ka gjasë që të lidhet me numra të ndryshëm telefonikë. 2. Numrat e vegjël, të plotë, emërtojnë regjistrat e procesorit. Vlera është vetë regjistri, dhe pasqyrimi nga emri te vlera bëhet me anë të telit. 3. Celulat e memories emërtohen njëlloj si numrat e quajtura adresa, dhe pasqyrimi emër-vlerë përsëri

bëhet me tel. Kapitulli 5 e përshkruan një mekanizëm të adresës së mbetur e quajtur si memorie virtuale, e cila i lidh blloqet e adresave virtuale me blloqet e celulave të memories së afërt. Kur sistemi implementon memorie virtuale të shumëfishta, secila memorie virtuale paraqet kontekst të veçantë; adresa e dhënë mund të referojë në celulat e ndryshme të memories në secilën memorie virtuale. Celulat e memories gjithashtu mund të ndahen ndërmjet memorieve virtuale, ku celula e njëjtë e memories mund t’i ketë adresat e njëjta (apo të ndryshme) në memoriet e ndryshme virtuale, siç përcaktohet nga lidhjet.

4. Sistemi tipik kompjuterik i fajlleve shfrytëzon disa shtresa emrash dhe kontekstesh: sektorët e diskut, particionet e diskut, fajllet, ndërsa skedarët emërtohen së bashku si objekte. Skedarët janë shembuj të konteksteve me kërkim tabelor. Emri i caktuar i fajllit mund të shfaqet në disa skedarë të ndryshëm i lidhur me fajlle të njëjtë apo të ndryshëm.Seksioni 2.5 paraqet rast studimor të emërtimit në sistemin e fajlleve të UNIX-it.

5. Kompjuterët lidhen me rrjetat për komunikimin e të dhënave në vendet e quajtura pikat e lidhjes në rrjet. Këto pika zakonisht emërtohen me dy skema të veçanta emërtimi. E para, e përdorur brenda rrjetit, përfshin hapësirën e emrit që përbëhet nga numra në fushë me gjatësi fikse. Këto emra janë të lidhura, disa herë përherë dhe disa herë vetëm shkurtimisht, me hyrjen fizike dhe pikat e daljes së rrjetit. Skema e dytë e emërtimit, e përdorur nga klientët e rrjetit, pasqyron një hapësirë universale emrash, me vargje me karaktere, në emra të hapësirës së parë të emrit. Seksioni 4.4 është rast studimor i Sistemit të Emrit të Domenit, që mundëson emërtim të lehtë të pikës së lidhjes për Internetin.

6. Programuesi i identifikon ndryshoret e procedurës me emra, dhe çdo aktivizim i procedurës jep një kontekst të veçantë ku vendosen shumica e atyre emrave. Disa emra, të identifikuara si “statike” apo “emra globale”, mund të vendosen në vend të kontekstit që ndahet ndërmjet aktiviteteve apo ndërmjet procedurave të ndryshme. Kur të kompajlohet procedura, disa nga emrat e ndryshoreve origjinale dhe të lehta mund të zhvendosen me identifikues me numra të plotë që janë më të përshtatshëm për t’i manipuluar makina, por modeli i emërtimit akoma mbetet.

FIGURA 2.11 Sistemi që përdor kërkimin tabelor si algoritëm për pasqyrimin e emrit. Ashtu si edhe në shembullin e Figurës 2.10, ky sistem po ashtu e vendos emrin N4 te vlera 13.


68

7. URL-ja e World Wide Web është pasqyruar në një web faqe të caktuar me algoritëm relativisht të komplikuar që e ndan URL në disa pjesë përbërëse dhe i vendos pjesët duke përdorur skema të ndryshme emërtimi; rezultati mund të identifikohet në web faqe të caktuar. Seksioni 3.2 është rast studimor i kësaj skeme të emërtimit.

8. Sistemi llogaritar i klientëve, si zakonisht, përmban dy lloje të emrave për secilën llogari të klientit. Numri i llogarisë emërton llogarinë në një hapësirë unike të emrit, por ekziston edhe hapësirë e veçantë e emrit me emrat personalë, që gjithashtu, mund të përdoret për të identifikuar llogarinë. Të dyja këto emra pasqyrohen te regjistrimi i llogarisë nga sistemi i bazës me të dhëna, ashtu që llogaritë mund të nxirren ose sipas numrit të llogarisë ose sipas emrit personal.

Këto shembuj po ashtu nxjerrin në pah dallimin ndërmjet “emërtimit” dhe lidhjes. Disa,

por jo të gjitha, kontekstet i “emërtojnë” gjërat, në kuptimin se ato pasqyrojnë emra të një objekti që mendohet se e ka atë emër. Si rrjedhim, fjalori i telefonit nuk “emërton” as njerëz as linjë telefonike. Tjetërkund ekzistojnë kontekste që i lidhin emrat me njerëz dhe lidhin numrat telefonikë me telefonat e caktuar fizikë. Fjalori telefonik i lidh emrat e njerëzve me emrat e telefonave. Për secilin nga këto shembuj, referenca e kontekstit duhet të identifikojë kontekstin në të cilin algoritmi i pasqyrimit të emrit duhet ta vendosi emrin. Pastaj, ne e eksplorojmë se prej ku vijnë referencat e kontestit.

2.2.2 Referencat e Paradefinuara dhe Eksplicite të Kontekstit Atëherë kur interpretuesi i programit has ndonjë emër në objekt, dikush duhet që ta

furnizojë referencën e kontekstit, ashtu që algoritmi për pasqyrimin e emrit të mund ta dijë se cilin kontekst duhet ta shfrytëzojë, për ta vendosur emrin. Shumë probleme enigmatike duket se lehtë mund të përcaktohen: algoritmi i pasqyrimit të emrit, për cilëndo arsye, e ka shfrytëzuar referencën e gabuar të kontekstit.

Ekzistojnë dy mënyra për ta nxjerrë kontekstin me të cilin vendosen emrat e gjetur në objekt. Ajo e paradefinuar dhe eksplicite. Referenca e paradefinuar e kontekstit është atëherë kur vendosësi furnizon, kurse referenca eksplicite e kontekstit është ajo që vjen si e paketuar me objektin që shfrytëzon emrin. Disa herë skema e emërtimit lejon përdorimin e të dyja metodave: e përdor referencën eksplicite nëse objekti apo emri jep një. Në të kundërtën e përdor kontekstin e paradefinuar. Figura 2.12 e reflekton taksonominë e referencave të kontekstit e përshkruar në dy kryerreshtat vijues. Referenca e paradefinuar e kontekstit mund të jetë konstante, që është e ndërfutur te vendosësi si pjesë e dizajnit. Meqë konstanta lejon hapësirë vetëm për një kontekst, hapësira emërtuese dalëse është universale. Në mënyrë alternative, referenca e paradefinuar mund të jetë ndryshore, të cilën e fiton vendosësi nga mjedisi i tij aktual i ekzekutimit. Ajo ndryshore mund të vendoset nga ndonjë rregull për caktimin e kontekstit. Për shembull, te shumica e sistemeve me përdorues të shumëfishtë, secili mjedis ekzekutimi i përdoruesit përmban një ndryshore e cila quhet skedari punues.


69

Skedari punues vepron si kontekst i paradefinuar për vendosjen e emrave të fajlleve. Ngjashëm, sistemi mund të caktojë kontekst të ndryshëm për secilin aktivitet të veçantë nga përdoruesi, siç do të shihet te Kapitulli 3 (figurat 3.2 dhe 3.3), për secilin nënsistem të madh të sistemit. Nga ana tjetër, referenca eksplicite zakonisht vjen në një apo dy forma: referencë e vetme kontekstuale e paramenduar për përdorimin e të gjitha emrave që përdoren nga objekti ose referencë e veçantë kontekstuale e lidhur me secilin emër të objektit.

Forma e dytë, ku secili emër është i paketuar me referencën e vet kontekstuale, njihet si emër i kualifikuar.

Referenca kontekstuale paraqet një emër (që emërton kontekstin), që bën që disa autorë ta përshkruajnë atë si emër bazik. Vendosësi i emrit duhet që ta vendos emrin e përfaqësuar nga referenca kontekstuale, përpara se mund të vazhdojë me vendosjen apo zgjidhjen e emrit origjinal. Ky rikthim mund të përsëritet disa herë, por duhet që dikur të përfundojë, me përfshirjen e vendosësit të emrit që ka një kontekst të vetëm në kuadër të tij. Ky kontekst përmban lidhjet që lejon qërikthimi të çthuret.

Përshkrimi i tillë është tepër abstrakt. Për ta bërë më konkret, le të kthehemi te shembulli paraprak real, ku për çdo rast të kërkimit të referencës kontekstuale vendosësi përdor:

1. Kur kërkohet një numër në librin telefonik, duhet që të jepet referenca kontekstuale: duhet të dimë nëse kemi zgjedh librin telefonik të Boston-it apo San Franciskos. Nëse thirret Ndihma e Skedarit për të pyetur për ndonjë numër, operatori menjëherë do ju pyesë për referencën kontekstuale duke thënë, “Cilin qytet, ju lutem?” Nëse emrin e keni në ndonjë letër, ajo letër mundet ta përmend emrin – një shembull i referencës eksplicite. Nëse jo, duhet që të qëlloni, ose të realizoni një kërkim të skedarëve për disa qytete të ndryshme.

2. Te procesori, zakonisht ka vetëm një bashkësi regjistrash të numëruar; ato përbëjnë kontekstin e paradefinuar që është i integruar duke përdorur tela. Disa procesorë kanë bashkësi të shumëfishta regjistrash, ku ekziston një regjistër plotësues, zakonisht i fshehur nga programuesi i aplikacionit, i cili përcakton se cila bashkësi regjistrash përdoret momentalisht. Procesori e përdor përmbajtjen e atij regjistri, i cili është komponent i mjedisit momental të interpretimit, si referencë kontekstuale e paradefinuar. E vendos atë numër me kontekstin e integruar që lidh numrat nga bashkësia e regjistrave me bashkësitë fizike të regjistrit, duke interpretuar numrin e

FIGURA 2.12 Taksonomia e referencave kontekstuale

Referencat kontekstuale për emrat e gjetur në objekt ■ Të paradefinuara: të furnizuara nga vendosësi □Konstante e ndërfutur në vendosës □Ndryshore nga mjedisi aktual ■ Eksplicite: Të furnizuara nga objekti □Për objekt □Për emër (emër i kualifikuar)


70

bashkësisë së regjistrit si një adresë që tregon lokacionin e bankës së saktë të regjistrave.

3. Në sistemin që implementon memorie virtuale të shumëfishta, mjedisi interpretues përfshin regjistrin e procesorit (regjistrin e adresës për pasqyrimin e faqes te Kapitulli 5.) që emërton tabelën e faqes aktive momentale; ai regjistër përmban një referencë deri te konteksti i para definuar. Disa sisteme të memories virtuale kanë vetitë e quajtura segmente. Tek ato sisteme, programi mund të lëshojë adresa që përmbajnë referencë kontekstuale eksplicite të njohur si numra të segmentit. Segmentet diskutohen në Seksionin 5.4.5.

4. Në sistemin e fajlleve me shumë skedarë, kur programi referon te fajlli që përdor emër të pakualifikuar apo të kualifikuar jo të plotë, sistemi i fajlleve e përdor skedarin punues si referencë kontekstuale të paradefinuar. Në mënyrë alternative, programi mund të përdor një emër absolut të rrugës, një shembull i emrit plotësisht të kualifikuar që do ta diskutojmë në thellësi në vijim. Emri i rrugës përmban referencën e vetë kontekstuale eksplicite. Edhe në skedarin punues edhe në emrin absolut të rrugës, referenca kontekstuale paraqet emër, që vendosësi duhet ta vendos para se të vazhdojë me vendosjen e emrit origjinal. Kjo na çon deri te vendosja rekursive e emrit që është diskutuar te Seksioni 2.2.3.

5. Në Internet, emrat e pikave lidhëse të rrjetit mund të jenë të kualifikuara (p.sh. ginge.pedantic.edu) apo jo të kualifikuara (p.sh. ginge). Kur vendosësi i emrit të rrjetit has në emër jo të kualifikuar, e kualifikon atë emër me referencë kontekstuale të paradefinuar, shpesh herë të quajtur edhe si domeni i paradefinuar. Megjithëse e materializon atë, emri i kualifikuar është një emër absolut i rrugës që akoma ka nevojë që të vendoset. Parametri për konfiguracionin e vendosësit të emrit, që është ndryshe i paradefinuar – e furnizon kontekstin për vendosje të atij emri absolut të rrugës në hapësirën universale të emrave të domeneve të Internetit. Seksioni 4.4 e përshkruan në detaje, duke mos e sqaruar hollësisht, mekanizmin që i vendos emrat e domeneve në Internet.

6. Komuniteti i gjuhëve programuese përdor terminologjinë e saj për përshkrimin e referencës kontekstuale eksplicite apo të paradefinuar. Gjatë implementimit të shtrirjes dinamike, vendosësi e përdor mjedisin momental të emërtimit, si kontekst të paradefinuar për vendosjen e emrave. Gjatë implementimit të shtrirjes statike (gjithashtu njihet edhe leksikore), krijuesi i objektit (shumë herë një objekt procedural) e asocon objektin me një referencë kontekstuale eksplicite, mjedis ky emërtues në atë moment. Komuniteti gjuhësor e quan kombinacionin e tillë të objektit dhe referencën e tij kontekstuale si mbyllje.

7. Për vendosjen e URL për World Wide Web, emri i vendosësit shpërndahet, dhe kontekste të ndryshme përdoren për komponentë të ndryshëm të URL.

8. Sistemet e bazave të të dhënave, në sistemin llogaritar, kanë kontekst për vendosjen edhe të numrave të llogarisë edhe të emrave personalë. Nëse sistemi llogaritës ka ndërfaqe grafike të përdorimit, mund të ofrojë formë kërkimi me fusha të zbrazëta edhe për numrin e llogarisë edhe për emrin personal. Përfaqësuesi i shërbimit të klientit e zgjedh referencën kontekstuale duke shkruar te një apo dy fusha dhe duke


71

shtypur butonin “Kërko”, që e thirr vendosësin. Secila nga fushat korrespondon me kontekst të ndryshëm.

Referenca kontekstuale mund të jetë dinamike, që nënkupton se ndryshon nga çasti në çast. Një shembull është kur shfrytëzuesi klikon në butonin e menysë së quajtur “Ndihmë”. Edhe pse butoni gjithmonë mund të shfaqet në vendin e njëjtë të ekranit, konteksti ku vendoset emri “Ndihmë” (edhe ekrani i caktuar ndihmës që shfaqet si përgjigje) mund të varet nga ajo se cili program aplikativ, ose madje cila pjesë e atij programi, ekzekutohet në rastin kur shfrytëzuesi e klikon butonin.

Problemi i zakonshëm është kur objekti që e përdor emrin nuk ka kontekst eksplicit, dhe vendosësi i emrit e zgjedh kontekstin e paradefinuar të gabuar. Për shembull, sistemi i fajlleve zakonisht vendos emër për fajllin që është relativ, me skedarin punues të çastit, edhe pse ky skedar punues mund të mos ketë lidhje me identitetin e programit apo objektin e të dhënave që përbën referencën. Krahasuar me mjedisin e vendosjes së emrit të sistemit programues, shumica e sistemeve të fajlleve kanë mekanizëm më primitiv të vendosjes së emrit.

Sistemi i postës elektronike është një shembull i problemit, nëse emrat interpretohen në kontekstin e paramenduar. Konsideroni mesazhin elektronik (e-mail) në Figurën 2.13, që kishte fillimin te Pediatric University. Në këtë mesazh, Alice, Bob, dhe Dawn janë emra nga hapësira lokale e emrave të kutive postare elektronike në Pediatric University, dhe [email protected] është emër i kualifikuar i kutisë postare i menaxhuar nga shërbimi i postës me emrin cse.Scholarly.edu në Institute of Scholarly Studies. Emri Charles është i veçantë në kutinë e atij shërbimi, dhe shenja @ përdoret me konventë për të ndarë emrin e kutisë postare nga emri i shërbimit postarë.

Duke qenë ashtu, nëse shfrytëzuesi Charles tenton t’i përgjigjet dërguesit të këtij mesazhi, përgjigja do t’i adresohet Bob-it. Meqë vendosësi i emrit të parë që do has mesazhin kthyes është brenda sistemit të emëruar cse.Schloarly.edu, ai vendosës në rrethana normale do ta përdor si kontekst të paradefinuat emrin e shërbimit lokal postarë. Pra, do të tentojë të dërgojë mesazh te [email protected]. Kjo nuk është kutia postare e shfrytëzuesit që e dërgoi mesazhin origjinal. Madje, mund të jetë edhe adresa e kutisë së dikujt tjetër.

To: Bob Cc: [email protected] From: Alice ------ Based on Dawn’s suggestions, this chapter has experienced a major overhaul this year. If you like it, send your compliments to Dawn (her e-mail address is “Dawn”); if you do not like it, send your complaints to me.

FIGURA 2.13 Një mesazh elektronik që përdor kontekst të paradefinuar.


72

To: [email protected] cc: [email protected] From: [email protected] ------ Based on Dawn’s suggestions, this chapter has experienced a major overhaul this year. If you like it, send your compliments to Dawn (her e-mail address is “Dawn”); if you do not like it, send your complaints to me.

FIGURA 2.14 Mesazhi elektronik nga Figura 2.13 pasi që sistemi postar e zgjeron çdo adresë të pakualifikuar për të përfshirë një referencë kontekstuale eksplicite.

Gjatë përpilimit të mesazhit elektronik, Alice i kishte ndër mend për t’i vendosur emrat, si Bob, në kontekstin e saj personal. Shumica e sistemeve të dërgimit të mesazheve dinë se emri lokal nuk është i dobishëm për ndonjë që është jashtë kontekstit lokal, dhe është me konventë që sistemi i mesazheve elektronike, emrat e pakualifikuar që i gjen në fushat e adresave, automatikisht i rishkruan ato si emra të kualifikuar, duke shtuar një referencë kontekstuale eksplicite te emrat Bob dhe Alice, si në Figurën 2.14. Për fat të keq, sistemi i mesazheve mund t’i ekzekutojë rishkrimet e adresës vetëm për fushat fillestare, sepse ajo është pjesa e vetme e formatit të mesazhit që është plotësisht e kuptueshme. Nëse një adresë e mesazhit elektronik është brenda tekstit të mesazhit (si në shembull, emri Dawn), sistemi nuk mund ta dallojë atë nga teksti tjetër. Nëse pranuesi i mesazhit dëshiron të përdor adresën e gjetur në tekstin e mesazhit, ai pranues do ta kuptojë se cila referencë kontekstuale përdoret. Disa herë është e lehtë për ta kuptuar këtë, por nëse mesazhi është ridërguar disa herë, apo pranuesi nuk është i vetëdijshëm për problemin, gabimi është evidentë. Një zgjidhje parciale mund të jetë etiketimi i mesazhit elektronik me referencë kontekstuale eksplicite, duke përdorur fushë fillestare plotësuese, si në Figurën 2.15. Me këtë plotësim, pranuesi i këtij mesazhi mund ta zgjedh ose Alice nga fusha fillestare ose Dawn nga teksti dhe të kërkojë nga sistemi i mesazhit të dërgojë përgjigje. Sistemi mundet që, duke ekzaminuar fushën Context, të përcaktojë se si do ta vendosë adresën e pakualifikuar të ndërlidhur me këtë mesazh, qoftë duke qenë në fushën fillestare origjinale apo e nxjerrë nga teksti i mesazhit. Kjo skemë është shumë rastësore; nëse përdoruesi Bob e ridërgon mesazhin e Figurës 2.15 me një shënim plotësues deri te ndonjë që është në kontekst tjetër emërtimi, çdo adresë e pakualifikuar në shënimin e shtuar do të ketë nevojë për referencë të ndryshme kontekstuale eksplicite. Edhe pse kjo skemë nuk përdoret në ndonjë sistem të mesazheve elektronike, ajo ka qenë e përdorur në sistemet e tjera emërtuese. Një shembull është elementi bazik i HTML, gjuha që e shfaq World Wide Web, e përshkruar shkurtë në Seksionin 3.2.2. Një problem shumë i ngjashëm është se kontekstet e ndryshme mund të lidhin emra të ndryshëm për objektin e njëjtë. Për shembull, për thirrjen e një numri të caktuar telefonik. Mund të kemi rast nëse personi në organizatën e njëjtë e kërkon numrin 2-7104, personi i dytë përtej qytetit kërkon numrin 312-7104, i treti që është pak më larg e kërkon numrin (517) 312-7104, dhe personi nga një shtet tjetër duhet ta kërkojë 001 (517) 312-7104. Kur objekti i njëjtë ka emra të ndryshëm në kontekste të ndryshëm, kalimi i emrit nga një shfrytëzues te tjetri është i vështirë sepse, si me shembullin e mesazhit elektronik, dikush duhet ta përkthejë emrin pare se ta përdor tjetri. Ashtu si edhe te shembulli i mesazhit elektronik, nëse dikush ju jep një copë letër ku është i shënuar numri 312-7104, duke e sjell atë numër mund të cingëroj ose mos cingërojë numri i paramenduar. Edhe pse disa emra janë të ngjashëm, duhet një përpjekje për të kuptuar se çfarë përkthimi është i nevojshëm.


73

To: Bob cc: [email protected] From: Alice Context: Pedantic.edu ------ Based on Dawn’s suggestions, this chapter has experienced a major overhaul this year. If you like it, send your compliments to Dawn (her e-mail address is “Dawn”); if you do not like it, send your complaints to me.

FIGURA 2.15 Mesazhi elektronik që në vete ka një referencë kontekstuale eksplicite si një fushë fillestare.

2.2.3 Emrat e rrugës, Rrjeti Emërtues, dhe Vendosja Rekursive e Emrave I dyti nga tre algoritmet për pasqyrimin e emrave të listuar në faqen 64 është vendosja

rikthyese (rekursive) e emrit. Emri i rrugës mund të merret si emri që në mënyrë eksplicite e përfshin referencën për te konteksti, te i cili duhet të vendoset. Në disa skema emërtimi, emrat e rrugës shënohen me referencën kontekstuale në fillim, në disa tjera me referencën kontekstuale në fund. Disa shembuj të emrave të rrugës janë:

ginger.pedantic.edu. /usr/bin/emacs Macintosh HD:projects:CSE 496:problem set 1 Kapitulli 2 , Seksioni 2, Pjesa 3, Paragrafi i parë Paragrafi 1 i pjesës 3 e seksionit 2 i kapitullit 2

Siç shohim nga shembujt, emri i emrit përfshin komponentë të shumëfishtë dhe sintaksë që i lejon vendosësit të emrit t’i analizojë komponentët. Dy shembujt e fundit ilustrojnë se skemat e ndryshme emërtuese i vendojnë emrat e komponentëve në radhitje të kundërt, dhe shembujt tjerë po ashtu i demonstrojnë të dyja radhitjet. Radhitja e komponentëve duhet të jetë e njohur për shfrytëzuesin e emrit dhe për vendosësin e emrit, por secila mënyrë e interpretimit të emrit të rrugës është më lehtë e sqaruar në mënyrë rekursive, duke huazuar terminologji nga paraqitja e numrave. E gjitha, përveç komponentit me rëndësi më të vogël të emrit të rrugës, është një referencë kontekstuale eksplicite që identifikon kontekstin që duhet përdorur për vendosjen e komponentit me rëndësi më të vogël. Në shembujt e mësipërm, komponentët me rëndësi më të vogël dhe referencat e tyre kontekstuale e eksplicite janë paraqitur më poshtë, respektivisht,

Komponenti me rëndësi më të vogël Referenca kontekstuale eksplicite ginger emacs problem set 1 paragrafi i parë Paragraf 1

pedantic.edu /usr/bin Macintosh HD:projects:CSE 496 Kapitulli 2 , Seksioni 2, Pjesa 3, pjesa 3 e seksionit 2 i kapitullit 2


74

Aspekti rekursiv i këtij përshkrimi është se referenca e kontekstit eksplicit në vete, është emër i rrugës që duhet të zgjidhet. Kështu që e përsërisim analizën aq herë sa është e nevojshme derisa ai që ishte në fillim komponenti më i rëndësishëm i emrit të rrugës, të jetë poashtu komponenti më pak i rëndësishëm, te e cila pikë zgjedhësi/vendosësi mund të bëjë një kërkim me tabelë të zakonshme, duke përdorur ca kontekste. Në përzgjedhjen e këtij konteksti, aplikohet diskutimi paraprak i referencave kontekstuale eksplicite dhe të paradefinuara. Në dizajnin e rëndomtë, zgjedhësi përdor një nga dy referencat kontekstuale të paradefinuara:

Një referencë speciale kontekstuale, e njohur si rrënja (ang. root) që është e ndërtuar në kuadër të zgjedhësit. Rrënja është një shembull i hapësirës universale të emrit. Emri i rrugës që e zgjedh zgjedhësi me rekursionin që mbaron në kontekstin e rrënjës, njihet si emri absolut i rrugës.

Emri i rrugës i një konteksti tjetër të paradefinuar. Për ta shmangur formën qarkore, ky emër i rrugës duhet të jetë një emër absolut i rrugës. Emri i rrugës që zgjidhet duke e kërkuar komponentin më të rëndësishëm të saj, në një kontekst tjetër quhet emri relativ i rrugës. (Në sistemin e fajllave, emri i rrugës, i këtij konteksti të para definuar, është ai që identifikohet si skedar punues te shembulli 4 në faqen 68.) Për këtë arsye në sistemin e fajllave në UNIX, për shembull, nëse skedari punues është /usr/Alice, emri relativ i rrugës është /usr/Alice/plans/Monday.

Nëse një zgjedhës i vetëm i emrit përgatitet të zgjedhë emrat relativ dhe absolut të rrugës, disa skema siç janë flamujtë sintaktikë (p.sh. shenja fillestare “ / ” në /usr/bin/emacs dhe shenja përfundimtare “.” në ginger.pedantic.edu.) mund të dallohen nga njëra-tjetra, ose ndoshta zgjedhësi i emrit do të tentojë në të dy mënyrat, duke përdorur të parën që do të funksionojë. Duke përdor dy skema kjo është një formë e thjeshtë e kërkimit të shumëfishtë të emrit, gjë për të cilën kemi të flasim në nënseksionin e ardhshëm.

Emrat e rrugës mund të llogariten edhe sikur identifikimi i objekteve që janë të organizuar në atë që quhet rrjeti emërtues. Në rrjetin emërtues, kontekstet trajtohen si objekte, dhe secili kontekst mund të përmbajë lidhjen emër-objekt për secilin objekt, duke përfshirë kontekstin tjetër. Zgjedhësi i emrit deridiku e zgjedh një kontekst që ta përdor si rrënjë (ndoshta duke pasur emër ti nivelit të ulët për kontekstin e lidhur për zgjidhësin), dhe pastaj i zgjedh të gjitha emrat absolut të emrave, duke vazhduar gjurmimin për rrugën nga rrënja e zgjedhur në kontekstin e parë, të emërtuar në emrin e rrugës, pastaj duke vazhduar derisa të arrihet objekti që ishte emërtuar nga emri origjinal i rrugës. Kjo ngjashëm i zgjedh emrat relativ të rrugës, duke filluar me kontekstin e para definuar që ndodhet në ndryshore, në mjedisin e tij. Kjo ndryshore përmban emrin absolut të rrugës për kontekstin e paradefinuar. Meqë ekzistojnë shumë rrugë nga një vend në tjetrin, mund të ketë shumë emra rrugësh për të njëjtin objekt apo kontekst. Emrat e shumëfishta për objektin e njëjtë njihen si sinonime apo aliase. (Ky libër e shmang fjalën “alias” sepse sistemet e ndryshme e përdorin atë në mënyra të ndryshme.) Nga ana tjetër, meqë rrënja posedon hapësirën universale të emrit, secili objekt që e përdor rrugën e njëjtë absolute tregon për te objekti i njëjtë dalës.


75

Ndarja e emrave të rrjetës emërtuese mund të paraqesë problem, sepse çdo përdorues mund të shprehë emrat e rrugës në raport me pikën e ndryshme startuese. Si rezultat, nuk mund të jetë e qartë sesi të përkthehet emri i rrugës gjatë kalimit nga një përdorues te tjetri. Një zgjidhje standarde e këtij problemi është kërkimi që përdoruesit të ndajnë vetëm emrat absolut të rrugës, duke filluar nga rrënja.

Sistemi i fajllave i sistemit operativ zakonisht është i organizuar si rrjet emërtimi, me skedarë që veprojnë si kontekste. Është rutinë që te sistemet e fajllave të hasen restrikcione të drejtuara nga implementimi i formës së rrjetës të emërtimit. Për shembull, kërkesa që kontekstet të organizohen në hierarki të emërtimit me rrënjën që do të ketë rolin e bazës së pemës. Hierarkia e vërtetë e emërtimit është aq kufizuese, saqë rrallë gjendet në praktikë. Sistemet reale, edhe nëse janë sipërfaqësisht hierarkike, zakonisht ofrojnë një mënyrë të shtimit të lidhjeve ndër-hierarkike. Lloji më i thjeshtë i lidhjes është sinonim: objekti i vetëm mund të lidhet në më shumë se një kontekst. Disa sisteme lejojnë llojin më të sofistikuar të lidhjes, i njohur si emri indirekt. Emër indirekt kemi atëherë kur konteksti lidhet me emrin tjetër, në hapësirën e njëjtë emërtuese dhe jo për objektin. Pasi që shumë dizajnues e kanë kuptuar, në mënyrë të pavarur, se emrat indirekt janë të dobishëm, ato i quajnë me emra të ndryshëm, si lidhje simbolike, lidhje të buta, dhe shkurtesa. Sistemi i fajllave të UNIX, i përshkruar në Seksionin 2.5 përfshinë hierarkinë e emërtimit, lidhjet, dhe emrat indirekt, të quajtura lidhje të buta.

Emri i rrugës ka strukturë të brendshme, dhe skema emërtuese që i mbështet emrat e rrugës. Zakonisht ka rregulla sa i përket konstruktimit të emrave të lejueshëm të rrugës. Emrat e rrugës mund të kenë gjatësi maksimale dhe disa simbole mund të jenë të mundshme, për përdorim, vetëm si ndarës struktural.

2.2.4 Kërkimi i Shumëfishtë: Kërkimi nëpër Kontekste të Shtresuara Të kthehemi te tema e konteksteve të paradefinuar! Në taksonominë e figurës 2.12,

rregullat e vendosjes së kontekstit janë vegël topitëse. Për shembull, skedari që përmban programe të librarisë, duhet të ndahet ndërmjet përdoruesve të ndryshëm; asnjë rregull vendosjeje e vetme nuk mund të jetë e tepërt. Kjo papërkulshmëri çon deri te skema e tretë e zgjedhjes së emrit që është kërkimi i shumëfishtë†. Ideja e kërkimit të shumëfishtë është braktisja e nocionit të kontekstit të vetëm dhe të para definuar dhe në vend të kësaj të zgjidhet emri duke u përpjekur sistematikisht me disa kontekste të ndryshëm. Meqë emri mund të lidhet në më shumë se një kontekst, kërkimi i shumëfishtë mund të prodhojë zgjidhje të shumëfishta, dhe disa skema duhet të vendosin se cila zgjidhje të përdoret.

Një skemë e tillë e rëndomtë quhet rruga e kërkimit, që nuk është asgjë më shumë se një listë specifike me kontekste për t’u përdorur. Zgjedhësi i emrit tenton të zgjedh emrin duke përdorur kontekstin e parë në listë. Nëse nuk gjen asgjë, tenton me kontekstin tjetër, e

† Komuniteti i sistemit operativ tradicionalisht e përdor fjalën “kërko” (ang. “search”) për kërkim të shumëfishtë, por avancimi i makinave të kërkimit në Internet dhe në desktop e ka bërë këtë përdorim të paqartë. Paragrafi i fundit në Seksionin 2.2.4, në faqen 75, e diskuton këtë temë.


76

kështu me radhë. Nëse emri lidhet në më shumë se një nga kontekstet e listuara, ai më i hershmi në listë fiton dhe zgjedhësi e kthen vlerën të asocuar me atë lidhje.

Rruga e kërkimit shpesh përdoret në programimin e sistemeve që kanë librari. Të supozojmë, për shembull, procedura e librarisë që kalkulon funksionin matematikor për rrënjën katrore, nxjerr një ndërfaqe procedurale me emrin SQRT. Pas kompajlimit të këtij funksioni, shënuesi ruan një kopje të programit binar në librarinë matematikore. Përdoruesi i ardhshëm i funksionit të rrënjës katrore e shkruan deklarimin:

x ←SQRT ( y )

në program, dhe kompajluesi gjeneron kod që e përdor procedura me emrin SQRT. Hapi i ardhshëm është kur kompajluesi (ose në disa sisteme ngarkuesi) ndërmerr një seri kërkimesh në librari të ndryshme publike dhe private që kanë njohuri për këtë. Secila librari paraqet kontekst, dhe rruga e kërkimit është listë me kontekste të librarisë. Secili hap i kërkimit të shumëfishtë përfshin një thirrje të një vendosësi të thjeshtë dhe kontekstual të emrit. Disa nga këto zgjidhje, të provuara, do të kthejnë rezultatin nuk-u-gjet. Prova e parë e zgjedhësit që gjen programin me emër SQRT, do e kthejë atë program si rezultat të kërkimit.

Rruga e kërkimit zakonisht është e implementuar si listë për shfrytëzues, me disa ose të gjitha elementet që i vendos shfrytëzuesi. Duke vendosur librari që përmbajnë programe personale, që herët në rrugën e kërkimit, shfrytëzuesi individual mund me efektshmëri ta zhvendos programin e librarisë me një tjetër që ka emrin e njëjtë, duke mundësuar lidhjen e varur nga shfrytëzuesi. Ky tipar zhvendos-sipas-emrit mund të jetë i dobishëm, por mund të jetë edhe i rrezikshëm sepse, pa qëllim, mund të zgjidhet emri për programin që poashtu është i nxjerrë nga ndonjë librari tërësisht e palidhur. Kur disa aplikacione tjera tentojnë ta thërrasin atë program të palidhur, kërkimi pasues i shumëfishtë mund ta gjejë të papërshtatshmin. Duke u rritur numri i librarive dhe emrave në rrugën e kërkimit, rritet shansi që dy librari do të përmbajnë gabimisht dy programe të palidhura që do ta nxjerrin emrin e njëjtë.

Pavarësisht rrezikut, rrugët e kërkimit janë mekanizma që përdoren shumë. Përveç ngarkuesve që përdorin rrugë kërkimi për gjetjen e procedurave të librarive, ndërfaqet e shfrytëzuesve përdorin rrugët e kërkimit për gjetjen e komandave, emrat e të cilave janë shtypur nga shfrytëzuesi; kompajluesit përdorin rrugë kërkimi për gjetjen e ndërfaqeve; sistemet e dokumentimit përdorin rrugë kërkimi për gjetjen e dokumenteve të cituara, dhe sistemet e përpunimit të fjalëve përdorin rrugë kërkimi për gjetjen e fragmenteve të tekstit që duhet të përfshihen në dokumentin aktualë.

Disa skema emërtimi përdorin metoda më të kufizuara të kërkimit të shumëfishtë. Për shembull, në vend të lejimit të një liste arbitrare të konteksteve, skema emërtuese mund të kërkojë që kontekstet të renditen në shtresën e mbyllur. Kontekstet e shtresëzuara kanë qenë më herët të famshme në gjuhët programore, ku programet definojnë dhe i thirrin nën programet, sepse mund të jenë të favorshme (deri në pikën e të qenurit i padisiplinuar, e kjo është arsyeja se nuk janë më të famshme) për lejimin që nënprogrami t’i qaset sipas emrit ndryshoreve të programit të definuar apo të thirrur. Për një shembull tjetër, skema për numërimin e pikave të bashkëngjitjes së rrjetit të Internetit, ka një shtresë të jashtme publike


77

dhe një shtresë të brendshme private. Disa adresa Interneti (p.sh. të gjitha adresat me bajtin e parë 10) janë të rezervuara për përdorim në rrjetat private; ato grupe adresash përbëjnë një shtresë të brendshme private. Këto adresa të rrjetit mund të lidhen me pika të ndryshme bashkangjitëse të rrjetit, në kontekste private të ndryshme, pa pasur rrezik për konflikt. Internet adresat që janë jashtë grupit të rezervuar për kontekste private, duhet të mos lidhen në asnjë kontekst privat, ato vendosen në kontekstin publik.

Në një tërësi me kontekste të shtresëzuara, shtrirja e emrit paraqet grupin e shtresave ku emri lidhet me objektin e njëjtë. Emri që është i lidhur vetëm në shtresën më të jashtme, dhe që gjithmonë është i lidhur me objektin e njëjtë, pavarësisht shtresë sdhe kontekstit aktual të shtresëzuar, njihet si emri global. Shtresa më e jashtme që i vendos emrat globalë, është një shembull i hapësirës universale të emrit.

Rastësisht, ne kemi përdorur termin rrugë edhe si kualifikues i ndajfoljes edhe si emër, por me kuptime shumë të ndryshme. Emri i rrugës është emri që e përmban kontekstin e vet eksplicit, kurse rruga e kërkimit është kontekst që përbëhet nga një listë kontekstesh. Secili element i rrugës së kërkimit mund të jetë emër i rrugës.

Fjala “kërko” po ashtu ka një kuptim tjetër, deri diku të ndryshëm. Makinat kërkimore të Internetit si Google dhe AltaVista marrin si hyrje një formulim që përbëhet nga një apo më shumë fjalë, dhe kthejnë një listë të web faqeve që i përmbajnë ato fjalë. Rezultatet e shumëfishta (të njohura si “hits” janë rasti më i përgjithshëm, dhe Google, për shembull, implementon një sistem të sofistikuar për klasifikimin e hits-ave. Google gjithashtu ofron për përdoruesin zgjedhjen e pranimit, vetëm të hit-it më lartë të renditur (“I’m feeling lucky”) apo pranimin e një liste të radhitur sipas hit-eve. Shumica e sistemeve kompjuterik gjithashtu kanë një formë të kërkimit të fjalëve kyçe për fajllet lokalë. Kur të haset fjala e pakualifikuar “kërko”, është një ide e mirë të ndalemi dhe të pyetemi nëse kjo i referohet kërkimit të shumëfishtë apo formulimit të fjalës kyçe.

2.2.5 Krahasimi i Emrave Ashtu siç përmendëm më lartë, ngandonjëherë te emrat aplikohen një apo më shumë

operacione:

rezultati ←COMPARE ( emri1 , emri2 ) ku rezultati është një vlerë binare, TRUE apo FALSE. Kuptimi i krahasimit të emrit kërkon pak vëmendje, sepse thirrësi mund të ketë parasysh një nga tre pyetjet e ndryshme :

1. A janë të dy emrat e njëjtë? 2. A janë të dy emrat të lidhur për vlerën e njëjtë? 3. Nëse vlera ose vlerat janë, në fakt, identifikues të mbajtësëve të depove, si për

shembull celulat e memorieve apo sektorët e diskut, a janë të njëjtë përmbajtjet e mbajtësve?

Pyetja e parë është mekanikisht më e lehta për t’iu përgjigjur, sepse ka të bëjë me krahasimin e paraqitjeve të dy emrave (“A është Jim Smith njëjtë si Jim Smith?”), dhe kjo është pikërisht ajo që vendosësi i emrit e bën, kur kërkon gjëra në kontekstin e kërkimit tabelor: kërko nëpër kontekst për emrin që është i njëjti me atë që vendoset. Nga ana tjetër, në shumë situata përgjigja nuk është e levërdishme, pasi emri i njëjtë mund të lidhet me vlera të


78

ndryshme në kontekste të ndryshëm dhe dy emra të ndryshëm mund të jenë sinonime që lidhen me vlerën e njëjtë. Ajo që mund të mësojmë nga pyetja e parë është, nëse vargjet e emrit e kanë apo jo formën e njëjtë të bitave.

Për këtë arsye, përgjigja për pyetjen e dytë është shpesh më interesante. (“A është Jim Smith ai që sapo ka fituar çmimin Nobël i njëjti me Jim Smith që kam njohur në shkollë të mesme?”) Për ta marrë atë përgjigje duhen kontekste për të dy emrat, si argumente shtesë për krahasim COMPARE, ashtu që mund të vendos emrat dhe të krahasojë rezultatin. Nëse marrim shembull vendosjen e emrit të ndryshores A dhe emrin e ndryshores B mund të zbulojmë, se ato të dy janë të lidhur me adresën e njëjtë të celulës në depo. Edhe pse kjo përgjigje nuk mund të zbulojë më shumë sesa pritet pasi që të dy emrat mund të vendosen te të dy emrat e skemës emërtuese me shtresë të ulët dhe të ndryshme, këtu lind pyetja e njëjtë duhet të parashtrohet në mënyrë rekursive në lidhje me emrat e shtresës më të ulët. Për shembull, emrat e ndryshores A dhe B mund të lidhen me adresa të ndryshme të celulave në depo, por nëse memoria virtuale është në përdorim, ato adresa të ndryshme të celulave në depo mund të pasqyrohen në adresën e njëjtë fizike në celulë. (Ky shembull do të jetë më i qëlluar kur të mbërrijmë në Kapitullin 5.)

Edhe pas arritjes së fundit të rekursionit, rezultati mund të jenë emrat e dy mbajtësve të ndryshëm të depos fizike që përmbajnë kopje identike të dhënave, ose mund të jenë dy emra të ndryshëm të shtresës së ulët (që paraqet sinonim) për mbajtësin e njëjtë të depos. (“Ky fajll i biografisë së Jim Smith është identik me fajllin e biografisë së Jim Smith. A janë një apo dy fajlle të biografisë?” “Kjo biografi për Edwin Aldrin është identike me biografinë për Buzz Aldrin. A janë ato dy emra për personin e njëjtë?” ) Pra, na shfaqet pyetja e tretë, bashkë me nevojën për të kuptuar thelbin e paraqitjes fizike. Mënyra e vetme e dallimit të dy rasteve mund të jetë ndryshimi i përmbajtjeve të njërës nga mbajtëset depos së emërtuar dhe të vëzhgohet, nëse kjo shkakton që përmbajtjet e tjetrës të ndryshojnë. (“Mëshoji kësaj këtu dhe shiko nëse nxjerr klithma ajo atje.”)

Në praktikë, sistemet (dhe disa gjuhë programore) si zakonisht kanë disa operatorë COMPARE që kanë semantika të ndryshme të dizajnuara për gjetjen e përgjigjes së këtyre pyetjeve të ndryshme, dhe programuesi ose përdoruesi duhet që të kuptojë se cili operacion COMPARE është i përshtatshëm për një punë të caktuar. Për shembull, Gjuha LISP ka tre operatorë të krahasimit, të emëruar EQ (që krahason lidhjet e argumenteve të tij të emërtuar), EQU (që krahason vlerat e argumenteve të tij të emërtuar), dhe EQUALS (që krahason në mënyrë rekursive të gjitha strukturat e të dhënave.)

2.2.6 Zbulimi i Emrave Në thelb të referencës së të gjitha emrave është protokolli rekursiv që i përgjigjet

pyetjes, “Si e mësove që ta përdorësh këtë emër?” Ky protokoll për zbulimin e emrit e informon shfrytëzuesin vijues të objektit të emrit që nxjerr objekti. Zbulimi i emrit përfshin dy elemente bazike: nxjerrësi lajmëron ekzistencën e emrit, kurse shfrytëzuesi vijues kërkon për lajmin e duhur. Ajo që e bën zbulimin e emrit rekursiv është se shfrytëzuesi i emrit duhet së pari ta dijë emrin e vendit për të kërkuar për lajmin. Ky rekursion duhet të përfundojë diku, ndoshta në një komunikim direkt jashtkompjuterik ndërmjet ndonjë shfrytëzuesi të emrit dhe nxjerrësi të emrit. Rasti më i thjeshtë është me programuesin që shkruan një program me dy procedura, ku secila referon te tjetra sipas emrit. Pasi programuesi i njëjti i shkroi të dyja, zbulimi i emrit është eksplicit dhe nuk është i nevojshëm rekursioni. Më pas, të supozojmë se të dy programet janë shkruar nga dy programues të ndryshëm. Programuesi që dëshiron të përdor procedurën sipas emrit, duhet në një farë mënyre të zbulojë emrin e nxjerrë. Një mundësi


79

është që programuesi i dytë të ekzekutojë lajmin, duke thirrur emrin e procedurës së mëposhtme. Një mundësi tjetër është kur programuesi përdorues shikon në skedarin e ndarë, ku secili pajtohet të vendos procedura të ndara. Si mund që programuesi të dijë emrin e atij skedari të ndarë? Ndoshta dikush e thirri emrin më poshtë. Ose ndoshta është skedari standard i librarisë, emri i të cilit është listuar në manualin e referencës të programuesit, ku ai manual e mbaron protokollin rekursiv. Edhe pse emrat e librarisë së programit nuk shfaqen si zakonisht në lajmërimet e magazinave apo në stenda afishimi, është bërë tashmë zakon që të zbulohen emrat e web faqeve në vende të tilla. Zbulimi i emrave mund të marrë disa forma: Emri i mirënjohur: Një emër (siç është Google apo Yahoo!) që është lajmëruar aq

shumë, saqë secili mund të varet nga ai për të qenë i qëndrueshëm, për aq kohë sa është emëruar. Ekzekutimi i një emri të mirënjohur është një metodë për zbulimin e emrit.

Transmetimi: Mënyrë e lajmërimit të emrit, për shembull duke mbajtur distinktiv ku shkruan “Përshëndetje, emri im është . . .”, vendosja e emrit në afishe, apo dërgimi i tij në lista postare. Transmetimi përdoret nga protokollet e konfigurimit automatik që disa herë quhen “plug-and-play” ose “zero konfigurim”. Mund të përdoret edhe në komunikimin pikë-në-pikë me arsyetimin se është dikush që dëgjon në skajin tjetër e që do të përgjigjet. Dëgjimi i transmetuesve është metodë për zbulimin e emrit.

Pyetësori (quhet ndryshe kërkim): Paraqet një apo më shumë fjalë kyçe, për shembull makina e kërkimit si Google. Pyetësori është metodë me zbatim të gjerë për zbulimin e emrit.

Transmetimi i pyetësorit: Një formë e përgjithësuar e pyetësorit me fjalë kyçe. Pyet secilin brenda distancës dëgjuese “a e din dikush emrin për . . . ?” (disa herë gabimisht thirret “transmetimi i kundërt”).

Vendosja e emrit të një hapësire emërtuese, emrit të hapësirës tjetër emërtuese: Kërkimi i emrit në librin telefonik çon deri te zbulimi i numrit të telefonit. Sistemi i Emrave të Domeneve të Internetit, i përshkruar në Seksionin 4.4, e kryen shërbimin e njëjtë, kërkon emrin e domenit dhe kthen adresën e pikës së bashkangjitur të rrjetit.

Paraqitja: Çka ndodh me palët dhe shërbimet e takimit onlajn. Disa entitete që tashmë ju i dini, e dinë emrin dhe ua japin emrin. Në sistemin kompjuterik, shoku mund t’u dërgojë një mesazh elektronik (email) që cek emrin e një web sajti interesant apo email adresën e shokut tjetër. Një shembull tjetër. Secila web faqe kryesisht përmban paraqitje (teknikisht të njohura si hiperlinqe) për te web faqet e tjera.

Takimet fizike: Një takim i mbajtur jashtë kompjuterit. Kërkohet që të bëhen aranzhime paraprake për kohën dhe vendin që kërkon edhe komunikim paraprak, e kjo pastaj kërkon dituri paraprake të disa emrave. Pasi kjo të kryhet, takimet fizike mund të përdoren për zbulimin e emrave të tjerë, si dhe për verifikimin e autenticitetit. Shumë kompani kërkojnë që për vendosjen e llogarisë së re në sistemin kompjuterik të tyre, duhet të merret parasysh takimi fizik me administratorin e sistemit për të shkëmbyer emrat dhe për të zgjedhur fjalëkalimet.

Ciladoqoftë nga metodat e mësipërme të zbulimit të emrit do të kërkojë së pari

zbulimin e disa emrave tjerë, siç është emri i burimit të referencës për emrat e mirënjohur, emri i stendës së afishes ku vendosen transmetuesit, emri i vendosësit të emrit, emri i palës nikoqir, e kështu me radhë. Metoda e zbulimit të këtij emri tjetër mund të jetë e njëjtë me metodën e parë të thirrur, ose mund të jetë e ndryshme. Gjëja e rëndësishme që dizajnuesi duhet ta ketë parasysh është se rekursioni duhet që patjetër të përfundojë diku – nuk mund të jetë qarkor.

Atje ku është i nevojshëm emri duhet edhe ndonjë metodë për zbulimin e tij. Një ushtrim interesant është analizimi i disa shembujve të emrave të cekura në pjesët e mësipërme të këtij


80

kapitulli, duke gjurmuar rekursionin e zbulimit të emrit, për të parë se si përfundon, sepse në shumë raste përfundimi është shumë i largët nga ndodhia e përdorimit të emrit dhe vendosja që është harruar. Disa shembuj tjerë plotësues. të zbulimit të emrit do të shfaqen në kapitujt pasues: emrat e përdorur për klientët dhe shërbimet, ku klienti kërkon të zbulojë emrin e shërbimit të duhur; rrjetat për komunikimin e të dhënave, ku rrugëtimi ofron një shembull të veçantë eksplicit të zbulimit të emrit; dhe mbrojtja, ku është kritike themelimi i integritetit të hapit përfundues.

2.3 ORGANIZIMI I SISTEMIT KOMPJUTERIK ME EMRA DHE SHTRESA

Seksioni 2.1 demonstroi se si dizajnuesit e sistemit kompjuterik përdorin shtresat për implementim të më shumë versioneve të ndërlikuar të tre abstraksioneve themelore, dhe Seksioni 2.2 sqaroi se si përdoren emrat për lidhjen e komponentëve të sistemit kompjuterik. Dizajnuesit gjithashtu përdorin shtresa dhe emra në mënyra të ndryshme te sistemet kompjuterik. Figura 2.16 tregon organizimin tipik të sistemit kompjuterik me tre shtresa të dallueshme. Shtresa e poshtme përbëhet nga komponentët e harduerit, si procesori, memoriet dhe lidhjet komunikuese. Shtresa e mesme përbëhet nga tërësia e moduleve softuerike, të quajtur si sistem operativ (shiko Shiritin anësor 2.4), që i abstrahon këto resurse harduerike në ndërfaqe të programimit të aplikacioneve (API) të duhura. Shtresa e lartë përbëhet nga softuerë që implementon funksione specifike të aplikacioneve, si proceduesi i fjalëve, programi i taksave, lojërat kompjuterike, ose shfletuesit e web faqeve.

FIGURA 2.16 Sistem tipik kompjuterik i organizuar në tre shtresa. Shtresa e sistemit operativ bën tejkalim, kështu që shtresa aplikative mundet drejtpërdrejtë të thirrë disa tipare të shtresës harduerike. Megjithatë, shtresa e sistemit operativ i fsheh disa tipare të rrezikshme të shtresës harduerike.


81

Nëse mund të ekzaminojmë secilën shtresë në detaje, do të zbulojmë se edhe ato vetë janë të organizuara në shtresa. Për shembull, shtresa harduerike mund të përbëhet nga portat e shtresës së poshtme, shoshonet, dhe telat, dhe shtresa e sipërme për regjistrat, celulat e memories, dhe makinat e gjendjes fundore.

Ndarja e saktë e aktivitetit ndërmjet shtresës harduerike dhe shtresave softuerike është një ekuilibrim inxhinierik dhe një temë me debat të konsiderueshëm ndërmjet dizajnuesve harduerik dhe atyre softuerik. Në princip, çdo modul softuerik mund të implemenohet në harduer. Ngjashëm, shumë nga modulet harduerike gjithashtu mund të implementohen në softuer, përveç disa komponentëve bazikë, siç janë transistorët dhe telat. Është tepër e vështirë të përcaktohet një princip gjenerik, sesi të vendoset ndërmjet një implementimi në harduer ose softuer. Kostoja, performansa, fleksibiliteti, përshtatshmëria, dhe forma e përdorimit janë ndër faktorët që janë pjesë e ekuilibrimit, por për çdo funksion individual ato mund të peshojnë ndryshe. Në vend të përpjekjes për shpikjen e principit, ne diskutojmë ekuilibrin ndërmjet harduerit dhe softuerit, në kontekst të funksioneve specifike.

Shtresa e sistemit operativ zakonisht shfaq një fenomen interesant që mund ta quajmë tejkalim shtresor. Në vend të fshehjes komplete të shtresës së poshtme harduerike, sistemi

Shiriti anësor 2.4 Çka është Sistemi Operativ? Sistemi operativ është një tërësi programesh dhe librarish që e bëjnë të lehtë punën e shfrytëzuesve dhe programuesve. Në fazat e hershme të kompjuterit, sistemet operative ishin programe të thjeshta që ndihmonin operatorët e kompjuterëve (në atë kohë shfrytëzuesit e vetëm që ndërvepronin me kompjuterin direkt), prej të cilëve quhen edhe sisteme operative. Sot sistemet operative vijnë me shumë shije dhe ndryshojnë, për nga funksioni që ato ofrojnë. Sistemi operativ për kompjuterët më të thjeshtë, siç është furra me mikrovalë, mund të përbëhet nga një librari që i fsheh detajet harduerike, me qëllim që ta bëjë të lehtë për programuesit e aplikacioneve të zhvillojnë aplikacione. Kompjuterët personal, nga ana tjetër, shiten me sistem operativ që përmban dhjetëra miliona rreshta kodi. Këto sisteme operative mundësojnë që disa njerëz ta përdorin kompjuterin e njëjtë; lejojnë që shfrytëzuesit të kontrollojnë cili informacion ndahet dhe me cilin; mund të ekzekutojë disa programe në të njëjtën kohë, duke i mbajtur ato larg përzierjes me njëri-tjetrin; ofrojnë ndërfaqe të sofistikuar të shfrytëzuesit, qasje në Internet, sisteme fajllash, aplikacione për ruajtje dhe arkivim, programe për pajisjet për shumë harduerë të bashkangjitur në kompjuterë (ang. Drivers), dhe një mori abstraksionesh për thjeshtëzimin e punës së programuesit të aplikacioneve, etj. Sistemet operative gjithashtu ofrojnë një rast studimor shumë interesant të dizajnimit të sistemeve. Ato zhvillohen shumë shpejtë, si rezultat i kërkesave të reja. Dizajnuesit e tyre ballafaqohen me betejën e vazhdueshme për ta kontrolluar kompleksitetin e tyre. Disa sisteme operative moderne kanë ndërfaqe që përbëhen nga mijëra procedura, dhe implementimi i tyre është shumë kompleks, gë që e bën një sfidë të vërtetë punën e tyre të besueshme. Ky libër ka shumë për të thënë për sistemet operative, duke filluar nga Seksioni 5.1.1, i cili fillon me zhvillimin e një modeli minimal të sistemit operativ.


82

operativ zakonisht i fsheh vetëm disa tipare të shtresës harduerike, siç janë instruksionet e caktuara të rrezikshme. Tiparet e mbetura të shtresës harduerike (në veçanti, shumica e repertorit të instruksioneve të procesorit) kalojnë nëpër shtresën e sistemit operativ për përdorim direkt nëpërmjet shtresës aplikative, si në Figurën 2.16. Kështu që, instruksionet e rrezikshme mund të përdoren vetëm nga shtresa e sistemit operativ dhe shtresat aplikative. Si koncept, dizajnuesi mund t’i vendos gjërat ashtu që shtresa e sistemit operativ ndërmjetëson në çdo thirrje të shtresës harduerike, nga shtresa aplikative dhe pastaj në mënyrë eksplicite e thirrë shtresën harduerike. Ai dizajn do ta ngadalësonte ndërfaqen e përdorur tejmase në mënyrë të papranueshme, ndërsa në implementimin e zakonshëm, shtresa aplikative drejtpërdrejt e thirr shtresën harduerike,duke tejkaluar tërësisht (kapërcyer) shtresën e sistemit operativ. Sistemet operative mundësojnë tejkalim për arsye të performancës, por tejkalimi nuk është unik për sistemet operative, ashtu siç nuk përdoret vetëm për përfitim të performancës. Për shembull, Interneti është sistem komunikimi i shtresëzuar që lejon tejkalim të shumë tipareve, nga shumica e shtresave të tij, me qëllim të arritjes së fleksibilitetit.

Në këtë seksion po ekzaminojmë dy shembuj të organizimit të sistemit të shtresëzuar kompjuterik: shtresën harduerike në fund të sistemit kompjuterik të zakonshëm dhe një pjesë të shtresës së sistemit operativ që krijon ndërfaqen tipike të programimit të aplikacioneve, e njohur si sistem i fajllave.

2.3.1 Shtresa Harduerike: Magjistralja Shtresa harduerike e sistemit tipik është konstruktuar nga module që drejtpërdrejtë

implementojnë versione të nivelit të ulët të tre abstraksioneve bazike. Në shembullin te Figura 2.17, modulet e procesorit i interpretojnë programet, modulet e memories me qasje direkt i ruajnë edhe programet edhe të dhënat, dhe modulet për hyrje/dalje (I/O) implementojnë lidhje komunikuese për botën jashtë kompjuterit.

Ekzistojnë disa shembuj për secilin modul harduerik – procesorët e shumëfishtë (ndoshta disa në një çip, një organizim i njohur si shumëbërthamor), memoriet e shumëfishta, dhe disa lloje modulesh I/O. Një vëzhgim i afërt i I/O moduleve na sjell te interpretuesit e specializuar që implementojnë I/O programe. Kështu, kontrolluesi i diskut është interpretues i programeve I/O në disk. Disa detyra janë pasqyrimi i adresave të diskut për te gjurmimi dhe numrat e sektorëve, dhe zhvendosja e të dhënave nga disku në memorie. Kontrolluesi i rrjetit është një interpretues që flet për pjesën tjetër të një apo më shumë lidhjeve të vërteta komunikuese. Kontrolluesi i ekranit interpreton listat e ekranit që i gjen në memorie dhe pikselat ndriçues në ekranin ku shfaqen. Ora nuk është asgjë tjetër, por një interpretues i vockël që vazhdimisht e përditëson regjistrin e vetëm me kohën për ditët e caktuara.

Modulet e ndryshme lidhen në magjistralen e ndarë, e cila është një lidhje tepër e specializuar për komunikim dhe për dërgim (SEND) të mesazheve te modulet e tjera. Ekzistojnë disa dizajnime të magjistraleve, por ato i kanë disa tipare të përbashkëta. Një tipar


83

i tillë është tërësia e telave‡ që përbëjnë adresën, të dhënat, dhe linjat kontrolluese që lidhen me ndërfaqen e magjistrales në secilin modul.

FIGURA 2.17

Një kompjuter me disa module të lidhura me një magjistrale të ndarë. Numrat paraqesin adresat e magjistrales që i përgjigjen modulit të bashkangjitur.

Për arsye se magjistralja është e ndarë, tipari i dytë i përbashkët është tërësia e rregullave, për të vendosur se cili modul mund të dërgojë apo pranojë mesazh në cilëndo kohë, e quajtur si protokolli për gjykimin e magjistrales,. Disa magjistrale kanë edhe një modul plotësues, gjyqtarin e magjistrales, një qark apo një interpretues i hollë që zgjedh se cili nga modulet garuese do ta përdor magjistralen. Në dizajnimet e tjera, gjykimi është funksion i shpërndarë ndërmjet ndërfaqeve të magjistrales. Ashtu siç ekzistojnë shumë dizajnime të magjistraleve, ashtu ekzistojnë disa protokole për gjykim të magjistrales. Një shembull i veçantë dhe i njohur i magjistrales është UNIBUS®, i futur në përdorim në vitet e 70-ta të shekullit të kaluar nga Digital Equipment Corporation. Modulariteti i ofruar nga magjistralja e ndarë me protokoll standard për gjykim, ndihmoi në riformulimin e industrisë kompjuterike, siç është përshkruar në Shiritin anësor 1.5.

Tipari i tretë i përbashkët në dizajnimin e magjistrales është lidhja për transmetim, që nënkupton se çdo modul i bashkangjitur me magjistralen dëgjon çdo mesazh. Meqë shumica e mesazheve janë të destinuara për vetëm një modul, fusha e mesazhit e quajtur adresa e magjistrales e identifikon pranuesin e destinuar. Ndërfaqja e magjistrales për secilin modul është konfiguruar për t’iu përgjigjur një tërësie të caktuar të adresave të magjistrales. Secili modul ekzaminon fushën e adresës së magjistrales (që në magjistralen paralele zakonisht kryhet në një tërësi me tela, të ndara nga pjesa tjetër e mesazhit) për secilin mesazh dhe injoron çdo mesazh që nuk është i destinuar për të. Adresat e magjistrales e definojnë hapësirën e adresës. Figura 2.17 tregon se dy procesorë mund të pranojnë mesazhe te adresa e magjistrales 101 dhe 102, respektivisht; kontrolluesi i ekranit te adresa e magjistrales 103; ‡ Përshkrimi për disa tela paralele është i një strukture e quajtur magjistrale paralele. Një diskutim më i gjërë për protokollet e lidhjes së komunikimit në Seksionin 7.3 [onlajn] tregon se si magjistralja mundet gjithashtu të implementohet duke dërguar sinjale të koduara me disa tela, skemë e quajtur magjistrale serike.


84

kontrolluesi i diskut te adresa e magjistrales 104 dhe 105 (duke u përdorur dy adresa bëhet më i përshtatshëm dallimi i kërkesave për dy disqet e tij); rrjeta te adresa e magjistrales 106; tastiera te adresa e magjistrales 107; dhe ora te adresa e magjistrales 109. Për shpejtësinë, modulet e memories zakonisht janë të konfiguruara me një interval të adresave të magjistrales, me një adresë të magjistrales për një adresë të memories. Kështu që, nëse në Figurën 2.17 dy modulet e memories implementojë secili një hapësirë adresuese me 1024 adresa, ato mund të konfigurohen me adresat e magjistrales 1024-2047 përkatësisht 3072-4095§.

Çdo modul i magjistrales që dëshiron të dërgojë mesazh nëpërmjet magjistrales duhet që ta dijë adresën e magjistrales, të cilën pranuesi i destinuar është i konfiguruar ta pranojë. Zbulimi i emrit në disa magjistrale është tepër i thjeshtë: cilido e vendos sistemin në mënyrë eksplicite. E konfiguron njohurinë e adresës së magjistrales në softuerin e procesorit, dhe softueri e kalon këtë njohuri, së bashku me modulet e tjera, në mesazhin që e dërgon nëpërmjet magjistrales. Dizajnimet e tjera të magjistrales në mënyrë dinamike e bashkëngjisin adresën e magjistrales te modulet e lidhura në magjistrale dhe e lajmërojnë praninë e tyre.

Një dizajn i përbashkët njihet si ndarje-transaksioni. Në këtë dizajn, kur një modul dëshiron të komunikojë me tjetrin, moduli i parë e përdor protokolin për gjykim të magjistrales në telat kontrollues për të kërkuar përdorim ekskluziv të magjistrales për mesazhin. Pasi e ka atë përdorim ekskluziv, moduli e vendos adresën e magjistrales së modulit të destinuar në telat e adresës dhe mesazhin e mbetur në telat e të dhënave. Të supozojmë një dizajn ku magjistralja dhe modulet e bashkangjitur në të, ekzekutohen në orë të pakoordinuara (pra janë asinkron), pastaj sinjalizojnë një nga telat kontrollues (të quajtur READY) për të informuar modulet e tjera se ekziston një mesazh në magjistrale. Atëherë kur moduli pranues njofton se një nga adresat e tij është në linjat adresuese të magjistrales, e kopjon atë adresë dhe mesazhin e mbetur në telat e të dhënave në regjistrat e tij lokal, pastajsinjalizon në linjën tjetër kontrolluese (e quajtur ACKNOWLEDGE) për t’i treguar dërguesit se është sigurt që magjistralja të lirohet për përdorim nga modulet e tjerë. (nëse magjistralja dhe modulet, të gjitha, ekzekutojnë me një orë të përbashkët, linjat READY dhe ACKNOWLEDGE nuk nevojiten; por, secili modul e kontrollon linjën e adresës në çdo cikël të orës.) Pastaj, pranuesi e inspekton adresën dhe mesazhin dhe e ekzekuton operacionin e kërkuar, që mund të përfshijë dërgimin e një apo më shumë mesazheve, prapa te moduli kërkues origjinal ose, në disa raste, edhe te modulet e tjera.

Për shembull, të supozojmë se procesori #2, duke interpretuar një program aplikativ që ekzekutohet, has në instruksionin:

LOAD 1742, R1 që nënkupton “ngarko përmbajtjen e adresës së memories 1742 në regjistrin R1 të procesorit”. Në skemën më të thjeshtë, procesori vetëm i përkthen adresat që i gjen në § Këto adresa të magjistrales zgjidhen për ta bërë më të qartë ilustrimin. Në praktikë, moduli i memories më shumë konfigurohet me mjaft adresa të magjistrales për të përshtatur disa gigabajt. .


85

instruksione, drejpëtrdrejt në adresat e magjistrales, pa ndryshime. Pastaj e dërgon këtë mesazh nëpër magjistrale: procesori #2 të gjitha modulet e magjistrales: {1742, READ, 102}

Ky mesazh përbëhet nga tre fusha. Fusha e parë e mesazhit (1742) është njëra nga adresat e magjistrales, së cilës i përgjigjet memoria #1; fusha e dytë e mesazhit kërkon që pranuesi të ekzekutojë operacionin READ; dhe e treta tregon se pranuesi duhet të dërgojë vlerën e fituar prapa nëpër magjistrale, duke përdorur adresën e magjistrales 102. Adresat e memories të njohura nga secili modul i memories bazohen në fuqinë me bazë 2, kështu që modulet e memories mund ti dallojnë të gjitha adresat në intervalin e tyre duke ekzaminuar vetëm disa bite të adresave të shkallës së lartë. Në këtë rast, adresa e magjistrales është përbrenda intervalit të njohur nga moduli 1 i memories, dhe moduli përgjigjet duke kopjuar mesazhin në regjistrat e tij. Pastaj e vërteton kërkesën, procesori e liron magjistralen, dhe moduli i memories pastaj e ekzekuton operacionin e brendshëm

vlera ← READ (1742)

Duke pasur vlerën, moduli i memories tani vetë i qaset magjistrales dhe e dërgon mesazhin prapa te procesori #2 duke ekzekutuat operacionin e magjistrales

memoria #1 të gjitha modulet e magjistrales: {102, vlera} ku 102 është adresa e magjistrales së procesorit të furnizuar në mesazhin e kërkesës origjinale READ. Procesori, i cili është duke pritur për këtë rezultat, njofton se linjat e adresës së magjistrales tani përmbajnë adresën e tij 102 të magjistrales. Për këtë qëllim e kopjon vlerën nga linjat e të dhënave në regjistrin e tij R1, ashtu siç kërkoi edhe instruksioni origjinal i programit. Më tej vërtetohet pranimin e mesazhit, dhe moduli i memories e liron magjistralen për t’u përdorur nga modulet e tjera. Pajisjet e thjeshta I/O, si tastiera, operojnë në mënyrën e njëjtë. Gjatë kohës së fillimit të sistemit, një nga procesorët dërgon (SEND) mesazh te kontrolluesi i tastierës, për ta njoftuar që t’i dërgojë (SEND) të gjitha shtypjet e tastierës në procesor. Sa herë që shfrytëzuesi e shtyp butonin, kontrolluesi i tastierës e dërgon mesazhin në procesor me të dhënën e emrit të tastierës që u shtyp. Në këtë rast, procesori nuk e pret këtë mesazh, por ndërfaqja e tij e magjistrales (që është një interpretues i veçantë që ekzekutohet në mënyrë konkurruese me procesorin) njofton se mesazhi me adresën e tij të magjistrales është shfaqur. Ndërfaqja e magjistrales e kopjon të dhënën nga magjistralja në regjistrin e përkohshëm, e vërteton mesazhin, dhe dërgon sinjal te procesori, se do të stimulojë procesorin të ekzekutojë një ndërprerje në ciklin e tij të ardhshëm të instruksionit. Manovruesi i ndërprerjes, pastaj e transferon të dhënën nga regjistri i përkohshëm në disa lokacione që e mbajnë hyrjen e tastierës, ndoshta duke dërguar edhe një mesazh tjetër nëpër magjistrale, te modulet e tjera të memories. Një problem i mundshëm i këtij dizajni është se manovruesi i ndërprerjes duhet që patjetër të përgjigjet dhe lexojë të dhënat e shtypura nga tastiera, nga regjistri i përkohshëm përpara se manovruesi i tastierës të dërgojë (SEND) një mesazh tjetër të shtypur. Meqë shtypja e butonave është e ngadalshme, në krahasim me shpejtësinë e kompjuterit, ekziston një shans i mirë që manovruesi i ndërprerjes të gjendet aty në kohë për të lexuar të dhënat përpara se shtypja e ardhshme t’i mbishkruaj ato. Megjithatë, pajisjet më të shpejta, siç është disku i ngurtë, mund ta mbishkruajnë regjistrin e përkohshëm. Një zgjidhje do të ishte të shkruhet program që ekzekuton në cikle shumë të ngushta, duke pritur për të dhënat që


86

kontrolluesi i diskut i dërgon nëpër magjistrale për t’i dërguar menjëherë (SEND) ato të dhëna përsëri nëpër magjistrale, te moduli i memories. Disa dizajnime të kompjuterëve me mbarim të ulët e bëjnë pikërisht këtë, por dizajnuesi mund të arrijë në thelb performancë të lartë, duke mbindërtuar kontrolluesin e diskut për të përdorur një teknikë të quajtur qasja e drejtpërdrejtë e memories, ose DMA. Me këtë teknikë, kur procesori dërgon (SEND) kërkesë deri te kontrolluesi i diskut, për të lexuar (READ) bllokun me të dhëna nga disku, e përfshin adresën në bafer të memories, si fushë të mesazhit të kërkuar. Pastaj, duke rrjedhë të dhënat nga disku, kontrolluesi i diskut i dërgon drejtpërdrejt te moduli i memories, duke e rritur adresën e memories nëpërmjet dërgimeve (SEND). Përveç lehtësimit të ngarkesës për procesorin, DMA po ashtu e redukton ngarkesën te magjistralet e ndara sepse e transferon secilën pjesë nëpër magjistrale vetëm njëherë (nga kontrolluesi i diskut në memorie) dhe jo dy herë (së pari nga kontrolluesi i diskut në procesor dhe pastaj nga procesori në memorie). Gjithashtu, nëse magjistralja toleron mesazhe të gjata, kontrolluesi i DMA mund të jetë në gjendje të arrijë përparësi nga ai tipar, më shumë sesa procesori, që zakonisht dizajnohet për të dërguar (SEND) dhe pranuar (RECEIVE) të dhënat e magjistrales në njësi që janë të së njëjtës madhësi, si te regjistrat e tij. Duke dërguar mesazhe të gjata, kontrolluesi i DMA e rrit performancën, sepse e amortizon pjesën e sipërme të protokollit për gjykim të magjistrales, që duhet patjetër njëherë ta ekzekutoj për një mesazh të caktuar. Së fundmi, DMA lejon që procesori të ekzekutojë disa programe tjera në të njëjtën kohë që kontrolluesi i diskut transferon të dhënat. Pasi që operacioni konkurrent mund të fsheh gjendjen latente të transferim të diskut, mund ta përmirësojë plotësisht performancën. Ideja e përmirësimit të performancës, duke fshehur gjendjen latente diskutohet në Kapitullin 6. I/O të pasqyruar në memorie mund të kombinohen me DMA. Për shembull, supozojmë se kontrolluesi i diskut i dizajnuar për I/O, të pasqyruar në memorie, e merr adresën e magjistrales deri në katër regjistrat e tij kontrollues si më poshtë: adresa e magjistrales regjistri kontrollues 121 numri_sektorit 122 DMA_adresa_startuese 123 DMA_numëruesi 124 kontroll Për të realizuar I/O në disk, procesori i përdor instruksionet RUAJ (STORE), për të dërguar (SEND) vlerat përkatëse të fillimit te tre regjistrat për kontrollin e diskut dhe një instruksion final STORE për dërgimin e vlerës që vendos bitin në regjistrin kontroll të cilin kontrolluesi i diskut e interpreton si sinjal për fillim. Programi për të MARRË (GET) një sektor prej 256 bajtësh që është aktualisht i ruajtur në sektorin me numër 11742 dhe i cili i transferon të dhënat në memorien që fillon me lokacionin 3328, fillon duke ngarkuar katër regjistra me këto vlera dhe pastaj lëshon një STORE të regjistrave te adresat përkatëse të magjistrales: R1← 11742; R2←3328; R3←256; R4←1; STORE 121, R1 // përcakton numrin e sektorit STORE 122, R2 // përcakton regjistrin e adresës së memories STORE 123, R3 // përcakton numërimin e bajteve STORE 124, R4 // fillon ekzekutimi i kontrolluesit të diskut Pas kompletimit të instruksionit SEND të magjistrales i gjeneruar nga instruksioni i fundit STORE, kontrolluesi i diskut, që paraprakisht ishte i jo aktiv, hidhet në aksion, e lexon sektorin e kërkuar nga disku në baferin e brendshëm, dhe fillon përdorimin e DMA për


87

transferimin e përmbajtjes së buferit në memorie, bllok pas blloku. Nëse magjistralja mund t’i manovrojë blloqet që janë nga 8 bajte, kontrolluesi i diskut do të dërgojë (SEND) një seri mesazhesh të magjistrales si kontrolluesi i diskut #1 të gjitha modulet e magjistrales: {3328, blloku[1]} kontrolluesi i diskut #1 të gjitha modulet e magjistrales: {3336, blloku[2]} etj . . I/O të pasqyruara në memorie paraqet një ndërfaqe të njohur, pasi jep një ndërfaqe uniforme të memories LOAD dhe STORE për secilin modul të magjistrales ku implementohet. Nga ana tjetër, dizajnuesi duhet të jetë i vëmendshëm gjatë përpjekjes së zmadhimit tej mase të modelit të pasqyrimit të memories. Për shembull, përpjekja që procesori të adresojë direkt bajte individuale apo fjalë në diskun magnetik, mund të jetë problematike në sistemin e hapësirën adresuese 32 bitëshe, sepse disku me kapacitet 4 gigabajt do të ta zë të gjithë hapësirën e adresimit. Më tutje, gjendja latente e diskut është tepër e madhe krahasuar me kohën e ciklit të procesorit. Instruksionit STORE do të operojë disa herë në nanosekonda (kur adresa është në memorien elektronike) dhe disa herë kërkon 10 milisekonda për të përfunduar (kur adresa është në disk), e kjo do të ishte e pa pritshme dhe do ta bëjë të vështirë shënimin e programeve që kanë performancë të parashikueshme. Veç kësaj, do ta thyej rregullën bazike të inxhinieringut njerëzor, principin e çudisë më të vogël (shiko Shiritin anësor 2.5). Tiparet fizike të diskut magnetik e bëjnë modelin e qasjes DMA më të përshtatshëm sesa modeli i pasqyrimit I/O në memorie.

Shiriti anësor 2.4 Inxhinieringu Human dhe Principi i Çudisë më të Vogël Një princip i rëndësishëm për inxhinieringun human për përdorim, i cili për disa sisteme kompjuterike nënkupton lehtësi për dizajnim, lehtësi për përdorim, lehtësi për të programuar, dhe lehtësi për mirëmbajtje, e ky është principi i çudisë më të vogël.

Principi i çudisë më të vogël Njerëzit janë pjesë e sistemit. Dizajni duhet të përafrojë përvojën e shfrytëzuesit, pritjet,

dhe modelet mentale. Qeniet njerëzor bëjnë modele mentale të sjelljes nga gjithçka që ato hasin: komponentë, ndërfaqe, dhe sisteme. Nëse komponenti aktual, ndërfaqja, apo sistemi e ndjekin atë model mental, do të ketë një shans më të mirë që të përdoret si i destinuar dhe më pak shans që keqpërdorimi apo keqkuptimi të çojë deti në gabim apo shqetësim. Meqë kompleksiteti është relativ ndaj kuptimit, principi gjithashtu tenton të ndihmojë reduktimin e kompleksitetit. Për këtë arsye, kur të zgjedhim ndërmjet disa alternativave, është më mirë të zgjedhim atë që është më i përafërt me pritjet e atyre që do t’i përdorin, aplikojnë, apo mirëmbajnë sistemin. Principi duhet të jetë edhe faktor gjatë vlerësimit të ekuilibrimeve.Ai aplikohet në të gjitha aspektet e dizajnimit sistemor, veçanërisht në dizajnimin e ndërfaqeve humane dhe në sigurinë kompjuterike. Duhet të theksohen disa konkluza: Bëju i qëndrueshëm! Bëju i parashikueshëm! Minimizoji efektet anësore! Përdor emra që përshkruajnë!. Bëji gjërat e qarta! Ofro interpretime të arsyeshme për të gjitha hyrjet e arsyeshme! Shmangi ndryshimet e panevojshme! Disa autorë i preferojnë fjalët “principi i surprizës më të vogël” në vend të “principi i çudisë më të vogël”. Kur staticienët e Bajesit e përdorin principin e surprizës më të vogël, ato nënkuptojnë “zgjidhe sqarimin më të mundshëm”, një version i përafërt i briskut të Occam-it. (Shikojeni aforizmin në faqen 9.)

(shiriti vazhdon)


88

2.3.2 Shtresa Softuerike: Abstraksioni i Fajllave

2.3.2 Shtresa Softuerike: Abstrahimi i Fajllit

Shtresat e mesme dhe të sipërme të sistemit kompjuterik zakonisht implementohen si module softuerike. Për ta bërë ma konkrete organizimin e shtresave, të konsiderojmë fajllin, një

Shiriti anësor 2.4 Inxhinieringu Human dhe Ligji Origjinal i Marfit. Nëse e pyetni një grup njerëzish “Çka është ligji i Marfit?” shumë nga përgjigjet do të ishin si: “nëse diçka mund të bëhet keq, do të bëhet”, duke u pasuar nga shumë të ngjashme, si: “tosti gjithmonë e derdh gjalpin poshtë”. Në fakt, Marfi në fillim tha diçka krejt ndryshe. Ndryshe nga komenti me natyrë çoroditëse të objekteve pa jetë (disa herë të njohur si ligji i Finaglit, nga një tregim nga fanta-shkenca), Marfi komentonte një tipar të natyrës njerëzore që duhet pasur parasysh gjatë dizajnimit të sistemeve komplekse: Nëse dizajnoni ashtu që të montohet gabimisht, dikush do ta montojë gabim. Marfi e vuri theksin te dituria e inxhinieringut të mirë human të gjërave që duhen montuar: dizajnoiashtu që mënyra e vetme për t’i montuar ato është mënyra më e drejtë. Eduard A. Marfi, Jr., ishte një inxhinier që punoi në eksperimentin e raketave të Forcave Ajrore të Shteteve të Bashkuara në bazën Edward Air Force në 1949, ku majori John Paul Stapp vullnetarisht u përcaktua të jetë pjesë e frenimeve ekstreme (40 Gs) për përcaktimin e limitit të tolerancës njerëzore, për dizajnimin e hedhjes së karrikes. Në një nga eksperimentet, dikush i lidhi të gjitha shkallët e tendosjes, ashtu që në fund të eksperimentit të Stapp-it nuk mbeti asnjë e dhënë e përdorshme. Marfi u tërbua nga tekniku që i lidhi nyjet e tendosjes dhe tha “nëse ai djali mund ta gjejë mënyrën për ta bërë gabim, do ta bëjë”. Stapp, i cili kishte hobi të formulojë ligje, e pagëzoi këtë observim “Ligji i Marfit”, dhe pothuajse menjëherë filloi t’u tregojë të tjerëve në formë të ndryshme e që tash gjerësisht është e njohur “nëse diçka mund të bëhet keq, do të bëhet”. Një shembull i mirë i observimit origjinal të Marfit, në vepër u tregua në një incident në aeroplanin kargo Convair 580 në vitin 1997. Dy kabllo identike të kontrollit dolën nga kontrolli i kabinës në ngritësin e bishtit, një sipërfaqe e vogël e lëvizshme në fund të avionit që i stabilizon krahët, kur lëvizet lartë apo poshtë dhe bën që pjesa e përparme (hunda) e avionit të ngjitet apo të ulet, respektivisht. Pasi fluturoi për herë të parë pas rregullimit të avionit, pilotët zbuluan se avioni lëkundet me hundën përpjetë. Ato u përpoqën ta rregullojnë ngritësin e bishtit në maksimum duke ulur hundën poshtë, por problemi u bë më serioz. Pas një përpjekje të madhe ato ia arritën ta ulin avionin pa probleme. Kur mekanikët e ekzaminuan avionin, ato zbuluan se dy kabllot e bishtit ishin shkëmbyer, ashtu që lëvizja e kontrollit sipër shkaktoi që bishti të ulet poshtë dhe e kundërta*. Seri të ngjashme me incidente në 1988 dhe 1989 përfshinë lidhjet e kryqëzuara të telave për sinjalizimin e alarmit të duhanit dhe telave të shuarjes së zjarrit në avionët Boeing 737, 757, dhe 767†. *Bordi i Sigurisë së Transportit i Kanadasë, Report A97O0077, 13 Janar, 2000, ndryshuar më 6 Tetor, 2002. †Karen Fitzgerald, “Boeing’s crossed connections”, IEEE Spectrum 26, 5 (May 1989), faqet 30–35.


89

version të nivelit të lartë të abstraksionit të memories. Fajlli përmban një varg bitesh apo bajtesh, numrin e të cilëve e zgjedh aplikacioni. Fajlli i ka dy tipari kyçe:

Është i qëndrueshëm. Informacioni, pasi të ruhet, do të mbetet i padëmtuar përgjatë fikjeve të sistemit dhe mund të thirret përsëri, mbase pas një jave apo muaji. Aplikacionet i përdorin fajllet për t’i ruajtur më gjatë dokumentet, të dhënat e pagesave, mesazhet elektronike, programet, dhe gjithçka tjetër që duan që mos humbet.

Ka një emër. Emri i fajllit mundëson që shfrytëzuesit dhe programet të ruajnë informacion në atë mënyrë që ato mund ta gjejnë dhe përdorin atë përsëri më vonë. Emrat e fajllave po ashtu iu mundësojnë shfrytëzuesve të shpërndajnë informacionin. Mund të shënojmë (WRITE) në fajllin e emërtuar dhe t’i tregojmë shokut emrin e fajllit, dhe pastaj shoku mund ta përdor emrin që ta lexojë (READ) fajllin.

Marrë së bashku, këto dy tipare nënkuptojnë se nëse, për shembull, Alice krijon një fajll të ri me emrin “plani strategjik”, shkruan (WRITE) disa informacione në të, e fik kompjuterin, dhe ditën e nesërme e hap kompjuterin përsëri, ajo do të mundet që ta lexojë (READ) fajllin me emrin “plani strategjik” dhe ta ketë në dispozicion përsëri përmbajtjet e saj. Më tutje, ajo mund t’i kërkojë Bob-it t’i hedh një sy fajllit me emrin “plani strategjik”. Kur Bob-i e pyet sistemin të lexojë (READ) fajllin me atë emër, ai do ta lexojë fajllin që ajo ka krijuar. Shumë nga fajll sistemet poashtu kanë edhe tipare tjera plotësuese për fajllet, siç janë koha se kur janë krijuar, ndryshimiet e fundit, apo përdorimi i fundit, garancia për qëndrueshmërinë e tyre (një temë që e trajton përsëri Kapitulli 10 [onlajn]), dhe mundësia e kontrollimit të ndarjes së tyre (një nga temat e Kapitullit 11 [onlajn]).

FIGURA 2.18

Përdorimi i abstraksionit të fajllit për implementimin e programit dalës, i cili po ashtu i shënon edhe hyrjet e tastierës në fajll. Për ta bërë më të qartë, ky program e injoron mundësinë që cilido primitiv i abstraksionit të fajllit mund të kthejë një status gabimi.

Një API tipik për abstraksionin e fajllit përmban thirrje për hapjen (OPEN) e fajllit, për lexim (READ) dhe shkrim, (WRITE) si dhedhe për ta mbyll (CLOSE) fajllin. Thirrja

character buf // bafer për karakterin hyrës fajlli ←OPEN ("plani strategjik", READWRITE) // hapet fajlli për lexim dhe shkrim hyrje←OPEN ("tastiera", READONLY) // hapet pajisja e tastierës për lexim dalje ← OPEN ("ekrani", WRITEONLY) // hapet pajisja e daljes për shkrim while not END_OF_FILE (hyrje) do READ (hyrje, buf, 1) // lexo 1 karakter nga tastiera WRITE (fajlli, buf, 1) // ruaje hyrjen në fajll WRITE (dalje, buf, 1) // shfaqe hyrjen CLOSE (fajlli) CLOSE (hyrje) CLOSE (dalje)


90

OPEN përkthen emrin e fajllit në një emër të përkohshëm në hapësirën lokale të emërtimit për t’u përdorur nga operacionet READ dhe WRITE. Gjithashtu, OPEN kontrollon nëse këtij shfrytëzuesi i lejohet qasja në fajll. Ashtu si edhe në hapin e fundit, OPEN e vendos kursorin, që disa herë quhet tregues i fajllit, në zero. Kursori regjistron një zhvendosje nga fillimi i fajllit për t’u përdorur si pikë fillestare për leximet (READ) dhe shkrimet (WRITE). Disa dizajnime të sistemeve të fajllave kanë kursorë të veçantë për lexim dhe shkrim, në të cilin rast OPEN mund ta nis kursorin WRITE te numri i bajteve të fajllit.

Thirrja te READ i jep thirrësit një numër specifik të bajteve nga fajlli, duke filluar nga kursori READ: Poashtu i shton kursorit READ numrin e bajteve të lexuar, ashtu që READ i ardhshëm vazhdon atje ku ka mbetur READ paraprak. Nëse programi kërkon që të lexojë bajtet përtej fundit të fajllit, READ kthen një lloj të indikatorit të statusit fundi-i-fajllit.

Në mënyrë të ngjashme, operacioni WRITE merr si argument baferin me bajte dhe gjatësi, i ruan ato bajte në fajll, duke filluar te zhvendosja e treguar nga kursori i WRITE (nëse kursori WRITE fillon apo e arrin fundin e fajllit, WIRTE zakonisht do të bëj zmadhimin e madhësisë se fajllit), dhe i shton kursorit WRITE numrin e bahteve të shënuara ashtu që WRITE pasues mund të vazhdojë që aty. Nëse nuk ka hapësirë të mjaftueshme në pajisje për shkrim të këtyre bajteve, procedura WRITE dështon duke kthyer një lloj të statusit me gabim, pajisja-e-mbushur apo përjashtim.

Më në fund, kur programi të mbaroj së lexuari dhe shkruari, e thërret procedurën CLOSE. Kjo procedurë e liron çdo gjendje që e ka sistemi i fajlleve (për shembull, kursorët dhe shënuesi i emrit të përkohshëm të fajllit, që tashmë është i pakuptimtë). Disa sisteme të fajllave po ashtu mundësojnë që, kur kthehet CLOSE, të gjitha pjesët e ndryshuara të fajllit janë ruajtur të qëndrueshëm, në pajisjen e memories së qëndrueshme. Sistemet e tjera të fajlleve e ekzekutojnë këtë operacion në prapavijë pasi të kthehet CLOSE.

Moduli i sistemit të fajllit e implementon fajllin API duke pasqyruar bajtet e fajllit në sektorët e diskut. Për secilin fajll sistemi i fajllit krijon një regjistrues të emrit të fushës dhe sektorëve të diskut, ku është ruajtur fajlli. Sistemi i fajllit po ashtu e ruan këtë regjistrues në disk. Kur të ristartohet sistemi, sistemi i fajlleve duhet që ta zbulojë vendin ku i ka lënë këto regjistrues, ashtu që të mund t’i gjejë përsëri fajllet. Procedura tipike për zbulimin e emrit është që sistemi i fajlleve të rezervojë një sektor shumë të njohur të diskut si numri 1 i sektorit, dhe ta përdorë atë sektor të njohur, si lokacion për gjetjen e sektorëve ku i ka lënë informacionet e mbetura të sistemit të fajlleve. Një përshkrim i detajuar i sistemit të fajlleve API të UNIX-it dhe implementimi i tij është dhënë në Seksionin 2.5.

Mund të parashtrojmë pyetjen përse fajlli API i mbështet OPEN dhe CLOSE në vend të READ dhe WRITE? Para së gjithash, mund të pyesim programuesin që ta kalojë emrin e fajllit dhe zhvendosjen e pozitës së fajllit në çdo thirrje READ dhe WIRTE. Arsyeja është se procedurat OPEN dhe CLOSE shënojnë fillimin dhe fundin e sekuencës së operacioneve READ dhe WRITE, ashtu që sistemi i fajlleve e di se cili e lexim dhe shkrim i takojnë grupit të përbashkët. Ekzistojnë disa arsye të mira për grupimin dhe përdorimin e emrit të përkohshëm të fajllit përbrenda grupimit. Në fillim, shqetësimet për menaxhimin e


91

performancës dhe resurseve kanë motivuar përdorimin e OPEN dhe CLOSE, por implementimet e mëvonshme të ndërfaqes e përdorën ekzistencën e OPEN dhe CLOSE për të dhënë semantikë të pastër në qasjet konkurrente në fajlle dhe në dështime.

Sistemet e hershme të fajlleve kanë përdorur OPEN për amortizimin e kostos së vënies së emrit të fajllit. Emri i fajllit është emër i rrugës që mund të përmbaj disa komponentë. Duke vënë emrin e fajllit në OPEN dhe duke i dhënë rezultatit një emër të thjeshtë, READ dhe WRITE e shmangim opsionin e vënies së emrit në çdo thirrje. Ngjashëm, OPEN amortizon koston e kontrollit, nëse shfrytëzuesi i ka lejet e duhura për ta përdor fajllin.

CLOSE u përdor për të thjeshtuar menaxhimin e resurseve: kur një aplikacion e thërret CLOSE, sistemi i fajlleve e din se aplikacioni nuk ka nevojë për resurse (p.sh., kursori) të cilat sistemi i fajlleve i mirëmban përbrenda. Edhe nëse aplikacioni i dytë e heq fajllin përpara se aplikacioni i parë të mbarojë së lexuari dhe shkruari fajllin, sistemi i fajlleve mund të implementojë procedurat READ dhe WRITE për aplikacionin e parë (për shembull, shmangi përmbajtjet e fajllit vetëm pasi që secili që e ka hapur (OPEN) fajllin e ka thirrur CLOSE). Sistemet e fajlleve më të rinj e përdorin OPEN dhe CLOSE për shënimin e fillimit dhe fundit të aksionit atomik. Sistemi i fajlleve mund t’i trajtojë të gjitha thirrjet ndërhyrëse READ dhe WRITE, si operacion të thjeshta dhe të padukshëm, edhe në faqe të qasjes konkurrente të fajllit apo dështimit të sistemit, pasi që të jenë të kompletuar disa WRITE, por jo të gjitha. Do të pasojnë dy mundësi:

1. Sistemi i fajlleve mund t’i përdor operacionet OPEN dhe CLOSE për koordinimin e qasjes konkurrente në fajll: nëse një program ka hapur një fajll dhe programi tjetër tenton ta hap (OPEN) të njëjtin fajll, sistemi i fajlleve do të çoj programin e dytë të presë, deri sa programi i parë ta mbyll (CLOSE) fajllin. Ky koordinim është një shembull i atomicitetit before-or-after, një temë që Seksioni 5.2.4 e eksploron në thellësi.

2. Nëse sistemi i fajlleve dështon (për shembull, për arsye të ikjes së rrymës) përpara se aplikacioni ta mbyll fajllin, asnjë nga shënimet (WRITE) nuk do të jetë në fajll, kur të rinis sistemi. Nëse dështon pasi që aplikacioni ta mbyll fajllin, të gjitha shënimet do të jenë në fajll. Jo të gjitha sistemet e fajllave e kanë këtë garanci, e njohur si atomiciteti all-ornothing, meqë nuk është lehtë të implementohet me saktësi dhe me efikasitet, siç e shpjegon Kapitulli 9 [onlajn].

Por, për modelin OPEN/COST ka një kosto: sistemi i fajlleve duhet ta mbajë gjendjen për-klient në formë të emrave të vëna të fajllit dhe kursorëve. Është e mundur të dizajnohet ndërfaqe komplet pa gjendje. Një shembull është Sistemi i Fajllave të Rrjetit, i përshkruar në Seksionin 4.5.

Fajlli është një abstraksion i përshtatshëm i memories ku disa sisteme (për shembull, sistemi i UNIX-it dhe derivatet e tij) çdo pajisje hyrëse/dalëse në sistemin kompjuterik ka një ndërfaqe të fajllit (shih Figurën 2.19). Në sistemet e tilla, fajllet jo vetëm që përbëjnë një abstraksion për memoriet e qëndrueshme (p.sh. disqet magnetike), por ato janë edhe një ndërfaqe e duhur për pajisjet e tastierës, ekranit, lidhjeve komunikuese, etj. Në sistemet e


92

këtilla, secila pajisje I/O ka emrin në skemën emërtuese të fajllit. Programi e hap (OPEN) pajisjen e tastierës, i lexon bajtet nga pajisja e tastierës, dhe pastaj e mbyll tastierën, duke mos ditur çdo detal për procedurën e menaxhimit të tastierës, si çfarë tipi është tastiera, etj. Ngjashëm, për ndërveprimin me ekranin, programi mund ta hap pajisjen e ekranit, shkruaj në të dhe e mbyll të njëjtin. Programi nuk duhet të dijë çdo detal për ekranin. Në pajtueshmëri me principin e çudisë më të vogël, secila procedurë për menaxhimin e pajisjes ka disa interpretime të arsyeshme për çdo metodë të sistemit të fajllave. Pseudokodi në Figurën 2.18 ilustron me shembull dobinë nga ky lloj i njëformësisë së dizajnit.

FIGURA 2.19

Përdorimi i abstraksionit të fajllit dhe shtresëzimit për të integruar lloje të ndryshme të pajisjeve hyrëse dalëse. Sistemi i fajlleve vepron si një ndërmjetës që ka njëformësinë, ndërfaqen e abstraktit, dhe menaxhues të ndryshëm të pajisjeve të cilat janë programe që përkthejnë atë ndërfaqe të abstraktit në kërkesa operacionale për pajisje të ndryshme.

Një tipar i një ndërfaqe uniforme është kur në shumë situata, duke e rilidhur emrin, mund të zhvendosë pajisjen I/O me fajll, ose e kundërta, duke mos ndryshuar në asnjë mënyrë programin aplikativ. Ky përdorim i emërtimit në mbështetje të modularitetit është veçanërisht ndihmues gjatë mënjanimit të gabimeve në programin aplikativ. Për shembull, lehtësisht mund të testohet programi që e pret tastierën për të shtypur diçka, duke zhvendosur fajllin e mbushur me tekst në vendin e pajisjes së tastierës. Për shkak të këtyre shembujve, abstraksioni i sistemit të fajlleve, është dëshmuar të jetë shumë i suksesshëm.

2.4 SHIKIMI PRAPA DHE PËRPARA

Ky kapitull ka zhvilluar disa ide dhe koncepte që japin një prapavijë të dobishme për studimin e dizajnit të sistemit kompjuterik. Së pari i përshkruan të tre abstraksionet më të mëdha që përdoren në dizajnin e sistemeve kompjuterik – memorinë, interpretuesit, dhe lidhjet komunikuese. Pastaj prezantohet një model se si përdoren emrat për t’i bashkuar modulet e bazuara në ato abstraksione për të krijuar sisteme të dobishme. Së fundmi, përshkruhen disa pjesë të sistemit kompjuterik tipik modern të shtresëzuar nga këndvështrimi


93

i tre abstraksioneve të mëdha. Me këtë prapavijë, tani jemi gati të ndërmarrim një seri të diskutimeve të thella për tema specifike në dizajnimin e sistemeve kompjuterike. Diskutimi i tillë i parë, në Kapitullin 3, ka të bëjë me disa probleme inxhinierike që e përshkojnë përdorimin e emrave. Secili nga kapitujt tjerë ndërmerr një diskutim të ngjashëm në thellësi për tema të ndryshme nga dizajni i sistemeve.

Përpara se të kalojmë në ato diskutime të thella, seksioni i fundit i këtij kapitulli është një rast studimor, sesi abstraksioni, emërtimit dhe shtresat shfaqen në praktikë. Rasti studimor i përdor ato tre koncepte për të përshkruar sistemin UNIX.

2.5 RAST STUDIMOR: EMËRTIMI DHE SHTRESËZIMI NË SISTEMIN E FAJLLAVE NË UNIX® Familja UNIX e sistemeve operative zanafillën e ka në sistemin UNIX të zhvilluar nga Bell Telephone Laboratories për Digital Equipment Corporation RDP të minikompjuterëve në vitet e vonshme të 1960 dhe fillim të viteve 1970 [Sugjerim për Lexim Plotësues 2.2], dhe përpara kësaj në sistemin operativ Multics** në fillim të viteve 1960 [Sugjerim për Lexim Plotësues 1.7.5 dhe 3.1.4]. Sot ekzistojnë disa lloje të UNIX sistemeve me relacione historike të komplikuara. Disa shembuj përfshijnë GNU/Linux, versione të Linux të distribuuar nga organizata të ndryshme (p.sh. Red Hat, Ubuntu), Darwin (sistem operativ UNIX që është pjesë e sistemit operativ të Apple Mac OS X), dhe disa lloje të sistemeve operative BSD. Disa nga këto drejtpërdrejt rrjedhin nga sistemi i hershëm operativ UNIX; tjerët kanë ndërfaqe të ngjashme, por janë implemenuar që nga fillimi. Disa janë si rezultat i një përpjekje të një grupi të vogël të programuesve, dhe të tjerë janë si rezultat i një grupi më të madh. Në rastin e fundit, është madje e paqartë si të emërtohet sistemi operativ saktësisht, sepse pjesë themelore vijnë nga ekipe të ndryshme.†† Rezultati i përgjithshëm i të gjitha këtyre përpjekjeve është, se sistemet operative të familjes UNIX kanë shtrirje të madhe nëpër kompjuterë, duke përfshirë kompjuterin personal, serverët, kompjuterët paralelë, dhe kompjuterët e mbjellur (embedded). Shumë nga ndërfaqet e UNIX janë standard zyrtar, ‡‡ dhe sistemet tjera operative që nuk janë UNIX e mbështesin gjithashtu këtë standard. Pasi që kodi burimor i disa versioneve është i qasshëm për publikun, sistemi UNIX shumë lehtë mund të studiohet.

Ky rast studimor ekzaminon mënyrat e ndryshme ku sistemi i fajllave i UNIX përdor emrat në dizajnin e tij. Gjatë ekzaminimit sesi e implementon skemën emërtuese, do të

** Emri UNIX evoluoi nga Unics, që ishte si lojë fjalësh për Multics. †† E përdorim “Linux” për bërthamën e Linux, kurse e përdorim “GNU/Linux” për sistemin e tërësishëm që kjo konventë e emërtimit nuk është e përsosur sepse janë disa pjesë të sistemit që nuk kanë as GNU softuer as pjesë e bërthamës (p.sh., e Sistemi X Window; shih Shiritin anësor 4.4). ‡‡ POSIX® (Portable Operating System Interface), Federal Information Processing Standards (FIPS) 151-2. FIPS 151-2 përdor ISO/IEC 9945-1: 2003 (IEEE Std. 1003.1: 2001) Information Technology- Portable Operating System Interface (POSIX)-Pjesa 1: System Application: Program Interface (API) [Gjuha C].


94

japim edhe një pasqyrë të nivelit të parë, për atë sesi është i organizuar sistemi i fajllave i UNIX.

2.5.1 Ndërfaqja për Programimin e Aplikacioneve për Sistemin e Fajllave të UNIX

Programi mund të krijojë një fajll me emër të zgjedhur nga shfrytëzuesi, të lexojë dhe shkruaj në përmbajtjen e fajllit, dhe të vendos dhe të marrë meta të dhënat e fajllit. Meta të dhënat përfshijnë ndryshimin e fundit, ID t shfrytëzuesit si pronar të fajllit, dhe lejet e qasjet për shfrytëzuesit e tjerë. (Për një diskutim të plotë mbi meta të dhënat shih Seksionin 3.1.2.) Për të organizuar fajllat e tyre, shfrytëzuesit mund t’i grupojnë ato në skedarë me emra të zgjedhur nga shfrytëzuesi, të krijojnë rrjetë emërtimi. Përdoruesit gjithashtu mund ta përdorin rrjetën e emërtuar të ruajtur në pajisje për ruajtje/depo në rrjetën ekzistuese të emërtimit, duke lejuar që rrjetat emërtuese për pajisje të ndryshme, të inkorporohen në një rrjet të vetme emërtimi. Për t’i mbështetur këto operacione, sistemi i fajllave i UNIX posedon ndërfaqen për programimin e aplikacioneve (API) e treguar në Tabelën 2.1.

Tabela 2.1 Ndërfaqja për Programimin e Aplikacioneve e Sistemit të Fajllave të UNIX Procedura Përshkrimi i shkurtër OPEN (emri, flamuri, modi) E hap emrin e fajllit. Nëse fajlli nuk ekziston dhe

vendoset flamuri, krijo fajll me lejen modi. Vendose kursorin e fajllit në 0!. Kthen një përshkrues (deskriptor) të fajllit.

READ (fd, buf, n) Lexo n bajte nga fajlli në kursorin aktual dhe zmadhoje kursorin sipas numrit të bajteve të lexuara!

WRITE (fd, buf, n) Shkruaj n bajte te kursori aktual dhe zmadhoje kursorin sipas bajteve të shkruara!

SEEK (fd, zhvendos,që_nga) Vendose kursorin në bajtet zhvendos, fund ose kursorin aktual!

CLOSE (fd ) Fshije deskriptonin e fajllit! Nëse kjo është referenca e fundit për te fajlli, fshije fajllin!

FSYNC (fd ) Bëji të gjitha ndryshimet e fajllit të qëndrueshme! STAT (emri) Lexo meta të dhënat e fajllit! CHMOD, CHOWN, etj. Procedura të ndryshme për vendosjen e meta të

dhënave specifike! RENAME (nga_emri, te_emri) Ndrysho emrin nga nga_emri në te_emri! LINK (emri, emri_lidhjes) Krijo lidhje të fortë emri_lidhjes në emrin e fajllit! UNLINK (emri) Hiqe emrin nga skedari i tij. Nëse emri është emri i

fundit për fajllin, fshije fajllin! SYMLINK (emri, emri_lidhjes) Krijo emër simbolik emri_lidhjes për emrin e fajllit! MKDIR (emri) Krijo një skedar të rij me emrin emri! CHDIR (emri) Ndrysho skedarin punues aktual në emri! CHROOT (emri) Ndrysho skedarin bazë në emri! MOUNT (emri, pajisja) Bashkëngjite sistemin e fajllit në pajisje te hapësira

emërtuese në emrin! UNMOUNT (emri) Largoje sistemin e fajllit në emri!

Për ta realizuar problemin e implementimit të këtij API, sistemi i fajlleve në UNIX posedon një strategji përça-dhe-sundo. Sistemi i fajllave UNIX përdor disa shtresa të fshehta të emrave të orientura nga makina (që janë adresat), një në krye të tjetrit, për të implementuar fajllet. Tabela 2.2 e ilustron këtë strukturë.


95

Në pjesën tjetër të këtij seksioni do japim sqarim nga shtresa e poshtme e Tabelës 2.2 deri te shtresa e sipërme, duke vazhduar nga shtresa e poshtme e sistemit e përpjetë, deri te shfrytëzuesi.

Tabela 2.2 Shtresat Emërtuese të Sistemit të Fajllave të UNIX Shtresa Qëllimi Shtresa e Lidhjeve Simbolike Integron sisteme fajllash të shumëfishta

me lidhjet simbolike.

Shtresa e emërtimit të rrugës absolute

Ofron rrënjën për emërtimin e hierarkive.

emra të orientuara nga shfrytëzuesi

Shtresa e emërtimit të rrugës Organizon fajllet në hierarki emërtimesh.

Shtresa e emërtimit të fajllit Ofron emra të orientuar nga njeriu për

fajllet. ndërfaqe makinë-shfrytëzues

Shtresa e numrit të strukturës i-nyjes

Ofron emra të orientuar nga makina për fajllet.

Shtresa e fajllit Organizon blloqet në fajlle.

emra të orientuara nga makina

Shtresa e bllokut Identifikon blloqet e diskut.

Ky përshkrim korrespondon shumë me implementimin e Versionit 6 të sistemit UNIX, që daton që nga vitet e hershme 1970. Versioni 6 është mirë i dokumentuar [Sugjerime për Lexim Plotësues 2.2.2] dhe i nxjerr në pah idetë që gjenden në shumë sisteme fajllesh modern UNIX, por versionet moderne janë më kompleks; ata ofrojnë fortësi dhe mbajnë fajlle të mëdha, shumë fajll me efikasitet. Në disa pjesë do të bëjmë me dije disa diferenca, por lexuesi inkurajohet të konsultojë artikuj nga literatura e sistemit të fajlleve, për të zbuluar si punon sistemi i fajlleve modern i UNIX dhe si po zhvillohet ai.

2.5.2 Shtresa e Bllokut Në shtresën e fundit të sistemit të fajlleve të UNIX emërton disa pajisje fizike siç janë

disku magnetik, flesh disku, apo kaseta magnetike që mund të ruajnë të dhëna përgjatë kohë. Deponimi në pajisjet e tilla ndahet në njësi me madhësi fikse, të quajtura blloqe. Për diskun magnetik (shih Shiritin anësor 2.2), blloku korrespondon me numrin e vogël të sektorëve të diskut. Blloku është njësia më e vogël përcaktuese, dhe madhësia e tij është një kompromis ndërmjet disa qëllimeve. Blloku i vogël e redukton sasinë e humbur të diskut për fajllet e vogla. Nëse shumë fajlla janë më të vogla se 4 kilobajt, blloku me madhësi 16 kilobajt e harxhon hapësirën. Nga ana tjetër, madhësia shumë e vogël e diskut mund të shkaktojë që strukturat e mëdha të të dhënave të ndjekin blloqet e lira dhe të caktuara. Veç kësaj, ekzistojnë konsiderime për perfomancën që ndikojnë në madhësinë e bllokut, disa prej të cilave do të diskutohen në Kapitullin 6. Në versionin 6, sistemi i fajlleve UNIX përdor blloqe prej 512 bajteve, por sistemet e fajlleve modern të UNIX shpesh përdorin blloqe prej 8 kilobajt.


96

Emrat e këtyre blloqeve janë numra, që zakonisht korrespondojnë me zhvendosjen e bllokut nga fillimi i pajisjes. Në fund, shtresa emërtuese, pajisja deponuese mund të shihet si kontekst që i lidh numrat e bllokut me blloqet fizike. Algoritmi për pasqyrimin e emrit për pajisjen e bllokut është i thjeshtë: e merr si hyrje numrin e bllokut dhe e kthen bllokun. Aktualisht, nuk na duhet blloku – kjo do të ishte një turrë e oksidit të hekurit. Ajo çka na duhet është përmbajtja e bllokut, ashtu që algoritmi aktualisht implementon një pasqyrim të fiksuar ndërmjet emrit të bllokut dhe përmbajtjes së bllokut. Nëse e paraqesim pajisjen për ruajtje/deponim si fushë lineare me blloqe, atëherë pjesa e kodit vijues implementon algoritmin për pasqyrimin e emrit.

procedure NUMRI_BLLOKUT_NeNUMER ( integer b ) returns blok return pajisja [ b ]

Në këtë algoritëm të thjeshtë emri i ndryshores, pajisja, referon te disa pajisje të caktuara fizike. Në shumë pajisje pasqyrimi është më i komplikuar. Për shembull, disku i ngurtë mund të mbajë një bashkësi të blloqeve rezerve në fund dhe i lidh numrat e bllokut të secilit bllok që ka gabime. Disku i ngurtë vetveten mund ta implementojë me shtresa, siç do të shihet në Seksionin 8.5.4 [onlajn]. Vlera e kthyer nga NUMRI_BLLOKUT_NëNUMËR paraqet përmbajtjen e bllokut b.

Zbulimi i emrit: Emrat e blloqeve janë numra të plotë nga një bashkësi kompakte, por shtresa e bllokut duhet të mbajë llogari se cilët blloqe janë në përdorin dhe cilat janë të mundshme për t’i aktivizuar. Siç do të shohim, sistemi i fajlleve në përgjithësi ka nevojë për përshkrimin e shpërndarjes së sistemit të fajllit në disk. Si një nyje për këtë informacion, sistemi i fajlleve i UNIX fillon me super bllok, i cili ka një emër të mirënjohur (p.sh. 1). Super blloku përmban, për shembull, madhësinë e diskut të sistemit të fajlleve në blloqe. (Blloku 0 zakonisht ruan një program të vogël që e fillon sistemin operativ; shih Shiritin anësor 5.3.)

Implementime të ndryshme të sistemit të fajlleve të UNIX përdorin paraqitje të ndryshme për listën e blloqeve të lira. Versioni 6 i implementimit mban një listë me numrat e bllokut për blloqet e papërdorura në listën e lidhur që ruhet në ndonjë bllok të papërdorur. Numri i bllokut të parë nga kjo listë ruhet në super bllok. Thirrja për përcaktimin e bllokut sjell deri te procedura në shtresën e bllokut e cila kërkon fushën e listës për bllokun e lirë, e heq atë nga lista, dhe e kthen atë numër të bllokut.

Sistemet moderne të fajlleve të UNIX shpesh përdorin bitmap-e (një grup bitesh që paraqesin një imazh grafik) për menaxhimin e blloqeve të lira. Biti i në bitmap regjistron nëse blloku i është i lirë apo i përcaktuar. Bitmap-i ruhet në një lokacion të ditur në disk (p.sh. menjëherë pas super bllokut). Figura 2.20 tregon një disk të mundshëm për një sistem të thjeshtë të fajllave. Fillon me super bllokun, e ndjekur nga bitmap-i që regjistron se cilët blloqe të diskut janë në përdorim. Pas bitmap-it vjen tabela me i-nyje, që ka një hyrje për secilin fajll (siç do shpjegohet më tutje), e ndjekur nga blloqet që janë ose të lira ose të përcaktuara për disa fajlle. Super blloku përmban madhësinë e bitmap-it dhe tabelën me i-nyje në blloqe.


97

0 1 ... n-1

Blloku bazë

Super blloku

Bitmap për blloqe të lira

Tabela me i-nyje

Blloku i fajllit

... Blloku i fajllit

FIGURA 2.20 Shpërndarja e mundshme në disk për një sistem të thjeshtë fajllash

2.5.3 Shtresa e Fajllit Shfrytëzuesit kanë nevojë të ruajnë gjëra që janë më të mëdha se një bllok në madhësi

dhe që mund të rritet apo zvogëlohet me kalimin e kohës. Për të realizuar këtë, sistemi i fajllave i UNIX përdor një shtresë për fajll. Fajlli është fushë lineare me bajte të një madhësie të ndryshme. Sistemi i fajlleve duhet të regjistrojë se cilët blloqe i përkasin secilit fajll. Për të mbështetur këtë kërkesë, sistemi i fajlleve i UNIX krijon një nyje të indeksit, apo i-nyje, si përmbajtës i meta të dhënave të fajllit. Deklarimi i jonë fillestar për i-nyjen është:

structure inyje integer numrat_e_blloqeve [ N ] // numrat e blloqeve që e përbëjnë fajllin integer madhësia // madhësia e fajllit në bajt

i-nyja për fajllin është një kontekst ku shumë blloqe të fajllit janë emërtuar me numra të plotë të bllokut. Me këtë strukturë, algoritmi i thjeshtëzuar i pasqyrimit të emrit për vënien e emrit të bllokut në fajll është si vijon:

procedure INDEKS_NË_NUMRIN_E_BLLOKUT ( inyje instance i , integer indeks ) returns integer return i.numrat_e_blloqeve [ indeks ]

Versioni 6 i sistemit të fajllave i UNIX e përdor këtë algoritëm për fajllet e vogla, që janë të kufizuara në N=8 blloqe. Për fajllet e mëdha, versioni 6 përdor një algoritëm më të sofistikuar për pasqyrimin e bllokut indeks, të një nyje në numrin e bllokut. Shtatë hyrjet e para në i.numrat_e_blloqeve janë blloqe indirekte. Blloqet indirekte nuk përmbajnë të dhëna, por numra blloqesh. Për shembull, me madhësinë e bllokut prej 512 bajt dhe indeks prej 2 bajt (si në Versionin 6), blloku indirekt mund të përmbajë 256 numra blloqesh prej 2 bajtesh. Hyrja e tetë është bllok indirekt i dyfishtë (blloqe që përmbajnë numra blloqesh të blloqeve indirekt). Ky dizajn me blloqe indirekte dhe dyfish indirekte mundëson për (N-1) x 256 +1 x 256 x 256 = 67,329 blloqe kur N=8, rreth 32 megabajt§§. Tërësia e problemeve 1 hulumton disa dizajnime për mundësimin e sistemit të fajllit që të mbështesë fajlle të mëdha. Disa sisteme moderne të fajlleve të UNIX përdorin paraqitje të ndryshme apo struktura të dhënash më të sofistikuara, siç janë B+ pemët, për implementimin e fajlleve.

Sistemi i fajlleve i UNIX u lejon përdoruesve të emërtojnë çfarëdo bajti të caktuar në fajll duke shtresëzuar dy skemat emërtuese paraprake dhe specifikuar numrin e bajtit si një zhvendosje nga fillimi i fajllit:

§§ Implementimi i Versionit 6, megjithatë, e kufizon numrin maksimal të blloqeve për fajll në 215.


98

1 procedure INYJE_NË_BLOK ( integer zhvendosje, inyje instance i ) returns blok 2 o ← zhvendosje / BLOCKSIZE

3 b ← INDEKS_NË_NUMRIN_E_BLLOKUT ( i , o ) 4 return NUMRI_BLLOKUT_NeNUMER ( b )

Vlera e kthyer është një bllok i plotë që përmban vlerën e bajtit në zhvendosje. Versioni 6 ka përdorur për zhvendose një numër 3 bajtësh, që e kufizon madhësinë maksimale të fajllit në 224 bajt. Sistemet moderne të fajlleve të UNIX përdorin numër 64 bitësh. Procedura e kthen bllokun e plotë që e përmban bajtin e emërtuar. Siç do të shohim në Seksionin 2.5.11, READ e përdor këtë procedurë për të kthyer bajtet e kërkuara.

2.5.4 Shtresa e Numrit të i-nyjes Në vend të kalimit të i-nyjeve, do të ishte më e përshtatshme ato të emërtohen dhe

pastaj të kalohen tutje. Për të arritur këtë veçori, sistemi i fajlleve i UNIX ka një tjetër shtresë emërtimi që i emërton i-nyjet me një numër për i-nyjet. Për të implementuar këtë eshtresë emërtimi duhet përdorur një tabelë që direkt i përmban të gjitha i-nyjet, të indeksuara me numër të i-nyjes. Këtu kemi një algoritëm të emërtimit:

1 procedure NUMRI_INYJES_NE_INYJE ( integer numri_inyjes) returns inyje 2 return tabela_inyjes [ numri_inyjes]

Ku tabela_inyjes është objekt që ruhet në një lokacion fiks, në pajisjet për ruajtje (p.sh., në fillim). Algoritmi për pasqyrim të emrit për tabela_inyjes kthen vetëm numrin e bllokut të parë të tabelës.

Zbulimi i emrit. numrat e i-nyjes, ashtu si numrat e bllokut të diskut, janë një bashkësi kompakte me numra të plotë, dhe pastaj shtresa e numrit të i-nyjes duhet të përcaktojë se cili numër i i-nyjes është në përdorim dhe cilët janë të lira për t’i aktivizuar. Ashtu si edhe me aktivizimin e numrit të bllokut, implementime të ndryshme përdorin paraqitje të ndryshme për një listë me i-nyje të lira dhe jep thirrje për përcaktimin dhe jopërcaktimin e i-nyjeve. Në implementimin më të thjeshtë, i-nyja përmban një fushë regjistruese, nëse është apo jo e lirë.

Duke i marrë së bashku këto tre shtresa, do të kemi procedurën në vijim.

1 procedure NUMRI_INYJES_NE_BLLOK ( integer zhvendosja, integer numri_inyjes) 2 returns bllok 3 inyje instance i ←NUMRI_INYJES_NE_INYJE (numri_inyjes) 4 o ←zhvendosje / MADHESIABLLOKUT 5 b ←INDEKS_NË_NUMRIN_E_BLLOKUT ( i , o ) 6 return NUMRI_BLLOKUT_NE_BLLOK ( b )

Kjo procedurë e kthen bllokun që përmban bajtin e zhvendosjes në fajllin e emërtuar me numri_inyjes. Ajo përshkon tri shtresa të emërtimit. Ato janë numrat për blloqet e depove, indekset e numëruara për blloqet që i përkasin një i-nyjeje, dhe numrat për i-nyjet.

2.5.5 Shtresa e Emrit të Fajllit Numrat janë emra të përshtatshëm për përdorim nga kompjuteri, (numrat mund të

ruhen në fusha me gjatësi fikse që e thjeshtëzon përcaktimin e depos) por janë emra të papërshtatshëm për përdorim nga njerëz (numrat kanë vlerë të vogël mnemonike). Veç kësaj,


99

blloku dhe numrat e i-nyjeve specifikojnë lokacionin, pra bëhet e nevojshme të shpërndahet rishtas depoja fizike, numrat duhet të ndërrohen, por edhe kjo është e papërshtatshme për njerëzit. Sistemi i fajllave i UNIX e zgjedh këtë problem duke ndërfutur shtresën emërtuese, qëllimi i vetëm i të cilës është t’i fsheh meta të dhënat e menaxhimit të fajllit. Mbi këtë shtresë

ndodhet një skemë emërtuese për objekte të qëndrueshme e lehtë për përdorim – fajllet dhe pajisjet hyrëse/dalëse. Kjo skemë emërtimi përsëri ka disa shtresa. Komponenti më i dukshëm i skemës emërtuese të objektit të qëndrueshëm është skedari. Në sistemin e fajllave të UNIX, skedari është një kontekst që përmban një bashkësi ndërlidhjesh ndërmjet emrave

karakter-varg dhe numrave i-nyje.

Për të krijuar një fajll, sistemi i fajllave në UNIX e përcakton një i-nyje, i fillon meta të dhënat e saj, dhe e ndërlidh emrin e propozuar me atë i-nyje në ndonjë skedar. Duke u shkruar fajlli, sistemi i fajllit i përcakton/shpërndan blloqet në i-nyje.

Në princip, sistemi i fajllave i UNIX e shton fajllin në skedarin aktual punues. Skedari punues aktual është referencë kontekstuale për skedarin ku punon aplikacioni aktiv. Forma e referencës kontekstuale është vetëm një tjetër numër i i-nyjes. Nëse wd është emri i ndryshores që përmban skedarin punues për programin që ekzekutohet (i thirrur si proces në sistemin UNIX), mund të kërkojmë numrin i-nyje të fajllit të sapo krijuar duke e vendosur wd si argument të dytë te procedura si më poshtë:

procedure EMER_NE_NUMER_INYJE ( character string emrifajllit , integer dir ) returns integer

return LOOKUP ( emrifajllit , dir )

Procedura CHDIR, implementimi i së cilës u përshkrua më përpara, lejon që procesi ta vendos wd.

Për të paraqitur skedarin, sistemi i fajllit UNIX e ripërdor mekanizmin e zhvilluar deri më tani: i paraqet skedarët si fajlle. Sipas marrëveshjes, fajlli që paraqet skedar përmban tabelë që pasqyron emrat e fajlleve në numra të i-nyjeve. Për shembull, Figura 2.21 është skedar me dy emra të fajllit (“program” dhe “letër”), që pasqyrohen në numrat e i-nyjes si 10, respektivisht 12. Në Versionin 6, gjatësia maksimale e emrit është 14 bajte, dhe hyrjet në tabelë kanë gjatësi fikse prej 16 bajteve (14 për emrin dhe 2 për numrin e i-nyjes). Sistemet moderne të UNIX lejojnë emra me gjatësi të ndryshueshme, por paraqitja tabelore është më e sofistikuar.

Për të regjistruar nëse i-nyja për skedarin është fajll, sistemi i fajlleve UNIX e zgjeron i-nyjen me një fushë tipi:

Emri i Fajllit Numri i inyjes program 10

letër 12 FIGURA 2.21 Një skedar.


100

structure inyje integer numri_bllokut [ N ] // numri i blloqeve që përbëjnë fajllin integer madhesia // madhësia e fajllit në bajt integer tipi // tipi i fajllit: fajll i rëndomtë, skedar, . . .

MKDIR krijon fajl (skedar) me gjatësi zero dhe e vendos tipi te SKEDARI. Përmirësimet e përdorura më vonë do të shtojnë vlera për tipi.

Me këtë paraqitje të skedarëve dhe i-nyjeve LOOKUP është si vijon:

1 procedure LOOKUP (character string emrifajllit , integer dir) returns integer 2 bllok instance b 3 inyje instance i ←NUMRI_INYJES_NE_INYJE (di ) 4 if i.tipi ≠ SKEDAR then return GABIM 5 for zhvendosje from 0 to i.size – 1 do 6 b ←NUMRI_INYJES_NE_BLLOK (zhvendosje, dir) 7 if VARGU_PERPUTHET(emrifajllit, b ) then 8 return NUMRI_INYJES (emrifajllit, b) 9 zhvendosje ←zhvendosje _ MADHESIABLLOKUT 10 return GABIM

LOOKUP i lexon blloqet që përmbajnë të dhënat e skedarit dir dhe kërkon për emrin e fajllit si varg, në të dhënat e skedarit. E njehson numrin e bllokut për bllokun e parë të skedarit (rreshti 6) dhe procedura VARGU_PERPUTHET (nuk është dhënë kodi) e kërkon bllokun për hyrje për emrin e fajllit. Nëse ka hyrje, NUMRI_INYJES (nuk është dhënë kodi) kthen numrin i-nyje në hyrje (rreshti 8). Nëse nuk ka hyrje, LOOKUP njehson numrin e bllokut për bllokun e dytë, dhe kështu me rradhë, deri sa të gjitha blloqet e skedarit të jenë kërkuar. Nëse asnjë bllok nuk përmban një hyrje për emrin e fajllit, LOOKUP kthen gabim (rreshti 10). Shembull, thirrja e LOOKUP (“program” , “dir”), ku dir është numri i i-nyjes për skedarin në Figurën 2.21, do të kthente numrin 10 të i-nyjes.

2.5.6 Shtresa e Emrit të Rrugës Duke i pasur të gjitha fajllet në një skedar të vetëm e bën të vështirë për shfrytëzuesit

menaxhimin e një numri të madh të fajlleve. Numërimi i përmbajtjeve të një skedari të madh do të gjenerojë një listë të gjatë që është e organizuar shumë thjeshtë (p.sh. alfabetikisht). Për të lejuar grupimin arbitrar të fajllave, sistemi i fajlleve në UNIX u lejon përdoruesve të krijojnë skedarë të emërtuara.

Skedari mund të emërtohet si fajlli, por përdoruesi po ashtu nevojitet të ketë një mënyrë të emërtimit të fajlleve në atë skedar. Zgjidhja është të shtuarit e disa strukturave në emrin e fajllit: për shembull, “projekte/letër”, ku “projekte” e emërton skedarin dhe “letër” emërton një fajll në atë skedar. Emrat e strukturuar, siç janë këto, janë shembuj të emrave të rrugës. Sistemi i fajlleve në UNIX përdor vizën e pjerrët si ndarëse të komponentëve të emrit të rrugës; sistemet e tjera përdorin karaktere ndarëse të ndryshme si presja, pika etj. Me këto vegla, përdoruesit mund të krijojnë hierarki të skedarëve dhe fajlleve.

Algoritmi i vënies së emrit për emrat e rrugës mund të implementohet me shtresëzimin e procedurës rekursive në procedurën paraprake për kërkim (Lookup) të skedarit:


101

1 procedure RRUGA_TE_NUMRI_INYJES (character string rruga , integer dir) returns integer 2 if (EMRI_PLOTE ( rruga )) return EMRI_TE_NUMRI_INYJES (rruga , dir) 3 else 4 dir ←LOOKUP (IPARI (rruga), dir) 5 path ←REST (rruga) 6 return RRUGA_TE_NUMRI_INYJES (rruga, dir)

Funksioni EMRI_PLOTE(rruga) e skanon argumentin e tij për ndarësin standard të rrugës në UNIX (viza e pjerrët) dhe kthen TRUE nëse nuk gjen një të tillë. Nëse nuk ka asnjë vizë ndarëse, programi e vendos emrin e thjeshtë për numrin e i-nyjes në skedarin e kërkuar (rreshti 2). Nëse ka një ndarëse në rruga, programi e bën atë emrin e rrugës dhe vazhdon të punojë me të (rreshti 4 deri 6). Funksioni IPARI kthen pjesën e mbetur të emrit të rrugës. Kështu për shembull, thirrja RRUGA_TE_EMRI(“projekte/letër”, wd) rezulton në thirrjen rekursive RRUGA_TE_EMRI(“letër”, dir), ku dir është numri i-nyjes për skedarin “projekte”.

Me emrat e rrugës, shpesh duhet të shtypen emrat me më shumë komponentë. Për të adresuar këtë shqetësim, sistemi i fajlleve në UNIX mbështet procedurën për ndryshim të skedarit, CHDIR, duke lejuar një proces të vendosjes së skedarit të tij punues:

procedure CHDIR (rruga character string) wd ← RRUGA_TE_NUMRI_INYJES (rruga, wd)

Kur nis procesi, e trashëgon skedarin punues nga procesi prind që e krijoi këtë proces.

2.5.7 Lidhjet Për t’iu referuar fajlleve në skedare, që nuk janë skedare punuese, nevojitet akoma të

shtypen emra të gjata. Për shembull, duke punuar në skedarin “projekte” – pas thirrjes së CHDIR (“projekte”) – do duhet që t’i referohemi shpesh fajllit “Mail/inbox/aktivitet-i-ri”. Për të adresuar këtë shqetësim, sistemi i fajllave i UNIX mbështet sinonimin e njohur si lidhje.. Në shembullin e dhënë, do të donim të krijojmë lidhje për këtë fajll, në skedarin punues aktual, “projekte”. Gjatë thirrjes së procedures LINK me argumentet vijuese:

LINK ("Mail/inbox/aktivitet-i-ri", "aktivitet")

“aktivitete” e bën sinonim për “Mail/inbox/aktivitet-i-ri” në “projekte”, nëse “aktivitete” akoma nuk ekziston. (Nëse po, LINK do të kthejë një gabim duke cituar “aktivitete” tashmë ekziston.) Me lidhjet, hierarkia e skedarit kthehet nga një hierarki strikte në graf direkt. (Sistemi i fajlleve në UNIX mundëson lidhje vetëm për fajllet, e jo të skedarëve, pra grafi nuk është vetëm direkt por edhe aciklik. Pas pak do e shohim përse.)

Sistemi i fajlleve në UNIX implementon lidhjet vetëm si lidhje në kontekste të ndryshme që pasqyrojnë emra të ndryshëm të fajllit, në numrin e njëjtë të i-nyjes, dhe kështu, lidhjet nuk kërkojnë ndonjë përmirësim të skemës emërtuese të zhvilluar deri më tani. Për shembull, nëse numri i i-nyjes për “aktivitet-i-ri” është 481, atëherë skedari “Mail/inbox/” përmban një hyrje {“aktivitetiri”, 481} dhe pasi që komanda e sipërme të ekzekutohet skedari


102

“projekte” përmban hyrjen {“aktiviteti”, 481}. Në fjalorin e sistemit UNIX, “projekte/aktivitete” është tani e lidhur me “Mail/inbox/aktiviteti-i-ri”.

Kur fajlli nuk është i nevojshëm, procesi mund ta fshijë fajllin me UNLINK(emrifajllit), duke sugjeruar te sistemi i fajllit që emri emrifajllit nuk është në përdorim. UNLINK e fshin lidhjen e emrifajllit me numrin e tij të i-nyjes nga skedari që e përmban emrifajllit. Sistemi i fajllit poashtu i vendos emrifajllit të i-nyjes dhe blloqet e emrifajlli të i-nyjes në listën e zbrazët, nëse kjo lidhje është e fundit që e përmban numrin e i-nyjes.

Përpara se t’i shtonim lidhjet, fajlli ishte i lidhur me emrin në vetëm një skedar, dhe nëse procesi kërkon të fshijë emrin nga ai skedar, sistemi i fajllit mund ta fshijë gjithashtu fajllin. Por, tani kur lidhjet janë shtuar, kur procesi kërkon të fshij emrin, mund të ketë akoma emra në skedarët tjerë të lidhur për fajlli, ndaj në këtë rast fajlli nuk duhet fshirë. Kjo e nxit pyetjen, kur duhet të fshihet fajlli? Sistemi i fajllit UNIX e fshin fajllin kur procesi e fshin lidhjen e funsit për fajllit. Sistemi i fajllit UNIX implementon këtë politikë duke mbajtur numërator reference në i-nyje:

structure inyje integer numri_bllokut [ N ] integer madhesia integer tipi integer numref

Sa herë që realizon lidhje në i-nyje, sistemi i fajllave e rrit numëratorin e referencës të asaj i-nyje. Për të fshirë fajllin, sistemi i fajllave i UNIX e zotëron procedurën UNLINK(emrifajllit), e cila fshin lidhjen e përcaktuar nga emrifajllit. Në të njëjtën kohë sistemi i fajlleve e zvogëlon numëratorin e referencës për një në i-nyjën përkatëse. Nëse zvogëlimi bën që numëratori i referencës të bëhet zero, kjo nënkupton se nuk ka më lidhje për atë i-nyje, dhe sistemi i fajllit mund ta lirojë iatë dhe blloqet e saj përkatëse. Për shembull, UNLINK(“Mail/inbox/aktivitet-i-ri”) e fshin hyrjen “aktivitet-i-ri” në skedarin “Mail/inbox/”, por jo “aktivitete”, sepse pas prishjes së lidhjes numref në i-nyjen 481 do të jetë 1. Vetëm pasi të thirret UNLINK(“aktivitete”) do të lirohen nyja 481 dhe blloqet e saj.

Shfrytëzimi i numëratoreve të referencës është i arsyeshëm vetëm nëse nuk ka cikle në grafin emërtues. Për t’u siguruar se rrjeta emërtuese e UNIX është graf direkt pa cikle, sistemi i fajlleve i UNIX i parandalon lidhjet për skedarë. Për të shikuar pse shmangen ciklet, të konsiderojmë skedarin “a”, që përmban skedarin “b”. Nëse programi e thërret LINK(“a/b/c”,”a”) në skedarin që e përmban “a”, atëherë sistemi do të kthejë një gabim dhe nuk do ta ekzekutojë operacionin. Nëse sistemi e ka ekzekutuar këtë operacion, do të ketë krijuar cikël nga “c” në “a” dhe do ta ketë rritur numëratorin e referencës në i-nyjen e “a” me një. Nëse programi që e thërret UNLINK(“a”), emri “a” fshihet, nyja dhe blloqet e “a” nuk do të fshihen, sepse numëratori i referencës në i-nyjen e “a” është akoma pozitiv (për shkak të lidhjes nga “c” në “a”). Por, pasi që emri “a” do të fshihet, shfrytëzuesi nuk do të ketë mundësi ta emërtojë më skedarin “a” dhe as nuk do të mundet ta fshijë atë. Në atë rast, skedari “a” dhe nënskedarët e tij do të ç’kyçen nga grafi emërtues, por sistemi nuk do t’i fshijë, sepse numëratori i referencës në inyjën “a” është akoma pozitiv. Është e mundur që të


103

zbulohet kjo situatë, për shembull duke përdorur grumbullues të hedhurinave, por varianta e tillë është shumë e shtrenjtë. Në vend të kësaj, dizajnuesi e përdor një zgjidhje më të thjeshtë: mos lejo lidhje deri te skedarët, të cilët e përjashtojnë mundësinë e cikleve.

Megjithatë, ekzistojnë dy raste speciale. I pari, në parim secili skedar përmban lidhje për te vetvetja; sistemi i fajlleve i UNIX e rezervon shenjë “.” (një pikë e vetme) për këtë qëllim. Emri “.” Mundëson që procesi të emërtojë skedarin aktual, duke mos e ditur se cili është ai skedar. Kur të krijohet skedari, i-nyja e skedarit ka 2 numërator reference: një për inyjen e skedarit dhe një për lidhjen “.”, sepse tregon te vetvetja. Për arsye se “.” përdor cikël me gjatësi 0, nuk ka ndonjë rrezik që një pjesë e rrjetës së emërtimit të ç’kyçet gjatë fshirjes së skedarit. Kur të ç’kyçet skedari, sistemi i fajlleve vetëm e zvogëlon numëratorin e referencës së i-nyjes së skedarit për 2.

I dyti, në parim, secili skedar gjithashtu përmban lidhje për te skedari prind; sistemi i fajlleve e rezervon shenjën “..” (dy pika të njëpasnjëshme) për këtë rast. Emri “..” mundëson që procesi të emërtojë skedarin prind dhe, për shembull, ta ngrejë lartë në hierarki, duke e thirrur CHDIR(“..”). Lidhja nuk krijon probleme. Vetëm kur skedari nuk ka hyrje tjera si “.” dhe “..” atëherë mund të fshihet. Nëse përdoruesi dëshiron ta fshijë skedarin “a”, i cili e përmban skedarin “b”, atëherë sistemi i fajlleve e refuzon ta bëjë atë, deri kur përdoruesi së pari ta fshijë “b”. Kjo rregull siguron se rrjeta emërtuese nuk mund të ç’kyçet.

2.5.8 Riemërtimi Me përdorimin e LINK dhe UNLINK, Versioni 6 e implementoi

RENAME(nga_emri, te_emri) si vijon:

1 UNLINK (te_emri) 2 LINK (nga_emri , te_emri) 3 UNLINK (nga_emri)

Ky implementim, megjithatë, ka një tipar të padëshirueshëm. Programet shpesh herë e

përdorin RENAME për ndërrimin e kopjes punuese të fajllit në versionin oficial, për shembull, përdoruesi mund ta editoj fajllin “x”. Edituesi i tekstit për momentin i bën të gjitha ndryshimet te fajlli i përkohshëm “≠x” . Kur përdoruesi e ruan fajllin, edituesi e riemërton fajllin e përkohshëm nga “≠x” në “x”. Problemi me implementimin e RENAME, duke përdorur LINK dhe UNLINK paraqitet, sepse sistemi dështon ndërmjet hapave 1 dhe 2 dhe pastaj ristartohet, ndërsa emri te_emri (“x” në këtë rast) do të humbet, gjë që do ta surprizoj përdoruesin, i cili nuk mund ta dijë se fajlli akoma ekziston por me emrin “≠x”. Ajo çka është e nevojshmë është se “≠x” do të riemërtohet në vetëm një “x” operacion atomik, por kjo do kërkoj veprime atomike, të cilat janë temë e Kapitullit 9 [onlajn]. Pa veprimet atomike, mund të implementohet specifikimi vijues por, ai është më i dobët për RENAME: nëse te_emri tashmë ekziston, një instancë e te_emri gjithmonë do të ekzistojë, edhe nëse sistemi do të dështojë në mes të RENAME. Ky specifikim është mjaftueshëm i mirë për edituesin që ta bëjë gjënë e duhur të cilën e ofrojnë versionet moderne. Versionet moderne në esencë e implementojnë këtë specifikim si vijon:

1 LINK (nga_emri , te_emri) 2 UNLINK (nga_emri)


104

Për shkak se nuk mund të bëhet lidhje deri te emri që tashmë ekziston, RENAME implementon efektet e këtyre dy thirrjeve, duke e manipuluar direkt strukturën e sistemit të fajllit. RENAME fillimisht e ndërron numrin e i-nyjes në hyrjen e skedarit për te_emri në numrin e i-nyjes për nga_emri në disk. Pastaj, RENAME e fshin hyrjen e skedarit për nga_emri. Nëse sistemi i fajllit dështon ndërmjet këtyre dy hapave, atëherë kur të kthehet sistemi i fajlleve, duhet të rris numëratorin e referencës në i-nyjen e nga_emri, sepse të dyja nga_emri dhe te_emri tregojnë për te i-nyja. Ky implementim siguron se nëse te_emri ekziston përpara thirrjes te RENAME, do të vazhdojë të ekzistojë, edhe nëse kompjuteri dështon gjatë RENAME.

2.5.9 Shtresa e Emërtimit të Rrugës Absolute Sistemi UNIX i ofron secilit përdorues nga një skedar personal, i quajtur skedari

home. Kur përdoruesi logohet në sistemin UNIX, fillon me punë interpretuesi i komandave (i njohur si shell) ku përdoruesi mund të bashkëveprojë me sistemin. Shell starton me skedarin punues (wd), i vendosur në numrin e i-nyjes te skedari home i përdoruesit. Me procedurat e mësipërme, përdoruesit mund të krijojnë pemë me skedarë personalë, për organizimin e fajlleve në skedarin e tyre home.

Pasja e më shumë pemëve të skedarëve personalë nuk nënkupton se përdoruesi mund të ndajë fajlle me përdoruesit e tjerë. Për ta realizuar këtë, nevojitet referim te emrat e fajlleve që i përkasin përdoruesit tjetër. Mënyra më e lehtë për ta përmbushur këtë është lidhja e emrit për secilin përdorues, me skedarin e nivelit të lartë të përdoruesit, gjë që në një farë mënyre është e mundshme për secilin përdorues. Por, pastaj nevojitet kusht që të emërtohet ky kontekst sistemor. Zakonisht, këto kontekste gjithëpërfshirëse janë të nevojshme, siç është skedari që përmban librari me program të ndarë. Për të adresuar këto nevoja, me sa më pak mekanizma plotësuese, sistemi i fajlleve posedon kontekstin universal, i njohur si skedari root. Skedari root përmban lidhjet për skedarët e përdoruesve, skedarët që përmbajnë librari programesh, dhe çdo skedar tjetër të ndarë. Rezultati është se të gjitha fajllet e sistemit janë të integruara në një pemë të vetme (me lidhje të kufizuara) me bazë në root.

Ky dizajn e nxit pyetjen për zbulimin e emrit: si mundet që përdoruesi ta emërtojë skedarin root? Të rikujtojmë se kërkimi i emrit, kërkonte referencën kontekstuale – emri i i-nyjes së skedarit - dhe deri më tani ajo i-nyje e skedarit është mundësuar nga ndryshorja e gjendjes së skedarit punues. Për të implementuar root-in, sistemi i fajlleve deklaron numrin e inyjes 1 për i-nyjen e skedarit root. Ky emër i mirënjohur pastaj mund të shfrytëzohet nga secili përdorues, si kontekst fillestar ku kërkohet emri i kontekstit të ndarë, ose përdoruesi tjetër (ose madje të kërkohet emri personal, për vendosjen e skedarit punues gjatë logimit).

Sistemi i fajlleve ofron dy mënyra të referimit në skedarin root. Duke filluar nga secili skedar në sistem, mund ta përdorim emrin “..” për emërtim prindin e skedarit, “../..” për emërtim të skedarit mbi atë, dhe kështu me radhë derisa të arrihet skedari root. Përdoruesi mund të tregojë se skedari është i arrirë, sepse “..” në skedarin root emërton skedarin root. Pra, në skedarin root, edhe “.” edhe “..” janë lidhje për te skedari root. Mënyra tjetër është me


105

emrat absolut të rrugës, të cilët në UNIX janë emra që fillojnë me “/”, për shembull, “/Alice/Mail/inbox/aktivitet-i-ri”.

Për të mbështetur emrat absolut të rrugës, na nevojitet edhe një shtresë në skemën emërtuese:

1 procedure RRUGAGJENERALE_TE_NUMRI_INYJES(character string rruga) returns integer 2 if (rruga [0] = "/") return RRUGA_TE_NUMRI_INYJES (rruga, 1)

3 else return RRUGA_TE_NUMRI_INYJES(rruga, wd )

Këtu e kemi kompletuar skemën emërtuese që na mundëson të emërtojmë dhe shpërndajmë ruajtje të qëndrueshme në një disk të vetëm. Për shembull, për të gjetur blloqet që korrespondojnë me fajllin “/programs/pong.c” me informacionin në Figurën 2.22, ne fillojme duke kërkuar tabelën e i-nyjes, e cila fillon te numri i bllokut, (blloku 4 në shembullin tonë) i ruajtur në super bllok (nuk është paraqitur në figurë, por shih Figurën 2.29). Nga atje e gjejmë i-nyjen e root (që dihet se është numri i inyjes 1). Inyja e root përmban numrat e bllokut të cilat përmbajnë blloqet e skedarit root; në figurë, root starton në numrin e bllokut 14. Blloku 14 i liston hyrjet në skedarin root: “programs” është i emërtuar nga numri i inyjes 7. Tabela e i-nyjes thotë se të dhënat për numrin e i-nyjes 7 fillojnë në numrin e bllokut 23, që përmban përmbajtjen e skedarit “programs”. Fajlii “pong.c” emërtohet nga numri i i-nyjes 9. Duke iu referuar edhe njëherë tabelës së i-nyjes, për të parë se ku ruhet numri i inyjes 9, shohim se të dhënat që korrespondojnë me i-nyjen 9 startojnë në numrin e bllokut 61. Thënë shkurt, skedarët dhe fajllet janë të patrazuar, ashtu që të gjitha informacionet mund të gjenden, duke filluar nga lokacioni i mirënjohur i i-nyjes së root-it.

Skedari i paradefinuar root në Versionin 6 është i-nyja 1. Versioni 7 e shtoi thirrjen CHROOT, për të ndryshuar skedarin root për një proces. Për shembull. Web serveri mund të punojë në këndin e hapësirës së emrave të UNIX, duke ndryshuar skedarin e tij root, për shembull, “/tmp”. Pas kësaj thirrjeje, skedari root për web serverin korrespondon me numrin e i-nyjes së skedarit “/tmp” dhe “..” në “/tmp” është lidhja deri te “/tmp”. Si rrjedhim, serveri mund të emërtojë vetëm skedarët dhe fajllet që janë më poshtë “/tmp”.

FIGURA 2.22

Shembull me diskun në sistemin e fajlleve UNIX, duke përpunuar Figurën 2.20 me fokus në tabelën e i-nyjes dhe blloqeve të dhënave. Tabela e i-nyjeve është një grup blloqesh të puthitur që startojnë te adresa e mirënjohur, që gjendet në super bllok (nuk është treguar). Në këtë shembull, blloqet 4,5, dhe 6 përmbajnë tabelën e i-nyjes, kurse blloqet 7-61 përmbajnë skedarë dhe fajlla. I-nyja e root me marrëveshje është i-nyja e mirënjohur me numër 1. Zakonisht, i-nyjet janë më të vogla se blloku, dhe në këtë shembull kemi katër i-nyje në secilin bllok. Blloqet #14, #37, dhe #16 përbëjnë skedarin root, kurse blloku #23 është i pari nga të katërtit në skedarin e emërtuar “/programs” dhe blloku #61 është blloku i parë i fajllit me tre blloqe “/programs/pong.c”


106

2.5.10 Shtresa e Lidhjeve Simbolike Për t’u mundësuar përdoruesve të emërtojnë fajlle në disqe të tjerë, sistemi i fajlleve i

UNIX mbështet një operacion për bashkëngjitjen e disqeve të rinj në hapësirën e emrit. Përdoruesi mund të zgjedh emrin me të cilin secila pajisje bashkëngjitet: për shembull procedura

MOUNT ("/dev/fd1", "/flash")

e vendos pemën e skedarit të ruajtur në pajisjen fizike të emërtuar “/dev/fd1” në skedarin “/flash”. (Kjo komandë demonstron se secila pajisje ka gjithashtu emër në hapësirën e emrit të njëjtë për objektin që e përshkruajmë; fajlli që korrespondon me pajisjen zakonisht përmban informacion për vet pajisjen.) Në parim bashkëngjitjet nuk i mbijetojnë fikjes së sistemit: pas ristartimit përdoruesi duhet ta bashkëngjis përsëri pajisjen. Është interesante të krahasojmë qasjen elegante të UNIX me atë të DOS, ku pajisjet janë të emërtuara me emra me një karakter fiks (p.sh. “C:”).

Sistemi i fajlleve i UNIX e implementon MOUNT duke regjistruar i-nyjen në memorie për “flash” për të cilën është bashkëngjitur sistemi i fajllit dhe atë i-nyje e ruan në memorie deri sa të korrespondojë me UNMOUNT. Në memorie, sistemi gjithashtu regjistron pajisjen dhe numrin e i-nyjes së root-it, të sistemit të fajllit që ka qenë i bashkëngjitur në të. Pastaj, e regjistron në versionin në-memorje të i-nyjes për “/dev/fd1” e cila është i-nyja prind i saj.

Informacioni për pikat e bashkëngjitjes regjistrohet në memorie të paqëndrueshme dhe jo në disk dhe nuk i mbijeton dështimit të kompjuterit. Pas dështimit, administruesi i sistemit ose programi duhet ta thirrë përsëri MOUNT. Mbështetja e MOUNT kërkon edhe ndryshim në shtresën e emrit të fajllit: nëse LOOKUP ekzekutohet në i-nyje ku është i bashkëngjitur sistemi i fajllave, atëherë do e përdorë për kërkim i-nyjen e root-it të sistemit të bashkëngjitur të fajllave.

UNMOUNT e zhbën bashkëngjitjen.

Te sistemet e bashkëngjitura të fajlleve, sinonimet bëhen një problem më i vështirë sepse ekziston një hapësirë adresimi i numrit të i-nyjes për secilin sistem të bashkëngjitur të fajllave. Çdo numër i i-nyjes ka një kontekst të paradefinuar: diskun ku gjendet ai. Si rrjedhim, nuk mundet assesi që hyrja e skedarit në një disk të lidhet me numrin e i-nyjes në diskun tjetër. Ky problem mund të parashtrohet në disa mënyra, dy nga të cilat janë: (1) bëji i-nyjet unike në të gjithë diskun ose (2) krijo sinonime për fajllet në disqet tjera në mënyrë tjetër! Sistemi UNIX e zgjedh qasjen e dytë duke përdorur emra indirekt të quajtur simbolik ose lidhje të buta, që e lidhin emrin e fajllit me emrin e fajllit tjetër. Shumica e sistemve e përdorin metodën (2) për shkak të komplikimeve që do tëshfaqeshin në përpjekjen pët t’i mbajtur numrat e i-nyjeve tërësisht unik, të vegjël në madhësi, dhe për t’i vendosur shpejt.

Duke përdorur procedurën SYMLINK, përdoruesit mund të krijojnë sinonime për fajllet në të njëjtin sistem fajllash ose për fajllat në sistemet e fajllave të bashkëngjitur. Sistemi i fajlleve implementon procedurën SYMLINK, duke lejuar që fusha e tipit të i-nyjes


107

të jetë SYMLINK, që tegon, nëse blloqet e ndërlidhura me i-nyjet përmbajnë të dhëna apo emër të rrugës:

structure inyje integer numri_bllokut [ N ] integer madhesia integer tipi // Tipi i inyjes: fajll i rëndomtë, skedar, lidhje simbolike, . . . integer numref

Nëse fusha tipi ka vlerë SYMLINK, atëherë të dhënat në fushën blloqe[i] do të përmbajnë karakteret e emrit të rrugës dhe jo bashkësinë me numra të i-nyjeve. Lidhjet e buta mund të implementohen duke i shtresëzuar ato mbi RRUGAGJENERALE_TE_NUMRI_INYJES:

1 procedure EMRIRRUGES_TE_INYJA(character string emrifajllit) returns inode 2 inyja instance i 3 numri_inyjes ←RRUGAGJENERALE_TE_NUMRI_INYJES: (emrifajllit) 4 i ←NUMRI_INYJES_TE_INYJA (numri_inyjes) 5 if i.tipi = SYMBOLIC then 6 i = RRUGAGJENERALE_TE_NUMRI_INYJES(COERCE_TO_STRING (i.numri_bllokut)) 7 return i

Vlera e kthyer nga EMRIRRUGES_TE_INYJA është përmbajtja e i-nyjes për fajllin me emrin emrifajllit. Procedura fillimisht e kërkon numrin e i-nyjes për emrifajllit. Pastaj, e kërkon i-nyjen me anë të NUMRI_INYJES_TE_INYJA. Nëse i-nyja tregon se ky fajll është lidhje simbolike, procedura e interpreton përmbajtjen e të dhënave të fajllist si emër rruge dhe e thirrë përsëri RRUGAGJENERALE_TE_NUMRI_INYJES.

Tani kemi dy lloje të sinonimeve. Lidhja direkte në numrin e i-nyjes quhet lidhje e fortë, për ta dalluar atë nga lidhja e butë. Duke vazhduar me shembullin paraprak, lidhja e butë në “Mail/inbox/aktivitet-i-ri” do ta përmbajë vargun “Mail/inbox/aktivitet-i-ri” e jo numrin e i-nyjes 481. Lidhja e butë është një shembull i emrit indirekt: e lidh emrin me emrin tjetër në të njëjtën hapësirë emrash, kurse disku i ngurtë e lidh emrin me numër tjetër të i-nyjes, që është emri në hapësirën e shtresës më të ulët të emrit. Si rezultat, lidhja e butë varet nga emri i fajllit “Mail/inbox/aktivitet-i-ri”; lidhja, do të përfundojë si referencë e veçuar (Seksioni 3.1.6 i diskuton referencat e veçuara). Por, meqë lidh sipas emrit e jo sipas numrit të i-nyjes, lidhja e butë mund të tregojë në fajll në disk të ndryshëm.

Të rikujtohemi se sistemi UNIX i parandalon ciklet e lidhjeve të forta, ashtu që mund të përdorë numërator të referencave për të zbuluar kur është më sigurt ta deklarojmë hapësirën e diskut për fajllin. Megjithatë, akoma mund të krijohen cikle me lidhjet e buta: emri i vendosur thellë më poshtë në pemë mund, për shembull, të emërtojë skedar më lartë në pemë. Struktura e fituar nuk është më graf i drejtuar aciklik, por rrjetë e plotë gjenerale emërtimi. Duke përdorur lidhje të buta, programi mund edhe të thirrë SYMLIN (“cikël”,”cikël”),, duke krijuar sinonim për emrin e fajllit, i cili nuk ka fajll të ndërlidhur me atë! Nëse procesi e hap fajllin e tillë, do ta ndjek zinxhirin e lidhjes për vetëm disa hapa të caktuara, përpara se të paraqitet një gabim si “Too many levels of soft links”.


108

Lidhjet e buta kanë edhe një sjellje tjetër interesante. Të supozojmë që skedari punues është “/Scholarly/programs/www” dhe se ky skedar punues përmban lidhje simbolike të emërtuar “CSE499-web” në “/Scholarly/CSE499/www”. Thirrjet e mëposhtme

CHDIR ("CSE499-web") CHDIR ("..")

e lënë thirrësin në “/Scholarly/CSE499” dhe jo prapa ku e filloi përdoruesi. Arsyeja është se “..” vendoset në kontekstin e ri të paradefinuar, “/Scholarly/CSE499/www”, dhe jo te konteksti i destinuar, “/Scholarly/programs/www”.

Tabela 2.3 Shtresat Emërtuese në UNIX, me Detajet e Skemës Emërtuese për çdo Shtresë Shtresa Emrat Vlerat Konteksti Algoritmi pasqyrues i emrave Lidhja simbolike

Emrat e rrugës

Emrat e rrugës

Hierarkia e skedarit

EMRIRRUGES_TE_RRUGAGJENERALE

Emri absolut i rrugës

Emrat absolute të rrugës

Numrat e i-nyjes

Skedari root

RRUGAGJENERALE_TE_NUMRI_INYJES

emra të orientuara

nga përdoruesi

Emri i rrugës

Emrat relativ të rrugës

Numrat e i-nyjes

Skedari punues

RRUGA_TE_NUMRI_INYJES

Emri i fajllit

Emrat e fajlleve

Numrat e i-nyjes

Skedari EMRI_TE_NUMRI_INYJES ndërfaqe makinë-

përdorues Numri i inyjes

Numri i inyjes

I-nyjet Tabela e i-nyjeve

NUMRI_INYJES_TE_INYJA

Fajlli Numri i indeksave

Numrat e bllokut

I-nyje INDEKS_TE_NUMRI_BLLOKUT emra të orientuara

nga makina Blloku Numrat

e bllokut

Blloqet Njësia e diskut

NUMRI_BLLOKUT_TE_BLLOKU

Kjo sjellje mund të jetë e dëshirueshme ose jo, por është pasojë e drejtpërdrejtë e semantikës emërtuese të UNIX. Sistemi Plan 9 ka një plan*** të ndryshëm, i cili poashtu është sqaruar në ushtrimet 3.2 dhe 3.3.

Si përfundim, shumë nga fuqia e skemës emërtuese të objekteve në UNIX vjen nga shtresa e tij e emërtimit. Tabela 2.3 e përsërit Tabelën 2.2, kësaj here duke treguar emrin, vlerën, kontekstin, dhe procedurën e pseudokodit të përdorur, te secila ndërfaqe e shtresës. (Edhe pse i kemi ekzaminuar të gjitha shtresat në tabelë, algoritmet që ne kemi demonstruar, në disa raste, i kanë kaluar shtresat në mënyra që nuk janë sugjeruar në tabelë.) Teknika gjenerale e dizajnit ka të bëjë me praktikimin e një shtrese tjetër emërtuese për çdo problem, një aplikim të principit separimi i moduleve me veprim të tërthortë.

*** Rob Pike. Lexical File Names in Plan 9 or Getting Dot-Dot Right. Proceedings of the 2000 USENIX Technical Conference (2000), San Diego, faqe 85–92.


109

2.5.11 Implementimi i Sistemit të Fajllave API Në procesin e përshkrimit të strukturimit të sistemit të fajlleve në UNIX, pamë se si

implementoheshin CHDIR, MKDIR, UNLINK, RENAME, SYMLINK, MOUNT, dhe UNMOUNT. Do ta kompletojmë këtë përshkrim të sistemit të fajlleve API, duke përshkruar implementimin e OPEN, READ, WRITE, dhe CLOSE. Përpara se t’i përshkruajmë implementimet e tyre, do t’i përshkruajmë tiparet të cilat ato duhet patjetër t’i mbështesin.

Sistemi i fajlleve u lejon përdoruesve të kontrollojnë qasjen deri te fajllet. Pronari i fajllit mund të specifikojë lejet sipas të cilave përdoruesit e tjerë i qasen fajllit. Për shembull, pronari mund të specifikojë se përdoruesit e tjerë kanë leje vetëm për lexim të fajllit e jo për shkrim në të.OPEN duhet të kontrollojë thirrësin, nëse ai i ka lejet e duhura. Fajlli mund të jetë pronë e një grupi të përdoruesve. Kapitulli 11 [onlajn] e diskuton sigurinë në detaje, dhe ne këtu do t’i kapërcejmë detajet.

Sistemi i fajlleve i regjistron intervalet kohore të qasjes së fundit, duke përfshirë datën dhe kohën, ndryshimin e fundit në fajll, dhe ndryshimin e fundit në i-nyjen e fajllit. Ky informacion është i rëndësishëm për programet, siç është rezerva rritëse, që duhet të përcaktojë cilat fajlle kanë ndryshuar që nga ekzekutimi i fundit i rezervës. Procedurat e sistemit të fajlleve duhet t’i ndryshojnë këto vlera. Për shembull, READ e ndryshon kohën e fundit për t’u qasur, WRITE e ndryshon kohën e fundit të modifikuar, dhe LINK e ndryshon kohën e fundit të ndryshuar.

OPEN kthen një emër të shkurtër për fajllin, i quajtur përshkruajtës i fajllit (fd), i cili përdor READ, WRITE, dhe CLOSE për emërtim të fajllit. Secili proces fillon me tre fajlle të hapura: “standard in” (përshkruesi i fajllit 0), “standard out” (përshkruesi i fajllit 1), dhe “standard error” (përshkruesi i fajllit 2). Përshkruesi i fajllit mund ta emërtojë pajisjen e tastierës, ekranit, apo fajllin në disk, por programi nuk duhet ta dijë këtë. Kjo i mundëson dizajnuesit të zhvillojë program, duke mos u brengosur se nga vjen hyrja e programit dhe ku shkon dalja e tij; edhe nëse programi vetëm e lexon nga përshkruesi 0 të fajllit dhe e shkruan në përshkruesin 1 të fajllit.

Disa procese mund ta përdorin fajllin në mënyrë konkurrente (p.sh. disa procese mund të shkruajnë te ekrani). Nëse disa procese e hapin fajllin e njëjtë, operacionet e tyre READ dhe WRITE kaneë kursorin e vet të fajllit për atë fajll. Nëse një proces e hap fajllin, dhe e kalon përshkruesin e fajllit, për atë fajll në proces tjetër, atëherë të dy proceset e ndajnë kursorin e fajllit. Rasti i fundit është i përgjithshëm, sepse në sistemin UNIX, kur një proces (prindi) starton një proces tjetër (fëmija), fëmija i trashëgon të gjitha përshkruesit e fajllit nga prindi. Ky dizajn i mundëson prindit dhe fëmijës të ndajnë daljen e përbashkët me saktësi. Nëse fëmija shkruan te fajlli dalës, për shembull, pasi e ka shkruar prindi, dalja e fëmijës shfaqet pas daljes së prindit, sepse ato e ndajnë kursorin.

Nëse një proces ka fajll të hapur dhe procesi tjetër e fshin emrin e fundit që tegon te ai fajll, i-nyja nuk është e lirë derisa procesi i parë ta thërret CLOSE.

Për t’i mbështetur këto veçori, i-nyja zgjerohet si në vijim:


110

structure inyje integer numri_bllokut [ N ] //numri i blloqeve që përbëjnë fajllin integer madhesia // madhesia e fajllit në bajte integer tipi // tipi i inyjes: fajll i rëndomtë, skedar, lidhje simbolike, . . . integer numref // numëratori i emrave për këtë i-nyje

integer idperdorues // ID e përdoruesit që e posedon këtë i-nyje integer idgrupit // ID e grupit që e posedon këtë integer modi // lejet për i-nyjen integer kohaq // koha e qasjes së fundit ( READ , WRITE , . . . ) integer koham // koha e modifikimit të fundit integer kohan // koha e ndryshimit të fundit të i-nyjes

Për të implementuar OPEN, READ, WRITE, dhe CLOSE, sistemi i fajlleve në memorie ruan disa tabela: një tabelë për fajllin (tabela_fajllit) dhe për secilin proces një tabelë përshkruese të fajllit (tabela_pf). Tabela e fajllit regjistron informacione për fajllet që i kanë hapur proceset (p.sh. fajllet për të cilat OPEN ka qenë i suksesshëm, por për të cilat CLOSE nuk është thirrur akoma). Për çdo fajll të hapur, ky informacion përfshin numrin e i-nyjes të fajllit, kursorin e tij të fajllit, dhe numëratorin e referencës që regjistron se sa procese e kanë hapur fajllin. Tabela për përshkrimi e fajllit regjistron për çdo përshkrues të fajllit indeksin, deri te tabela e fajllit. Pasi që kursori i fajllit është i ruajtur në tabela_fajllit dhe jo në tabela_pf, fëmijët mund të ndajnë kursorin për një fajll të trashëguar me prindërit e tyre.

Me këto informacione që kemi, OPEN implementohet si vijon:

1 procedure OPEN (character string emrifajllit , flamur, modi) 2 numri_inyjes ←RRUGA_TE_NUMRI_INYJES (emrifajllit, wd ) 3 if numri_inyjes = FAILURE and flamur = O_CREATE then // Krijon fajllin? 4 numri_inyjes ←CREATE (emrifajllit, modi) // Po, krijoje atë. 5 if numri_inyjes = FAILURE then 6 return FAILURE 7 inyja ←NUMRI_INYJES_TE_INYJA (numri_inyjës) 8 if PERMITTED (inyja, flamur) then // A i ka ky përdorues lejet e nevojshme 9 indeksi_fajllit ←INSERT ( tabela_fajllit , numri_inyjës) 10 fd ←FIND_UNUSED_ENTRY (tabela_pf ) // Gjeji hyrjet në tabelen përshkruese të fajllit 11 tabela_pf [ fd ] ←indeksi_fajllit // Regjistro indeksin e fajllit për përshkruesin e fajllit 12 return fd // Kthej fd 13 else return FAILURE // Jo, kthej deshtim

Rreshti 2 e gjen numrin e i-nyjes për emrifajllit të fajllit. Nëse fajlli nuk ekziston, por thirrësi dëshiron ta krijojë atë, ashtu siç është shënuar me flamur O_CREATE (rreshti 3), OPEN e thërret CREATE, e cila e përcakton i-nyjen, e starton atë, dhe e kthen numrin e saj të i-nyjes (rreshti 4). Nëse fajlli nuk ekziston (edhe pas tentativës për ta krijuar atë), OPEN kthen vlerën që tregon dështim (rreshti 6). Rreshti 7 e gjen i-nyjen. Rreshti 8 e përdor informacionin e i-nyjes për të kontrolluar nëse thirrësi ka leje për ta hapur fajllin; kontrolli është përshkruar në detaje në Seksionin 11.6.3.4 [onlajn]. Nëse është kështu, rreshti 9 e krijon hyrjen e re për numrin e i-nyjes në tabelën e fajllit dhe e vendos kursorin e hyrjes së fajllit në zero , ndërsa numëratorin e referencës në 1. Rreshti 10 e gjen përshkruesin e parë të fajllit, i cili është i papërdorur, e regjistron në indeksin e tij të fajllit, dhe e kthen vlerën e përshkruesit të fajllit te thirrësi (rreshtat 10 deri 12). Në të kundërtën, do ta kthejë vlerën që tregon dështim (rreshti 13).


111

Nëse procesi starton një proces tjetër, procesi i fëmijës i trashëgon përshkruesit e hapur të fajllit të prindit. Pra, informacioni në çdo hyrje të përdorur në tabela_pf kopjohet në hyrjen e njejtë të numëruar në tabela_pf të fëmijës. Si rezultat, hyrjet për prindin dhe fëmijën në tabela_pf do të tregohen te hyrja e njëjtë në tabela_fajllit, duke rezultuar me kursor të ndarë ndërmjet prindit dhe fëmijës.

READ implementohet si në vijim:

1 procedure READ (fd, character array reference buf, n) 2 indeksi_fajllit ←tabela_pf [ fd ] 3 kursor ←tabela_fajllit [ indeksi_fajllit ]. cursor 4 inyja ←NUMRI_INYJES_TE_INYJA(tabela_fajllit[indeksi_fajllit].numri_inyjes) 5 m = MINIMUM(inyja.madhesia – kursor, n) 6 kohaq of inyja ←NOW() 7 if m = 0 then return END_OF_FILE 8 for i from 0 to m – 1 do { 9 b ←NUMRI_INYJES_TE_BLLOKU (i, numri_inyjes) 10 COPY(b, buf, MINIMUM (m – i , BLOCKSIZE)) 11 i ←i + MINIMUM (m – i, BLOCKSIZE ) 12 tabela_fajllit [indeksi_fajllit].cursor ←cursor _ m 13 return m

Rreshtat 2 dhe 3 e përdorin indeksin e fajllit për të gjetur kursorin e fajllit. Rreshti 4 e gjen i-nyjen. Rreshti 5 dhe 6 njehson se sa bajta mund të lexojë READ dhe e përditëson kohën e fundit të qasjes. Nëse nuk ka bajte të mbetura në fajll, READ kthen vlerën që tregon fundin e fajllit. Rreshtat nga 8 deri 12 i kopjojnë bajtet nga blloqet e fajllit, në buferin e thirrësit. Rreshti 13 e përditëson/ndryshon kursorin.

Mund të dizajnohet skemë emërtuese akoma më e sofistikuar për READ që, për shembull, do mundësojë emërtim me fjalë kyçe dhe jo me zhvendosje. Sistemet e bazave të të dhënave, zakonisht, implementojnë skema të tilla emërtuese, duke paraqitur të dhënat si regjistrime të strukturuara që indeksohen sipas fjalëve kyçe. Por me qëllim të bërjes së dizajnit sa më të thjeshtë, sistemi i fajllave në UNIX e kufizon paraqitjen e fajllit në një fushë lineare bajtesh.

Implementimi i WRITE është i ngjashëm me READ. Dallimet kryesore janë se ai e kopjon buf në blloqet e i-nyjes, duke përcaktuar blloqe të reja sipas nevojës, dhe e përditëson madhesia dhe koham të inyjes.

CLOSE e liron hyrjen në tabelën e përshkrimit të fajllit dhe e zvogëlon numëratorin e referencës në hyrjen e tabelës së fajllit. Nëse asnjë proces tjetër nuk e ndan këtë hyrje (p.sh., numëratori i referencës ka arritur në zero), CLOSE po ashtu do ta liroj hyrjen në tabelën e fajllit. Nëse nuk ka hyrje tjera në tabelën e fajllit që e përdorin këtë fajll dhe numëratori i fajllit në i-nyjen e fajllit është bërë zero (pasi që një proces tjetër e ka ç’kyçur atë), atëherë CLOSE e liron i-nyjen.

Ashtu si edhe RENAME, shumë nga këto operacione kërkojnë disa shënime në disk për t’u kompletuar. Nëse sistemi i fajllit dështon (p.sh., për shkak të ndërprerjes së rrymës( në mes të këtyre operacioneve, atëherë disa nga shkrimet në disk mund të jenë kompletuar dhe disa jo. Një dështim i tillë mund të shkaktojë paqëndrueshmëri ndër strukturat e të dhënave të


112

diskut. Për shembull, lista e lirë në disk tregon se blloku është i përcaktuar, por asnjë i-nyje nuk e regjistron atë bllok në indeksin e tij. Nëse nuk ndërmerret asgjë për këtë paqëndrueshmëri, atëherë ai bllok praktikisht humbet. Tërësia e problemeve 8 e eksploron këtë problem dhe zgjidhjen e thjeshtë me një rast special. Kapitulli 9 [onlajn] i eksploron zgjidhjet sistematike. Versioni 6 (dhe të gjitha implementimet moderne) ka një kesh brenda memories për blloqet e diskut që përdoret më së fundmi. Kur sistemi i fajlleve kërkon një bllok, së pari e kontrollon keshin për atë bllok. Nëse blloku gjendet aty, e përdor bllokun e keshit; përndryshe e lexon atë nga pajisja ruajtëse. Me keshin, edhe nëse sistemi i fajlleve kërkon të lexojë bllokun e caktuar disa herë, e lexon bllokun e tillë nga pajisja deponuese vetëm njëherë. Meqë leximi nga njësia e diskut është shpeshherë një operacion i shtrenjtë, keshi mund ta përmirësojë rrënjësisht performancën e sistemit të fajlleve. Kapitulli 6 e diskuton implementimin e kesheve në detaje dhe mënyrën se si mund të përdoren ato për të përmirësuar performancën e sistemit të fajllit. Në mënyrë të ngjashme, për të arritur performancë të lartë te operacionet që e modifikojnë fajllin (p.sh., WRITE), sistemi i fajlleve do të përditësojë blloqet e fajlleve në kesh, por nuk do ta shtyjë i-nyjen e fajllit të modifikuar dhe blloqet menjëherë në pajisjen ruajtëse. Sistemi i fajllave e vonon shkrimin ashtu që nëse blloku përditësohet disa herë, do ta shkruaj bllokun vetëm një herë. Si rrjedhim, mund të bashkoj disa përditësime në një shkrim (shih Seksionin 6.1.8).

Nëse procesi dëshiron të sigurojë se rezultatet e shkrimit dhe ndryshimet e i-nyjes janë përhapur nëpër pajisjen që e ruan sistemin e fajllit, duhet ta thirrë FSYNC; specifikimi i UNIX kërkon që nëse një thirrje e FSYNC për një fajll kthen vlerë, të gjitha ndryshimet te fajlli duhet të jenë të shkruara në pajisjen ruajtëse.

2.5.12 Shelli dhe Kontekstet e Vetëkuptuara, Rrugët e Kërkimit, dhe Zbulimi i Emrave

Me përdorimin e sistemit të fajlleve API, sistemi UNIX implementon programe për përdorues që të manipulojnë fajllet dhe hapësirat e emrave. Këto programe përfshijnë edituesit e teksteve (siç janë ed, vi, dhe emacs), rm (për fshirjen e fajlleve), ls (për listimin e përmbajtjes së skedarit), mkdir (për krijimin e skedarëve të rinj), dhe find (për kërkimin e fajllit në pemën me skedarë).

Një nga programet më interesant të UNIX është interpretuesi i komandave, i njohur si “shell”. Shell ilustron një numër me skema tjera emërtuese të UNIX. Le të themi se përdoruesi dëshiron të kompajlojë një fajll burimor C të emëruar si “x.c”. Me marrëveshje mbingarkohet emri i fajllit, duke i shtuar një prapashtesë që tregon tipin e fajllit, siç është “.c” për fajllet burimore në C. (Diskutim të plotë për mbingarkimin mund të gjeni në Seksionin 3.1.2.) Përdoruesi e shtyp këtë komand në shell:

cc x.c

Kjo komandë përbëhet nga dy emra: emri i programit (kompajluesi “cc”) dhe emri i fajllit që përmban kodin burimor (“x.c”) për kompajluesin që duhet të kompiloj. Gjëja e parë që shell duhet të bëjë është të gjendet programi me të cilin do të ekzekutohet “cc”. Për ta bërë


113

këtë, interpretuesi i komanave në UNIX e përdor referencën kontekstuale që është në ndryshoren e mjedisit të emëruar PATH (Rruga). Kjo ndryshore e mjedisit përmban një listë me kontekste, (në këtë skedar të rastit) te të cilat kryhet kërkim i shumëfishtë për gjërat e emërura si “cc”. Duke supozuar se kërkimi është i suksesshëm, shell lëshon programin, duke e thirrur atë me argumentin “x.c”.

Gjëja e parë që bën kompiluesi është vendosja e emrit “x.c”. Kësaj rradhe shfrytëzon referencë të ndryshme kontekstuale: skedarin punues. Duke qenë kompajlimi në rrugë e sipër, fajlli “x.c” mund të përmbajë referenca për te fajllet tjerë të emëruar, për shembull, deklarime si

#include <stdio.h>

Ky deklarim i tregon kompiluesit që t’i përfshijë të gjitha definicionet e fajllit “stdio.h” në fajllin “x.c”. Për ta vendosur “stdio.h”, kompiluesit i duhet konteksti ku do ta vendosë. Për këtë qëllim, kompiluesi konsulton një tjetër ndryshore (zakonisht e kaluar si një argument kur thirret kompiluesi), e cila përmban kontekstin e definuar që do të përdoret si rrugë/shteg kërkimi ku mund të gjenden fajllet për përfshirje (include). Ndryshoret e përdorura nga shelli dhe kompiluesi përbëhen nga një seri me emra të rrugës që përdoren si bazë për një kërkim të shumëfishtë, ashtu si është përshkruajtur në Seksionin 2.2.4.

Shumë programe të tjera të UNIX, si paketi për dokumentim, man, kryen kërkim të shumëfishtë për fajllet që përdorin rrugët e kërkimit të cilat ndodhen në ndryshoret mjedisore.

Shell i vendos emrat e komandave duke përdorur ndryshoren PATH, por disa herë është më e përshtatshme të thuhet “Dua t’i ekzekutoj programet që ndodhen në skedarin punues aktual”. Për shembull, përdoruesi mund të zhvilloj një version të ri të kompiluesit C, i cili po ashtu quhet “cc”. Nëse përdoruesi e shtyp “cc”, shell do të kërkoj kompiluesin C duke përdorur ndryshoren PATH dhe e gjen atë që është më standard, në vend të një të riu në skedarin punues aktual.

Për të tilla raste, përdoruesit mund të shtypin komandën vijuese:

./cc x.c

që e tejkalon ndryshoren PATH dhe e thërret programin me emrin “cc” në skedarin aktual punues (“.”).

Sigurisht që përdoruesi mund ta fus (“.”) në fillim të ndryshores PATH, ashtu që të gjitha programet në skedarin punues të përdoruesit do t’i paraprijnë programit standard korrespondues. Kjo praktikë, megjithatë, mund të krijojë surpriza. Të supozojmë se “.” Është hyrja e parë në ndryshoren PATH, dhe përdoruesi e lëshon sekuencën vijuese me komanda në shell:

cd /usr/potluck ls

me qëllim të listimit të përmbajtjeve të skedarit me emër potluck. Nëse ai skedar përmbante programin me emrin ls që bën diçka krejt tjetër nga komanda standarde ls, diçka e papritur


114

mund të ndodhte (p.sh. programi i emëruar ls mund t’i fshijë të gjitha fajllet private)! Për këtë qëllim, nuk është ide e qëlluar për të përfshirë emrat që janë të varura në kontekste, si “.” ose “..” te rruga e kërkimit. Më mirë është që të përfshihet emri absolut i rrugës të skedarit të dëshiruar përpara PATH.

Përmirësim tjetër i interpretuesit të komandave bëhet kur emrat mund të jenë përshkrues dhe jo emra të thjeshtë. Për shembull, emri përshkrues “*.c”, përputhet me të gjitha emrat e fajllave që mbarojnë me “.c”. Për të bërë këtë përmirësim, interpretuesi i komandave e transformon argumentin e vetëm në një listë me argumente, (me ndihmën e më shumë operacioneve të kërkimit në hyrjet e kontekstit) përpara se ta thërrasë programin e specifikuar të komandës. Në shell, përdoruesit mund të përdorin shprehje të rregullta për emrat përshkrues.

Si shënim përfundimtar, në praktikë hapësira emërtuese e objekteve në UNIX ka një strukturë mjaft konvencionale. Në veçanti, ekzistojnë disa skedarë të caktuar, me emrat e mirënjohur, siç janë përshembull, programet e emrave “/bin”, fajllet për konfigurim të emrave “/etc”, emrat e pajisjeve hyrëse/dalëse “/dev”, dhe skedarët e përdoruesve “/usr” (dhe jo root). Me kalimin e kohës këto konventa janë ngulitur në mendjet e programuesve dhe në programet ku nuk instalohen si duhet softuerët e UNIX, dhe magjistari i UNIX do të bëhet tepër konfuz, kur të ballafaqohet me një sistem që nuk i përfill këto konventa.

2.5.13 Sugjerime për Lexim Plotësues Për përshkrim të detajuar të sistemit operativ modern UNIX, shihni librin që

përshkruan sistemin operativ BSD [Sugjerime për Lexim Plotësues 1.3.4]. Pasardhësi i sistemit original UNIX është Plan 9 [Sugjerime për Lexim Plotësues 3.2.2], i cili përmban një numër të abstraksioneve të reja emërtuese, disa prej të cilave kanë gjetur zbatim te implementimet më të reja të UNIX. Gjendet edhe një literaturë e pasur për përshkrimin e implementimeve të sistemit të fajllave dhe ekuilibrimeve të tyre. Një pikë e mirë fillestare janë artikujt mbi FFS [Sugjerime për Lexim Plotësues 6.3.2], LFS [Sugjerime për Lexim Plotësues 9.3.1], dhe përditësimet e buta [Sugjerime për Lexim Plotësues 6.3.3].

USHTRIME

2.1 Ben Bitdiddle ka pranuar një punë në një kompani telefonike dhe është pyetur të implementojë rikahëzimin e thirrjes. Ai është menduar se çka do të ndodhë, nëse dikush i rikahëzon thirrjet në ndonjë numër dhe pastaj pronari i atij numri i rikahëzon thirrjet në një numër të tretë. Deri tani, Ben ka menduar për dy mundësi për implementimin e tij:

a) Më ndiq mua! Bob do të shkoj në aheng te shtëpia e Mary në mbrëmje, dhe ai e rikahëzon thirrjen telefonike të tij te Mary. Ann është ruajtëse fëmijësh për


115

Bon, dhe ajo e rikahëzon telefonin e saj te Bon. Jim e thërret numrin e Ann, cingëron numri i Bob, dhe përgjigjet Ann.

b) Delegimi. Bob do shkoj në aheng te shtëpia e Mary në mbrëmje, dhe ai e rikahëzon thirrjen telefonike të tij te Mary. Ann nuk do jetë për një javë në shtëpi dhe e ka rikahëzuar telefonin e saj te Bob ashtu që ai të mund t’u përgjigjet thirrjeve të saj. Jim e thërret numrin e Ann, cingëron telefoni i Mary, dhe Mary ia dorëzon telefonin B që të përgjigjet.

2.1a Duke përdorur terminologjinë e seksionit të emërtimit të këtij kapitulli, sqaroi këto dy mundësi! 2.1.b Çfarë mund të shkojë keq nëse Bob tashmë e ka rikahëzuar telefonin e tij te Mary përpara se Ann e rikahëzon telefonin e saj te ai? 2.1c Kompania e telefonit zakonisht ofron Delegim dhe jo Më ndiq. Përse?

2.2 Konsideroni pjesën e hierarkisë emërtuese të sistemit të fajlleve të ilustruar më poshtë:

Ju e keni emrin e rrugës si në vijim:

/projects/systems/exercises/Ex.2.2

1995–2–1a 2.3 Një mënyrë e përshpejtimit rë vënies së emrave është implementimi i keshit që i mban mend çiftet {emër, objekt} që janë kërkuar së fundmi.

2.3a Çfarë problemesh implikojnë sinonimet për dizajnuesit e keshit, krahasuar me keshet që nuk i mbështesin sinonimet?

1994–2–3 2.3a Propozoni një mënyrë të zgjidhjes së problemeve, nëse çdo objekt ka nj ID unike.

1994–2–3a

Konsideroni pjesën e sistemit të fajllave


116

2.4 Louis Reasoner është brengosur për efikasitetin e implementimit të rregullës së kërkimit në sistemin Eunuchs (një version më i dobër i sistemi UNIX). Ai propozon që të shtojë një tabelë për objekte të referencuara (TOR), të cilën do ta mirëmbajë sistemi për çdo sesion të çdo përdoruesi, dhe është e vendosur të jetë e zbrazët kur logohet përdoruesi. Kurdo që sistemi vendos emra nëpërmjet përdorimit të rrugës së kërkimit, e bën një hyrje në TOR e përbërë nga emri dhe emri i rrugës së atij objekti. Rregulla e kërkimit “tashmë të referencuara” kërkon për TOR për të përcaktuar nëse emri shfaqet atje. Nëse gjendet një përputhje, atëherë vendosësi do ta përdor emrin e rrugës së asocuar nga TOR. Louis propozon që gjithmonë të përdoret së pari rregulla “tashmë të referencuara”, e ndjekur nga mekanizmi për kërkim tradicional. Ai deklaron se përdoruesi nuk do të zbulojë ndonjë dallim, përveç vënies së shpejtë të emrave. A ka të drejtë Louis?

1985–2–2

2.5 Rreshti i fundit në Figurën 2.4 emërton tre web shfletues si shembuj të interpretuesve. Sqaroni si është e mundur që web shfletuesi të jetë një interpretues duke identifikuar instruksionet e tij të referencës, repertorin e tij, dhe referencën e tij të mjedisit!

2009-0-1

Ushtrime plotësuese në lidhje me Kapitullin 2 mund të gjeni në tërësinë me probleme që fillojnë në faqen 425.

elementet e organizimit 2 - · pdf filekapitulli 2 elementet e organizimit të sistemit...

Documents