Zoltan Geller Operativni sistemi Beleke sa predavanja profesora Zorana Budimca 2000/2001 * * Univerzitet u Novom Sadu Prirodno-matemati?

ki fakultet Departman za matematiku i informatiku * * * * * * * * 2003 * * * * * * * * * * * * * * SADRAJ SADRAJ... 1<#_Toc41802215> PREDGOVOR..... 6<#_Toc41802216> UVOD..... 7<#_Toc41802217> ta je operativni sistem ?. 7<#_Toc41802218> Istorija operativnih sistema.... 8<#_Toc41802219> Osnovni pojmovi, koncepti OS-a.... 10<#_Toc41802220> Procesi. 10<#_Toc41802221> Stanja procesa.. 11<#_Toc41802222> PCB Process Control Block.. 12<#_Toc41802223> Operacije sa procesima.. 13<#_Toc41802224> Odnos procesa.. 13<#_Toc41802225> Podela operativnih sistema u odnosu na procese.. 13<#_Toc41802226> Teki i laki procesi. 13<#_Toc41802227> Konkurentno programiranje.. 15<#_Toc41802228> Fajl sistem . 15<#_Toc41802229> Sistemski pozivi . 16<#_Toc41802230> Komandni interpreter . 16<#_Toc41802231> Prekidi . 16<#_Toc41802232> Jezgro OS-a . 18<#_Toc41802233> Dizajn, struktura operativnih sistema.... 18<#_Toc41802234> Monolitni sistemi . 18<#_Toc41802235> Slojevita realizacija . 19<#_Toc41802236> Virtuelne maine . 20<#_Toc41802237> Klijent-server model . 20<#_Toc41802238> SINHRONIZACIJA PROCESA..... 21<#_Toc41802239> Kriti?na oblast.... 21<#_Toc41802240> Softverska realizacija kriti?ne oblasti.. 22<#_Toc41802241> Dekkerov algoritam..... 26<#_Toc41802242> Petersenov algoritam..... 27<#_Toc41802243> Hardverska realizacija kriti?ne oblasti.. 28<#_Toc41802244> Realizacija pomo?u sistemskih poziva.... 30<#_Toc41802245> Sleep & WakeUp... 30<#_Toc41802246> Semafori . 32<#_Toc41802247> Broja?i doga?aja . 34<#_Toc41802248> Monitori i USLoVNE PROMENLJIVE... 36<#_Toc41802249> Ekvivalencija sistema za sinhronizaciju procesa... 38<#_Toc41802251> Implementacija monitora kori?enjem semafora.. 38<#_Toc41802252> Implementacija semafora pomo?u monitora.. 40<#_Toc41802253> Klasi?ni problemi sinhronizacije.... 41<#_Toc41802254> Problem jedu?ih filozofa... 41<#_Toc41802255> Problem ?itaoca i pisaca... 44<#_Toc41802256> Problem uspavanog berberina... 46<#_Toc41802257> Komunikacija tekih procesa.... 47<#_Toc41802258> Dispe?er . 49<#_Toc41802259> UPRAVLJANJE MEMORIJOM....... 54<#_Toc41802260> Upravljanje memorijom bez swappinga i paginga.... 55<#_Toc41802261> Monoprogramiranje . 55<#_Toc41802262> Multiprogramiranje . 56<#_Toc41802263> Fixne particije... 56<#_Toc41802264> Relokacija i zatita... 57<#_Toc41802265> Upravljanje memorijom sa swappingom..... 58<#_Toc41802266> Multiprogramiranje sa promenljivim particijama 59<#_Toc41802267> Strukture podataka za upravljanje memorijom..... 59<#_Toc41802268> Bitne mape 59<#_Toc41802269> Povezane liste 60<#_Toc41802270> Sistem drugova 61<#_Toc41802271> Algoritmi za izbor prazne particije... 62<#_Toc41802272> Virtuelna memorija.... 63<#_Toc41802273> Overlay... 63<#_Toc41802274> Virtuelna
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

PRO version

memorija... 63<#_Toc41802275> Paging (strani?enje). 64<#_Toc41802276> Izbor stranica za u?itavanje . 66<#_Toc41802277> Izbor stranica za izbacivanje... 67<#_Toc41802278> Dalji problemi strani?enja... 70<#_Toc41802279> Belady-jeva anomalija... 70<#_Toc41802280> Radni skup (Working Set). 71<#_Toc41802281> Lokalnost i globalnost.. 71<#_Toc41802282> Segmentacija . 72<#_Toc41802283> FAJL SISTEM....... 74<#_Toc41802284> Fajl sistem sa korisni?ke ta?ke gledita.... 74<#_Toc41802285> Fajlovi . 74<#_Toc41802286> Imenovanje 74<#_Toc41802287> Struktura fajlova 75<#_Toc41802288> Tipovi fajlova 75<#_Toc41802289> Na?in pristupa fajlovima 75<#_Toc41802290> Atributi fajlova 75<#_Toc41802291> Operacije sa fajlovima 76<#_Toc41802292> Direktorijumi . 76<#_Toc41802293> Operacije sa direktorijumima.. 77<#_Toc41802294> Realizacija fajl sistema.... 77<#_Toc41802295> Neiskori?eni blokovi. 78<#_Toc41802296> Implementacija fajlova (zauzeti blokovi). 79<#_Toc41802297> Implementacija direktorijuma... 82<#_Toc41802298> Linkovi. 83<#_Toc41802299> Pouzdanost i performanse fajl sistema.... 83<#_Toc41802300> Pouzdanost fajl sistema... 84<#_Toc41802301> Loi blokovi. 84<#_Toc41802302> Sigurnosne kopije (backup). 84<#_Toc41802303> Konzistentnost 84<#_Toc41802304> Performanse fajl sistema... 85<#_Toc41802305> Optimizacija diska.... 86<#_Toc41802306> Algoritmi za optimizaciju pomeranja glave... 87<#_Toc41802307> ZAGLAVLJIVANJE.... 87<#_Toc41802308> Resursi 88<#_Toc41802309> Zaglavljivanje 88<#_Toc41802310> Prevencija . 89<#_Toc41802311> Izbegavanje . 90<#_Toc41802312> Bankarov algoritam... 90<#_Toc41802313> Detekcija . 92<#_Toc41802314> Oporavak . 92<#_Toc41802315> Izgladnjivanje . 93<#_Toc41802316> SIGURNOST I ZATITA..... 93<#_Toc41802317> Sigurnost.... 93<#_Toc41802318> Nekoliko poznatih greaka u ranijim operativnim sistemima 94<#_Toc41802319> ta treba da radi osoba koja provaljuje ?.. 95<#_Toc41802320> Principi za ostvarivanje sigurnosti. 95<#_Toc41802321> Provera identiteta... 95<#_Toc41802322> Kako izabrati lozinku i da li je ona dovoljna?.. 96<#_Toc41802323> Zatita.... 96<#_Toc41802324> PREDGOVOR Skripta koju upravo ?itate predstavlja beleke sa predavanja profesora Zorana Budimca iz predmeta Operativni Sistemi, odranih 2000/2001 godine, Prirodno-Matemati?ki Fakultet, Novi Sad. Nastala je na osnovu slede?ih knjiga, skripti i beleaka : 1. Sveska sa belekama slede?ih studenata : Zoltan Geller, Igor Mladenovi?, Agne Sepei 2. Andrew S. Tanenbaum : Modern Operating Systems 3. Skripta Dejana pegara 4. Beny Balzs, Fk Mrk, Kiss Istvn, Kczy Annamria, Kondorosi Kroly, Mszros Tams, Romn Gyula, Szebernyi Imre, Sziray Jzsef: Opercis Rendszerek Mrnki Megkzeltsben 5. Knapp Gbor, Dr.Adamis Gusztv: Opercis Rendszerek 6. Zoran Budimac, Mirjana Ivanovi?, ?ura Pauni?: Programski jezik Modula-2 7. Dragoslav Peovi?: Sinhronizacija procesa (skripta) Poglavlje SIGURNOST I ZATITA je u celosti i bez promena preuzet iz
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

Sinhronizacija procesa (skripta) Poglavlje SIGURNOST I ZATITA je u celosti i bez promena preuzet iz skripte Dejana pegara. UVOD * *Softver se moe podeliti u dve grupe: 1. *sistemski programi* upravljaju ra? unarom 2. *korisni?ki* (*aplikacioni*)*programi* reavaju probleme korisnika Operativni sistem je fundamentalni deo sistemskih programa, ?iji je zadatak upravljanje resursima ra?unara i koji obezbe?uje osnovu za pisanje aplikacionih programa. Kako obezbe?uje OS osnovu za pisanje aplikacionih programa? Odgovor: Ra?unar je kompleksni sistem sastavljen od raznih delova, kao to su: procesor, memorija, diskovi, tastatura, mi, tampa?, skener itd. Pisanje programa na taj na?in da se ti delovi ra?unara programiraju direktno je vrlo teak posao. Zato je dolo do ideje da se stavi jedan sloj izme?u aplikacionih programa i hardvera. Uloga tog sloja je da obezbedi neki interfejs (ili *virtuelnu mainu*) ostalim programima radi lakeg i bezbednijeg pristupa hardveru. Taj sloj je upravo OS. Sada imamo slede?u situaciju: office baze podataka igre *Korisni?ki programi* kompajleri,interpreteri editori linkeri * Sistemski programi* operativni sistem mainski jezik *HARDVER* mikro programi fizi?ki ure?aji Na najniem nivou imamo *fizi?ke ure?aje* fizi?ki delovi ra?unara. Iznad tog sloja su *mikro programi * direktno kontroliu fizi?ke ure?aje i obezbe?uju interfejs prema slede?em nivou. Predstavljaju elementarne korake od kojih se sastoje instrukcije mainskog jezika. *Mainski jezik *je skup instrukcija koje procesor direktno razume (izvrava ih pomo?u svojih mikro programa). Glavna funkcija operativnog sistema je sakrivanje detalje ovih niih nivoa od ostalih programa i pruanje niza jednostavnijih instrukcija za pristup hardveru. ta je operativni sistem ? * * *1. **OS kao proirena *(*extended*)*ili virtuelna *(*virtual*)*maina *arhitektura (niz instrukcija, organizacija memorije, IO, itd.) ra?unara na nivou mainskog jezika je primitivna i nije pogodna za programiranje. Kao primer, moemo uzeti /NEC PD765/ kontroler za disketni ure?aj (koristi se na personalnim ra?unarima). Taj kontroler ima 16 komandi. Najosnovnije komande su /READ/ i /WRITE/ i zahtevaju 13 parametara koja su smetena u 9 bajtova. Prilikom pristupa disketnom ure?aju, treba voditi ra?una o tome, da li je motor uklju?en, pa treba na?i stazu, pa sektor itd - i to bi trebalo raditi svaki put kada elimo neto pisati ili ? itati sa diskete. Zadatak OS-a kao proirene ili virtuelne maine je upravo to da te stvari radi umesto nas i da nam prua neke funkcije vieg nivoa apstrakcije radi pristupa hardveru. *2. **OS kao upravlja? resursima *(*resource manager*)** *RESURS *obuhvata sve to je programu potreban za rad (memorija, procesor, disk, tampa?, skener, itd.). Kao upravlja? resursima OS ima zadatak, da vodi ra?una u resursima ra?unara da zadovolji potrebe programa, da prati koji program koristi koje resurse, itd. Primer: imamo viekorisni?ki sistem: dva korisnika istovremeno ele neto tampati OS je duan da vodi ra?una o tome da programi tih korisnika do?u do tampa?a kao resursa i da se podaci ne meaju * * * * * * * * * * Istorija operativnih sistema * * * * * * * * * * * *Istoriju operativnih sistema ?emo posmatrati preko istorije ra?unara: *1. **Generacija: *(1945-1955)
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

PRO version

- ra?unari pravljeni od *vakuumskih cevi*. Ra?unari su bili ogromnih dimenzija i jako skupi (koristio ih je vojska), u jednom ra?unaru je bilo ?ak i do 20.000 cevi, bili su jako spori, programirao se na mainskom jeziku, programski jezici (ulku?uju?i i asemblera) i operativni sistemi su bili nepoznati. Ljudi koji su radili na tim ra?unarima radili su sve: od programiranja do odravanja ra?unara. *2. **Generacija: *(1955-1965) ra?unari se prave od *tranzistora*, postaju manji, pouzdaniji i jeftiniji tako da su ih mogli kupovati (pored vojske) i velike korporacije, univerziteti itd. Ra? unari su bili odvojeni u posebnim sobama. Programeri piu programe na papiru u programskom jeziku /FORTRAN/, zatim se ti programi prenose na buene kartice. Buene kartice se ostavljaju u sobi sa poslovima (input room). Sistem operator pokupi buene kartice, u ra?unar ubaci kartice sa /FORTRAN/ kompajlerom, pa buene kartice sa programom koji treba izvriti. Ra?unar odradi posao i razultat se dobija isto na buenim karticama, koje se prenose u prostoriju sa rezultatima (output room). Ovde se mnogo vremena troi na etanje izme?u raznih prostorija sa buenim karticama. Jo uvek nema operativnog sistema. Uvodi se slede?e poboljanje: - *paketna obrada* (*batch system*) u sobi sa poslovima se sakuplja jedna koli?ina sli?nih (npr. svi zahtevaju fortran kompajler) poslova (programa), koji se pomo?u jeftinijeg ra?unara (npr. /IBM 1401/) prenosi na magnetnu traku. Nakon toga se magnetna traka prenosi u sobu sa glavnom ra?unarom mo?niji i skuplji ra?unar predvi?en za izvravanje programa (npr. /IBM 7094/), na glavni ra?unar se u?itava poseban program koji je zaduen da sa trake sa poslovima redom u?itava programe i izvrava ih. Taj program je *predak dananjih OSa*. Nakon izvravanja programa, rezultat se snima na drugu magnetnu traku. Kada su svi poslovi (programi) odra? eni, operator stavlja drugu traku sa programima, a traku sa rezultatima prenosi do tre?eg ra?unara koji je zaduen za prebacivanje rezultata sa magnetne trake na buene kartice to je ponovo neki jeftiniji ra?unar (npr. /IBM 1401/). Manji ra?unari nisu vezani za glavni ra?unar, rade *off-line*. Tipi?an izgled poslova (na karticama): $JOB, ,programer,. // ime posla i neki podaci $FORTRAN // treba nam FORTRAN kompajler fortranski program // program u FORTRANU koji treba prevesti $LOAD // u?itaj preveden program $RUN // izvri program sa slede?im podacima : ulazni podaci $END // kraj posla *3. **Generacija :*(1965-1980) ra?unari se prave od *integrisanih kola* (/IC/) po?etkom 60-ih ve?ina proizvo?a?a ra?unara proizvodi dve vrste ra?unara : jednu ja?u verziju (kao /IBM 7094/) i jednu slabiju (kao /IBM 1401/) to je skup poduhvat. Novi korisnici ra?unara ele slabije ra?unare koji su jeftiniji, a posle nekog vremena treba im ja?i model koji je u stanju da izvri sve stare programe, ali bre. /IBM/ taj problem pokuava reiti uvo?enjem *Systema*/*360*. To je *serija kompatibilnih ra?unara razli?itih snaga*. Svaki od ovih ra?unara je pogodan i za nau?nu i za poslovnu primenu, pa je time podela ra?unara na dve vrste nestala. Ovaj koncept su preuzeli i ostali proizvo?a?i ra?unara. Ra?unari iz serije /System/360/ su radili pod *operativnim sistemom OS/360* koji je bio jako glomazan i prepun greaka. Razvija
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

/System/360/ su radili pod *operativnim sistemom OS/360* koji je bio jako glomazan i prepun greaka. Razvija se nova disciplina : *softversko innjerstvo*. *Multiprogramiranje (multiprogramming) :*kada program ?eka na rezultate IO operacija, procesor je neiskori?en, pa se javlja gubljenje procesorskog vremena to nije problem kod nau?no-orijentisanih programa, koji retko koriste IO operacije, ali jeste kod poslovnih programa. Kao reenje, javlja se multiprogramiranje: memorija se deli na particije u kojima se u?itavaju razli?iti programi (jobs-poslovi). Dok neki program ?eka na neke IO operacije, procesor moe izvravati drugi program. Na taj na?in, ako imamo dovoljan broj programa u memoriji, procesor je u stalnoj upotrebi. *SPOOL*(*/S/*/imultaneous *P*eripheral *O*peration *O*n *L*ine/) prebacivanje sadraja buenih kartica na disk (traku) pomo?u posebnog ure?aja a bez procesora. Zna?i procesor izvrava program u memoriji, a paralelno se disk puni novim poslovima (jobs,programi). Kada jedan program zavri sa radom, procesor na njegovo mesto moe u?itati drugi program sa diska. Isto se koristi i za izlazne podatke. *Podela vremena (time-sharing*)*: *kod prve generacije, imali smo jednu grupu ljudi koji su koristili ra?unar, programer je napisao program, ubacio u ra?unar i dobio rezultate, nije ? ekao na obradu ostalih programa (jobs). Kod paketne obrade programer donese program na buenim karticama, pa na rezultate ponekad ?eka i nekoliko sati. Ako ima greku u kodu, izgubi pola dana na ?ekanje. Kao reenje uvodi se time-sharing (podela vremena): svaki korisnik ima tastaturu i monitor (*terminal*) koji su priklju?eni na *glavni ra?unar*. To je jedan oblik multiprogramiranja. Procesorsko vreme razli?itim terminalima dodeljuje OS na osnovu dva kriterijuma: - ?ekanje na IO operacije - istek dodeljenog vremena (uvodi se pojam *quantum*-a to je koli?ina vremena nakon ?ijeg isteka kontrola se predaje drugom programu; multiprogramming + quantum = timesharing). *MULTICS *(*/MULTI/*/plexed Information and *C*omputing *S*ervice/) neuspela ideja (/MIT/,/Bell Labs/,/General Electric/) da se napravi mo?an ra?unar koji ?e biti u stanju da radi sa velikim brojem terminala. Kao osnovu, uzeli su model distribucije elektri?ne energije: elim da sluam radio, samo ga uklju?im na struju Isto su hteli napraviti sa ra?unarima: u jednom gradu imamo mo?an centralni ra?unar, a gra?ani imaju terminale, kojima se pristupa tom ra?unaru predak ra?unarskih mrea i Interneta. *Minira?unari: *prvi minira?unar je /DEC/-ov (/Digital Equipment Corporation/) /PDP-1/, do tada najmanji i najjeftinij ra?unar. Kotao je samo $120.000 *UNIX: Ken Thompson*, jedan od nau?nika firme /Bell Labs/, koji je radio na projektu /MULTICS/, uzeo je jedan /PDP-7/ minira?unar i napisao za taj ra?unar mini verziju /MULTICS/-a od tog projekta je posle nastao /UNIX/ (UNI = jedan , X = CS Computing Service). *4. **Generacija: *(1980-1990) *Personalni Ra?unari* razvoj personalnih ra?unara po?eo je pojavom *LSI* (*/L/*/arge *S*cale *I*ntegration/ veliki stepen integracije) ?ipova. Minira?unari su bili dovoljno jeftini, da ih imaju i vie departmana iste firme ili univerziteta, a personalni ra?unari su postali dovoljno jeftini da ih imaju i pojedinci. Primer personalnih ra?unara: /Spectrum/, /Commodore/, /Atari/. Zatim /IBM
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

PC/, /Apple Macintosh/ , itd. Javljaju se prvi pravi operativni sistemi kao to su /MS-DOS/,/UNIX/,itd. Prave se programi za korisnike, koji nisu stru?njaci za ra?unare, pa se razvija i korisni?ki interfejs programa. Dolazi do razvoja grafi?kog okruenja. Pored klasi?nih operativnih sistema javljaju se i dve nove vrste: *Mreni OS * ra? unari su povezani u *mre****u*, svaki ra?unar ima svoj OS koji me?usobno komuniciraju pomo?u nekog protokola (operativni sistemi mogu biti razli?iti, potrebno je samo zajedni?ki protokol, tj. zajedni?ki jezik za komunikaciju). Korisnik jednog ra?unara, moe se prijaviti na drugi, preuzeti neke fajlove itd. Korisnik zna da nije sam u mrei, svestan je razli?itih ra?unara sa kojima komunicira preko mree. Mree mogu biti *lokalne* i *globalne*. *Distribuirani OS* korisnici ga vide kao jedno-procesorski sistem, ali u stvari radi sa vie procesora. Imamo vie ra?unara povezanih u mreu, ali samo jedan OS, koji upravlja svim resursima u mrei. U pravom distribuiranom sistemu korisnik ne treba da vodi ra?una o tome, gde su njegovi fajlovi smeteni ili gde se izvrava njegov program, to je posao OS-a. Distribuirani OS se dakle ponaa kao jedinstvena celina. Korisnik nije svestan toga da je u mrei sa drugim ra?unarima, njemu to izgleda kao da je jedan ra?unar. * * * * * * * * Osnovni pojmovi, koncepti OS-a * * * * * * * * * * Imamo hardver, operativni sistem i korisni?ke programe. Videli smo da je jedan od zadataka OS-a da sakrije hardver od aplikacionih programa, odnosno da obezbedi laki pristup hardveru. To se ostvaruje preko niza proirenih instrukcija, koji se zovu *sistemski pozivi* (*system calls*). Procesi Procesi predstavljaju jedan od najvanijih koncepata operativnih sistema. *Program* je niz instrukcija koji ostvaruje neki algoritam. *Proces *je program u statusu izvravanja, zajedno sa svim resursima koji su potrebni za rad programa. Zna?i: program je fajl na disku. Kada se taj fajl u?ita u memoriju i po?inje da se izvrava dobijemo proces. Stanja procesa Procesi se nalaze u jednom od slede?ih stanja: - proces se *izvrava *(/RUNNING/) procesor upravo izvrava kod ovog procesa - proces je *spreman*, ali se ne izvrava (/READY/) - proces je dobio sve potrebne resurse, spreman je za izvravanje, ?eka procesora - proces je *blokiran*, ?eka na neto (npr. ?eka tampa?a da zavri sa tampanjem /BLOCKED/) - za dalji rad procesa potrebni su neki resursi, koji trenutno nisu na raspolaganju, ?eka IO operaciju, rezultat nekog drugog procesa itd. Imamo 4 prelaska izme?u razli?itih stanja: *1. *proces prelazi iz stanja IZVRAVANJA u stanje BLOKIRAN kada su mu za dalje izvravanje potrebni neki resursi, koji trenutno nisu dostupni. Ovu promenu stanja vri sam proces: predaje zahtev za neki resurs, pa ?eka tog resursa. Npr.: poalje zahtev skeneru da skenira neku sliku, i ?eka rezultat skeniranja *2. *proces prelazi iz stanja IZVRAVANJA u stanje SPREMAN ako mu istekne dodeljeno procesorsko vreme (/timesharing/) tada proces prelazi u listu procesa koji ?ekaju na procesor *3. *proces prelazi iz stanja SPREMAN u stanje IZVRAVANJA kada se procesor oslobodi i moe da izvrava kod posmatranog procesa (izabere se iz liste ?ekanja po nekom kriterijumu i izvrava se) *4. *proces prelazi iz stanja BLOKIRAN u stanje SPREMAN, kada
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

liste ?ekanja po nekom kriterijumu i izvrava se) *4. *proces prelazi iz stanja BLOKIRAN u stanje SPREMAN, kada do?e do potrebnih resursa i spreman je za dalji rad, ali procesor trenutno nije slobodan, pa prelazi u listu ?ekanja (npr. skener je zavrio skeniranje, i sad proces moe nastaviti sa radom (spreman je), ali procesor je trenutno zauzet izvravanjem nekog drugog procesa, pa mora da ?eka u red) Kod nekih operativnih sistemima procesi mogu biti i *suspendovani* (*suspended*). Na taj na?in dobijamo jo dva stanja: - proces je *suspendovan *i *spreman *(ako je dolo do suspendovanja u stanju spreman) - proces je *suspendovan *i *blokiran* (ako je dolo do suspendovanja u stanju blokiran) i slede?i dijagram: Proces koji je *suspendovan*, prestaje da se takmi?i za resurse, osloba?aju se resursi koje je zaouzeo, ali ostaje i dalje proces. Proces koji je u stanju suspendovan i blokiran prelazi u stanje suspendovan i spreman, ako postaje spreman, tj. ako moe da nastavi sa radom (npr. proces poalje zahtev skeneru da skenira sliku, ?eka da skener zavri sa radom, pa se blokira, u me?uvremenu se suspendira, pa postaje suspendovan i blokiran, kada skener zavri skeniranje, proces prelazi iz stanja suspendovan i blokiran u stanje suspendovan i spreman.) Iz stanja suspendovan i blokiran u stanje blokiran i iz stanja suspendovan i spreman u stanje spreman procesi mogu pre?i samo explicitno, tj. zahtevom korisnika. Iz stanja spreman u stanje suspendovan i spreman proces prelazi iz nekog od slede?ih razloga : - *prevelik broj spremnih procesa* procesi se suspendiraju kao zatita od preoptere?ivanja sistema - *explicitno suspendiranje procesa od strane korisnika*(npr. da bi korisnik mogao proveriti neke me?urezultate izvravanja procesa i nakon toga mogao nastaviti rad bez ponovnog pokretanja celog programa.) - *izbegavanje zaglavljivanja*(dead lock) do zaglavljivanja se dolazi kada dva (ili vie) procesa blokiraju jedan drugi u izvravanju (npr. procesu P1 treba resurs A koji je kod procesa P2, a procesu P2 treba resurs B koji dri P1 ovi procesi su se zaglavili, jer nijedan od njih ne moe nastaviti sa radom u ovom slu?aju jedan od procesa se suspenduje, pa drugi moe da odradi svoj zadatak, pa kada se resursi oslobode i prvi ?e mo?i da zavri svoj rad). PCB Process Control Block Posmatrajmo slede?u situaciju: imamo multiprogramirano okruenje sa dva procesa. Proces P1 se izvrava dok ne do?e do blokiranja zbog ?ekanja na neki doga?aj (npr. skeniranje). Tada krenemo sa izvravanjem procesa P2 koji se nakon nekog vremena isto postaje blokiran. U me?uvremenu se desi doga?aj na koji je ?ekao proces P1 i sada moemo nastaviti sa izvravanjem. Da bismo znali, gde treba nastaviti, potrebno je pamtiti neke informacije o procesu. Upravo tome slui /PCB/ tj. /Process Control Block/. Svakom procesu se dodeljuje jedinstveni /PCB/ koji sadri informacije koje su potrebne za nastavak izvravanja tog procesa. Te informacije uklju?uju: - jedinstveni identifikator procesa (*pid* process ID) - stanje procesa - *prioritet*procesa (iz liste ?ekanja biramo najpre procese sa ve?im prioritetima) - adresa memorije gde se nalazi proces - adrese zauzetih resursa - sadraj registara procesora, itd. /PCB/-ovi svih procesa u memoriji smetaju se u neki niz ili
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

povezanu listu. Operacije sa procesima Operativni sistem treba da obezbedi slede?e operacije sa procesima: kreiranje novog procesa (kreiranjem /PCB/-a) - unitavanje procesa (brisanjem /PCB/-a iz liste) - menjanje stanja procesa - menjanje prioriteta procesa - izbor procesa za izvravanje (dodela procesora nekom procesu *context switch*) - *sinhronizacija*procesa - *komunikacija*izme?u procesa itd. Odnos procesa I sami procesi mogu kreirati nove procese. U tom slu?aju proces koji kreira novi proces zove se *roditelj* a novi proces *dete*, pa je odnos procesa hijerarhijski (u obliku stabla). Izme?u roditelja i deteta moemo imati dve vrste veze: 1. procesroditelj kreira novog procesa i ?eka dok proces-dete zavri sa radom 2. proces-roditelj kreira novog procesa i nastavljaju sa radom oba procesa (rade paralelno) Podela operativnih sistema u odnosu na procese Operativni sistemi mogu podravati: - *monotasking*(jednoprocesni, monoprogramiranje) : u memoriji istovremeno imamo samo jedan program, tj. istovremeno se izvrava samo jedan proces (npr. /DOS/) *multitasking*(vieprocesni, multiprogramiranje) : u memoriji istovremeno imamo i vie programa, tj. istovremeno se izvravaju i vie procesa (npr. /Windows/,/Linux/) * * U odnosu na broja korisnika, operativni sistemi mogu biti: - *monouser*(jednokorisni?ki): npr. /DOS/ (jednokorisni?ki,jednoprocesni), /Windows 98/ (jednokorisni?ki, vieprocesni ) - *multiuser*(viekorisni?ki): npr. /UNIX/ (viekorisni?ki, vieprocesni) * * Teki i laki procesi Procesi se dele na *teke* i na *lake *procese. Da bismo videli razliku izme?u ove dve vrste procesa, posmatrajmo najpre kako procesi koriste memoriju. Za izvravanje nekog procesa, potrebno je 4 dela (vrste) memorije: - *heap* - *stack* - *memorija za globalne promenljive* - *memorija za kod procesa* Memorija zauzeta od strane nekog procesa izgleda na slede?i na?in: HEAP STACK globalne promenljive kod procesa *HEAP*(*hrpa*) je deo memorije koji je rezervisan za dinami?ke promenljive, tj. za promenljive koje se stvaraju u toku izvravanja programa. Npr. u /Moduli-2/ zauzimanje memorije (kreiranje dinami?ke promenljive) se vri naredbom /ALLOCATE/ iz modula /Storage/, a osloba?anje zauzete memorije naredbom /DEALLOCATE/ isto iz modula /Storage/. Pristup dinami?ki kreiranim promenljivama se ostvaruje pomo?u pokaziva?a. To su promenljive koje sadre po?etnu adresu zauzete memorije. Na jednu istu dinami?ku promenljivu mogu pokazivati i vie pokaziva?a. Ako smo zauzeli neku koli?inu memorije i nemamo vie ni jednog pokaziva?a na tu memoriju, taj deo /HEAP/-a je izgubljen (nemamo vie pristupa, ne znamo adresu zauzete memorije, ne moemo je osloboditi) to se zove *sme?e* u memoriji (*garbage*) i moe dovesti do ozbiljnih greaka u radu programa. Ovaj problem se kod nekih OS-a reava pomo?u *sakuplja?a sme?a* (*garbage collector*) koji vode ra?una o zauzetim delovima memorije: npr. broje pokaziva?e na zauzetu memoriju i ako taj broja? postaje nula, osloba?aju memoriju. Postoje i programski jezici koji imaju ugra?en sakuplja? otpadaka kao to su /Java/,/PC Scheme/ itd. *STACK* (*stek*) je deo memorije koji je rezervisan za ?uvanje lokalnih promenljivih, parametara procedura, povratnih adresa
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

(*stek*) je deo memorije koji je rezervisan za ?uvanje lokalnih promenljivih, parametara procedura, povratnih adresa itd. Pod /DOS/-om maximalna veli?ina steka-a je 64Kb, a maximalna veli?ina heap-a je 640Kb. Veli?ina heap-a i stack-a je unapred odre?ena i ne moe se menjati u toku izvravanja programa. Stek se puni prema gore a heap se puni prema dole. Npr. u /Turbo Pascalu/ postoji *direktiva* (kompajler vri prevod izvornog koda u funkciji direktiva ugra?enih u izvorni kod) /$M/ koja odre?uje veli?inu /heap/-a i /stack/-a na slede?i na?in: {$M veli? inaSteka,heapMin,heapMax}. Podela procesa na teke i lake procese vri se na osnovu toga, kako koriste gore navedene delove memorije : - svaki *teki proces* ima sopstveni memorijski prostor za kod, globalne promenljive, stek i heap koju ne deli ni sa kim, pristup tim delovima ima samo dati proces. - *laki procesi*(*niti, threads*) mogu deliti memorijski prostor za kod, globalne promenljive i heap. Stek se ne moe deliti jer ne moemo unapred znati koji proces koristi stek: proces A stavi neto na stek i nastavlja rad, dolazi proces B i on isto stavi neto na stek, A je zavrio svoj rad i sad su mu potrebni podaci sa steka, a tamo su podaci procesa B Zna?i laki procesi imaju sopstveni stek a mogu deliti kod,globalne promenljive i heap. * * Programski jezici, koji omogu?avaju kreiranje lakih procesa: /Java/,/Modula-2/,/Concurrent Pascal/,/Ada/,itd. U /M2/ laki procesi su zapakovani u teke procese, kompajler deli vreme izme?u vie procesa. Postoje operativni sistemi, koji podravaju: 1. samo teke procese (/UNIX/) 2. samo lake procese (/Oberon/) 3. podravaju i teke i lake procese (/Windows/) Problem komunikacije kod tekih procesa je u tome, to su oni me?usobno odvojeni, tj. ne dele nijedan deo memorije. Kako nemaju zajedni?ku memoriju, operativni sistem mora obezbediti neke strukture i mehanizme za *me?uprocesnu komunikaciju* (*interprocess communication*). Laki procesi mogu bez problema komunicirati jer dele odre?ene delove memorije. Kod njih se javlja problem *sinhronizacije*. Konkurentno programiranje Kod *SEKVENCIJALNOG* programiranja, podrazumevamo da se prorgam sastoji od niza naredbi koji se izvrava u ta?no odre?enom redosledu od strane jednog procesora. Zna?i sekvencijalni program predstavlja ta?no jedan proces koji se izvrava od po?etka do kraja na jednom procesoru. *KONKURENTNO *programiranje uzima u obzir mogu?nost postojanja i vie procesora, pa se konkurentni program sastoji od vie nezavisnih procesa ili zadataka (/task/), koji se mogu istovremeno izvravati. Stil konkurentnog programiranja koristimo kada se zadatak moe razbiti na vie me?usobno relativno nezavisnih delova procesa, koji se mogu istovremeno izvravati. Konkurentni programi se mogu izvrsavati i na ra?unaru sa jednim procesorom i na ra?unaru sa vie procesora. Konkurentno programiranje se koristi kod programiranja operativnih sistema, simulacija itd. Npr.: elimo napisati program za simulaciju igre jednog fudbalskog tima. Sekvencijalno: piemo program koji vodi ra?una o svakom igra?u tima. Konkurentno: za svaki igra? piemo jedinstvenu proceduru te procedure se izvravaju istovremeno. Fajl sistem (file system) Videli smo da je operativni sistem duan da obezbedi laki pristup hardveru programima na
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

viim nivoima. Na isti na?in, treba da obezbedi i apstraktniji pogled na fajlove, na fajl sistem. Zna?i, programi na viim nivoima ne treba da vode ra?una o tome, kako su u stvari fajlovi smeteni na disku, o tome ?e voditi ra?una OS. Za rad sa fajlovima, OS treba da obezbedi operacije, kao to su: - otvaranje fajlova - zatvaranje fajlova promena pozicije fajl-pokaziva?a (/FilePos/) - ?itanje iz fajlova - pisanje u fajlove - kreiranje novih fajlova - brisanje postoje?ih fajlova - reimenovanje,kopiranje, itd. Mnogi operativni sistemi podravaju i koncept *direktorijuma*, kao na?in grupisanja fajlova pa obezbe?uju i operacije za rad sa njima. Elementi direktorijuma mogu biti fajlovi i drugi direktorijumi, tako dolazimo do fajl sistema u obliku stabla. Sistemski pozivi (system calls) Aplikacioni programi komuniciraju sa OS-om pomo?u *sistemskih poziva*, tj. preko operacija (funkcija) definisanih od strane OS-a. Sistemski pozivi se realizuju pomo?u sistema *prekida*: korisni?ki program postavlja parametre sistemskog poziva na odre?ene memorijske lokacije ili registre procesora, inicira prekid, OS preuzima kontrolu, uzima parametre, izvri traene radnje, rezultat stavi u odre?ene memorijske lokacije ili u registre i vra?a kontrolu programu. Sistemske pozive ?esto podrava i hardver, tj. procesor, na taj na?in to razlikuje dva reima rada: *korisni?ki reim *(*user mode*) i *sistemski reim *(*kernel mode*, *system mode*, *supervisor mode*) rada. Korisni?ki programi mogu raditi isklju?ivo u korisni?kom reimu rada procesora, sistemski reim rada je predvi?en za OS. Ako korisni?ki program pokua izvriti neku operaciju koja je dozvoljena samo u sistemskom reimu rada, kontrola se predaje OS-u. Prilikom sistemskih poziva procesor prelazi iz korisni?kog reima rada u sistemski, OS obradi poziv pa se procesor vra?a u korisni?ki reim rada. /Primer/ sistemskog poziva u /TopSpeed Moduli-2/ pod /DOS/-om : FROM SYSTEM IMPORT Registers ; FROM Lib IMPORT Dos ; VAR r : Registers ; BEGIN r.AH : = 02H ; // broj sistemskog poziva: servisa DOS-a // 02H ozna?ava servis za ispis jednog // karaktera na standardni izlaz ekran r.DL : = BYTE(A) ; // karaketer koji treba ispisati: // parametar sistemskog poziva Dos ( r ) // sistemski poziv END Komandni interpreter (shell) Operativni sistem je zaduen za sistemske pozive. Komandni interpreter interpretira komande korisnika i izvrava ih oslanjaju?i se na sistemske pozive OS-a. To je deo OS-a koji je vidljiv za korisnike ra?unara. Npr. u /DOS/-u to izgleda na slede?i na?in: komandni interpreter nakon startovanja ispisuje *prompt*, i ?eka komande korisnika: C:\TEMP\dir Komandni interpreter je primarni interfejs izme?u korisnika i operativnog sistema.U /DOS/-u to je fajl COMMAND.COM. Prekidi (interrupts) * * * * * *Imamo galvni procesor, koji izvrava programe i imamo IO ure?aje (disk,tampa?,skener,itd.). Svaki IO ure?aj ima svoj kontroler koji sadri neki slabiji procesor koji je jedino zaduen za upravljanje tim ure?ajem i za komunikaciju sa glavnim procesorom. Imamo dve strategije za upravljanje ure?ajima: 1. *polling*: u odre?enim vremenskim intervalima glavni procesor prekida svoj rad i proveri da li neki kontroler ima neku poruku za njega, ako ima, obradi poruku i nastavlja sa radom 2. *prekidi (interrupt)*: glavni procesor radi svoj posao, i ure?aji rade svoj posao. Ako ure?aj zavri svoj posao ili
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

2. *prekidi (interrupt)*: glavni procesor radi svoj posao, i ure?aji rade svoj posao. Ako ure?aj zavri svoj posao ili do?e do neke greke, ure?aj o tome obavetava glavni procesor *zahtevom za prekid* (*interrupt request*). Kada procesor dobije zahtev za prekid, prekida svoj rad, zapamti gde je stao, obradi prekid, pa nastavlja sa radom tamo gde je bio prekinut (ako prekid ne predstavlja neku fatalnu greku, takvu da se rad ne moe nastaviti). /Primer/: Mama kuva ru?ak a dete se igra. Ako je polling, mama svakih 10 sekundi proveri ta dete radi i ako neto ne valja onda dotr?i da mu pomogne. Ako su interapti onda ga ne proverava. Ali, dete se pose?e i po?ne da pla?e. To je interapt. Mama skine erpe sa poreta (prekine proces pravljenja ru?ka) zapamti gde je stala, locira dete (pogleda u tabelu), previje ga i poljubi (obradi prekid), vrati se u kuhinju, seti se gde je stala i nastavi sa kuvanjem. Ako se dete ba unakazilo, mama suspenduje proces pravljenja ru?ka i vodi dete na urgentno. Nedostaci polling strategije: 1. ure?aj mora ?ekati na glavni procesor da bi predao svoju poruku (koja moe biti npr. vrlo vana poruka o greci) 2. procesor prekida svoj rad u odre?enim vremenskim intervalima i kada nema nikakvih poruka Obrada prekida se izvrava po slede?em algoritmu: - procesor radi svoj zadatak - stie zahtev za prekid - sa?uva se stanje trenutnog procesa - onemogu?avaju se dalji prekidi - u *tabeli prekida* (*interrupt table* - ?uva adrese procedura za obradu svih mogu?ih prekida) trai se adresa procedure za obradu prekida izvrava se procedura za obradu prekida - omogu?avaju se dalji prekidi - nastavlja se rad na prekinutom procesu Vrste prekida: 1. Hardverski prekidi generiu se od strane hardvera, mogu biti: 1. prekidi koji se *mogu maskirati* (*maskable interrupt*) ove prekide procesor moe ignorisati ako je dobio takvu naredbu (npr. pritisnuta je tipka na tastaturi) 2. prekidi koji se *ne mogu maskirati *(*non maskable interrupt*) prekidi ?ija obrada ne moe biti odloena to su neke ozbiljne greke hardvera (npr. greka memorije) 2. Softverski prekidi prekidi generisani od strane programa 3. Sistemski pozivi (jesu softverski prekidi) 4. *Izuzeci* (*exceptions*) generiu se od strane procesora, npr. ako se pokua deliti sa nulom Jezgro OS-a (kernel,nucleus,core) * * * * * *Jezgro je deo operativnog sistema, koji obavlja najbitnije operacije: - upravljanje prekidima - kreiranje i unitavanje procesa - odabiranje procesa iz liste spremnih procesa (context switch) suspenzija i nastavljanje procesa - sinhronizacija procesa - komunikacija izme?u procesa - manipulacije sa /PCB/om - podrka za ulaz/izlaz (IO) - upravljanje memorijom - upravljanje fajl sistemom, itd. Dizajn, struktura operativnih sistema * * * * * * * * * * Monolitni sistemi (monolithic systems) U prolosti monolitni sistemi su predstavljali naj? e?u organizaciju OS-a. Ovaj na?in organizacije OS-a dobio je naziv *The Big Mess* velika zbrka, vide? emo zato. OS je realizovan kao skup procedura, od kojih svaka moe pozvati svaku ako je to potrebno. Korisni? ki programi servise OS-a koriste na slede?i na?in: parametri sistemskog poziva se smetaju u odre?ena mesta, kao to su registri procesora ili stek, pa sledi specijalna operacija *poziv jezgra* OS-a (*kernel call*). Ova
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

operacija prebacuje procesor iz *korisni?kog reima *rada**u *sistemski reim *rada i kontrolu predaje OS-u. U korisni?kom reimu rada nisu dozvoljene neke komande procesora, a u sistemskom reimu mogu se koristiti sve operacije poznate od strane procesora. Posle poziva jezgru, OS preuzima kontrolu, na osnovu parametara poziva odre?uje koju sistemsku proceduru treba pozvati i poziva tu proceduru i na kraju se kontrola vra?a korisni?kom programu. Zna?i OS ima slede?u strukturu (sastoji se od 3 sloja): 1. glavni program koji obra?uje sistemske pozive 2. skup sistemskih procedura koje se pozivaju prilikom sistemskih poziva 3. skup pomo?nih procedura koje se koriste od strane sistemskih procedura Slojevita realizacija (layered systems) * * * * Kod slojevite realizacije OS se deli na razli?ite slojeve na hijerarhijski na?in: svaki sloj se gradi na slojeve ispod njega. Prvi OS koji je napravljen na ovaj na?in je OS sa imemom *THE* (/Technische Hogeschool Eindhoven/) od strane *E.W.Dijkstre*. /THE/ se sajtojao od 6 sloja na slede?i na?in: 5. komandni interpreter 4. korisni?ki programi 3. ulazne,izlazne operacije 2. procesi 1. upravljanje memorijom 0. procesor i multiprogramming Nulti sloj se bavi upravljanjem procesora, obezbe? uje prebacivanje izme?u razli?itih procesa. Prvi sloj upravlja memorijom: zauzima potrebnu memoriju za procese. Slojevi iznad prvog sloja ne treba da brinu o memorijskim potrebama, to ?e umesto njih uraditi prvi sloj. Drugi sloj upravlja komunikacijom izme?u razli?itih procesa i komandnog interpretatora. Tre?i sloj obavlja ulazno\izlazne operacije. Slojevi 0..3 predstavljaju jezgro OS-a i rade u sistemskom reimu rada. Na ?etvrtom nivou imamo korisni?ke programe oni ne treba da se brinu ni oko procesa, memorije,komandnog interpretera, IO operacija, sve to obavljaju slojevi ispod. Zna?i *bitna razlika izme?u monolitne i slojevite realizacije* je u tome, to se OS kod monolitne strukture sastoji od skupa procedura bez ikakvog grupisanja ili hijerarhije, a kod slojevite realizacije OS se deli na vie slojeva od kojih se svaki oslanja na slojeve ispod, i gde svaki sloj ima ta?no odre?enu funkciju (upravlja ta?no odre?enim resursima). Kod /MULTICS/ sistema umesto slojeva, koriste se koncetri?ni prstenovi. Kada neka procedura iz ve?eg (spoljanijeg) prstena eli pozvati neki servis nekog manjeg (unutranijeg) prstena to ?e uraditi pomo?u poziva koji je sli?an sistemkim pozivima. Virtuelne maine (virtual machines) * * * * Struktura virtuelnih maina je izra?ena od strane firme /IBM/ na slede?i na?in: imamo na najniem nivou hardver, iznad hardvera imamo sistem koji se zove *monitor virtuelnih maina* (*virtual machine monitor*) i koji obezbe?uje niz *virtuelnih maina* - to nisu proirene maine kao operativni sistemi koji pruaju niz proirenih i jednostavnijih operacija za pristup hardveru, ve? su *ta?ne kopije hardvera *ispod monitora virtuelnih maina. Zatim se na te virtuelne maine mogu biti instalirani operativni sistemi koji mogu biti i razli?iti. Sistemske pozive korisni?kih programa primaju odgovaraju?i operativni sistemi, a hardverske operacije koje alju ti OS-ovi prema svojim virtuelnim mainama hvata monitor virtuelnih maina i realizuje ih u skladu sa hardverom ispod sebe. Kao primer moemo navesti /IBM/-ov /VM/370/. aplikacija 1 aplikacija 2 aplikacija 3 operativni sistem 1 operativni
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

primer moemo navesti /IBM/-ov /VM/370/. aplikacija 1 aplikacija 2 aplikacija 3 operativni sistem 1 operativni sistem 2 operativni sistem 3 monitor virtuelnih maina HARDVER Klijent-server model (client-server model) U ovom modelu, procese delimo na dve vrste: *klijent procesi* (*client process*) predstavljaju procese korisnika i *server procesi* (*server process*) koji su zadueni za obradu klijentskih procesa. I klijentni i serverski procesi rade u korisni?kom reimu rada. *Kernel* OS-a je zaduen za komunikaciju izme?u klijentskih i serverskih procesa. Server procesi su delovi OS-a i grupisani su prema tome koje funkcije obavljaju: proces serveri (zadueni za procese), fajl serveri (zadueni za fajl sistem), serveri memorije itd. Svi serveri rade u korisni?kom reimu, pa nemaju direktan pristup hardveru. Prednosti ovog modela: 1. OS je razbijen na manje delove (servere) koji se mogu odravati nezavisno 2. ako do?e do greke u nekom serveru, ne mora pasti i ceo sistem 3. pogodan je za pravljenje *distribuiranog sistema*: razli?iti serveri mogu se izvravati na razli?itim ra?unarima (koji su naravno povezani), kada neki klijent proces poalje neku poruku nekom serverskom procesu, ne treba da vodi ra?una o tome, kako ?e sti?i poruka do servera, to je zadatak kernela. Isto tako, kernel ?e znati kako da vrati odgovor. Postoji jo jedna stvar kod ovog modela, o ?emu treba voditi ra?una: neke funkcije OS-a ne mogu se ili se teko mogu realizovati u korisni?kom reimu rada. Imamo dve mogu?nosti da reimo ovaj problem: 1. imamo neke *kriti?ne server procese* koji se izvravaju u sistemskom reimu rada i imaju direktan pristup harveru, ali sa ostalim procesima komuniciraju kao to se to radi u ovom modelu 2. neke kriti?ne *mehanizme *ugra?ujemo u sam kernel, a pravimo server u korisni?kom reimu koji sadri samo interfejs tih operacija klijentni proces 1 klijentni proces 2 server procesa fajl server ......... server memorije KERNEL SINHRONIZACIJA PROCESA Kriti?na oblast(critical section) * * * * * * * * * * * *Posmatrajmo slede?i primer: imamo dva terminala A i B. Na oba terminala po jedan proces. Ti procesi vode ra?una o broju pritiskanja tipke ENTER. Taj broj se ?uva u zajedni?koj promenljivoj /broja?/. Program tih procesa je dat pomo?u slede?eg pseudo-koda: ako se pritisne ENTER: /1. /uzmi vrednost /broja?a/ /2. /pove?aj vrednost za 1// /3. /vrati novu vrednost u broja?// Posmatrajmo sada slede?u situaciju: neka je broja?=5, i neka se na terminalu A pritisne ENTER, proces A uzima vrednost /broja?a/ i pove?ava je za jedan u tom trenutku se zbog ne?ega do?e do zastoja u izvravanju procesa A. Sada, dok proces A ?eka, neka se pritisne ENTER na drugom terminalu i neka proces B izvri sva tri koraka tada ?e vrednost /broja?a /biti 6. Neka sada proces A nastavi sa radom. Zna?i on je primio za vrednost /broja?a/ 5, pove?ao je za jedan i postavio vrednost /broja?a/ na 6. Dva puta je pritisnut ENTER, a /broja?/ ima vrednost 6!! Ovu greku moemo izbe?i tako to ?emo zabraniti procesu B (A) da u?e u deo gde pristupa /broja?u/ ako je drugi proces ve? uao u taj deo. Zna?i, proces B ?e da sa?eka da proces A zavri svoj rad sa zajedni?kom promenljivom i tek ?e tada po?eti sa radom. *Kriti?na oblast (critical section) *je deo programskog koda za koji vai: ako je neki proces unutar svoje kriti?ne oblasti, ni jedan
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

drugi proces ne sme biti unutar svoje kriti?ne oblasti. Drugim re?ima, proces ne sme biti prekinut dok se nalazi u svojoj kriti?noj oblasti. Kriti?na oblast se posmatra kao neprekidiv niz operacija (kao jedna primitivna operacija). Odre?ivanje dela programskog koda koji predstavlja kriti?nu oblast je zadatak programera. Kriti?na oblast moe se realizovati : - softverski - hardverski - pomo?u operativnog sistema (sistemski pozivi) Softverska realizacija kriti? ne oblasti * * * * * * * * * * * *Pretpostavke i osobine softverskog reenja : 0. Unutar kriti?ne oblasti istovremeno moe se nalaziti najvie do jedan proces. 1. Kriti?na oblast se realizuje softverski bez pomo?i operativnog sistema. 2. Prilikom razvoja programa ne uzimamo u obzir pretpostavke ni o brzini, ni o broju procesora. 3. Ni jedan proces koji je izvan svoje kriti?ne oblasti ne sme spre?iti druge procese da u?u u svoje kriti?ne oblasti. Jedino proces unutar kriti?ne oblasti moe spre?iti ostale procese da u?u u k.o. 4. Ni jedan proces ne sme neograni?eno dugo ?ekati da u?e u svoju kriti?nu oblast. Algoritam mora garantovati svakom procesu mogu?nost ulaska u kriti?nu oblast. Slede?i primeri ilustruju probleme softverske realizacije kriti?ne oblasti. Svi programi su dati pomo?u pseudo-koda: *MODULE Version1 ; *// teki proces VAR *processNumber* : CARDINAL ; // pomo?na promenljiva *PROCEDURE* Process1 ; // prvi laki proces * BEGIN* LOOP WHILE processNumber = 2 DO END ; // ?ekamo dok je red na P2 KriticnaOblast1 ; processNumber := 2 ; OstaleStvari1 END *END* Process1 ; *PROCEDURE* Process2 ; // drugi laki proces * BEGIN* LOOP WHILE processNumber = 1 DO END ; // ?ekamo dok je red na P1 KriticnaOblast2 ; processNumber := 1 ; OstaleStvari2 END *END* Process2 ; *BEGIN* processNumber := 1 ; * PARBEGIN*; Process1 ; Process2 ; * PAREND* *END Version1.* Sadraj pomo?ne promenljive /processNumber/ je index onog procesa koji se nalazi u kriti?noj oblasti. /PARBEGIN/ i /PAREND/ su pseudonaredbe. Ozna?avaju da procedure koje se pozivaju izme?u njih treba izvravati paralelno. */Analiza: /*ovaj algoritam *radi dobro*: istovremeno moe biti najvie do jedan proces u svojoj kriti?noj oblasti. *Nedostatak *ovog algoritma je: procesi ulaze u svoje k.o. alternativno, tj u slede?em redosledu: /Process1/, /Process2/, /Process1/, /Process2/,... *Objanjenje: *poto smo na po?etku stavili processNumber:=1, sigurno ?e /Process1/ biti prvi, koji ?e u?i u k.o., prilikom izlaska iz k.o., on ?e staviti processNumber:=2i time onemogu?iti sebi da u?e u k.o, odnosno dozvoli?e da /Process2/ u?e u k.o. Neka sada /Process2/ u?e u k.o, pa prilikom izlaska stavi processNumber:=1i neka sada ovaj proces zaglavi u delu OstaleStvari2dovoljno dugo vremena, da /Process1/ u?e i iza?e iz k.o. Sada je processNumber=2 (to je postavio /Process1/), /Process2/ radi neto to dugo traje u delu OstaleStvari2 to zna?i da nije unutar kriti?ne oblasti, pa bi /Process1/ mogao slobodno u?i, ali ne moe jer je processNumber=2, to zna?i da mora sa?ekati da /Process2/ zavri sa radom i da ponovo u?e i iza?e iz svoje kriti?ne oblasti. *MODULE Version2 ;* VAR *P1_INSIDE, P2_INSIDE* : BOOLEAN ; *PROCEDURE*Process1 ; *BEGIN* LOOP WHILE P2_INSIDE DO END ; // ?ekamo dok je P2 unutra P1_INSIDE := TRUE ; // ulazimo
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

*BEGIN* LOOP WHILE P2_INSIDE DO END ; // ?ekamo dok je P2 unutra P1_INSIDE := TRUE ; // ulazimo KriticnaOblast1 ; P1_INSIDE := FALSE ; // izlazimo OstaleStvari1 END *END*Process1; *PROCEDURE*Process2 ; *BEGIN* LOOP WHILE P1_INSIDE DO END ; // ?ekamo dok je P1 unutra P2_INSIDE := TRUE ; // ulazimo KriticnaOblast2 ; P2_INSIDE := FALSE ; // izlazimo OstaleStvari2 END *END*Process2; *BEGIN* P1_INSIDE := FALSE ; P2_INSIDE := FALSE ; PARBEGIN ; Process1 ; Process2 ; PAREND *END Version2.* * * */Analiza: /*uvo?enjem dve logi?ke promenljive /P1_INSIDE/ i /P2_INSIDE/ (imaju vrednost /TRUE/, ako su odgovaraju?i procesi unutar svojih k.o.) reili smo problem alternativnog izvravanja, ali smo dobili algoritam koji *ne radi*!! *Objanjenje: *krenimo od po?etka: P1_INSIDE:=FALSE, P2_INSIDE:=FALSE.Pp. da je /Process1/ stigao prvi do /WHILE/ petlje, on odmah ide i dalje, poto je P2_INSIDE=FALSE, neka u ovom trenutku i /Process2/ do?e do /WHILE/ petlje, i on ?e nastaviti sa radom, poto je jo uvek P1_INSIDE=FALSE i dobili smo da ?e oba procesa istovremeno u?i u k.o. Zna?i do problema dolazimo, ako se proces prekine izme?u /WHILE/ petlje i reda Px_INSIDE:=TRUE. *MODULE Version3 ;* VAR *p1WantsToEnter, p2WantsToEnter* : BOOLEAN ; * PROCEDURE*Process1 ; *BEGIN* LOOP p1WantsToEnter := TRUE ; // javimo da P1 eli u?i WHILE p2WantsToEnter DO END ; // dok P2 eli u?i, ?ekamo KriticnaOblast1 ; p1WantsToEnter := FALSE ; // izlazimo OstaleStvari1 END *END* Process1; *PROCEDURE* Process2 ; *BEGIN* LOOP p2WantsToEnter := TRUE ; // javimo da P2 eli u?i WHILE p1WantsToEnter DO END ; // dok P1 eli u?i, ?ekamo KriticnaOblast2 ; p2WantsToEnter := FALSE ; // izlazimo OstaleStvari2 END *END* Process2; *BEGIN* p1WantsToEnter := FALSE ; p2WantsToEnter := FALSE ; PARBEGIN ; Process1 ; Process2 ; PAREND *END Version3.* * * Promenljive /p1WantsToEnter/ i /p2WantsToEnter/ ozna?avaju da odgovaraju?i proces eli u?i u kriti?nu oblast. */Analiza: /*algoritam *ne radi*!! *Objanjenje: *pp. da se procesi izvravaju istovremeno /Process1/ ?e staviti p1WantsToEnter:=TRUEa /Process2/ stavlja p2WantsToEnter:=TRUE. Zatim ?e oba procesa zaglaviti unutar /WHILE/ petlje: /Process1/ ?e ?ekati na /Process2/ i obrnuto to se zove *zaglavljivanje* (*dead lock*). Oba procesa ?ekaju na neki doga?aj koji se nikada ne?e desiti. *MODULE Version4 ;* VAR *p1WantsToEnter, p2WantsToEnter* : BOOLEAN ; * PROCEDURE *Process1 ; *BEGIN* LOOP p1WantsToEnter := TRUE ; // javimo da P1 eli u?i WHILE p2WantsToEnter DO // sve dok P2 eli u?i p1WantsToEnter := FALSE ; // odustajemo od toga da P1 u?e DELAY ( maliInterval1 ) ; // ?ekamo malo,da to P2 primeti p1WantsToEnter := TRUE // javimo da P1 eli u?i END; KriticnaOblast1 ; p1WantsToEnter := FALSE ; // izlazimo OstaleStvari1 END *END *Process1; *PROCEDURE *Process2 ; *BEGIN* LOOP p2WantsToEnter := TRUE ; // javimo da P2 eli u?i WHILE p1WantsToEnter DO // sve dok P1 eli u?i p2WantsToEnter := FALSE ; // odustajemo od toga da P2 u?e DELAY ( maliInterval2 ) ; // ?ekamo malo,da to P1 primeti p2WantsToEnter := TRUE // javimo da P2 eli u?i END;
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

PRO version

KriticnaOblast2 ; p2WantsToEnter := FALSE ; // izlazimo OstaleStvari2 END *END *Process2; *BEGIN* p1WantsToEnter := FALSE ; p2WantsToEnter := FALSE ; PARBEGIN ; Process1 ; Process2 ; PAREND *END Version4.* * * */Analiza:/*ova verzija zamalo da radi, ali postoji mogu?nost greke. Pp. da se procesi izvravaju paralelno: /Process1/ stavlja p1WantsToEnter:=TRUE, /Process2/ stavlja p2WantsToEnter:=TRUE, zatim oba procesa u?u u /WHILE/ petlju, oba procesa za neko vreme odustaju od ulaska u k.o. /Process1/ ?eka u trajanju /maliInterval1/ a /Process2/ u trajanju /maliInterval2/. Neka generatori slu?ajnih brojeva generiu iste vrednosti, tj neka je /maliInterval1=maliInterval2/, tada ?e ponovo biti p1WantsToEnter:=TRUEi p2WantsToEnter:=TRUEi sve po?injemo iz po?etka. Zna?i, mada je mala verovatno?a da oba generatora slu?ajnih brojeva izgeneriu isti niz vrednosti, postoji mogu?nost da ovaj algoritam *ne radi *i da do?e do zaglavljivanja (dead lock) a to moe dovesti do vrlo ozbiljnih greaka npr. ako se algoritam koristi za upravljanje nuklearnom elektranom, saobra?ajem itd. Do zaglavljivanja dolazimo i ako se procesi izvravaju ba alternativno: izvrimo jednu naredbu prvog procesa, pa jednu naredbu drugog procesa, pa jednu naredbu prvog, itd. Dekkerov algoritam * * * * *MODULE Dekker ;* VAR *p1WantsToEnter, p2WantsToEnter* : BOOLEAN ; *favouredProcess : ( first,second ) ;* * PROCEDURE *Process1 ; *BEGIN* LOOP p1WantsToEnter := TRUE ; // P1 javlja da eli u?i WHILE p2WantsToEnter DO // sve dok P2 eli u?i IF favouredProcess = second THEN // ako P2 ima prednost p1WantsToEnter := FALSE ; // P1 odustaje WHILE favouredProcess = second DO END; // ?eka prednost p1WantsToEnter := TRUE // pa javi da eli u?i END END; KriticnaOblast1 ; favouredProcess := second ; // prednost dajemo P2-u p1WantsToEnter := FALSE ; // izlaz OstaleStvari1 END *END* Process1; * PROCEDURE *Process2 ; *BEGIN* LOOP p2WantsToEnter := TRUE ; // P2 javlja da eli u?i WHILE p1WantsToEnter DO // sve dok P1 eli u?i IF favouredProcess = first THEN // ako P1 ima prednost p2WantsToEnter := FALSE ; // P2 odustaje WHILE favouredProcess = first DO END ; // ?eka prednost p2WantsToEnter := TRUE // pa javi da eli u?i END END; KriticnaOblast2 ; favouredProcess := first ; // prednost dajemo P1-u p2WantsToEnter := FALSE ; // izlaz OstaleStvari2 END *END *Process2; *BEGIN* p1WantsToEnter := FALSE ; p2WantsToEnter := FALSE ; favouredProcess := first ; PARBEGIN ; Process1 ; Process2 ; PAREND *END Dekker.*** * * */Analiza: /**u ?emu je razlika izme?u Dekkerovog algoritma i Verzije 4?*Kod Dekkerovog algoritma uvodi se jo jedna pomo?na promenljiva, /favouredProcess/, koja ozna?ava koji proces ima prednost (tj. ve?i prioritet). Ne mogu oba procesa istovremeno u?i u kriti?nu oblast (greka druge verzije): pp. da oba procesa istovremeno daju zahtev za ulazak poto postoji prioritet procesa, u?i ?e onaj koji ima ve?i prioritet, a drugi ?e odustati od ulaska i ?ekati u /WHILE/ petlji dok dobije prednost. Tada drugi proces ulazi u k.o. a prvi ?e ?ekati. Nema zaglavljivanja (greka tre?e verzije): proces koji nema prednost odusta?e od toga da u?e u k.o. time ?e omogu?iti drugom procesu da u?e.
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

verzije): proces koji nema prednost odusta?e od toga da u?e u k.o. time ?e omogu?iti drugom procesu da u?e. Nema zaglavljivanja (greka ?etvrte verzije): poto prilikom ?ekanja umesto generatora slu?ajnih brojeva proveravamo da li smo dobili prednost, ne moe do?i do zaglavljivanja. Nema alternacije (greka prve verzije): zato to umesto jedne pomo?ne promenljive (/processNumber/) koristimo dve logi?ke: /p1WantsToEnter/, /p2WantsToEnter/. Dekkerov algoritam (1965) je dugo bio *najbolje reenje* za softversku realizaciju sinhronizacije. 1981 *Petersen* objavljuje novo, kra?e i lepe reenje. Petersenov algoritam * * * * *MODULE Petersen ;* VAR *p1WantsToEnter, p2WantsToEnter *: BOOLEAN ; *favouredProcess : ( first,second ) ;* *PROCEDURE *Process1 ; *BEGIN* LOOP p1WantsToEnter := TRUE ; // javimo da P1 eli u?i favouredProcess := second ; // dajemo prednost drugom proc. WHILE p2WantsToEnter AND // sve dok P2 eli u?i i ( favouredProcess = second ) DO END ; // P2 ima prednost // ?ekamo KriticnaOblast1 ; p1WantsToEnter := FALSE ; // izlaz OstaleStvari1 END *END *Process1; *PROCEDURE *Process2 ; *BEGIN* LOOP p2WantsToEnter := TRUE ; // javimo da P2 eli u?i favouredProcess := first ; // dajemo prednost prvom proc. WHILE p1WantsToEnter AND // sve dok P1 eli u?i i ( favouredProcess = first ) DO END ; // P1 ima prednost // ?ekamo KriticnaOblast2 ; p2WantsToEnter := FALSE ; // izlaz OstaleStvari2 END *END *Process2 ; *BEGIN* p1WantsToEnter := FALSE ; p2WantsToEnter := FALSE ; favouredProcess := first ; PARBEGIN ; Process1 ; Process2 ; PAREND *END Petersen ;*** * * */Analiza: /*Petersenov algoritam koristi iste pomo?ne procedure kao i Dekkerov algoritam, ali je kod mnogo jednostavniji. Proverimo da li izbegava greke prethodnih algoritama: Ne mogu oba procesa istovremeno u?i u kriti?nu oblast (greka druge verzije): zbog pomo?ne promenljive /favouredProcess/ uvek ?e u?i samo jedan i to onaj proces koji ima prednost. Nema zaglavljivanja (greka tre?e verzije): proces koji nema prednost, ne odustaje ali ?e i dalje ?ekati na prednost. Drugi proces ?e mo?i u?i u k.o jer ima prednost, pa ?e vrednost logi?kog izraza u /WHILE/ petlji biti: /TRUE AND FALSE/, a to je /FALSE/, to zna?i da proces moe u? i u k.o. Nema zaglavljivanja (greka ?etvrte verzije): poto ne moe biti istovremeno favouredProcess=first i favouredProcess=second, tj. ne mogu oba procesa istovremeno imati prednost (jer promenljiva /favouredProcess/ ne moe imati istovremeno dve vrednosti, ili je first ili je second) ne postoji mogu?nost da oba procesa neograni?eno dugo ostanu unutar /WHILE/ petlje. Nema alternacije (greka prve verzije): neka se /Process2/ zaglavi u deo /OstaleStvari2/ dovoljno dugo, da /Process1/ krene iz po?etka. Tada je p2WantToEnter=FALSE, p1WantToEnter=TRUE, favouredProcess=second, vrednost logi?kog izraza /WHILE/ petlje prvog procesa bi?e FALSE AND TRUE = FALSE, pa /Process1/ moe ponovo u?i u k.o. a da ne ?eka na /Process2/. Hardverska realizacija kriti?ne oblasti * * Kriti?na oblast moe se implementirati i na nivou harvera ako postoji procesorska instrukcija koja to podrava. Neka je to npr. naredba *TestAndSet ( a,b )*, koja radi slede?e tri stvari: 1. ?ita
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

vrednost logi?ke promenljive *b* 2. kopira tu vrednost u logi?ku promenljivu *a* 3. postavlja vrednost promenljive *b* na *TRUE* Kako je TestAndSet naredba procesora, ona se izvrava kao jedna operacija, tj. ne moe biti prekinuta. *Operacija TestAndSet garantuje, da promenljivama a i b istovremeno moe pristupiti samo jedan procesor, to zna?i da se ova operacija ne moe biti paralelno izvrena na vie procesora.* (u praksi *a *predstavlja neki registar procesora, a *b *neku memorijsku lokaciju) Sada, kada imamo podrku hardvera za realizaciju kriti?ne oblasti, moemo koristiti slede?i algoritam: *MODULE TAS ;* VAR *inside* : BOOLEAN ; // globalna pomo?na promenljiva * PROCEDURE*Process1 ; *VAR* firstCannotEnter : BOOLEAN ; // lokalna pomo? na promenljiva *BEGIN* LOOP firstCannotEnter := TRUE ; // javimo da P1 ne moe u?i WHILE firstCannotEnter DO // sve dok P1 ne moe u?i *TestAndSet*(firstCannotEnter,*inside*) // nedeljiva operacija END; KriticnaOblast1 ; *inside := FALSE ;* // izlaz OstaleStvari1 END *END* Process1; *PROCEDURE* Process2 ; *VAR *secondCannotEnter : BOOLEAN ; // lokalna pomo?na promenljiva *BEGIN* LOOP secondCannotEnter := TRUE ; // javimo da P2 ne moe u?i WHILE secondCannotEnter DO // sve dok P2 ne moe u?i *TestAndSet*(secondCannotEnter,*inside*) // nedeljiva operacija END; KriticnaOblast2 ; *inside := FALSE ;* // izlaz OstaleStvari2 END *END *Process2; *BEGIN* active := FALSE ; PARBEGIN ; Process1 ; Process2 ; PAREND *END TAS.* * * */Analiza: /*kod ovog algoritma koristimo jednu globalnu pomo?nu promenljivu /inside /koja ozna? ava, da li se neki proces nalazi unutar svoje kriti?ne oblasti. Pored te globalne, svaki proces ima i jednu pomo?nu promenljivu, koja ozna?ava da li dati proces moe u?i u k.o. Ne mogu oba procesa istovremeno u?i u kriti?nu oblast (greka druge verzije): pp. da oba procesa stignu istovremeno do /WHILE/ petlje. Tada je inside=FALSE, firstCannotEnter=TRUE, secondCannotEnter=TRUE. Oba procesa ?e u?i u petlju, ali poto je naredba /TestAndSet/ nedeljiva, i garantuje da se ne moe paralelno izvravati na vie procesora, sigurno je da ?e samo jedan proces uspeti da je izvri. Neka je to /Process1/. Tada ?e biti firstCannotEnter=FALSE i inside=TRUE. to zna?i, da ?e /Process1/ u?i u kriti?nu oblast. Za sve ostale procese ?e vaiti inside=TRUE, pa ?e svaka pomo?na lokalna promenljiva uzeti tu vrednost, i ti procesi ?e i dalje ?ekati unutar /WHILE/ petlje. Nema zaglavljivanja (greka tre?e verzije): zbog nedeljivosti naredbe /TestAndSet/. Nema zaglavljivanja (greka ?etvrte verzije): ne postoji mogu?nost da nakon prvog ulaska u /WHILE/ petlju istovremeno bude firstCannotEnter=TRUE i secondCannotEnter=TRUE zbog naredbe TestAndSet i zbog toga to je inside=FALSE. Nema alternacije (greka prve verzije): neka se /Process2/ dovoljno dugo zaglavi, tako da /Process1/ stigne ponovo do /WHILE/ petlje. Tada je firstCannotEnter=TRUE i inside=FALSE (Process1 je postavio ovu vrednost, poto je ve? jednom uao i izaao iz svoje k.o.). Tada ?e /Process1/ jednom u?i u /WHILE/ petlju, ali ?e posle instrukcije /TestAndSet/ biti firstCannotEnter=FALSE i inside=TRUE, pa ?e ponovo u?i. Realizacija pomo?u sistemskih poziva * * * * * * * * *
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

biti firstCannotEnter=FALSE i inside=TRUE, pa ?e ponovo u?i. Realizacija pomo?u sistemskih poziva * * * * * * * * * * *Nedostatak i softverske//i hardverske realizacije *je to to se dolazi do pojave koja se zove *busy waiting *(*zaposleno ?ekanje*): proces se neprestano vrti unutar WHILE petlje, ne radi nita korisno, svaki put samo proverava vrednost neke promenljive da bi saznao da li moe u?i u svoju kriti?nu oblast ili ne. Zna?i i pored toga to dati proces ne radi nita korisno, troi procesorsko vreme, a poto znamo da unutar kriti?ne oblasti istovremeno moe biti samo jedan proces, moemo zamisliti i situaciju da imamo 1001 procesa od kojih se jedan nalazi unutar k.o, a ostali stoje u jednom mestu, vrte se u krugu unutar /WHILE/ petlje. Tako imamo jedan proces koji radi neto korisno i 1000 procesa koji ?ekaju?i na taj jedan troe procesorsko vreme. *Drugi nedostatak*prethodnih realizacija je u tome to ne vode ra?una o prioritetima procesa: moe se desiti da najprioritetniji proces u?e u kriti?nu oblast, tek posle mnotva neprioritetnih procesa. Da bismo izbegli ove nedostatke softverske i hardverske realizacije, koristi?emo pomo? operativnog sistema, tj. kriti?nu oblast ?emo realizovati pomo?u sistemskih poziva. Kod ove realizacije, kada proces ?eka da u?e u kriti?nu oblast, postaje *blokiran* (*blocked*), sve dok ga neki drugi proces ne odblokira. Sve varijante sinhronizacije procesa pomo?u sistemskih poziva ilustrova?emo na *PROBLEMU PROIZVO?A?A I POTROA?A (The Producer-Consumer Problem): *imamo jednog proizvo?a?a i jednog potroa?a. Proizvo?a? neto proizvodi to je proces koji puni neki bafer. Potroa? troi ono to je proizvo?ac proizveo to je proces koji prazni bafer (uzima elemente iz bafera). Proizvo?a? moe da proizvodi dok skladite (bafer) ne postane pun, a potroa? moe da troi dok skladite (bafer) ne postane prazan. U tim situacijama, proizvo?a? odnosno potroa? odlazi na spavanje. Sleep & WakeUp * * * * Kod ove realizacije koristimo dva sistemska poziva: /Sleep/ (spavaj) i /WakeUp/ (probudi se). Sistemski poziv *Sleep* blokira onog procesa koji ga je pozvao, a *WakeUp* *( x ) *probu?uje procesa *x* . U slu? aju problema proizvo?a?a i potroa?a, ove pozive koristimo na slede?i na?in: Kada proizvo?a? vidi da nema mesta u baferu, ode da spava (postaje blokiran) pomo?u naredbe /Sleep/ u tom stanju ostaje sve dok ga potroa? ne probudi. Kada potroa? vidi da je bafer prazan, odlazi na spavanje u tom stanju ostaje sve dok ga proizvo?a? ne probudi. Proizvo?a? ?e probuditi potroa?a kada stavi prvi elemenat u bafer to zna?i da je pre toga bafer bio prazan, pa potroa? spava. Potroa? ?e probuditi proizvo?a?a kada konstatuje da je zaspao, a ima mesta u baferu. *MODULE Sleep&WakeUp ;* CONST *n = 100 ; *// veli?ina bafera VAR *count* : CARDINAL ; // broj elemenata u baferu * bafer*: ARRAY [1..n] OF INTEGER ; *PROCEDURE* Producer ; // proizvo?a? *VAR* item : INTEGER ; *BEGIN* LOOP ProduceItem ( item ) ; // proizvodi elemenat IF count = n THEN // ako je bafer pun, *Sleep *// spavaj END; EnterItem ( bafer,item ) ; // ina?e, ubaci elemenat u bafer INC ( count ) ; // pove?aj broja? IF count = 1 THEN // ako smo stavili prvi elemenat, *WakeUp ( Consumer ) *// probudi potroa?a, poto je spavao
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

END END *END* Producer ; * PROCEDURE *Consumer ; // potroa? VAR *item *: INTEGER ; *BEGIN* LOOP IF count = 0 THEN // ako je bafer prazan, *Sleep *// spavaj END; RemoveItem ( bafer, item ) ; // ina?e, uzmi elemenat iz bafera DEC ( count ) ; // smanji broja? IF count = n-1 THEN // ako je bafer bio pun, *WakeUp ( Producer ) *// probudi proizvo?a?a END; ConsumeItem ( item ) // radi neto sa preuzetom elementom END *END *Consumer ; *BEGIN* count := 0 ; Init ( bafer ) ; PARBEGIN ; Producer ; Consumer ; PAREND *END Sleep&WakeUp ;* * * */Analiza: /*algoritam *ne radi*!! *Objanjenje: * posmatrajmo slede?u situaciju: neka je bafer prazan, tada je count=0, neka se izvrava proces potroa?a. Potroa? pogleda vrednost /count/-a, vidi da je nula, i u?e unutar /IF/ naredbe. Neka se u tom trenutku, potroa? prekida (pre nego to izvri naredbu /Sleep/) , i procesorsko vreme se daje proizvo?a?u. Proizvo?a? proizvodi jedan elemenat, vidi da bafer nije pun, stavi elemenat u bafer i pove?a broja? za jedan. Tada primeti da je pre toga bafer bio prazan, pa shvati da je potroa? zaspao (tu je problem: potroa? je bio prekinut pre nego to je uspeo da zaspi) i pokua ga probuditi. *Poto potroa? jo ne spava, ta informacija se gubi.* Sada potroa? ponovo dobije procesor i ode da spava poto je ube?en da je bafer prazan. Nakon izvesnog vremena, proizvo?a? ?e napuniti bafer do kraja i odlazi na spavanje ?eka potroa?a da ga probudi. I tako, i potroa? i proizvo?a? spavaju do beskona?nosti..., tj. javlja se zaglavljivanje (deadlock). *U ?emu je problem?*Problem je u kori?enju zajedni?ke, globalne promenljive /count/!! Da bi sinhronizacija bila uspena, pristup toj promenljivoj treba da bude unutar kriti?ne oblasti!! (unutar kriti?ne oblasti istovremeno moe biti samo jedan proces) to u ovom slu?aju ne vai. Semafori (semaphores) * * * * Kori?enje semafora za sinhronizaciju procesa predloio je *Dijkstra* (1965). Semafor je apstraktni tip podataka, koji se koristi kao broja? bu?enja. Ako je vrednost semafora nula (0), to zna?i da nije dolo do bu?enja, ako je vrednost semafora pozitivan broj, ozna?ava broj sa?uvanih bu?enja. Nad semaforima definiemo dve nedeljive operacije: *Up (S)* i *Down (S)*. Operacija *Down (S)* radi na slede?i na?in: uzima vrednost semafora S i proverava da li je ta vrednost ve?a od nule (u tom slu?aju imamo sa?uvanih bu?enja) ako jeste, smanjuje vrednost semafora za jedan i vra?a kontrolu. Ako je vrednost semafora S jednak nuli, to zna?i da nemamo vie sa?uvanih bu?enja, proces odlazi na spavanje. Operacija /Down/, moe se posmatrati kao generalizacija operacije *Sleep*. Operacija *Up (S)* radi na slede?i na?in: ako neki procesi spavaju ?ekaju na semaforu S probu?uje jedan od tih procesa. Izbor procesa je zadatak operativnog sistema (moe biti slu?ajan). U ovom slu?aju se vrednost semafora S ne menja, tj. ostaje nula, ali ?emo imati za jedan manji broj spavaju?ih procesa. Ako je vrednost semafora S ve?a od nule, tada se samo pove?ava ta vrednost za jedan. Operacija /Up/ moe se posmatrati kao generalizacija operacije *WakeUp*. *Vano je zapamtiti*da su operacije /Down/ i /Up/ nedeljive, tj. ako smo po?eli sa izvravanjem, ne moemo biti prekinuti dok ne budemo zavrili. Rad ovih naredbi moemo opisati pomo?u slede?ih pseudo-kodova: *Down ( s
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

prekinuti dok ne budemo zavrili. Rad ovih naredbi moemo opisati pomo?u slede?ih pseudo-kodova: *Down ( s )*: IF s > 0 THEN DEC ( s ) ELSE uspavaj proces koji je pozvao Down ( s ) END; *Up ( s )*: IF ima uspavanih procesa na semaforu s THEN probudi jedan od procesa koji ?ekaju na semaforu s ELSE INC ( s ) END; Pored gore navedenih operacija, moemo definisati i slede?e dve: - *Init (S,n)*inicijalizuje semafor S sa vredno?u n, *Value (S)*vra?a vrednost semafora S. *BINARNI SEMAFORI*predstavljaju poseban tip semafora koji se inicijalizuju sa 1 (jedan) i koji se koriste za spre?avanje ulaska vie od jednog procesa u kriti?nu oblast. Ako svaki proces pre ulaska u svoju k.o. pozove /Down/ i nakon izlaska pozove /Up/, binarni semafori garantuju *me?usobno isklju?ivanje (mutual exlusion)* zbog toga se ti semafori ?esto ozna?avaju sa imenom *mutex* (od /MUTual EXclusion/). Vrednost binarnih semafora moe biti samo 1 ili 0 i imaju slede?e zna?enje: *0 neki proces je unutar kriti?ne oblasti* *1 ni jedan proces nije unutar kriti?ne oblasti* Kako do pove?avanja /mutex/ semafora dolazi samo pri izlasku iz kriti?ne oblasti naredbom Up, ne moe dobiti vrednost ve?u od 1, poto da bi neki proces izaao iz k.o., mora najpre da u?e, a pri ulasku poziva naredbu /Down/, koja ?e ili smanjiti za 1 vrednost /mutex/-a ili ?e (ako je ve? 0) proces biti poslat na spavanje a znamo da se /mutex/ inicijalizuje sa 1. Problem proizvo?a?a i potroa?a se pomo?u semafora reava na slede?i na?in: *MODULE Semaphores ;* CONST n = 100 ; VAR bafer : ARRAY [1..n] OF INTEGER ; *mutex,empty,full : Semaphore ; *// semafori *PROCEDURE *Producer ; // proizvo?a? VAR item : INTEGER ; *BEGIN* LOOP ProduceItem ( item ) ; // proizvodi elemenat Down ( *empty *) ; // ako nema slobodnog mesta, ?ekaj Down ( *mutex *) ; // ako je neko unutar k.o., ?ekaj EnterItem ( bafer,item ) ; Up ( *mutex *) ; // izlazak iz k. o. Up ( *full *) // javi, da smo neto stavili u bafer END *END *Producer ; *PROCEDURE *Consumer ; // potroa? VAR item : INTEGER ; *BEGIN* LOOP Down ( *full *) ; // ako nema nita u baferu, ?ekamo Down ( *mutex *) ; // ako je ve?neko unutar k. o., ?ekaj RemoveItem ( bafer,item ) ; Up ( *mutex *) ; // izlazak iz k.o. Up ( *empty *) ; // javi, da smo neto vadili iz bafera ConsumeItem ( item ) END *END *Consumer ; *BEGIN* Init ( *mutex,1 *) ; Init ( *full,0 *) ; Init ( *empty,n *) ; PARBEGIN ; Producer ; Consumer ; PAREND *END Semaphores ;*** * * */Analiza: /*koristimo 3 semafora: /mutex,full,empty/. /Mutex/ se inicijalizuje sa 1, to ozna?ava da nema procesa unutar k.o., /full /se inicijalizuje sa 0, ozna?ava broj zauzetih mesta u baferu, /empty /se inicijalizuje sa *n*, i ozna?ava da je broj praznih mesta u baferu n, tj. da je bafer potpuno prazan. Posmatrajmo rad *proizvo?a? a*: pozivanjem Down(empty)obezbe?ujemo, da u slu?aju da nema vie slobodnih mesta u baferu (empty=0), proces ode na spavanje, a ako ima, Down(mutex)obezbe?uje ulazak u k.o. tek ako nema nikoga unutar, ina?e opet spavanje. Izlaskom iz k.o., naredba Up(mutex)javlja potroa?u, da moe u?i u k.o. /mutex/ je tu sigurno 0, pa ako potroa? ?eka na /mutex/u, bi?e probu?en, ina?e /mutex/ postaje 1. Na kraju sledi naredba Up(full), tj javimo da smo stavili neto u bafer, pa ako potroa? ?eka na to, bi?e probu?en. Posmatrajmo rad *potroa?a*:
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

pozivanjem Down(full)obezbe?ujemo, da u slu?aju da je bafer prazan (full=0), proces ode na spavanje, a ako nije prazan, Down(mutex)obezbe?uje ulazak u k.o. tek ako proizvo?a? nije unutar, ina?e opet spavanje. Izlaskom iz k.o., naredba Up(mutex)javlja proizvo?a?u, da moe u?i u k.o., ako eli (tj. spava na semaforu /mutex/), ako proizvo? a? ne eli u?i, bi?e mutex=1. Na kraju sledi naredba Up(empty), tj. javimo da smo uzeli neto iz bafera, pa ako proizvo?a? ?eka na to, bi?e probu?en. Vano je primetiti da ovde koristimo *dva tipa semafora:* 1. /mutex / koristimo da bismo obezbedili da unutar kriti?ne oblasti u istom trenutku nalazi najvie do jedan proces 2. /empty,full / koristimo da bismo obezbedili sinhronizaciju izme?u procesa proizvo?a?a i procesa potroa?a. Ova realizacija radi bez problema to se ti?e implementacije semafora, ali pogreno kori?enje semafora moe dovesti do ozbiljnih greaka: npr. pp. da je bafer pun, tada ako kod *proizvo?a?a* najre stavimo Down(/mutex/), pa tek onda Down(/empty/), dolazimo do slede?e situacije: proizvo?a? je uao u kriti?nu oblast i ne moe biti prekinut, a poto je bafer pun, otiao je i na spavanje tada, potroa? vidi da bafer nije prazan, ali ?e i on zaspati jer ne moe u?i u k.o. zbog proizvo?a?a i tako dolazimo do *zaglavljivanja.* * * * * Broja?i doga? aja (event counters) * * * * Broja?i doga?aja (event counters, *Reed, Kanodia, 1979*) predstavljaju apstraktni tip podataka, nad kojim se definiu slede?e operacije: 1. *Init ( e ) *inicijalizuje broja? *e*, 2. *Read ( e ) *vra?a trenutnu vrednost broja?a doga?aja *e*, 3. *Advance ( e ) *pove?ava vrednost broja?a *e* za jedan 4. *Await ( e,v )*?eka dok vrednost broja?a *e* ne postane ve?e ili jednako od *v* * * *Vano*je napomenuti, da se vrednost broja?a doga?aja uvek pove?ava, nikada se ne smanjuje, ne moe se podesiti na eljenu vrednost (vrednost b.d. moe se samo ?itati i pove?avati). Inicijalna vrednost broja?a je nula. Realizacija problema proizvo?a?a i potroa?a pomo?u broja?a doga?aja izgleda na slede?i na?in: *MODULE ECounters ;* CONST n = 100 ; VAR bafer : ARRAY [1..n] OF INTEGER ; *in,out : EventCounter ; *// broja?i doga?aja *PROCEDURE *Producer ; // proizvo?ac VAR item : INTEGER ; *count* : INTEGER ; // ukupan broj /proizvedenih/ elemenata *BEGIN* count := 0 ; LOOP ProduceItem ( item ) ; // proizvodi elemenat INC ( count ) ; // pove?aj broj proizvedenih elem. *Await* *( out, count n ); *// spavaj ako nema mesta u baferu EnterItem ( bafer,item ) ; *Advance ( in ) *// pove?aj broja? *in* za jedan END *END *Producer; *PROCEDURE *Consumer ; // potroa? VAR item : INTEGER ; *count *: INTEGER ; // ukupan broj /potroenih/ elemenata *BEGIN* * *count := 0 ; LOOP INC ( count ) ; // pove?aj broj potroenih elem. *Await ( in, count ) ; *// spavaj, ako je bafer prazan RemoveItem ( bafer,item ) ; *Advance ( out ) ; *// pove?aj broja? *out* za jedan ConsumeItem ( item ) END *END *Consumer ; *BEGIN* Init ( in ) ; Init ( out ) ; PARBEGIN ; Producer ; Consumer PAREND *END ECounters.*** * * */Analiza: /*algoritam koristi dva broja?a doga?aja: *in *ozna?ava broj ubacivanja u bafer (ukupan broj /uba?enih/ elemenata od startovanja programa) , a *out *broj preuzimanja iz bafera (ukupan broj /preuzetih/ elemenata od startovanja programa). Pri tome mora vaiti da je *in* uvek ve?i ili jednak od
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

(ukupan broj /preuzetih/ elemenata od startovanja programa). Pri tome mora vaiti da je *in* uvek ve?i ili jednak od *out*-a (u suprotnom, dobijamo da je preuzeto vie elemenata nego to je uba?eno, to je nemogu?e), ali razlika izme?u *in*-a i *out*-a ne sme biti ve?a od *n*, tj. od veli?ine bafera (u suprotnom, dolazimo do situacije, da smo ubacili vie elemenata, nego to bafer moe primiti). Posmatrajmo rad *proizvo?a?a*: nakon to proizvo?a? proizvede novi elemenat, pove?a broj proizvedenih elemenata i naredbom Await(out,count-n)proveri da li ima mesta u baferu da stavi novi elemenat. Kada imamo mesto za novi elemenat? Ako je broj slobodnih mesta u baferu ve?i od 1, tj ako je potroa? potroio barem count-n elemenata (ako je out=count-1, onda je bafer prazan, ako je out=count-2, onda imamo n-1 mesta u baferu,...,ako je out=count-n, onda imamo jedno slobodno mesto u baferu). Rad ?e sigurno po?eti proizvo?a?, jer se inicijalno stavlja in=0,out=0, pa ?e vaiti 0=out>=1-n, gde je naravno n>=1. Pri izlasku iz kriti?ne oblasti, proizvo?a? javlja da je uspeno ubacio novi elemenat u bafer naredbom Advance(in). Posmatrajmo rad *potroa?a*: u prvom koraku se pove?ava broj potroenih elemenata, a zatim se ?eka da proizvo?a? proizvede dovoljan broj elemenata sa naredbom Await(in,count), tj. potroa? moe uzeti k-ti elemenat iz bafera, tek ako je proizvo?a? proizveo barem k elemenata. Monitori (monitors) i uslovne promenljive (condition variables) Prilikom analize rada algoritma za reavanja problema proizvo?a?a i potroa?a pomo?u semafora uo?ili smo da neispravno kori?enje semafora (lo redosled) moe dovesti do zaglavljivanja. Semafori rade savreno, ali ako ih pogreno koristimo mogu se javiti ozbiljne greke u radu programa. Zna?i, bilo bi poeljno na?i neki mehanizam koji bi olakao pisanje korektnih programa. Upravo je to bila pokreta?ka ideja koja je dovela do razvoja koncepta monitora. *Monitor*predstavlja skup procedura, promenljivih, tipova podataka, konstanti itd. koji su grupisani u specijalni modul ili paket. Kori?enje monitora za sinhronizaciju procesa predloili su *Hoare *(1974) i *Brinch Hansen *(1975). Monitori predstavljaju specijalne module, sa slede?im karakteristikama : 1. procedure iz monitora moe istovremeno pozvati najvie do jedan proces, zna?i ako je proces A pozvao neku proceduru monitora X, tada ni jedan drugi proces ne moe pozvati ni jednu proceduru iz tog monitora, dok ta procedura ne zavri sa radom, 2. procedure monitora se izvravaju bez prekida *Monitori nasuprot semafora predstavljaju karakteristiku programskih jezika, a ne operativnih sistema.*To zna?i da kompajleri tih jezika znaju da sa tim modulima treba raditi na poseban na?in: na osnovu prethodnih karakteristika. Pomo?u monitora lako moemo reiti probleme vezanih za *kriti?ne oblasti*: kriti?nu oblast ubacimo u monitor a ostalo je zadatak kompajlera. Programski jezici koji podravaju monitore: /Modula-2/, /Concurrent Pascal/, /Concurrent Euclid/, itd. Monitori predstavljaju dobro reenje za kriti?nu oblast, ali to nije dovoljno: potrebno je na?i neko reenje i za to da se proces, koji je pozvao neku proceduru iz monitora pre?e u stanje *BLOKIRAN* (blocked) ako je to potrebno (npr. ako proizvo?a? primeti da nema mesta u baferu, treba da
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

ode na spavanje i time omogu?i da potroa? u?e u svoju kriti?nu oblast pozivanjem neke procedure iz monitora). Da bismo ovaj problem reili, uvodimo pojam *uslovnih promenljivih *(*condition variables*). *Uslovne promenljive*su globalne promenljive (vidi ih svaki proces), nad kojima se definiu slede?e nedeljive operacije (poto su nedeljive, moraju biti unutar monitora!!): 1. *Init ( c )*inicijalizuje uslovnu promenljivu *c* 2. *Wait ( c ) *blokira (uspava) proces koji je pozvao naredbu /Wait/ na uslovnoj promenljivoj *c* zna?i, ovaj proces postaje blokiran (?eka na signal *c*), a kontrola se predaje nekom drugom procesu koji sada ve? moe u?i u kriti?nu oblast. *3. **Signal ( c )*alje signal *c *ostalim procesima ako postoji neki proces koji ?eka na ovaj signal, treba da se probudi i da nastavi sa radom. Ovde dolazimo do problema, jer izgleda da ?emo imati dva procesa unutar monitora: jedan koji je pozvao nardbu Signal (c), i drugi koji je ?ekao na taj signal i sad je probu?en. Imamo dva pristupa za reenje ovog problema: *Hoare* je predloio slede?e: neka proces koji je pozvao /Signal/ postaje suspendovan, a proces koji je probu?en nastavi sa radom. Ideja *Hansena* je slede?a: proces koji je pozvao /Signal/, mora iza?i iz monitora, tj. /Signal/ mora biti poslednja naredba odgovaraju?e procedure monitora, tako ?e probu?eni proces biti jedini u monitoru i moe nastaviti svoj rad. Mi ?emo koristiti Hansenovo reenje. *Ako nemamo ni jedan proces koji ?eka na signal c, teku?i proces nastavlja sa radom a signal se gubi.* 4. *Awaited ( c ) *vra?a logi?ku vrednost /TRUE/, ako neki proces ?eka (spava) na uslovnoj promenljivoj *c*, odnosno /FALSE/, ako takav proces ne postoji Za demonstraciju kori?enja monitora za reavanje problema proizvo?a?a i potroa?a koristimo programski jezik /Modula-2/ (program je zadat u pseudo-kodu) : *DEFINITION MODULE Monitor ;* PROCEDURE EnterItem ( item : INTEGER ) ; PROCEDURE RemoveItem ( VAR item : INTEGER ) ; *END Monitor.* *IMPLEMENTATION MODULE Monitor[1000]; *// modul, koji predstavlja monitor CONST n = 100 ; VAR *count* : CARDINAL ; // index elemenata bafer : ARRAY [1..n] OF INTEGER ; * notFull, notEmpty : CondVAR ; *// uslovne promenljive, signali *PROCEDURE *EnterItem ( item : INTEGER ) ; // ubacivanje u bafer *BEGIN* IF *count = n* THEN // ako je bafer pun, *Wait ( notFull ) *// spavamo, dok nam potroa? END; // ne javi, da nije pun INC ( count ) ; bafer [ count ] := item ; IF count = 1 THEN // bafer je bio prazan, *Signal ( notEmpty ) *// potroa? je verovatno spavao END // traba ga probuditi *END *EnterItem; *PROCEDURE *RemoveItem (VAR item : INTEGER); // izbacivanje iz bafera *BEGIN* IF*count = 0 *THEN // ako je bafer prazan, *Wait ( notEmpty ) *// spavamo, dok nam proizvo?a? END; // ne javi, da nije prazan item := bafer [ count ] ; DEC ( count ) ; IF count = n-1 THEN // bafer je bio pun, *Signal ( notFull ) *// proizvo?a? je verovatno spavao * *END // treba ga probuditi *END *RemoveItem ; *BEGIN* count := 0 ; Init ( notFull ) ; Init ( notEmpty ) *END Monitor.* * * *MODULE Primer ;* *FROM*Monitor *IMPORT* EnterItem, RemoveItem ; // koristimo monitor * PROCEDURE *Producer ; // proizvo?a? VAR item : INTEGER ; BEGIN LOOP ProduceItem ( item ) ; *EnterItem ( item )* END *END *Producer ; *PROCEDURE *Consumer ; //
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

BEGIN LOOP ProduceItem ( item ) ; *EnterItem ( item )* END *END *Producer ; *PROCEDURE *Consumer ; // potroa? BEGIN LOOP *RemoveItem *( item ) ; ConsumeItem ( item ) END *END *Consumer ; *BEGIN* PARBEGIN ; Producer ; Consumer PAREND *END Primer.*** * * /Primedba: /radi jednostavnosti, odnos potroa? a i proizvo?a?a je realizovan na osnovu /LIFO/ (/Last In First Out/) sistema, to zna?i: onaj elemenat koji je poslednji put uba?en u bafer, bi?e prvi izba?en (bafer se puni prema gore a prazni se prema dole). Ekvivalencija sistema za sinhronizaciju procesa * * * * Problem ekvivalencije sistema za sinhronizaciju procesa glasi: da li i kako moemo pomo?u datog mehanizma sinhronizacije realizovati neki drugi mehanizam. Pokaza?emo da se monitori mogu biti implementirani na osnovu semafora i obrnuto. Implementacija monitora kori?enjem semafora Pretpostavimo da operativni sistem podrava rad sa semaforima. ta nam je potrebno za realizaciju monitora? Treba obezbediti: - da procedure iz monitora istovremeno moe pozvati najvie do jedan proces - da se procedure monitora izvravaju bez prekida - rad sa uslovnim promenljivama *Problem kriti?ne oblasti *(prva dva uslova) reavamo na slede?i na?in: *Svakom monitoru dodeljujemo jedan binarni semafor koji se inicijalizuje sa vredno?u 1 *(podsetimo se: binarni semafori mogu imati samo vrednost 1 (ozna?ava da nema ni jednog procesa unutar kriti?ne oblasti) ili 0 (ozna?ava da je neki proces unutar k.o.) , inicijalno uzimaju vrednost 1). Neka se taj semafor zove /mutex/. Njegov zadatak je da kontrolie ulazak u monitor (pozivanje procedura monitora). Kada kompajler vidi da sledi poziv neke procedure iz nekog monitora, on ?e pre tog poziva ubaciti poziv slede?e procedure : PROCEDURE *EnterMonitor* ( mutex ) ; BEGIN Down ( mutex ) END EnterMonitor ; Ova procedura garantuje da se procedure datog monitora ne izvravaju paralelno, naime, ako proces A pozove neku proceduru monitora X, kompajler ?e automatski ubaciti poziv procedure /EnterMonitor/, pa ?e /mutex/ postati 0. Neka sada i proces B pozove neku proceduru monitora X, tada se ponovo poziva /EnterMonitor/, pa poto je mutex=0, proces B ide na spavanje. Isto tako ovaj postupak garantuje i neprekidno izvravanje procedura monitora. Posmatrajmo sada *problem uslovnih promenljivih*! Posmatrajmo na koje na?ine moe neki proces iza?i iz monitora (kako mogu procedure monitora zavriti svoj rad). Imamo 3 mogu?nosti: 1. naredbom /Wait (c)/, to zna?i da postaje blokiran i neki drugi proces dobija mogu?nost ulaska u kriti?nu oblast (u ovom slu?aju zapravo nema pravog izlaska iz monitora, proces jednostavno postaje blokiran da bi pustio drugi proces da u?e u k.o.) 2. naredbom /Signal (c)/, to zna?i da alje signal c, to moe dovesti do bu?enja nekog procesa koji ?eka na taj signal 3. normalno, tj. ne?e pozvati /Signal/ Reenje je slede?e: *svakoj uslovnoj promenljivoj pridruujemo po jedan semafor koji se inicijalizuje na nulu*. U tre?em slu?aju, jednostavno treba pozvati proceduru /LeaveNormally/*,* koja ?e probuditi jednog procesa koji ?eka na ulazak u k.o, ako takav proces postoji (i ostavi?e /mutex/ odgovaraju?eg monitora na nuli), a ako takav proces ne postoji pove?ava vrednost /mutex/a (poto je mutex binarni semafor, bi?e mutex=1),
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

to ?e zna?iti da nema nikoga unutar k.o. PROCEDURE *LeaveNormally* ( mutex ) ; BEGIN Up ( mutex ) END LeaveNormally; U slu?aju poziva naredbe /Wait (c)/, treba pozvati slede?u proceduru: PROCEDURE *Wait *( mutex,c ) ; BEGIN Up ( mutex ) ; Down ( c ) END Wait; Naredba Up ( mutex )radi slede?e: ako postoji neki proces koji spava na /mutexu/, bi?e probu?en, ako ne, /mutex/ postaje 1, to ozna?ava da se ni jedan proces ne nalazi unutar odgovaraju?eg monitora. Naredbom Down ( c )dobijamo da se proces blokira na semaforu c. U slu?aju da se procedura zavrava naredbom /Signal (c)/, potrebno je pozvati slede?u proceduru: PROCEDURE *LeaveWithSignal* ( c ) ; BEGIN Up ( c ) END LeaveWithSignal ; Ova procedura probu?uje procesa koji ?eka na signal c. *Panja*!!*Ovde se pretpostavlja slede?e: iz procedure monitora izlazimo sa operacijom Signal (c), samo ako je to potrebno, tj. samo ako smo sigurni da postoji neki proces koji ?eka na taj signal.* U tom slu?aju, ne treba nam /Up ( mutex )/, tj, ne treba javiti da nema nikoga unutar kriti?ne oblasti, jer je to neta?no: kako neko ?eka na signal c, to zna?i da je pozvao proceduru /Wait ( mutex,c )/ unutar kriti?ne oblasti i taj proces ?e nastaviti svoj rad unutar k.o., pa mora ostati mutex=0. Implementacija semafora pomo?u monitora Sada ?emo pretpostaviti da operativni sistem podrava monitore i uslovne promenljive za sinhronizaciju lakih procesa, pa ?emo na osnovu njih implementirati semafore. Ideja je slede?a: za svaki semafor treba nam po jedan broja? bu?enja i jedna uslovna promenljiva. Reenje je dat u obliku pseudo-koda koji se oslanja na karakteristike programskog jezika /Modula-2/: *DEFINITION MODULE Semaphores ; *// interfejs modula semafori *TYPE Semaphore ; *// nedostupni tip podataka PROCEDURE Init ( VAR s : Semaphore ; v : CARDINAL ) ; PROCEDURE Down ( s : Semaphore ) ; PROCEDURE Up ( s : Semaphore ) ; PROCEDURE Value ( s : Semaphore ) : CARDINAL ; PROCEDURE Kill ( s : Semaphore ) ; *END Semaphore ;* *IMPLEMENTATION MODULE Semaphores [1000] ;* TYPE *Semaphore *= *POINTER TO SemDesc ; *// Semafor je pokaziva? na slog *SemDesc *= RECORD *signal : CondVAR ; *// uslovna promenljiva *count *: CARDINAL // broja? END; * PROCEDURE Init *(VAR s : Semaphore ; v : CARDINAL) ; * *// inicijalizacija semafora BEGIN NEW ( s ) ; // alokacija memorije s^.count := v ; // inicijalizacija broja?a Init ( s^.signal ) // ini. uslovne promenljive *END Init ;* *PROCEDURE Down *( s : Semaphore ) ; BEGIN IF s^.count = 0 THEN // ako je broja? na nuli, Wait ( s^.signal ) // ?ekamo na signal (spavamo) ELSE // ina?e, imamo signal, pa DEC ( s^.count ) // ne treba spavati, moemo dalje, END // samo treba javiti da nismo zasp. *END Down ;* * PROCEDURE Up *( s : Semaphore ) ; BEGIN IF Awaited ( s^.signal ) THEN // ako neko ?eka na signal, Signal ( s^.signal ) // bi?e probu?en, ELSE // ako niko ne ?eka, INC ( s^.count ) // zapamtimo da smo imali signal END *END Up ;* *PROCEDURE Value *( s : Semaphore ) : CARDINAL ; BEGIN RETURN s^.count *END Value ;* * * * PROCEDURE Kill *( VAR s : Semaphore ) : CARDINAL ; BEGIN FREE ( s ) // ako semafor vie nije potreban, END Kill; // treba osloboditi zauzetu mem. *END Semaphores;* Klasi?ni problemi sinhronizacije * * * * * * * * * * Problem jedu?ih filozofa * (The
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

zauzetu mem. *END Semaphores;* Klasi?ni problemi sinhronizacije * * * * * * * * * * Problem jedu?ih filozofa * (The Dining Philosophers Problem)* Problem jedu?ih filozofa poti?e od *Dijkstre*, a glasi ovako: pet filozofa sede oko okruglog stola. Ispred svakog filozofa nalazi se po jedan tanjir sa pagetom. Izme?u svaka dva tanjira postavljena je po jedna viljuka. Filozofi su svoj ivot posvetili razmiljanju. Ako postanu gladni, jedu pagete, pa ponovo razmiljaju. Problem je u tome, to da bi neki filozof mogao jesti, potrebne su mu dve viljuke. Zato kada filozof postane gladan, pogleda, da li moe uzeti obe viljuke, ako moe jede (za to vreme njegovi susedi ne mogu jesti), ako ne moe, ode na spavanje dok viljuke ne postanu slobodne. Zadatak je slede?i: napisati program koji ?e reiti problem ovih filozofa, tj. koji ?e uspeno sinhronizovati rad 5 procesa koji predstavljaju filozofe. O? igledno reenje bi izgledalo na slede?i na?in: PROCEDURE Philosopher ; BEGIN LOOP Think ; // razmiljaj TakeFork ( leftside ) ; // uzmi viljuku sa leve strane, // ako ne moes ?ekaj TakeFork ( rightside ) ; // uzmi viljuku sa desne strane, // ako ne moes ?ekaj Eat ; // jedi PutFork ( leftside ) ; // vrati levu viljuku PutFork ( rightside ) ; // vrati desnu viljuku END END Philisopher; *Ovakvo reenje ne?e raditi*: pp. da se svi procesi izvravaju paralelno, tada ?e svaki filozof uzeti levu viljuku i onda ?e svaki od njih ?ekati na svog desnog suseda da mu da desnu viljuku dolazimo do zaglavljivanja. Pokuajmo sada, slede?e: uzmimo levu viljuku, pa ako desna nije slobodna, vratimo levu ?ekamo neko vreme, pa ponovo uzmemo levu itd. Naalost ni ova ideja nam ne? e pomo?i: ponovo pp. da svi procesi rade paralelno, i da ?e na neki na?in svi ?ekati istu koli?inu vremena, tada opet niko ne?e jesti ovaj algoritam ?e moda raditi, ali moe do?i do zastoja ako svi generatori slu?ajnih brojeva generiu iste brojeve, to u nekim slu?ajevima moe dovesti do katastrofalnih rezultata (npr. upravljanje nuklearnim elektranama, saobra?ajem ili raketama itd.). Mogli bismo koristiti jedan binarni semafor, pa staviti /Down(mutex)/ ispred TakeFork(leftside)i /Up(mutex)/ iza PutFork(rightside) takav algoritam bi sigurno radio: najpre pogledamo da li postoji neki filozof koji ve? jede, ako jeste, ?eka?emo da zavri ru?ak, ako niko nejede, red je na nas. Nedostatak je u tome, to ?e istovremeno jesti samo jedan filozof, tj. koristi?emo samo dve viljuke od pet, a mogli bismo ?etri, tj. mogli bi i dva filozofa jesti istovremeno. Pravo reenje kori?enjem semafora izgleda na slede?i na?in: * * *MODULE Philosophers ;* CONST n = 5 ; // broj filozofa TYPE *State = ( thinking, hungry, eating ) ;* // stanja filozofa : razmilja,gladan,jede VAR *mutex : Semaphore ; *// binarni semafor *states*: ARRAY [1..n] OF *State *; // stanja filozofa *s *: ARRAY [1..n] OF *Semaphore *; // pomo?ni semafori * PROCEDURE Philosopher *( i : CARDINAL ) ; // i ozna?ava redni broj filozofa BEGIN LOOP Think ; // razmiljaj TakeForks ( i ) ; // uzmi viljuke Eat ; // jedi PutForks ( i ) // vrati viljuke END * END *Philosopher ; * PROCEDURE *TakeForks ( i : CARDINAL ) ; // i ozna?ava redni broj filozofa BEGIN Down ( mutex ) ; // ulazak u kriti?nu oblast states [ i ] := hungry ; // filozof je gladan Test ( i ) ; // ako bar jedan od suseda jede, Up ( mutex ) ; //
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

izlazimo iz kriti?ne oblasti, Down ( s[i] ) // ali ?emo ?ekati na viljuku (moda na obe) * END *TakeForks ; * PROCEDURE *PutForks ( i : CARDINAL ) ; // i ozna?ava redni broj filozofa BEGIN Down ( mutex ) ; // ulazak u k.o. states [ i ] := thinking ; // filozof prestaje da jede, // po?inje razmiljati Test ( left ( i ) ) ; // javimo levom filozofu Test ( right ( i ) ) ; // javimo desnom filozofu Up ( mutex ) // izlaz iz k.o. * END *PutForks ; * PROCEDURE *Test ( i : CARDINAL ) ; // i ozna?ava redni broj filozofa BEGIN IF ( states [ i ] = hungry ) AND // ako je na filozof gladan, ( states [ left ( i ) ] <> eating ) AND // a ni levi filozof, (states[ right ( i ) ] <> eating) // ni desni filozof ne jede, THEN states[i] := eating ; // na filozof moe slobodno jesti Up ( s [ i ] ) // pa ga treba probuditi END * END *Test ; *BEGIN* Init ( mutex,0 ); Init ( s[1],1 ); states[1]:=thinking; ... Init ( s[n],1 ); states[n]:=thinking; PARBEGIN ; Philosopher ( 1 ) ; ... Philosopher ( n ) ; PAREND *END Philosophers.* */Analiza: /*Posmatrajmo rad programa. Neka neki filozof (A) postane gladan, tada pogleda levog i desnog suseda, ako ni jedan od njih ne jede, to zna?i da je i leva i desna viljuka slobodna, pa moe da jede (to se odvija u proceduri /Test/) i poalje signal na svoj semafor, da ne bi zaspao pri izlasku iz procedure /TakeForks/. Ako bar jedan od suseda jede, ne moe uzeti obe viljuke, pa ne moe ni jesti, zato ?e ?ekati na svom semaforu to obezbe?uje /Down/ operacija na kraju procedure /TakeForks/. Pretpostavimo sada da je ovaj na filozof (A) uspeo da uzme obe viljuke i po?eo da jede. Neka sada ogladi filozof (B) pored njega. Taj isto javi da je gladan i ode da testira susede. Vidi da filozof (A) pored njega jede, pa ne moe uzeti viljuku (filozofi su vrlo miroljubivi, pa ne?e silom oduzeti viljuku od suseda) zato ?e da zaspi na svom semaforu. Nakon izvesnog vremena filozof A prestaje da jede, i kae ostalima: idem ja da razmiljam. Ali pre nego to iza?e iz procedure /PutForks/, javi susedima da mu viljuke vie nisu potrebne, tako to ?e pozvati /Test/ i za levog i za desnog suseda. Kada pozove /Test/ za filozofa B (koji gladan ?eka na svom semaforu), uz pretpostavku da ni drugi sused od B ne jede, B ?e po?eti da jede (state[B]:=eating) i dobija signal na svom semaforu da moe iza?i iz procedure /TakeForks/ i nastaviti svoj rad. *Problem jedu?ih filozofa je koristan za modeliranje procesa koji se takmi?e za ekskluzivan pristup nekim resursima *(tj. datim resursima istovremeno moe pristupiti samo jedan proces). Problem ?itaoca i pisaca * (The Readers and Writers Problem)* * * * * *Problem ?itaoca i pisaca je koristan za modeliranje pristupa bazi podataka. *Imamo neku bazu podataka, nekoliko procesa koji ele upisivati podatke u bazu i nekoliko procesa koji ele ?itati podatke iz baze kako to realizovati a da ne do?emo do problema? Moramo se drati slede?ih pravila: - istovremena ?itanja moemo dopustiti jer procesi-?itaoci ne smetaju jedan drugom - istovremeno ?itanje i pisanje nije dozvoljeno, jer moemo do?i do toga da proces koji ?ita pro?ita pogrene podatke (proces A po?ne ?itati, nakon nekog vremena do?e proces B i izmeni neke podatke u bazi, proces A pro?ita pogrene podatke, dobija loe informacije i pokrene proces samounitavanja svemirske letelice...) - istovremena pisanja nisu dozvoljena, jer mogu prouzrokovati
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

proces samounitavanja svemirske letelice...) - istovremena pisanja nisu dozvoljena, jer mogu prouzrokovati ozbiljne greke Mi ?emo ovde posmatrati problem jednog pisca i ve?eg broja ?italaca. Ideja reenja je slede?a: kada pisac pie, ?itaocima je zabranjem pristup, dok ?itaoci ?itaju, piscu je zabranjen da pie. *MODULE RW ;* VAR *mutex : Semaphore ;* * *// binarni semafor za kontrolu pristupa globalnoj prom. *rc * *db : Semaphore ;* * *// binarni semafor za kontrolu pristupa bazi podataka *rc : CARDINAL ;* * *// broja? ?itaoca koji istovremeno ?itaju iz baze *PROCEDURE *Writer ; // pisac BEGIN LOOP GetData ; // sakupi podatke koje eli upisati u bazu Down ( *db *) ; // ?ekaj ako nema pristup bazi WriteToDataBase ; // pii podatke u bazu Up ( *db *) // javi da si zavrio sa radom END *END *Write ; *PROCEDURE *Reader ; // ?italac BEGIN LOOP Down ( *mutex *) ; // elimo pristup broja?u INC ( rc ) ; // pove?ava se broj ?itaoca IF *rc = 1* THEN // ako smo prvi, Down ( *db *) // treba traiti pristup bazi podataka END; // ina?e ne treba jer je baza ve? otvorena Up ( *mutex *) ; // mogu ostali ?itaoci pristupiti rc-u ReadFromDataBase ; // ?itamo iz baze Down ( *mutex *) ; // traimo ekskluzivni pristup broja?u DEC ( rc ) ; // smanjimo broj ?itaoca IF *rc = 0 *THEN // ako smo mi zadnji, Up ( *db *) // javimo da moe pisa? pristupiti bazi END; Up ( *mutex *); // mogu ostali ?itaoci pristupiti rc-u UseData // koristimo pro?itane podatke END *END *Reader ; *BEGIN* Init ( mutex,1 ) ; // niko jo nije pristupio rc-u Init ( db, 1 ) ; // niko jo nije pristupio bazi rc := 0 ; PARBEGIN ; Writer ; Reader ; ... PAREND *END RW ;* * * */Analiza: /*kada ?italac poeli da ?ita iz baze podataka, najpre proveri da li moe pristupiti globalnoj promenljivoj /rc/ koja ozna?ava broj onih ?itaoca koji istovremeno (u datom trenutku) ?itaju iz baze. Ako ne moe, ?eka na semaforu /mutex/. Ako moe, onda gleda: ako je on prvi od ?itaoca koji ele ?itati iz baze, onda mora zatraiti pristup bazi podataka preko semafora /db/. Ako pisac ve? pie, onda ?e ?ekati na tom semaforu. Ako ne, onda ?e dopustiti ostalim ?itaocima pristup rc-u. Zatim ?e ?itati iz baze. Posle toga ponovo trai pristup rc-u, kada dobije pristup, onda proverava da li je on moda zadnji od ?itaoca, ako jeste, onda nikom (iz skupa ?itaoca) vie nije potrebna baza, pa ?e javiti da moe neko drugi pristupiti. Zna?i prvi ?itaoc ?e zatraiti pristup bazi (to istovremeno ne mogu uraditi i vie njih zbog semafora /mutex/), kada dobije pristup, baza ?e biti otvorena za sve ?itaoce. Poslednji ?itaoc ima zadatak da zatvori bazu i time omogu?i piscu (ili moda nekom ?itaocu koji ponovo eli ?itati) pristup. *Nedostatak ovog reenja*je u tome to favorizuje ?itaoce: ako pisac poeli da upie neto u bazu, mora sa?ekati da svi ?itaoci odustanu od ?itanja, pa se moe desiti da jako dugo ne dobije pristup. Ova pojava se zove *izgladnjivanje (starvation).* Problem uspavanog berberina *(The Sleeping Barber Problem)* * * * * U frizerskom salonu radi jedan berberin. U prostoriji imamo jednu stolicu za ianje i n stolica za muterije koji ?ekaju da dobiju novu frizuru. Ako nema ni jedne muterije, berber sedi na svoju stolicu i spava. Kada u?e prva muterija, budi berberina, sedi na stolicu za ianje i berber ga ia. Slede?a muterija koja do?e, sedi na jednu od tih
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

PRO version

n stolica za ?ekanje, ako ima mesta, i ?eka svoj red, ako nema mesta odustaje od ianja. CONST n = 5 ; // broj stolica za ?ekanje VAR *barber : Semaphore ; *//**da li je berberin slobodan za ianje *customers : Semaphore ; *// da li ima muterija *mutex : Semaphore ; *// za kontrolu pristupa promen. /waiting/ *waiting : CARDINAL ; *// broj muterija koja ?ekaju na ianje *PROCEDURE Barber ; *// berberin BEGIN LOOP Down ( customers ) ; // ako nema muterija, berberin spava Down ( mutex ) ; // traimopristup globalnoj prom. /waiting/ DEC ( waiting ) ; // smanjimo broj muterija koji ?ekaju Up ( barber ) ; // javimo, da ianje moe po?eti Up ( mutex ) ; // pustimo promenljivu waiting CutHair // ianje END *END Barber ;* *PROCEDURE Customer ; *// muterija BEGIN Down ( mutex ) ; // traimo pristup prom. /waiting/ IF waiting < n THEN // ako ima mesta za ?ekanje, INC ( waiting ) ; // ostajemo, pove?amo broj onih koji ?ekaju Up ( customers ) ; // javimo da ima muterije Up ( mutex ) ; // pustimo prom. waiting Down ( barber ) ; // ?ekamo berberina GetHairCut // ianje ELSE // ako nema mesta, odustajemo od ianja i Up ( mutex ) // javimo, da nam ne treba prom. waiting END *END Customer ;* Inicijalizacija : Init ( barber,0 ) ; // berberin spava Init ( customers,0 ) ; // nema ni jedne muterije Init ( mutex,1 ); // pristup waiting-u je dozvoljen waiting := 0 ; // ne ?eka niko na ianje */Analiza: /*Na po?etku nema muterije (Init (customers,0 , waiting=0)). Dolazi prva muterija, vidi da ima mesta (waitingj, A ne?e mo?i traiti resurs Rj. Ako je i Ovaj fajl je svima dostupan za ?itanje. Postoji komanda UNIX-a *lpr* koja se koristi za tampanje fajlova. Ova komanda izme? u ostalih ima i opciju brisanja fajla pa se njom moe obrisati i fajl passwords. Brisanjem ovog fajla ni jedan korisnik se vie ne moe prijaviti na sistem. Tako?e u UNIX-u. Proces koji je pokrenuo neki program ima ista prava kao i njegov vlasnik. Postoji bit koji kontrolie prava i on se zove *setuid*. Ako je *setuid* setovan tada proces koji ga je pokrenuo ima sva prava. Korisnik (nasilnik) iz svog procesa pokrene proces koji ima *setuid* postavljen na 1 (na primer mkdir) i zatim ga nasilno prekine. Pod UNIX-om postoji standardni fajl *core* koji operativni sistem kreira i popunjava kada do?e do greke pri izvravanju programa. Ako korisnik predhodno napravi u svom direktorijumu fajl *core* kao link na fajl */etc/passwords* neki sadraj ?e biti direktno upisan u njega. Ovo je mogu?e zato to je u trenutku prekida proces imao postavljen *setuid* na 1 tj. imao je sve privilegije. Uz malo muke, ono to se upisuje moe li?iti na sadraj *passwords* pa se korisnik na taj na?in dopie. *MULTICS*je imao loe zati?ene mehanizme za paketne obrade. Bilo je mogu?e u?itati podatke sa trake, odnosno kartice i snimiti ih bilo gde. Jedini uslov je bio da se to uradi paketno a ne interaktivno. Ljudi su tada pravili svoje editore koje su snimali u direktorijum odakle ele ukrasti fajl. Kada bi korisnik pokrenuo takav editor ne bi bio svestan da dok on kuca, program mu paketno krade podatke. Ovakvi programi, koji osim to rade ono ?emu su namenjeni rade i neto kriom se nazivaju *trojanski konji*. *TENEX - Digital DEC10 *je tako?e imao neke mane: - za svaki Page Fault se mogla zaka?iti proizvoljna procedura - pristup svakom fajlu se kontrolisao lozinkom i to interaktivno - lozinka se
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

zaka?iti proizvoljna procedura - pristup svakom fajlu se kontrolisao lozinkom i to interaktivno - lozinka se proveravala slovo po slovo. ?im bi naiao na slovo koje ne odgovara, javio bi greku Neka neki program eli da pristupi zati?enom faju. On pokuava sa nekom lozinkom koja se napravi tako da prvo slovo lei u jednoj stranici memorije a ostatak u drugoj. Memorija se popuni (nebitnim stvarima) tako da se u njoj na?e samo prva stranica. Ovo je potrebno da bi dolo do Page Faulta nakon to se obradi prvo slovo lozinke. Na Page Fault se zaka?i procedura koja obavetava o svakom Page Fault-u. Tako, ako se pogodi prvo slovo procedura ?e odreagovati na Page Fault i obavestiti korisnika, a ako ne operativni sistem ?e javiti da je lozinka pogrena. Kada se pogodi prvo slovo onda se lozinka tako teluje da prva dva slova budu u jednoj stranici a ostatak u drugoj i postupak se ponavlja. Za lozinku od 6 od 30 mogu?ih znakova grubom silom bi trebalo izvriti _provera, a na ovaj na?in samo _. Operativni sistem *OS/360* je omogu?avao da se u toku ra?unanja u pozadini neto ?ita. Lozinka se pri kopiranju proveravala u dva navrata i to prvi put se proveravalo smemo li uopte kopirati sa trake u zadati fajl a drugi put kada kopiranje zaista i po?ne (ali tada se nije proveravalo i ime fajla). Ako se izme?u ove dve provere promeni ime fajla, bilo je mogu?e kopirati preko nekog fajla bez obzira da li se imala njegova lozinka ili ne. ta treba da radi osoba koja provaljuje ? - Treba da gleda deo diska sa izba?enim stranicama iz memorije. Operativni sitem ih nekad ne obrie posle swap-ovanja pa se tu mogu kriti vredni podaci. - Treba da poziva nepostoje?e sistemske pozive ili postoje?e ali sa pogrenim parametrima. Postoji mogu?nost da ?e se operativni sistem zbuniti pa se iz takvih situacija moe neto korisno zaklju?iti. - Pri procesu prijavljivanja nekako ga nasilno prekinuti. Tako se moda moe zaobi?i proveravanje lozinke. - Modifikacija strukture podataka koja se koristi za pozivanje servisa operativnog sistema moe zbuniti operativni sistem pa se opet moe neto korisno saznati. Moe da napravi program koji simulira prijavljivanje. Pokrene takav program i napusti ra?unar. Slede?i korisnik seda za ra?unar i unosi svoju lozinku koju program negde zapamti pa zatim pozove pravi program za prijavljivanje. Raditi sve to uputstva kau da nije dozvoljeno, da je opasno ... - armirati sekretaricu ? Principi za ostvarivanje sigurnosti - Dizajn zatite treba da bude javan. Treba dobro realizovati principe (pa se hvaliti). - Podrazumevaju?i na?in pristupa svakom objektu - fajlu je bez pristupa tj niko ne sme da mu pristupi. U praksi nikad nije ba tako ali je neto logi?no, na primer vlasnik ima sve privilegije a ostali nikakve. - Uvek se trae teku?a prava pristupa.. - Svaki proces treba da zapo?ne rad sa to manje privilegija. Ako su potrebne ve?e, onda se naknadno eksplicitno pove?aju. - Mehanizam zatite treba da bude jednostavan, uniforman, od po?etka zamiljen. Mehanizam zatite treba da bude psiholiki prihvatljiv. Provera identiteta Ni jedan korisnik se ne bi smeo lano predstaviti. Korisnik ne sme koristiti resurse ako nije ovla?en. Uobi?ajeni na?in provere identiteta je putem lozinke. Pri prijavljivanju na UNIX sistem potrebno je uneti *login* (korisni?ko ime pod kojim smo poznati
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

operativnom sistemu) i *password *(lozinka). UNIX tada proverava u fajlu *etc/passwords *da li postoji odgovaraju?e ime i da li lozinka odgovara. Lozinka je jednostrano ifrirana to zna?i da ne postoji na?in da se nakon kriptovanja vrati u prvobitno stanje. Kako izabrati lozinku i da li je ona dovoljna? * * Teoretski je mogu?e napraviti _lozinki duine sedam karaktera to je i vie nego dovoljno. Ali korisnici prave kra?e lozinke i ne koriste sve mogu?e karaktere. Tako?e, korisnici su skloni standardnim, predvidivim lozinkama. Tokom nekog istraivanja pokuale su se provaliti lozinke koje ljudi koriste. Upotrebljavana su imena i prezimena korisnika, imena njihovih ena, dece, brojevi automobilskih tablica, datumi ro?enja i sli?no. Kada su tako napravljene lozinke upore?ene sa pravim vie od 85% je bilo pogo?eno. Zato se uvode dodatne provere. - Generatori slu?ajnih brojeva. Lozinka se dodatno ifrira 12-bitnim brojem koji je jedinstven za svakog korisnika? - Jednokratne lozinke. Korisnik ima knjiicu sa lozinkama, pro?ita koja mu treba, iskoristi je pa dobije drugu. - Li?na pitanja. Pri prvom prijavljivanju se korisniku postavljaju li?na pitanja, pa se ponekad proverava identitet korisnika pomo?u njih. - Korisniku se pri prvom prijavljivanju dodeli algoritam, na primer _. Pri kasnijim prijavljivanjima od korisnika se zahteva ime, lozinka i da mu se neki broj. Korisnik tada unosi ime, lozinku i reenje. - Pri odabiranju lozinke se mogu postavljati uslovi tako da lozinka na kraju mora ispasti nelogi?na. Na primer, korisnik u lozinci mora da iskoristi est znakova od kojih jedan mora biti specijalan, jedan mora biti veliko slovo, jedan mora biti cifra,... Ako je provera identiteta jako bitna onda se koristi i fizi?ka provera (koja nije ba jako popularna od strane korisnika). Moe se proveravati zenica, krv, otisci prstiju,... Zatita Svakom objektu se dodele tri slova koja ozna?avaju prava pristupa. Na primer (objekat,rwx). Domen je skup parova (objekat,prava).Kada se proces po?ne izvravati dodeli mu se domen i tada on moe da pristupa samo objektima iz tog domena i to kako su prioriteti zadani.Oni koji dele domene sa vremena na vreme mogu menjati domen. Domeni se predstavljaju matricama. Na primer: Fajl1 Fajl2 Fajl4 Fajl4 Fajl5 Stampac Fajl6 Ploter D1 D2 D3 Dom1 R RW Enter Dom2 R RW RX W Dom3 W R W Poslednje tri kolone slue za prelazak iz jednog domena u drugi. Kako su ovakve matrice prili?no retko popunjene, obi?no se predstavljaju druga?ije i to po vrstama ili kolonama pri ?emu se pamte samo korisni podaci. Ako se matrica pamti po kolonama onda se naziva Acces Control List (ACL), a ako se pamti po vrstama C-lista. Na primer, po kolonama. Domen je korisnik+grupa: Fajl0 - (Pera,*,rwx) Fajl1 - (Djoka,system,rwx) Fajl2 - (Pera,*,rw)(Mika,osoblje,r)(Aca,nastavnici,rx) Fajl3 - (Pera,*, )(*,studenti,rwx) Fajlu Fajl0 moe da pristupa Pera iz bilo koje grupe i da radi sve. Fajlu Fajl1 moe da pristupa Djoka iz grupe system i da radi sve. Fajlu Fajl2 mogu da pristupaju Pera iz bilo koje grupe (da ?ita i pie), Mika iz grupe osoblje (da ?ita) i Aca iz grupe nastavnici (da ?ita i izvrava). Fajlu Fajl3 Pera iz bilo koje grupe ne moe da pristupi ni na koji na?in dok svi korisnici iz grupe studenti mogu da rade sve. U *UNIX*-u su svakom fajlu pridrueni 9 bitova kojima se odre?uju prioriteti. Prva tri se odnose na vlasnika, druga tri na grupu kojoj vlasnik
PRO version
Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

pridrueni 9 bitova kojima se odre?uju prioriteti. Prva tri se odnose na vlasnika, druga tri na grupu kojoj vlasnik pripada, a poslednja tri na sve ostale korisnike. *r* bit ozna?ava pravo ?itanja, *w* bit ozna?ava pravo pisanja, a *x* bit ozna?ava pravo izvravanja fajla. Na primer, 111101100 zna?i da: - vlasnik moe da ?ita i pie u fajl i da ga izvrava fajl - grupa kojoj vlasnik pripada moe da ?ita i izvrava fajl - svi ostali mogu samo da ?itaju fajl. rwx rwx rwx v l a s n i k g r u p a o s t a l i

PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com