Skripta iz operativnih sistema, Beleške' predlog Kompjuterske aplikacije
BokiGaja
BokiGaja

Skripta iz operativnih sistema, Beleške' predlog Kompjuterske aplikacije

102 str.
77broj poseta
Opis
Skripta iz operativnih sistema, beleške sa predavanja profesora Zorana budimca
20 poeni
poeni preuzimanja potrebni da se preuzme
ovaj dokument
preuzmi dokument
pregled3 str. / 102
ovo je samo pregled
3 prikazano na 102 str.
ovo je samo pregled
3 prikazano na 102 str.
ovo je samo pregled
3 prikazano na 102 str.
ovo je samo pregled
3 prikazano na 102 str.
Operativni Sistemi

Zoltan Geller

Operativni sistemi

Beleške sa predavanja profesora Zorana Budimca

2000/2001

Univerzitet u Novom Sadu Prirodno-matematič ki fakultet

Departman za matematiku i informatiku

2003

1

SADRŽAJ

SADRŽAJ ..................................................................................................................................1

PREDGOVOR...................................................................................................................6

UVOD ...............................................................................................................................................7ŠTA JE OPERATIVNI SISTEM ?............................................................................................................7

ISTORIJA OPERATIVNIH SISTEMA ......................................................8OSNOVNI POJMOVI, KONCEPTI OS-A ............................................10PROCESI ..........................................................................................................................................10STANJA PROCESA .................................................................................................................................11PCB – PROCESS CONTROL BLOCK..................................................................................................12OPERACIJE SA PROCESIMA ..............................................................................................................13ODNOS PROCESA ..................................................................................................................................13PODELA OPERATIVNIH SISTEMA U ODNOSU NA PROCESE...................................................13TEŠKI I LAKI PROCESI........................................................................................................................13KONKURENTNO PROGRAMIRANJE................................................................................................15

FAJL SISTEM ............................................................................................................................15SISTEMSKI POZIVI ...........................................................................................................16KOMANDNI INTERPRETER ....................................................................................16PREKIDI ..........................................................................................................................................16JEZGRO OS-A ...........................................................................................................................18DIZAJN, STRUKTURA OPERATIVNIH SISTEMA..............18MONOLITNI SISTEMI ....................................................................................................18SLOJEVITA REALIZACIJA ......................................................................................19

2

VIRTUELNE MAŠINE ......................................................................................................20KLIJENT-SERVER MODEL ......................................................................................20

SINHRONIZACIJA PROCESA ......................................................22KRITIČ NA OBLAST ......................................................................................................22SOFTVERSKA REALIZACIJA KRITIČ NE OBLASTI .....23DEKKEROV ALGORITAM ..........................................................................................27PETERSENOV ALGORITAM ....................................................................................28HARDVERSKA REALIZACIJA KRITIČ NE OBLASTI ...29REALIZACIJA POMOĆ U SISTEMSKIH POZIVA................31SLEEP & WAKEUP...............................................................................................................32SEMAFORI ...................................................................................................................................33BROJAČ I DOGAĐ AJA .....................................................................................................36MONITORI I USLOVNE PROMENLJIVE ....................................................37EKVIVALENCIJA SISTEMA ZA SINHRONIZACIJU PROCESA ........................................................................................................................................40IMPLEMENTACIJA MONITORA KORIŠĆ ENJEM SEMAFORA.................................................40IMPLEMENTACIJA SEMAFORA POMOĆ U MONITORA ............................................................41

KLASIČ NI PROBLEMI SINHRONIZACIJE ..................................43PROBLEM JEDUĆ IH FILOZOFA .........................................................................43PROBLEM Č ITAOCA I PISACA .............................................................................46PROBLEM USPAVANOG BERBERINA..........................................................47KOMUNIKACIJA TEŠKIH PROCESA..................................................49DISPEČ ER .................................................................................................................................51

3

UPRAVLJANJE MEMORIJOM ...................................................56UPRAVLJANJE MEMORIJOM BEZ SWAPPINGA I PAGINGA .....................................................................................................................................57MONOPROGRAMIRANJE ..........................................................................................57MULTIPROGRAMIRANJE .........................................................................................58FIXNE PARTICIJE ......................................................................................................................58RELOKACIJA I ZAŠTITA .....................................................................................................59

UPRAVLJANJE MEMORIJOM SA SWAPPINGOM ...........61MULTIPROGRAMIRANJE SA PROMENLJIVIM PARTICIJAMA ..........................................................................................................................61STRUKTURE PODATAKA ZA UPRAVLJANJE MEMORIJOM .....................................................................................................................................................................61BITNE MAPE ...........................................................................................................................................62POVEZANE LISTE .................................................................................................................................62SISTEM DRUGOVA ...............................................................................................................................63

ALGORITMI ZA IZBOR PRAZNE PARTICIJE ......................................64VIRTUELNA MEMORIJA .....................................................................................65OVERLAY.......................................................................................................................................65VIRTUELNA MEMORIJA .............................................................................................65PAGING (STRANIČ ENJE) .............................................................................................66IZBOR STRANICA ZA UČ ITAVANJE ............................................................68IZBOR STRANICA ZA IZBACIVANJE ............................................................69DALJI PROBLEMI STRANIČ ENJA ....................................................................72BELADY-JEVA ANOMALIJA.............................................................................................72RADNI SKUP (WORKING SET) ........................................................................................73LOKALNOST I GLOBALNOST .........................................................................................74SEGMENTACIJA ...................................................................................................................74

4

FAJL SISTEM.................................................................................................................76FAJL SISTEM SA KORISNIČ KE TAČ KE GLEDIŠTA.....76FAJLOVI .........................................................................................................................................76IMENOVANJE ........................................................................................................................................76STRUKTURA FAJLOVA .......................................................................................................................77TIPOVI FAJLOVA ..................................................................................................................................77NAČ IN PRISTUPA FAJLOVIMA ........................................................................................................77ATRIBUTI FAJLOVA ............................................................................................................................77OPERACIJE SA FAJLOVIMA .............................................................................................................78

DIREKTORIJUMI .................................................................................................................78OPERACIJE SA DIREKTORIJUMIMA ..............................................................................................79

REALIZACIJA FAJL SISTEMA.....................................................................80NEISKORIŠĆ ENI BLOKOVI ......................................................................................80IMPLEMENTACIJA FAJLOVA (ZAUZETI BLOKOVI) ................82IMPLEMENTACIJA DIREKTORIJUMA .......................................................85LINKOVI .............................................................................................................................................86

POUZDANOST I PERFORMANSE FAJL SISTEMA ...........87POUZDANOST FAJL SISTEMA ..............................................................................87LOŠI BLOKOVI .............................................................................................................................87SIGURNOSNE KOPIJE (BACKUP) .................................................................................87KONZISTENTNOST ..................................................................................................................87PERFORMANSE FAJL SISTEMA .........................................................................88OPTIMIZACIJA DISKA ............................................................................................89ALGORITMI ZA OPTIMIZACIJU POMERANJA GLAVE...........................90

ZAGLAVLJIVANJE ...........................................................................................91RESURSI ............................................................................................................................................91ZAGLAVLJIVANJE ...................................................................................................................91

5

PREVENCIJA .............................................................................................................................92IZBEGAVANJE ........................................................................................................................93BANKAROV ALGORITAM...................................................................................................................93

DETEKCIJA ................................................................................................................................95OPORAVAK ................................................................................................................................95IZGLADNJIVANJE ..............................................................................................................96

SIGURNOST I ZAŠTITA ...........................................................................97SIGURNOST..............................................................................................................................97NEKOLIKO POZNATIH GREŠAKA U RANIJIM OPERATIVNIM SISTEMIMA......................................................................................................................................97ŠTA TREBA DA RADI OSOBA KOJA PROVALJUJE ? ..................................98PRINCIPI ZA OSTVARIVANJE SIGURNOSTI........................................99PROVERA IDENTITETA ................................................................................................99KAKO IZABRATI LOZINKU I DA LI JE ONA DOVOLJNA? ....................99

ZAŠTITA......................................................................................................................................100

6

PREDGOVOR

Skripta koju upravo č itate predstavlja beleške sa predavanja profesora Zorana Budimca iz predmeta Operativni Sistemi, održanih 2000/2001 godine, Prirodno-Matematič ki Fakultet, Novi Sad. Nastala je na osnovu sledeć ih knjiga, skripti i beležaka :

1. Sveska sa beleškama sledeć ih studenata : Zoltan Geller, Igor Mladenović , Agneš Sepeši 2. Andrew S. Tanenbaum : Modern Operating Systems 3. Skripta Dejana Š pegara 4. Benyó Balázs, Fé k Má rk, Kiss István, Kóczy Annamá ria, Kondorosi Ká roly, Mé szá ros Tamás, Román Gyula, Szeberé nyi Imre, Sziray József: Operációs Rendszerek Mé rnöki Megközelíté sben 5. Knapp Gábor, Dr.Adamis Gusztáv: Operációs Rendszerek 6. Zoran Budimac, Mirjana Ivanović , Đ ura Paunić : Programski jezik Modula-2 7. Dragoslav Pešović : Sinhronizacija procesa (skripta) Poglavlje ‘SIGURNOST I ZAŠ TITA’ je u celosti i bez promena preuzet iz skripte Dejana Š pegara.

7

UVOD Softver se može podeliti u dve grupe:

1. sistemski programi – upravljaju rač unarom 2. korisnički (aplikacioni) programi – rešavaju 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 težak posao. Zato je došlo do ideje da se stavi jedan sloj između aplikacionih programa i hardvera. Uloga tog sloja je da obezbedi neki interfejs (ili virtuelnu maš inu) ostalim programima radi lakšeg 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

operativni sistem Sistemski programi

mašinski jezik mikro programi fizič ki uređaji

HARDVER

Na najnižem nivou imamo fizičke uređ aje – fizič ki delovi rač unara. Iznad tog sloja su mikro programi – direktno kontrolišu fizič ke uređaje i obezbeđuju interfejs prema sledeć em nivou. Predstavljaju elementarne korake od kojih se sastoje instrukcije mašinskog jezika. Maš inski jezik je skup instrukcija koje procesor direktno razume (izvršava ih pomoć u svojih mikro programa). Glavna funkcija operativnog sistema je sakrivanje detalje ovih nižih nivoa od ostalih programa i pružanje niza jednostavnijih instrukcija za pristup hardveru. Šta je operativni sistem ?

1. OS kao proš irena (extended) ili virtuelna (virtual) maš ina – arhitektura (niz instrukcija, organizacija memorije, IO, itd.) rač unara na nivou mašinskog jezika je primitivna i nije pogodna za programiranje. Kao primer, možemo 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 smeštena u 9 bajtova. Prilikom

8

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 nešto pisati ili č itati sa diskete. Zadatak OS-a kao proširene ili virtuelne mašine je upravo to da te stvari radi umesto nas i da nam pruža neke funkcije višeg 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 višekorisnič ki sistem: dva korisnika istovremeno žele nešto štampati – OS je dužan da vodi rač una o tome da programi tih korisnika dođu do štampač a kao resursa i da se podaci ne mešaju…

Istorija operativnih sistema Istoriju operativnih sistema ć emo posmatrati preko istorije rač unara:

1. Generacija: (1945-1955) - 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 mašinskom 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 održavanja 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 pišu programe na papiru u programskom jeziku FORTRAN, zatim se ti programi prenose na bušene kartice. Bušene kartice se ostavljaju u sobi sa poslovima (input room). Sistem operator pokupi bušene kartice, u rač unar ubaci kartice sa FORTRAN kompajlerom, pa bušene kartice sa programom koji treba izvršiti. Rač unar odradi posao i razultat se dobija isto na bušenim karticama, koje se prenose u prostoriju sa rezultatima (output room). Ovde se mnogo vremena troši na šetanje između raznih prostorija sa bušenim karticama. Još uvek nema operativnog sistema. Uvodi se sledeć e poboljšanje: - 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 izvršavanje programa (npr. IBM 7094), na glavni rač unar se uč itava poseban program koji je zadužen da sa trake sa poslovima redom uč itava programe i izvršava ih. Taj program je predak današnjih OS-a. Nakon izvršavanja 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 zadužen za prebacivanje rezultata sa

9

magnetne trake na bušene 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 // izvrši 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 izvrši sve stare programe, ali brže. IBM taj problem pokušava rešiti 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 grešaka. Razvija se nova disciplina : softversko inžnjerstvo. 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 rešenje, 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 može izvršavati drugi program. Na taj nač in, ako imamo dovoljan broj programa u memoriji, procesor je u stalnoj upotrebi. SPOOL (Simultaneous Peripheral Operation On Line) – prebacivanje sadržaja bušenih kartica na disk (traku) pomoć u posebnog uređaja – a bez procesora. Znač i procesor izvršava program u memoriji, a paralelno se disk puni novim poslovima (jobs,programi). Kada jedan program završi sa radom, procesor na njegovo mesto može 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 bušenim karticama, pa na rezultate ponekad č eka i nekoliko sati. Ako ima grešku u kodu, izgubi pola dana na č ekanje. Kao rešenje 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 = time-sharing).

MULTICS (MULTIplexed Information and Computing Service) – 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 slušam radio, samo ga uključ im na struju… Isto su hteli napraviti sa rač unarima: u jednom gradu

10

imamo moć an centralni rač unar, a građani imaju terminale, kojima se pristupa tom rač unaru – predak rač unarskih mreža i Interneta. Miniračunari: prvi minirač unar je DEC-ov (Digital Equipment Corporation) PDP-1, do tada najmanji i najjeftinij rač unar. Koštao 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 (Large Scale Integration – veliki stepen integracije) č ipova. Minirač unari su bili dovoljno jeftini, da ih imaju i više 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 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 okruženja. Pored klasič nih operativnih sistema javljaju se i dve nove vrste: Mrežni 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, može se prijaviti na drugi, preuzeti neke fajlove itd. Korisnik zna da nije sam u mreži, svestan je različ itih rač unara sa kojima komunicira preko mreže. Mreže mogu biti lokalne i globalne. Distribuirani OS – korisnici ga vide kao jedno-procesorski sistem, ali u stvari radi sa više procesora. Imamo više rač unara povezanih u mrežu, ali samo jedan OS, koji upravlja svim resursima u mreži. U pravom distribuiranom sistemu korisnik ne treba da vodi rač una o tome, gde su njegovi fajlovi smešteni ili gde se izvršava njegov program, to je posao OS-a. Distribuirani OS se dakle ponaša kao jedinstvena celina. Korisnik nije svestan toga da je u mreži 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 lakši pristup hardveru. To se ostvaruje preko niza proširenih instrukcija, koji se zovu sistemski pozivi (system calls).

Procesi Procesi predstavljaju jedan od najvažnijih koncepata operativnih sistema. Program je niz

instrukcija koji ostvaruje neki algoritam. Proces je program u statusu izvršavanja, zajedno sa svim

11

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 izvršava dobijemo proces. Stanja procesa Procesi se nalaze u jednom od sledeć ih stanja:

- proces se izvršava (RUNNING) - procesor upravo izvršava kod ovog procesa - proces je spreman, ali se ne izvršava (READY) - proces je dobio sve potrebne resurse,

spreman je za izvršavanje, č eka procesora - proces je blokiran, č eka na nešto (npr. č eka štampač a da završi 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 IZVRŠ AVANJA u stanje BLOKIRAN kada su mu za dalje izvršavanje potrebni neki resursi, koji trenutno nisu dostupni. Ovu promenu stanja vrši sam proces: predaje zahtev za neki resurs, pa č eka tog resursa. Npr.: pošalje zahtev skeneru da skenira neku sliku, i č eka rezultat skeniranja

2. proces prelazi iz stanja IZVRŠ AVANJA u stanje SPREMAN ako mu istekne dodeljeno procesorsko vreme (time-sharing) – tada proces prelazi u listu procesa koji č ekaju na procesor

3. proces prelazi iz stanja SPREMAN u stanje IZVRŠ AVANJA kada se procesor oslobodi i može da izvršava kod posmatranog procesa (izabere se iz liste č ekanja po nekom kriterijumu i izvršava 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 završio skeniranje, i sad proces može nastaviti sa radom (spreman je), ali procesor je trenutno zauzet izvršavanjem 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 došlo do suspendovanja u stanju spreman) - proces je suspendovan i blokiran (ako je došlo do suspendovanja u stanju blokiran)

i sledeć i dijagram:

12

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 može da nastavi sa radom (npr. proces pošalje zahtev skeneru da skenira sliku, č eka da skener završi sa radom, pa se blokira, u međuvremenu se suspendira, pa postaje suspendovan i blokiran, kada skener završi 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 zaštita od preoptereć ivanja sistema

- explicitno suspendiranje procesa od strane korisnika (npr. da bi korisnik mogao proveriti neke međurezultate izvršavanja procesa – i nakon toga mogao nastaviti rad bez ponovnog pokretanja celog programa.)

- izbegavanje zaglavljivanja (dead lock) – do zaglavljivanja se dolazi kada dva (ili više) procesa blokiraju jedan drugi u izvršavanju (npr. procesu P1 treba resurs A koji je kod procesa P2, a procesu P2 treba resurs B koji drži P1 – ovi procesi su se zaglavili, jer nijedan od njih ne može nastaviti sa radom – u ovom sluč aju jedan od procesa se suspenduje, pa drugi može da odradi svoj zadatak, pa kada se resursi oslobode i prvi ć e moć i da završi svoj rad).

PCB – Process Control Block Posmatrajmo sledeć u situaciju: imamo multiprogramirano okruženje sa dva procesa. Proces P1 se

izvršava dok ne dođe do blokiranja zbog č ekanja na neki događaj (npr. skeniranje). Tada krenemo sa izvršavanjem 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 možemo nastaviti sa izvršavanjem. Da bismo znali, gde treba nastaviti, potrebno je pamtiti neke informacije o procesu. Upravo tome služi PCB tj. Process Control Block. Svakom procesu se dodeljuje jedinstveni PCB koji sadrži informacije koje su potrebne za nastavak izvršavanja 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

13

- sadržaj registara procesora, itd. PCB-ovi svih procesa u memoriji smeštaju se u neki niz ili povezanu listu. Operacije sa procesima Operativni sistem treba da obezbedi sledeć e operacije sa procesima:

- kreiranje novog procesa (kreiranjem PCB-a) - uništavanje procesa (brisanjem PCB-a iz liste) - menjanje stanja procesa - menjanje prioriteta procesa - izbor procesa za izvršavanje (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 možemo imati dve vrste veze:

1. proces-roditelj kreira novog procesa i č eka dok proces-dete završi 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 podržavati:

- monotasking (jednoprocesni, monoprogramiranje) : u memoriji istovremeno imamo samo jedan program, tj. “ istovremeno” se izvršava samo jedan proces (npr. DOS)

- multitasking (višeprocesni, multiprogramiranje) : u memoriji istovremeno imamo i više programa, tj. “ istovremeno” se izvršavaju i više 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, višeprocesni )

- multiuser (višekorisnič ki): npr. UNIX (višekorisnič ki, višeprocesni) Teški i laki procesi Procesi se dele na teške i na lake procese. Da bismo videli razliku između ove dve vrste procesa,

posmatrajmo najpre kako procesi koriste memoriju. Za izvršavanje nekog procesa, potrebno je 4 dela (vrste) memorije:

- heap - stack- memorija za globalne promenljive- memorija za kod procesa

14

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 izvršavanja programa. Npr. u Moduli-2 zauzimanje memorije (kreiranje dinamič ke promenljive) se vrši 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 sadrže poč etnu adresu zauzete memorije. Na jednu istu dinamič ku promenljivu mogu pokazivati i više pokazivač a. Ako smo zauzeli neku količ inu memorije i nemamo više ni jednog pokazivač a na tu memoriju, taj deo HEAP-a je izgubljen (nemamo više pristupa, ne znamo adresu zauzete memorije, ne možemo je osloboditi) – to se zove smeće u memoriji (garbage) i može dovesti do ozbiljnih grešaka u radu programa. Ovaj problem se kod nekih OS-a rešava 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 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 može se menjati u toku izvršavanja programa. Stek se puni prema gore a heap se puni prema dole. Npr. u Turbo Pascalu postoji direktiva (kompajler vrši 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 teške i lake procese vrši se na osnovu toga, kako koriste gore navedene delove memorije :

- svaki teški 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 može deliti jer ne možemo unapred znati koji proces koristi stek: proces A stavi nešto na stek i nastavlja rad, dolazi proces B i on isto stavi nešto na stek, A je završio 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 teške procese, kompajler deli vreme između više procesa. Postoje operativni sistemi, koji podržavaju:

15

1. samo teške procese (UNIX) 2. samo lake procese (Oberon) 3. podržavaju i teške i lake procese (Windows)

Problem komunikacije kod teških 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 izvršava u tač no određenom redosledu od strane jednog procesora. Znač i sekvencijalni program predstavlja tač no jedan proces koji se izvršava od poč etka do kraja na jednom procesoru. KONKURENTNO programiranje uzima u obzir moguć nost postojanja i više procesora, pa se konkurentni program sastoji od više nezavisnih procesa ili zadataka (task), koji se mogu istovremeno izvršavati. Stil konkurentnog programiranja koristimo kada se zadatak može razbiti na više međusobno relativno nezavisnih delova – procesa, koji se mogu istovremeno izvršavati. Konkurentni programi se mogu izvrsavati i na rač unaru sa jednim procesorom i na rač unaru sa više procesora. Konkurentno programiranje se koristi kod programiranja operativnih sistema, simulacija itd. Npr.: želimo napisati program za simulaciju igre jednog fudbalskog tima. Sekvencijalno: pišemo program koji vodi rač una o svakom igrač u tima. Konkurentno: za svaki igrač pišemo jedinstvenu proceduru – te procedure se izvršavaju istovremeno.

Fajl sistem (file system) Videli smo da je operativni sistem dužan da obezbedi lakši pristup hardveru programima na višim

nivoima. Na isti nač in, treba da obezbedi i apstraktniji pogled na fajlove, na fajl sistem. Znač i, programi na višim nivoima ne treba da vode rač una o tome, kako su u stvari fajlovi smešteni 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 podržavaju 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.

16

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, izvrši tražene radnje, rezultat stavi u određene memorijske lokacije ili u registre i vrać a kontrolu programu.

Sistemske pozive č esto podržava i hardver, tj. procesor, na taj nač in što razlikuje dva režima rada: korisnički režim (user mode) i sistemski režim (kernel mode, system mode, supervisor mode) rada. Korisnič ki programi mogu raditi isključ ivo u korisnič kom režimu rada procesora, sistemski režim rada je predviđen za OS. Ako korisnič ki program pokuša izvršiti neku operaciju koja je dozvoljena samo u sistemskom režimu rada, kontrola se predaje OS-u. Prilikom sistemskih poziva procesor prelazi iz korisnič kog režima rada u sistemski, OS obradi poziv pa se procesor vrać a u korisnič ki režim 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 zadužen za sistemske pozive. Komandni interpreter interpretira komande korisnika i izvršava 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 izvršava programe i imamo IO uređaje (disk,štampač ,skener,itd.). Svaki IO uređaj ima svoj kontroler koji sadrži neki slabiji procesor koji je jedino zadužen za upravljanje tim uređajem i za komunikaciju sa glavnim procesorom. Imamo dve strategije za upravljanje uređajima:

17

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 završi svoj posao ili dođe do neke greške, uređaj o tome obaveštava 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 grešku, takvu da se rad ne može nastaviti).

Primer: Mama kuva ruč ak a dete se igra. Ako je polling, mama svakih 10 sekundi proveri šta dete radi i ako nešto 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 može biti npr. vrlo važna poruka o grešci)

2. procesor prekida svoj rad u određenim vremenskim intervalima i kada nema nikakvih poruka

Obrada prekida se izvršava po sledeć em algoritmu:

- procesor radi svoj zadatak - stiže 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) traži se adresa procedure za obradu prekida - izvršava se procedura za obradu prekida - omoguć avaju se dalji prekidi - nastavlja se rad na prekinutom procesu

Vrste prekida:

1. Hardverski prekidi – generišu se od strane hardvera, mogu biti: 1. prekidi koji se mogu maskirati (maskable interrupt) – ove prekide

procesor može 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 može biti odložena – to su neke ozbiljne greške hardvera (npr. greška memorije)

2. Softverski prekidi – prekidi generisani od strane programa 3. Sistemski pozivi (jesu softverski prekidi) 4. Izuzeci (exceptions) – generišu se od strane procesora, npr. ako se pokuša deliti sa nulom

18

Jezgro OS-a (kernel,nucleus,core) Jezgro je deo operativnog sistema, koji obavlja najbitnije operacije:

- upravljanje prekidima - kreiranje i uništavanje procesa - odabiranje procesa iz liste spremnih procesa (context switch) - suspenzija i nastavljanje procesa - sinhronizacija procesa - komunikacija između procesa - manipulacije sa PCB-om - podrška za ulaz/izlaz (IO) - upravljanje memorijom - upravljanje fajl sistemom, itd.

Dizajn, struktura operativnih sistema Monolitni sistemi (monolithic systems) U prošlosti 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 zašto. OS je realizovan kao skup procedura, od kojih svaka može pozvati svaku ako je to potrebno. Korisnič ki programi servise OS-a koriste na sledeć i nač in: parametri sistemskog poziva se smeštaju u određena mesta, kao što su registri procesora ili stek, pa sledi specijalna operacija – poziv jezgra OS-a (kernel call). Ova operacija prebacuje procesor iz korisničkog režima radau sistemski režim rada i kontrolu predaje OS-u. U korisnič kom režimu rada nisu dozvoljene neke komande procesora, a u sistemskom režimu 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

19

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 režimu 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 više 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).

1

2 2 2 2

3 3 3 3 3

korisnič ki programi, korisnič ki režim

20

Kod MULTICS sistema umesto slojeva, koriste se koncetrič ni prstenovi. Kada neka procedura iz već eg (spoljašnijeg) prstena želi pozvati neki servis nekog manjeg (unutrašnijeg) prstena to ć e uraditi pomoć u poziva koji je slič an sistemkim pozivima.

Virtuelne maš ine (virtual machines) Struktura virtuelnih mašina je izrađena od strane firme IBM na sledeć i nač in: imamo na najnižem

nivou hardver, iznad hardvera imamo sistem koji se zove monitor virtuelnih maš ina (virtual machine monitor) i koji obezbeđuje niz virtuelnih maš ina - to nisu proširene mašine kao operativni sistemi koji pružaju niz proširenih i jednostavnijih operacija za pristup hardveru, već su tačne kopije hardvera ispod monitora virtuelnih mašina. Zatim se na te virtuelne mašine 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 mašinama hvata monitor virtuelnih mašina i realizuje ih u skladu sa hardverom ispod sebe. Kao primer možemo navesti IBM-ov VM/370.

aplikacija 1 aplikacija 2 aplikacija 3 operativni sistem 1 operativni sistem 2 operativni sistem 3

monitor virtuelnih mašina 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 zaduženi za obradu klijentskih procesa. I klijentni i serverski procesi rade u korisnič kom režimu rada. Kernel OS-a je zadužen za komunikaciju između klijentskih i serverskih procesa. Server procesi su delovi OS-a i grupisani su prema tome koje funkcije obavljaju: proces serveri (zaduženi za procese), fajl serveri (zaduženi za fajl sistem), serveri memorije itd. Svi serveri rade u korisnič kom režimu, pa nemaju direktan pristup hardveru.

Prednosti ovog modela: 1. OS je razbijen na manje delove (servere) koji se mogu održavati nezavisno 2. ako dođe do greške u nekom serveru, ne mora pasti i ceo sistem 3. pogodan je za pravljenje distribuiranog sistema: različ iti serveri mogu se izvršavati

na različ itim rač unarima (koji su naravno povezani), kada neki klijent proces pošalje 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 teško mogu realizovati u korisnič kom režimu rada. Imamo dve moguć nosti da rešimo ovaj problem:

1. imamo neke kritične server procese koji se izvršavaju u sistemskom režimu rada i imaju direktan pristup harveru, ali sa ostalim procesima komuniciraju kao što se to radi u ovom modelu

21

2. neke kritič ne mehanizme ugrađujemo u sam kernel, a pravimo server u korisnič kom režimu koji sadrži samo interfejs tih operacija

klijentni proces 1

klijentni proces 2

server procesa fajl server .........

server memorije

KERNEL

22

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 izvršavanju procesa A. Sada, dok proces A č eka, neka se pritisne ENTER na drugom terminalu i neka proces B izvrši 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 grešku možemo izbeć i tako što ć emo zabraniti procesu B (A) da uđe u deo gde pristupa brojač u ako je drugi proces već ušao u taj deo. Znač i, proces B ć e da sač eka da proces A završi 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 važi: ako je neki proces

unutar svoje kritič ne oblasti, ni jedan 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 može se realizovati : - softverski - hardverski - pomoć u operativnog sistema (sistemski pozivi)

23

Softverska realizacija kritične oblasti

Pretpostavke i osobine softverskog rešenja :

0. Unutar kritič ne oblasti istovremeno može se nalaziti najviše 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 može 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 ; // teški 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.

24

Sadržaj pomoć ne promenljive processNumber je index onog procesa koji se nalazi u kritič noj

oblasti. PARBEGIN i PAREND su pseudo-naredbe. Označ avaju da procedure koje se pozivaju između njih treba izvršavati paralelno.

Analiza: ovaj algoritam radi dobro: istovremeno može biti najviše 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,... Objašnjenje: pošto 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:=2 i 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:=1 i neka sada ovaj proces zaglavi u delu OstaleStvari2 dovoljno dugo vremena, da Process1 uđe i izađe iz k.o. Sada je processNumber=2 (to je postavio Process1), Process2 radi nešto što dugo traje u delu OstaleStvari2 – što znač i da nije unutar kritič ne oblasti, pa bi Process1 mogao slobodno uć i, ali ne može jer je processNumber=2, što znač i da mora sač ekati da Process2 završi 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 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.

nema postavljenih komentara
ovo je samo pregled
3 prikazano na 102 str.