Operativni sistemi

1 Uvod
Donedavno su se operativni sistemi vezivali isklju£ivo za personalne ra£u-
nare. Kada vam neko pomene operativni sistem, prva asocijacija bi, uglavnom
bio Microsoft Windows (10/7/Vista/XP/98..), moºda neka distribucija Linux
operativnog sistema ili eventualno macOS-X. Ali svakako neki personalni ra-
£unar na kojem moºete da u gra£kom okruºenju pokre¢ete programe koji se
izvr²avaju (naizgled) istovremeno.
Sa druge strane, sve rasprostranjeniji su postajali embeded sistemi. Prvobitni
embeded sistemi su bili prili£no jednostavni: naj£e²¢e su sadrºali neki mikrokon-
troler skromnih performansi. Oni nisu imali previ²e RAM memorije, uglavnom
su imali skroman CPU, eventualno sa mogu¢no²¢u proto£ne obrade instrukcija-
dok se jedna izvr²ava, druga se dekoduje, a tre¢a prihvata iz memorije. Imali
su relativno mnogo periferijskih jedinica koje su bile zna£ajne za interakciju sa
spolja²njim svetom - A/D konvertori, tajmeri/broja£i, komunikacioni interfejsi
(UART, SPI, I2C), PWM izlazi, itd.
Tipi£an program koji bi se izvr²avao na jednom takvom embeded sistemu
obavezno je sadrºao jednu beskona£nu petlju, koja je obezbeživala da program-
ski broja£ nikada ne dosegne zabranjenu zonu tj. zonu u kojoj se ne nalazi
nikakav program, odnosno zonu u kojoj se nalaze ilegalne instrukcije. Unutar
petlje, sekvencijalno su se izvr²avale operacije koje su uklju£ivale interakciju sa
periferijskim jedinicama i obradu podataka. Na primer, pseudo kod programa
koji detektuje da li je pritisnut taster (koji ubrzava/usporava motor), a onda ge-
neri²e PWM izlaz za kontrolu motora kori²¢enjem PID regulatora i eventualno
prikazuje trenutnu brzinu na displeju:

while ( true )
{
ocitaj_trenutnu_brzinu_obrtanja ()
if pritisnut_taster ()
{
aºuriraj_parametre_regulatora ()
}
izra£unaj_novi_izlaz_za_pwm ()
podesi_kontroler_za_pwm ()
prikaºi_brzinu_na_displeju ()
}

U pozadini, kompajler bi preveo ovaj kod u niz instrukcija iz instrukcijskog

seta datog mikrokontrolera, a prilikom programiranja mikrokontrolera, ovaj niz
instrukcija bi se upisao na unapred poznatu lokaciju u memoriji, naj£e²¢e na
adresu 0, odakle bi krenulo izvr²avanje programa jer je to podrazumevana po-
£etna vrednost programskog broja£a. Podaci i promenljive bi se nalazile u RAM
memoriji (koje je vrlo £esto bilo ne vi²e od nekoliko stotina bajta), gde bi se
uglavnom nalazio i stek koji se koristi prilikom poziva procedura ili izvr²avanja
rutina za obradu prekida.
Ovakvo sekvencijalno izvr²avanje instrukcija je uglavnom prihvatljivo, sve
dok se ne pojavi potreba za paralelnim izvr²avanjem odreženih delova programa.
Na primer, osim kontrole motora, ukoliko bi trebalo komunicirati sa drugim
mikrokontrolerom ili personalnim ra£unarom putem serijske komunikacije:
 2

while ( true )
{
ocitaj_trenutnu_brzinu_obrtanja ()
if pritisnut_taster ()
{
aºuriraj_parametre_regulatora ()
}
izra£unaj_novi_izlaz_za_pwm ()
podesi_kontroler_za_pwm ()
prikaºi_brzinu_na_displeju ()
if ( pristigla_poruka ())
{
dekoduj_pristiglu_poruku ()
spremi_odgovor ()
odgovori_na_zahtev ()
}
}

Mežutim, ovde se ve¢ pojavljuju potencijalni problemi: ²ta ako se blok za

komunikaciju dugo izvr²ava, pa usled toga regulacija brzine zakasni? Takože,
²ta se de²ava ako se tokom ra£unanja izlaza za PWM modul, propusti poruka
pristigla putem serijske komunikacije? ’ta ako osim ove dve aktivnosti, treba
dodatno vr²iti sloºene prora£une koji zahtevaju dosta vremena. Prekidi re²avaju
problem brze reakcije na neki dogažaj, ali usloºnjavaju hardver, programski kod
i organizaciju prioriteta dogažaja na koje treba reagovati. O£igledno bi nam
bilo zgodno da vi²e poslova moºemo da obavljamo istovremeno, ali kako da to
uradimo?
Vremenom, embeded sistemi su postajali sve kompleksniji i kompleksniji.
Umesto CPU sa jednim jezgrom, pojavili su se vi²e-jezgarni procesori koji sa-
drºe skrivenu ( cache ) memoriju i koji mogu da rade na znatno vi²im u£estano-
stima. Koli£ina dostupne RAM memorije je postajala sve ve¢a i ve¢a, hardver
sve sloºeniji i sloºeniji i vremenom smo do²li u situaciju da se na embeded si-
stemima mogu izvr²avati znatno kompleksniji programi. Kao rezultat, dana²nji
embeded sistemi su sposobni da pokrenu kompletan operativni sistem, gotovo
identi£an onome koji se pre mogao pokrenuti samo na personalnim ra£unari-
ma. Time se spektar aplikacija koje se mogu izvr²avati na takvim platformama
vrtoglavo pro²irio. Odjednom imamo mogu¢nost istovremenog izvr²avanja vi-
²e programa, mogu¢nost komunikacije sloºenijim komunikacionim kanalima kao
²to je Ethernet/Internet, moºemo mnogo jednostavnije da skladi²timo podatke
kori²¢enjem fajl sistema, interfejs ka periferijskim jedinicama je znatno jedno-
stavniji, ne moramo da vodimo ra£una o registrima periferijske jedinice jer to
za nas radi operativni sistem koji pojednostavljuje situaciju toliko da slanje po-
datka ka urežaju svede na upis u takozvanu datoteku urežaja (o ovome ¢emo
mnogo detaljnije pri£ati u nastavku), a £itanje podatka sa urežaja na £itanje
datoteke urežaja, potpuno identi£no kao ²to bismo £itali/upisivali tekstualnu
datoteku. Operativni sistem kao softver koje upravlja resursima ra£unara, omo-
gu¢io nam je da i u embeded svetu konstrui²emo pouzdan, prenosiv, ekasan i
siguran ra£unarski sistem.
Stoga, u nastavku ovoga predmeta izu£ava¢emo brojne tehnike i koncepte
koji se koriste u operativnim sistemima, kako bi vam pribliºili svu mo¢ i snagu
koju sa sobom oni nose, pod uslovom da ih pravilno koristite.
Koncepti operativnih sistema su mežu najkompleksnijim temama u okviru
 3

ra£unarskih nauka. Savremeni operativni sistem op²te namene sastoji se od pre-

ko 50 miliona linija koda. Operativni sistemi se, sa druge strane, kontinualno
razvijaju, a novi nastaju. Ukoliko se ovaj tekst £ita na £ita£u e-knjiga, tabletu
ili pametnom telefonu, operativni sistem je taj koji upravlja urežajem. Po²to
ne¢emo mo¢i da pokrijemo sve, na² fokus ¢e biti na su²tinskim konceptima ope-
rativnih sistema.
Sa druge strane dobra vest je da su koncepti operativnih sistema takože
mežu dostupnijim temama u okviru ra£unarskih nauka. Ve¢ina problema koje
svakodnevno sre¢emo ima svoj analog u teoriji operativnih sistemima, ²to ¢e nam
omogu¢iti da moºemo objasniti kako operativni sistemi rade svoj posao u okviru
jednog udºbenika. Sve ²to se od £itatelja zahteva, to je osnovno razumevanje
rada ra£unara i mogu¢nost £itanja pseudo-koda.
Razumevanje na£ina na koji rade operativni sistemi je denitivno od su²tin-
skog zna£aja za svakog studenta zainteresovanog za rad sa savremenim ra£u-
narskim sistemima. Naravno, svako ko koristi ra£unar ili pametni telefon (ili
£ak moderan toster) koristi operativni sistem, pa je razumevanje funkcionisa-
nja operativnog sistema korisno svima. Na² cilj u ovom predmetu je da idemo
mnogo dublje od toga, da objasnimo tehnologije koje se koriste u operativnim
sistemima, tehnologije na koje se mnogi od nas oslanjaju svakodnevno, a da
toga nisu ni svesni najverovatnije.
Softverski inºenjeri £esto se susre¢u sa izazovima sli£nim onima koji se re-
²avaju u okviru operativnih sistema, prilikom izgradnji drugih sloºenih sistema
i koriste £esto iste tehnologije i dizajn. Bilo da je va² cilj rad na kernelu ope-
rativnog sistema ili na razvoju nove generacije softvera za Cloud ra£unanje,
bezbednim i pouzdanim veb pretraºiva£ima, konzolama za igranje, gra£kim
korisni£kim interfejsima, medijskim plejerima ili bazama podataka, koncepti i
apstrakcije potrebne za pouzdan, prenosiv, ekasan i siguran softver su uglav-
nom isti. Moºda i najbolji na£in da se nau£e ovi koncepti je da se prou£i kako se
oni koriste u operativnim sistemima, ali ¢e se njihova primena svakako veoma
brzo prepoznati u mnogo ²irem spektru ra£unarskih sistema.
Za po£etak, razmatra¢emo veb server. Njegovo pona²anje je zapanjuju¢e jed-
nostavno: on dobija paket koji sadrºi ime veb stranice putem mreºe. Veb server
dekoduje paket, preuzima datoteku sa diska i vra¢a sadrºaj preko mreºe korisni-
ku. Deo posla operativnog sistema je da olak²ava pisanje aplikacija poput veb
servera. Ali, ako zagrebemo malo dublje i paºljivije analiziramo ovaj jednostavan
koncept, brzo se postavlja mnogo novih pitanja:

ˆ Mnogi veb zahtevi uklju£uju kako same podatke tako i zahtevno i kom-
pleksno ra£unanje. Na primer, Google stranica predstavlja jednostavan
tekstualni okvir, ali svaki upit za pretragu une²en u taj okvir, sadrºi pre-
traºivanje baza podataka koje se prenosi bukvalno na hiljade ma²ina. Da bi
njihov softver bio upravljiv, veb serveri £esto pozivaju pomo¢ne aplikacije,
npr. za kontrolu same funkcije pretraºivanja. Ove pomo¢ne aplikacije mo-
raju da komuniciraju sa glavnim veb serverom da bi £itav ovaj postupak
bio uspe²no obavljen. Kako operativni sistem omogu¢ava vi²e aplikacija
da komuniciraju jedne sa drugima?
 4

ˆ ’ta se de²ava ako dva korisnika (ili milion njih) poku²aju da zatraºe veb
stranicu sa servera istovremeno? Jednostavan pristup bi mogao biti obraži-
vanje svakog zahteva po redu pristizanja. Mežutim, ako svaki pojedina£ni
zahtev traje duºe vremena, ovaj pristup bi zna£io da bi svi ostali morali
da sa£ekaju da se on zavr²i. Brºe, ali sloºenije re²enje je multitasking obra-
da: istovremeno obraživanje vi²e zahteva u istom vremenskom intervalu.
Multitasking je posebno vaºan na savremenim ra£unarima sa vi²e jezgara,
jer pruºa na£in da se vi²e procesora koristi istovremeno. Kako operativni
sistem omogu¢ava aplikacijama da rade vi²e stvari istovremeno?

ˆ Radi boljih performansi, veb server ¢e £esto kreirati kopiju, koja se naziva
ke², nedavno zatraºenih stranica, kako bi slede¢i korisnik koji zahteva istu
stranicu mogao dobiti rezultat iz ke²a, umesto zapo£injanja zahteva od po-
£etka. Za ovo je potrebno da aplikacija sinhronizuje pristup ke² podacima
od strane hiljade veb zahteva koji istovremeno pristiºu. Kako operativni
sistem podrºava sinhronizaciju aplikacija sa deljenim podacima?

ˆ Da biste prilagodili i obogatili korisni£ko iskustvo, uobi£ajeno je za veb

servere da koriste klijentske skript programe, umetnute u sam sadrºaj veb
stranice. Ali to zna£i da klik na link moºe prouzrokovati pokretanje tužeg
koda na va²em ra£unaru. Kako se klijentski operativni sistem ²titi od toga
da ga kompjuterski virus, eventualno umetnut u skript kod, na bilo koji
na£in ugrozi?

ˆ Pretpostavimo da administrator veb stranice koristi tekstualni editor za

aºuriranje sadrºaja veb stranice. Veb server tada mora biti u mogu¢nosti
da pro£ita datoteku koju je administrator kreirao - kako operativni sistem
£uva podatke na disku tako da veb server moºe da ih pronaže i pro£ita?

ˆ ’ta se dogaža kada veb pretraºiva£ i veb server rade razli£itim brzinama?
Ako server poku²ava da po²alje veb stranicu klijentu brºe nego ²to klijent
moºe da prikaºe stranicu, gde se nalazi sadrºaj datoteke u mežuvremenu?
Moºe li operativni sistem potpuno razdvojiti klijenta i server tako da svaki
moºe raditi svojom brzinom, a da se pritom drugi ne usporava?

ˆ Kako saobra¢aj ka veb serveru raste, administrator ¢e verovatno ºeleti da

preže na bolji hardver, sa vi²e memorije, vi²e procesora, brºim mreºnim
urežajima i brºim diskovima. Da biste iskoristili prednost ovog novog har-
dvera, da li je potrebno da veb server bude dizajniran ispo£etka ili moºe
biti napisan na hardverski-nezavisan na£in? ’ta je sa operativnim siste-
mom - da li je njega potrebno razvijati od nule za svaki novi hardver koji
se pojavi?

Mogli bismo u nedogled da nastavimo sa navoženjem ovakvih i sli£nih problema,

ali ideja je jasna: zadatak operativnog sistema jeste da ih razre²i. U nastavku ¢e-
mo dati deniciju operativnog sistema i navesti izazove koji postoje u njihovom
dizajniranju.
 5

Slika 1: Komponente u ra£unarskom sistemu

Operativni sistem je slo j softvera ko ji upravlja resursima ra£unara

za svoje korisnike i njihove aplikacije. Operativni sistemi rade u ²irokom
rasponu ra£unarskih sistema. Ponekad su krajnjem korisniku nevidljivi i kon-
troli²u embeded urežaje poput tostera, konzola za igre i mnogih ra£unarskih
sistema u okviru modernih automobila ili aviona. Operativni sistemi su tako-
že esencijalna komponenta sistema op²te namene kao ²to su pametni telefoni,
desktop ra£unari i serveri.
Kao ²to je prikazano na slici 1 ra£unarski sistem se moºe grubo podeliti na
£etiri komponente: hardver, operativni sistem, aplikativni programi i korisnici.
Hardver, koji £ine centralna procesna jedinica (CPU), memorija i urežaji za
ulaz/izlaz (U/I) - predstavljaju osnovne ra£unarske resurse u uokviru sistema.
Aplikativni programi - kao ²to su editori teksta, kompajleri, i veb pretraºiva£i -
deni²u na£ine na koje se ovi resursi koriste za re²avanje ra£unarskih problema
korisnika. Operativni sistem kontroli²e hardver i koordinira njegovu upotrebu
putem razli£itih aplikativnih programa za brojne korisnike.
Sa ra£unarske ta£ke gledi²ta, operativni sistem je program koji je najintim-
nije povezan sa hardverom. U tom kontekstu moºemo videti operativni sistem
kao alokator resursa. Ra£unarski sistem ima mnogo resursa koji ¢e biti kori-
²¢eni za re²avanje problema: centralnu procesorsku jedinicu, memoriju, prostor
za skladi²tenje datoteka, U/I urežaje i tako dalje. Operativni sistem pona²a se
kao menadºer ovih resursa. Suo£avaju¢i se sa brojnim i eventualno koniktnim
zahtevima za resursima, operativni sistem mora odlu£iti kako ih dodeliti odre-
ženim programima i korisnicima kako bi ra£unarski sistem funkcionisao ekasno
i po²teno.
Sa druge strane, kod operativnog sistema nagla²ena je potreba za kontrolom
razli£itih U/I urežaja i korisni£kih programa. Operativni sistem je, u skladu
 6

sa tim, kontrolni program. Kontrolni program kontroli²e izvr²avanje korisni£kih

programa radi spre£avanja gre²aka i nepravilne upotrebe ra£unara. Posebno se
to odnosi na rad i kontrolu ulazno/izlaznih urežaja.
Operativni sistemi op²te namene i njihove tehnologije generalizacija su teh-
nologija potrebnih za embeded sisteme. Mežutim, tehnologije op²te namene sve
se £e²ce razvijaju ka sferi embedded aplikacija. Na primer, rani mobilni te-
lefoni imali su jednostavne operativne sisteme za upravljanje hardverom i za
pokretanje nekoliko primitivnih aplikacija. Dana²nji pametni telefoni, sposob-
ni za pokretanje eksternih aplikacija ( third party applications ), deo su najbrºe
rastu¢eg razvoja u svetu mobilne telefonije. Ovi novi urežaji zahtevaju mnogo
sloºenije operativne sisteme, sa sosticiranim upravljanjem resursima, dodatnim
zadacima i za²titom od otkaza.
U slu£aju sistema op²te namene, korisnici komuniciraju sa aplikacijama, apli-
kacije se izvr²avaju u okruºenju koje obezbežuje operativni sistem, a operativni
sistem posreduje i kontroli²e pristup osnovnom hardveru. ’ta nam treba od ope-
rativnog sistema da bismo mogli pokrenuti grupu programa? Operativni sistemi
imaju tri uloge:

1. Operativni sistemi igraju ulogu sudije - oni upravljaju zajedni£kim re-

sursima izmežu razli£itih aplikacija koje rade na istoj zi£koj ma²ini. Na
primer, operativni sistem moºe zaustaviti jedan program i pokrenuti dru-
gi. Operativni sistemi razdvajaju razli£ite aplikacije jednu od druge, tako
da, ako postoji gre²ka u jednoj aplikaciji, ona ne o²teti druge aplikacije
koje se pokre¢u na istoj ma²ini. Dodatno, operativni sistem mora za²ti-
titi sebe i druge aplikacije od zlonamernih ra£unarskih virusa. Na kraju,
po²to aplikacije dele zi£ke resurse, operativni sistem mora da odlu£i koje
aplikacije dobijaju koji resurs.

2. Operativni sistemi igraju ulogu iluzioniste - oni pruºaju apstrakciju zi£-

kog hardvera kako bi pojednostavili dizajn aplikacija. Da biste napisali
"Hello world" program, ne trebate (i ne ºelite!) da razmi²ljate o tome ko-
liko zi£ke memorije ima sistem ili koliko drugih programa moºe da deli
resurse va²eg ra£unara. Umesto toga, operativni sistemi pruºaju iluziju
beskona£ne memorije, kao apstrakciju ograni£ene koli£ine zi£ke memori-
je. Isto tako, operativni sistemi pruºaju iluziju da svaki program ima na
raspolaganju procesor ra£unara alociran u potpunosti za njega. O£igledno
je da je stvarnost sasvim druga£ija! Ove iluzije omogu¢avaju da se aplika-
cije pi²u nezavisno od koli£ine zi£ke memorije u sistemu ili zi£kog broja
procesora. Po²to su aplikacije napisane na vi²em nivou apstrakcije, opera-
tivni sistem ima slobodu da menja resurse dodeljene svakoj pojedina£noj
aplikaciji, bilo u trenutku pokretanja ili zaustavljanja aplikacije.

3. Operativni sistemi se pona²aju kao lepak - poseduju¢i skup zajedni£kih

servisa koji se dele izmežu aplikacija. Korist postojanja zajedni£kih servi-
sa ogleda se u olak²avanju komunikacije i deljenja podataka izmežu apli-
kacija. Tako, na primer, cut i paste deluje jednoliko u celom sistemu, a
 7

datoteku koju kreira jedna aplikacija moºe da £ita bilo koja druga. Dodat-
no, operativni sistemi obezbežuju standardni korisni£ki interfejs kako bi
aplikacijama pomogli da imaju uobi£ajeni izgled (" look and feel "). Moºda
najvaºnije od svega jeste da operativni sistemi pruºaju sloj koji razdva-
ja aplikacije od hardverskih ulazno-izlaznih urežaja, tako da se aplikacije
mogu razvijati potpuno nezavisno od toga koja tastatura, mi² ili hard disk
se koristi u sistemu.

Prokomentarisa¢emo svaku od tih uloga detaljnije u nastavku.

2 Uloge operativnog sistema

2.1 Deljenje resursa: Operativni sistem kao sudija
Deljenje resursa je centralni problem kod ve¢ine ra£unara: u datom trenutku
na jednom ra£unaru moºe biti pokrenut veb pretraºiva£, ureživa£ teksta, klijent
program za elektronsku po²tu, i program za pu²tanje muzike. Operativni sistem
mora podrºavati sve ove aktivnosti odvojeno, ali dozvoliti svakoj puni kapacitet
ma²ine ukoliko ostali ne rade. U najmanju ruku, kada se jedan program prestane
izvr²avati, operativni sistem bi trebao dozvoliti pokretanje drugog. Jo² bolje,
operativni sistem bi trebao omogu¢iti istovremeno pokretanje vi²e aplikacija, kao
kad £itamo e-po²tu dok preuzimamo sa interneta aºuriranja sistemskog softvera.
ƒak i pojedina£ne aplikacije mogu biti dizajnirane da rade vi²e stvari odjednom.
Na primer, veb server ¢e vi²e odgovarati svojim korisnicima ako ima mogu¢nost
da podnese vi²e zahteva istovremeno, a ne da £ekate da se svaki zavr²i pre nego
²to po£ne slede¢i. Isto vaºi i za veb pretraºiva£ koji je korisniji i funkcionalniji
ako moºe po£eti iscrtavati stranice dok se ostatak stranice jo² uvek prenosi
i u£itava. Na sistemima sa vi²e procesora, ra£unanje u okviru aplikacija koje
podrazumevaju paralelno procesiranje se moºe podeliti na odvojene jedinice
koje se mogu pokrenuti nezavisno, u cilju brºeg izvr²enja. Sam operativni sistem
je primer softvera u kome se moºe raditi vi²e stvari odjednom. Kao ²to ¢emo
kasnije videti, sam operativni sistem je korisnik svojih apstrakcija.
Ipak, iako je ideja jednostavna, samo deljenje resursa vodi ka vi²estrukim
izazovima kada dože do implementacije.

1. Alokacija resursa: Operativni sistem mora da izvr²ava sve istovremene ak-

tivnosti odvojeno, rasporežuju¢i resurse po potrebi. Ra£unar obi£no ima
samo nekoliko procesora i ograni£enu koli£inu memorije, kapacitet mreºe i
prostor na disku. Kada treba obaviti vi²e zadataka u isto vreme, kako ope-
rativni sistem treba da odabere koliko resursa da dodeli svakom? Naizgled
trivijalne razlike u na£inu na koji se dodeljuju resursi mogu imati veliki uti-
caj na performanse koje percipiraju korisnici. Kao ²to ¢emo videti kasnije,
ako operativni sistem dodeli programu premalo operativne memorije, to
ne¢e samo usporiti taj odreženi program, ve¢ moºe drasti£no usporiti rad
£itave ma²ine. Kao dodatni primer, ²ta se de²ava ako korisni£ki program
ima beskona£nu petlju:
 8

while ( true ){
;
}

Ako bi se programi izvr²avali direktno na hardveru, ovaj fragment koda bi

blokirao ra£unar i on £ak ne bi mogao ni da reaguje na unos od strane kori-
snika. Uz multipleksiranje resursa koje pruºa operativni sistem, speci£na
aplikacija se moºe blokirati, ali ostali programi ¢e se i dalje nesmetano
izvr²avati. Dodatno, korisnik moºe zatraºiti od operativnog sistema da
nasilno terminira program i na taj na£in izaže iz beskona£ne petlje.

2. Izolacija: Gre²ka u jednoj aplikaciji ne bi trebalo da poremeti druge aplika-

cije, pa £ak i sam operativni sistem. To se naziva izolacija gre²aka. Svako
ko je ikada i²ta programirao zna kolika je vrednost operativnog sistema
koji moºe da za²titi sebe i druge aplikacije od programskih gre²aka. Otkla-
njanje pogre²aka bilo bi znatno teºe ako gre²ka u jednom programu moºe
pokvariti strukture podataka u drugim aplikacijama. Isto tako, preuzima-
nje i instaliranje jedne aplikacije, nikako ne bi smelo da poremeti programe
koji ne zavise od nje, niti bi takva instalacija trebala omogu¢iti proprat-
nu instalaciju ra£unarskog virusa u sistemu. Takože, jedan korisnik ne bi
nikako trebao da ima pristup ili da promeni podatke drugog bez eksplicit-
no date dozvole. Izolacija gre²aka ograni£ava aplikacije na ograni£en skup
hardverskih resursa. Ukoliko bi bio omogu¢en potpuni pristup hardveru,
bilo koja aplikacije preuzeta sa interneta ili bilo koja skripta umetnuta
u veb stranicu, imala bi potpunu kontrolu nad ma²inom. Tako bi mogao
da se jednostavno pokrene virus koji bi, na primer, pratio i beleºio svaki
taster koji korisnik pritisne ili pamtio lozinke na svakoj veb lokaciji koju
je korisnik posetio. Bez izolacije gre²ke koju obezbežuje operativni sistem,
bilo kakva gre²ka u bilo kojem programu moºe nepovratno o²tetiti disk.
Pogre²ne ili zlonamerne aplikacije prouzrokovale bi totalni haos.

3. Komunikacija: Mana izolacije od gore je potreba za komunikacijom izme-

žu razli£itih aplikacija i izmežu razli£itih korisnika. Na primer, veb strani-
ca se moºe implementirati putem istovremenog izvr²avanja £itavog skupa
aplikacija: jedna za odabir banera, druga za ke²iranje nedavno primljenih
podataka, tre¢a za preuzimanje podataka sa diska i upisivanje podata-
ka na disk, £etvrta za pristup podacima u bazi podataka, itd. Da bi ovo
funkcionisalo, potrebno je omogu¢iti svim tim programima da komunici-
raju jedni s drugima. Ako su operativni sistemi dizajnirani za spre£avanje
gre²aka i zlonamernih korisnika i aplikacija koji uti£u na druge korisnike
i njihove aplikacije, kako operativni sistem moºe podrºati komunikaciju u
cilju deljenja rezultata? Prilikom postavljanja granica, operativni sistem,
dakle, mora omogu¢iti da se te granice mogu pre¢i paºljivo, na kontrolisani
na£in, kada se za to ukaºe potreba.

U svojoj ulozi sudije, operativni sistem balansira potrebe, razdvaja konikte i

olak²ava deljenje. Jedan korisnik ne bi smeo nikako biti u mogu¢nosti da pri-
svoji sve resurse sistema, da pristupi ili promeni datoteke drugih korisnika bez
 9

dozvole. Gre²ka u aplikaciji ne bi smela biti u stanju da sru²i operativni sistem

ili druge aplikacije nezavisne od nje. A, ipak, aplikacije moraju da rade zajedno.
Forsiranje i uravnoteºenje ovih zahteva je uloga operativnog sistema.

2.2 Maskiranje limitacija hardvera: Operativni sistem kao

iluzionista
Druga vaºna uloga operativnih sistema je da prikrivaju postoje¢a ograni£e-
nja u ra£unarskom hardveru. Hardver je nuºno ograni£en zi£kim ograni£enjima
- ra£unar ima samo ograni£en broj procesora i ograni£enu koli£inu zi£ke memo-
rije, kapacitet mreºnog interfejsa i diska. Nadalje, budu¢i da operativni sistem
mora odlu£iti kako podeliti ksni skup resursa izmežu razli£itih aplikacija koje
se pokre¢u, odrežena aplikacija moºe, u zavisnosti od trenutka, imati razli£ite
koli£ine dodeljenih resursa, £ak i kada se pokre¢e na istom hardveru. Iako je
zna£ajan broj aplikacija dizajniran tako da iskoristi prednost speci£ne kon-
guracije hardvera i dodeljivanja speci£nih resursa, ve¢ina programera ºeli da
koristi vi²i nivo apstrakcije.
Kao ²to smo pomenuli ranije, ra£unar sa jednim procesorom moºe pokrenuti
samo jedan program u datom trenutku. Ipak, ve¢ina operativnih sistema omo-
gu¢ava iluziju za korisnika da se vi²e aplikacija istovremeno izvr²ava, £ak i na
sistemima sa jednim procesorom. Operativni sistem to £ini kroz koncept koji
se zove virtualizacija. Virtualizacija pruºa aplikaciji iluziju resursa koji zi£ki
nisu prisutni. Na primer, operativni sistem moºe svakoj aplikaciji predstaviti
apstrakciju £itavog procesora posve¢enog isklju£ivo njoj, iako na zi£kom ni-
vou moºe biti samo jedan procesor koji se deli izmežu svih aplikacija koje se
pokre¢u na ra£unaru. Sa odgovaraju¢om hardverskom i podr²kom operativnog
sistema, ve¢ina zi£kih resursa moºe se virtualizovati. Primeri uklju£uju pro-
cesor, memoriju, prostor na ekranu, disk i mreºu. ƒak se i tip procesora moºe
virtualizovati, kako bi se omogu¢ilo pokretanje iste, neizmenjene aplikacije na
pametnom telefonu, tabletu i laptop ra£unaru.
Ako odemo korak dalje, svi savremeni operativni sistemi virtualizuju ceo ra-
£unar, kako bi se pokrenuo operativni sistem kao aplikacija koja se pokre¢e u
okvoru drugog operativnog sistema. Ovakav koncept se naziva virtualna ma²i-
na. Operativni sistem koji je pokrenut u okviru virtualne ma²ine i koji se £esto
naziva gostuju¢i operativni sistem (guest operating system ), izvr²ava se potpu-
no identi£no kao ²to bi se izvr²avao na stvarnoj, zi£koj ma²ini, ²to je iluzija
predstavljena od strane operativnog sistema na kojem je pokretnuta virtualna
ma²ina. Jedan od razloga za²to operativni sistem obezbežuje virtualnu ma²inu
je prenosivost aplikacija. Ako se program pokre¢e samo na staroj verziji opera-
tivnog sistema, virtualizacija nam omogu¢ava da moºemo pokrenuti program i
na novom sistemu koji pokre¢e samu virtualnu ma²inu. Virtualna ma²ina po-
kre¢e aplikaciju na starom operativnom sistemu, a pokre¢e je izvr²avaju¢i se na
novom operativnom sistemu. Drugi razlog za virtualne ma²ine je pomo¢ u otkla-
njanju pogre²aka - debagovanje. Ako se operativni sistem moºe pokrenuti kao
aplikacija, tada programeri operativnog sistema mogu postaviti ta£ke prekida
( breakpoints ), zaustaviti i korak po korak prolaziti kroz kod kao u slu£aju deba-
 10

govanja aplikacija. Vrlo £esto se virtualne ma²ine koriste u slu£ajevima kada se

ºeli izbe¢i migracija softvera zahtevana prelaskom na novi operativni sistem, ta-
kože. Ako se koristi virtualna ma²ina, bilo koja izmena postoje¢ih biblioteka ili
zamena sistemskih resursa u novom operativnom sistemu ne¢e zahtevati izmenu
aplikacije, obzirom da se ona i dalje izvr²ava na starom operativnom sistemu.
Osim virtualizacije, operativni sistemi maskiraju mnoga druga ograni£enja
svojstvena hardveru, pruºaju¢i aplikacijama iluziju hardverskih mogu¢nosti koje
zi£ki nisu prisutne. Na primer, na ra£unaru sa vi²e procesora koji dele memo-
riju svaki procesor moºe da aºurira samo pojedina£nu memorijsku lokaciju u
datom trenutku. Memorijski sistem u hardveru osigurava da je svako aºuriranje
date memorijske re£i atomi£ka operacija (eng. atomic ), odnosno da je vrednost
sa£uvana u memoriji poslednja vrednost koju je sa£uvao jedan od procesora, a
ne me²avina aºuriranja razli£itih procesora. Iako se ovo moºe £initi dovoljnim,
aplikacije (i sam operativni sistem) moraju biti u mogu¢nosti da aºuriraju ve¢e
strukture podataka, one koje zauzimaju ²iri opseg memorijskih lokacija. ’ta se
de²ava kada dva procesora poku²aju aºurirati istu strukturu podataka otprilike
u isto vreme? Kao ²to ¢emo kasnije videti, rezultati mogu biti prili£no neo£e-
kivani i drasti£no razli£iti od onoga ²to bi se dogodilo da su procesori aºurirali
strukturu podataka sukcesivno, jedan za drugim. U idealnom slu£aju, programer
bi ºeleo da apstrakuje atomi£ko aºuriranje na celokupnu strukturu podataka, a
ne samo na jednu re£ u okviru memorije. Iluziju atomi£kog aºuriranja struktura
podataka obezbežuje operativni sistem koriste¢i neke specijalizovane mehani-
zme hardvera. O tome ¢emo pri£ati mnogo detaljnije u narednim predavanjima.
Urežaji za trajno skladi²tenje podataka, poput magnetnog diska ili ash
RAM-a, pruºaju jo² jedan primer. Na zi£kom nivou, ovaj sistem podrºava upis
podataka u blokovima, pri £emu veli£ina bloka zavisi od zi£kih karakteristika
urežaja. Ako se, iz bilo kog razloga, rad ra£unara prekine usred upisa u blok, disk
bi mogao da ostane u nedenisanom stanju, u kojem na toj lokaciji nije sa£uvana
ni stara ni nova vrednost. Naravno, aplikacije moraju biti u mogu¢nosti da
upisuju podatke na disk razli£ite veli£ine, pri £emu sam upis moºe da obuhvata
vi²e blokova. Pri svemu tome, korisnici svakako podrazumevaju da ¢e im podaci
biti sa£uvani, £ak (ili posebno) ako dože do kvara na ma²ini dok se disk aºurira.
Razgovara¢emo o tehnikama koje operativni sistem koristi da bi postigao ove i
druge iluzije. U svakom od ovih slu£ajeva, operativni sistem pruºa pogodniju i
eksibilniju apstrakciju programerima od one koja je data od strane osnovnog
hardvera.

2.3 Zajedni£ki servisi: Operativni sistem kao lepak

Operativni sistem takože igra i tre¢u ulogu, pruºaju¢i skup uobi£ajenih,
standardnih servisa aplikacijama kako bi se pojednostavio i standardizovao nji-
hov dizajn. Primer toga videli smo sa veb serverom navedenim na po£etku ovog
poglavlja. Operativni sistem krije speci£nosti na£ina rada mreºe i urežaja za
skladi²tenje podataka, pruºaju¢i jednostavniju apstrakciju aplikacijama na osno-
vu prijema i slanja kori²¢enjem pouzdanih tokova bajtova, kao i £itanja i pisanja
podataka kori²¢enjem imenovanih datoteka. To omogu¢ava da se veb server fo-
 11

kusira na svoj osnovni zadatak dekodiranja dolaznih zahteva i ispunjavanja istih,

umesto da tro²i vreme na formatiranje podataka u pojedina£ne mreºne pakete
ili u blokove koji ¢e se koristiti prilikom upisa na disk.
Vaºan razlog za²to operativni sistem pruºa zajedni£ke usluge, umesto da ih
prepusti svakoj aplikaciji, jeste omogu¢avanje deljenja izmežu aplikacija. Veb
server mora biti u mogu¢nosti da pro£ita datoteku koju je kreirao i popunio
tekst editor. Ako aplikacije ºele da dele datoteke, one se moraju £uvati u stan-
dardnom formatu, u okviru standardnog fajl sistema i uz standardizovano upra-
vljanje direktorijumima datoteka. Sli£no tome, ve¢ina operativnih sistema pruºa
standardni na£in da aplikacije prenose poruke i razmenjuju memoriju kako bi
olak²ali deljenje podataka.
Izbor servisa koje bi operativni sistem trebao da pruºa £esto je pitanje pro-
cene. Na primer, ra£unari mogu da se konguri²u sa £itavim spektrom razli£itih
urežaja: razli£iti gra£ki koprocesori i formati piksela, razli£iti mreºni interfejsi
(WiFi, Ethernet i Bluetooth), razli£iti diskovi (SCSI, IDE), razli£iti interfejsi
urežaja (USB, Firewire) i razli£iti senzori (GPS, akcelerometri), da ne spomi-
njemo razli£ite verzije svakog od tih standarda. Ve¢ina aplikacija mo¢i ¢e da
ignori²e ove razlike koriste¢i samo generi£ki interfejs koji pruºa operativni si-
stem. Za ostale aplikacije, kao ²to je baza podataka, odreženi tip disk urežaja
moºe da ima izuzetan zna£aj. Za one aplikacije koje mogu raditi na vi²em nivou
apstrakcije, operativni sistem sluºi kao sloj interoperabilnosti, obezbežuju¢i da
se i aplikacije i sami urežaji mogu nezavisno razvijati bez potrebe za istovreme-
nim promenama sa druge strane.
Druga standardna usluga u ve¢ini modernih operativnih sistema je biblioteka
gra£kog korisni£kog interfejsa. I Microsoft i Apple operativni sistemi pruºaju
set standardnih komponenti ( widget ) za korisni£ki interfejs. Ovo olak²ava uo-
bi£ajeni izgled i ose¢aj za korisnike, tako da se £este operacije, kao ²to su
padaju¢i meniji i cut i paste, koriste na identi£an na£in u razli£itim apli-
kacijama.
Ve¢ina koda operativnog sistema upravo ima ulogu da implementira ove
zajedni£ke servise. Mežutim, veliki deo sloºenosti operativnih sistema nastaje
zbog potreba rasporeživanja resursa i maskiranja ograni£enja hardvera. Budu¢i
da su zajedni£ki servisi izgraženi na apstrakcijama koje pruºaju dve druge uloge
operativnog sistema, u nastavku gradiva ¢emo se uglavnom fokusirati na te dve
teme.

3 Kriterijumi za poreženje operativnih sistema

Nakon ²to smo denisali ²ta radi operativni sistem, potrebno je prokomen-
tarisati na koji na£in se moºe birati izmežu alternativnih pristupa u izazovima
dizajna operativnih sistema? U nastavku ¢emo raspravljati o nekoliko krite-
rijuma za poreženje operativnih sistema. U mnogim slu£ajevima, kompromisi
izmežu ovih kriterijuma su neizbeºni - pobolj²anje sistema duº jedne dimenzije
¢e dovesti do pogor²anja sistema u drugoj.
 12

3.1 Pouzdanost
Moºda i najvaºnija karakteristika operativnog sistema je njegova pouzda-
nost. Pouzdanost podrazumeva da sistem radi upravo ono za ²ta je stvoren.
Kao najniºi nivo softvera koji radi na sistemu, gre²ke u kodu operativnog si-
stema mogu imati pogubne i skrivene efekte. Ako se operativni sistem pokvari,
korisnik uglavnom ne¢e mo¢i obaviti nikakav posao, a u nekim slu£ajevima moºe
£ak i izgubiti prethodno uraženi posao, na primer, ako novonastali kvar o²teti
datoteke na disku. Nasuprot tome, kvarovi aplikacija mogu biti mnogo benig-
niji, upravo zato ²to operativni sistemi omogu¢avaju izolaciju gre²aka i brzo i
jednozna£no ponovno pokretanje nakon gre²ke u aplikaciji.
Dizajnirati pouzdan operativni sistem je veliki izazov. Operativni sistemi
£esto rade u neprijateljskom okruºenju, gde ra£unarski virusi i sli£ni zlonamerni
kodovi £esto poku²avaju da preuzmu kontrolu nad sistemom za sopstvene svrhe
iskori²¢avanjem gre²aka u dizajnu ili implementaciji operativnog sistema.
Naºalost, tipi£ne metode za pobolj²anje pouzdanosti softvera, kao ²to su
testiranje uobi£ajenih putanja koda, manje su ekasne kada se primenjuju na
operativne sisteme. Budu¢i da zlonamerni napadi naj£e²¢e ciljaju upravo izvr-
²avanje retkih putanja koda, bukvalno sve mora ispravno raditi da bi operativni
sistem bio pouzdan. ƒak i bez zlonamernih napada koji namerno aktiviraju
gre²ke, mogu se javiti izuzetno retki slu£ajevi gre²aka i bagova u kontekstu ope-
rativnog sistema ( corner cases ). Ako operativni sistem ima milion korisnika,
dogažaj sa verovatno¢om jedan u milijardu ¢e se, naºalost, dogoditi nekome od
njih brºe nego ²to je o£ekivano.
Srodni koncept pouzdanosti je odzivnost, procenat vremena u kojem je sistem
upotrebljiv. Bagoviti operativni sistem koji se £esto ru²i, ²to uzrokuje gubitkom
rezultata rada korisnika, je istovremeno i nepouzdan je i neodzivan. Bagoviti
operativni sistem koji se £esto ru²i, ali nikada ne gubi rad korisnika i ne moºe
ga upropastiti eventualnim virusima, bio bi pouzdan, ali neodzivan. Operativni
sistem koji je nefunkcionalan, ali i dalje deluje normalno dok registruje korisni£ke
pritiske tastera ili pomeraje mi²a, nepouzdan je, ali odzivan.
Stoga su jednako poºeljna i pouzdanost i odzivnost. Na odzivnost uti£u dva
faktora:

ˆ u£estalost otkaza, koja se meri srednjim vremenom do otkaza (Mean Time

To Failure - MTTF) i

ˆ vreme potrebno za vra¢anje sistema u funkcionalno stanje posle neuspeha

(na primer, ponovno pokretanje), ²to se naziva srednje vreme oporavka
Mean Time To Recover
( - MTTR).

Odzivnost se moºe pobolj²ati pove¢anjem MTTF ili smanjenjem MTTR. U pre-

davanjima koja slede, predstavi¢emo razli£ite pristupe pobolj²anju pouzdanosti
i odzivnosti operativnog sistema. U mnogim slu£ajevima apstrakcije koje ¢emo
uvoditi mogu na prvi pogled izgledati prestrogo i preformalno. Mežutim, vaºno
je shvatiti da je to u£injeno namerno: samo precizne apstrakcije daju osnovu za
konstrukciju pouzdanih i odzivnih sistema.
 13

3.2 Sigurnost
Dva koncepta usko povezana sa pouzdano²¢u su sigurnost i privatnost. Si-
gurnost je svojstvo koje garantuje da napada£ ne moºe ugroziti rad ra£unara.
Privatnost je deo sigurnosti - da su podaci sa£uvani na ra£unaru dostupni samo
ovla²¢enim korisnicima.
Nijedan upotrebljiv ra£unar nije savr²eno siguran! Bilo koji sloºeni deo sof-
tvera ima gre²ke, a £ak i ina£e ne²kodljivi bagovi mogu biti iskori²¢eni od strane
napada£a da bi stekli kontrolu nad sistemom. Sa jedne strane, hardver ra£u-
nara moºe biti tako dizajniran da omogu¢ava pristup potencijalnom napada£u,
sa druge strane, moºda je administrator ra£unara nepouzdan, te koriste¢i pri-
vilegije omogu¢ava kražu korisni£kih podataka. Na kraju krajeva, programer
operativnog sistema je moºda namerno i svesno omogu¢io ulazne ta£ke kako bi
napada£ mogao pristupiti sistemu.
Ipak, operativni sistem moºe i treba da bude osmi²ljen tako da, koliko god
je to mogu¢e, minimizira svoju ranjivost na napade. Na primer, dobra izolacija
gre²aka moºe spre£iti eksterne aplikacije ( third party applications ) da preuzmu
kontrolu nad sistemom. Ali £ak i sa jakom izolacijom gre²aka, sistem moºe biti
nesiguran ako njegove aplikacije nisu dizajnirane imaju¢i u vidu sigurnost. Na
primer, Internet standard elektronske po²te ne omogu¢ava pouzdan identitet
po²iljaoca; mogu¢e je formirati poruku elektronske po²te sa proizvoljnom adre-
som u polju od, koja ne odgovara adresi stvarnog po²iljaoca. Stoga se moºe
pojaviti email od nekoga kome verujete, a u stvarnosti je od nekog drugog (i
sadrºi virus koji preuzima kontrolu nad ra£unarom kada se otvori prilog). Ovaj
problem bi mogao da se posmatra kao ograni£enje interakcije izmežu klijenta
elektronske po²te i operativnog sistema - da je operativni sistem omogu¢io jeftin
i jednostavan na£in da otvori prilog u izolovanom okruºenju izvr²enja sa ogra-
ni£enim mogu¢nostima, problema garantovano ne bi bilo £ak i ako prilog sadrºi
virus.
Komplikacija je svakako to ²to operativni sistem ne mora samo da spre£ava
neºeljeni pristup deljenim podacima, ve¢ mora da omogu¢i pristup u mnogim
slu£ajevima. šelimo da korisnici i programi mežusobno komuniciraju, da mogu
da urade cut i paste teksta izmežu razli£itih aplikacija i da £itaju ili upisuju
podatke na disk ili putem mreºe. Ako bi svaki program bio potpuno samostalan
bez ikakve mogu¢nosti za interakciju s bilo kojim drugim programom, tada
bi bila dovoljna samo izolacija gre²aka. Mežutim, ne samo da ne moºemo da
izolujemo programe jedne od drugih, ve¢ ºelimo da lako delimo podatke izmežu
programa i izmežu korisnika.
Stoga su operativnom sistemu potrebni i mehanizam podsticanja (enforce-
ment mechanism ) i sigurnosna politika (security policy ). Mehanizam podsticanja
predstavlja na£in na koji operativni sistem omogu¢ava izvr²avanje samo dozvo-
ljenih radnji. Sigurnosna politika, sa druge strane, deni²e ²ta je dozvoljeno -
kome je dozvoljen pristup podacima i ko moºe obavljati neke operacije.
Zlonamerni napada£i mogu ciljati kako na ranjivosti u mehanizmima pod-
sticanja, tako i u bezbednosnoj politici.
 14

3.3 Prenosivost (Portabilnost)

Svi operativni sistemi pruºaju apstrakciju osnovnog ra£unarskog hardvera, a
prenosiva apstrakcija je ona koja se ne menja u zavisnosti od promena hardvera.
Program napisan za Microsoft-ov Windows 10 trebao bi ispravno da radi bez
obzira da li se koristi odrežena gra£ka kartica, da li je obezbeženo trajno skla-
di²tenje podataka putem SSD ili magnetnog diska ili da li je mreºa Bluetooth,
WiFi ili gigabitni Ethernet.
Prenosivost se odnosi i na sam operativni sistem. Operativni sistemi spa-
daju u najsloºenije softverske sisteme ikada izumljene, tako da je neprakti£no
razvijati ih ispo£etka svaki put kada se proizvede novi hardver ili svaki put kada
se razvije nova aplikacija. Umesto toga, novi operativni sistemi £esto nasležuju,
bar delimi£no, od starih. Kao jedan primer, iOS, operativni sistem za iPhone i
iPad, nasležen je od OS-X, Apple Macintosh operativnog sistema. Kao rezultat
toga, najuspe²niji operativni sistemi imaju vek meren decenijama: po£etna pri-
mena Microsoft Windows 8 po£ela je razvojem Windows NT-a po£ev od 1990.
godine, kada je tipi£ni ra£unar bio vi²e od 10000 puta manje mo¢an i imao
je 10000 puta manje memorije i prostora na disku, nego ²to je to danas slu£aj.
Operativni sistemi koji traju decenijama nisu anomalija: Microsoftov raniji ope-
rativni sistem, MS / DOS, prvi put je predstavljen 1981. Kasnije je evoluirao u
ranim verzijama Microsoft Windows-a, a kona£no je ukinut oko 2000.
Sve ovo gore navedeno zna£i da operativni sistemi moraju biti dizajnirani
tako da podrºavaju aplikacije koje jo² nisu napisane i da rade na hardveru koji
tek treba razviti. Isto tako, ne ºelimo da razvijamo od nule aplikacije, samo zato
²to se operativni sistem, na kome se one izvr²avaju, preneo sa jedne ma²ine na
drugu.
Kako dizajnirati operativni sistem u cilju postizanja prenosivosti? Za pre-
nosivost, izuzetno je zna£ajno da postoji jednostavan, standardizovan na£in in-
terakcije aplikacija s operativnim sistemom, putem tzv apstraktnog ma²inskog
intrerfejsa (Abstract Machine Interface - AMI ). Apstraktni ma²inski interfejs
(AMI) je interfejs koji operativni sistemi pruºaju aplikacijama. Klju£ni deo AMI
jeinterfejs za programiranje aplikacija (Application Programming Interface -
API ), lista funkcija koje operativni sistem pruºa aplikacijama. AMI takože
uklju£uje model pristupa memoriji i koje instrukcije se mogu legalno izvr²iti.
Na primer, instrukcija za promenu moda rada (kanije ¢e biti vi²e re£i o tome),
koja deni²e da li procesor izvr²ava pouzdan kod u okviru kernela operativnog
sistema ili nepouzdan kod iz korisni£ke aplikacije mora biti dostupna operativ-
nom sistemu, ali ne i aplikacijama.
Dobro dizajniran AMI operativnog sistema omogu¢ava ksnu ta£ku preko
koje i kod aplikacije i hardver mogu evoluirati nezavisno. Takav koncept je sli£an
ulozi Internet Protocol (IP) standarda u umreºavanju - distribuirane aplikacije
kao ²to su elektronska po²ta i web, razvijane kori²¢enjem IP-a, izolovane su od
promena u osnovnoj mreºnoj tehnologiji (Ethernet, WiFi, opti£ka).
Jednako je vaºno da promene u aplikacijama ne zahtevaju istovremeno pro-
mene osnovnog hardvera.
Ovaj pojam prenosne hardverske apstrakcije je toliko mo¢an da operativni
 15

sistemi koriste istu ideju za svoju implementaciju. Ovo omogu¢ava da se sam

operativni sistem moºe u velikoj meri implementirati nezavisno od speci£nosti
sloj hardverske apstrakcije (Hardware Abstrac-
hardvera. Ovaj interfejs naziva se
tion Layer - HAL). Na prvi pogled moºe izgledati da bi AMI i HAL operativnog
sistema trebalo da budu identi£ni - na kraju krajeva oba su prenosivi slojevi di-
zajnirani da sakriju nevaºne detalje o hardveru. AMI je ipak znatno sloºeniji
- kao ²to smo napomenuli, aplikacije se izvr²avaju u ograni£enom, virtualizo-
vanom kontekstu uz pristup standardizovanim servisima visokog nivoa, dok se
sam operativni sistem implementira pomo¢u apstrakcije koja je mnogo bliºa
stvarnom hardveru.
Linux je primer visoko prenosivog operativnog sistema. Linux se koristi kao
operativni sistem za web servere, personalne ra£unare, tablete, netbook-ove,
£ita£e e-knjiga, pametne telefone, set-top-boksove, rutere, WiFi pristupne ta£ke
i konzole za igre. Linux je zasnovan na operativnom sistemu zvanom UNIX, koji
je prvobitno razvijen po£etkom 1970-ih. UNIX je razvio mali tim programera,
te po²to nisu mogli da priu²te razvoj obimnog koda, dizajniran je tako da bude
veoma mali, jednostavan za programiranje i veoma prenosiv, uz odrežene cene
u pogledu performansi. Tokom godina, prenosivost UNIX-a i Linux-a, kao i
pogodne apstrakcije za programiranje bili su klju£ za njihov uspeh.

3.4 Performanse
Za razliku od prenosivosti operativnog sistema, koja se moºe posmatrati
samo u ²irem vremenskom okviru, performanse operativnog sistema su £esto
odmah vidljive njegovim korisnicima.
Iako £esto povezujemo performanse sa svakom pojedina£nom aplikacijom,
dizajn operativnog sistema moºe imati veliki uticaj na percipirane performan-
se aplikacije jer operativni sistem odlu£uje kada se aplikacija moºe pokrenuti,
koliko memorije moºe da koristi i da li se datoteke ke²iraju u memoriju ili se
skladi²te na disku. Operativni sistem takože posreduje prilikom pristupa apli-
kacije memoriji, mreºi i disku. Performanse se ne mogu meriti jednozna£no, ve¢
isklju£ivo kori²¢enjem vi²estrukih metrika. Jedna metrika performansi je eka-
snost apstrakcije koja je predstavljena aplikacijama. Ekasnost je uvek u uskoj
vezi sa dodatnim tro²kom resursa za sprovoženje same apstrakcije (eng Overhe-
ad ). Jedan od na£ina za merenje ekasnosti je stepen do koga apstrakcija ometa
performanse aplikacije. Pretpostavimo da je aplikacija dizajnirana da radi di-
rektno na osnovnom hardveru, bez dodatnih tro²kova apstrakcije operativnog
sistema; koliko bi to pobolj²alo performanse aplikacije?
Operativni sistemi takože moraju da rasporežuju resurse izmežu aplikacija,
a to moºe uticati na performanse sistema onako kako ih opaºa krajnji korisnik.
Jedno je pitanje pravi£nost ( fairness ), izmežu razli£itih korisnika iste ma²ine
ili izmežu razli£itih aplikacija koje se pokre¢u na toj ma²ini. Treba li resurse
podeliti podjednako izmežu razli£itih korisnika ili razli£itih aplikacija ili bi neki
trebali imati povla²¢en tretman? Ako je tako, kako operativni sistem odlu£uje
koji zadaci dobijaju prioritet?
 16

Dva povezana koncepta su vreme odziva (response time ) i propusnost (thro-

ughput ). Vreme odziva, koje se ponekad naziva ka²njenje, pokazuje koliko traje
odreženi zadatak, od trenutka kada zapo£inje do njegovog zavr²etka. Na pri-
mer, visoko vidljivo vreme odziva za desktop ra£unare je vreme od kada kori-
snik pomera hardverski mi², pa sve dok pokaziva£ na ekranu ne odreaguje na
korisnikovu radnju. Operativni sistem koji pruºa lo²e vreme odziva moºe biti
neupotrebljiv. Propusnost je brzina kojom se moºe obavljati grupa zadataka.
Propusnost je merilo ekasnosti za grupu zadataka a ne jedan pojedina£ni. Iako
se moºe £initi da ¢e dizajni koji pobolj²avaju vreme odziva takože pobolj²ati
propusnost, to nije slu£aj, o £emu ¢emo kasnije govoriti.
Predvidljivost performansi, pokazuje koliko su performanse sistema vreme-
nom konzistentne, bez obzira da li je vreme odziva sistema ili neka druga me-
trika kori²¢ena. Predvidljivost £esto moºe biti vaºnije od prose£nih performansi.
Razmotrimo, na primer, dva sistema: u jednom su korisnikovi pritisci na tastere
gotovo uvek trenutni, ali 1% vremena pritisak tastera zahteva 10 sekundi ka²nje-
nja. U drugom sistemu korisnikovim pritiscima tastera uvek treba 0,1 sekunda
da se odraze na ekranu. Prose£no vreme odziva moºe biti isto u oba sistema, ali
drugi je predvidljiviji i samim tim korisniji (vi²e user friendly ).

3.5 Dostupnost
Pored pouzdanosti, prenosivosti i performansi, uspeh operativnog sistema
zavisi od dva faktora koji su van njegove neposredne kontrole: (²iroka) dostup-
nost aplikacija prenosivih u taj operativni sistem i (²iroka) dostupnost hardvera
koji operativni sistem moºe da podrºi. IPhone pokre¢e iOS, ali bez unapred in-
staliranih aplikacija i sadrºaja App Store-a, iPhone bi bio samo mobilni telefon
sa verovatno lo²im prijemom kod korisnika.
Neto efekat nastaje kada vrednost neke tehnologije ne zavisi samo od njenih
sopstvenih mogu¢nosti, ve¢ i od broja drugih ljudi koji su usvojili tu tehnologiju.
Dizajneri aplikacija i hardvera tro²e svoje napore na platformama operativnog
sistema s najvi²e korisnika, dok korisnici favorizuju one operativne sisteme sa
najboljim aplikacijama ili najjeftinijim hardverom. Ako ovo zvu£i kao kruºni
efekat, to i jeste tako: vi²e korisnika podrazumeva vi²e aplikacija i jeftiniji har-
dver; vi²e aplikacija i jeftiniji hardver podrazumeva vi²e korisnika u virtualnom
ciklusu.
Izazov onda o£igledno postaje dizajniranje operativnog sistema tako da is-
koristi neto efekat ili bar da bude imun na njega. O£igledan korak u tom smeru
bi bio dizajniranje sistema tako da se olak²a dodatak novog hardvera i olak²a
prenos aplikacija u razli£itim verzijama istog operativnog sistema.
Suptilnije je pitanje izbora da li je interfejs za programiranje (API) opera-
tivnog sistema ili sam izvorni kod operativnog sistema otvoren (open code ) ili
zatvoren (proprietary ). Softver zatvorenog koda je pod kontrolom jedne kom-
panije, pa ga vlasnik moºe u bilo kom trenutku promeniti kako bi zadovoljio
potrebe svojih kupaca. Otvoreni sistem je onaj gde je izvorni kod sistema javni,
omogu¢avaju¢i svima da ga pregledaju i promene. ƒesto ¢e otvoreni sistem imati
API koji se moºe menjati samo uz saglasnost tela za javne standarde. Pridrºava-
 17

Slika 2: Struktura ra£unarskog sistema

nje standarda pruºa sigurnost programeru da se API ne¢e menjati, osim op²tim
sporazumom; s druge strane, organi za standarde mogu oteºati brzo dodavanje
novih, ºeljenih funkcija. Ni otvoreni ni zatvoreni sistemi nisu o£igledno bolji za
²iroko usvajanje. Windows 10 i MacOS su primeri zatvorenih operativnih siste-
ma, Linux je primer otvorenog operativnog sistema i sva tri se ²iroko koriste!
Otvoreni sistemi se lak²e prilagožavaju ²irokom rasponu hardverskih platformi,
ali rizikuju fragmentaciju, ²to uti£e na neto efekat. Tvorci zatvorenih operativ-
nih sistema tvrde da su njihovi sistemi pouzdaniji i bolje prilagoženi potrebama
kupaca. Problemi interoperabilnosti i kompatibilnosti su smanjeni ako i hardver
i softver kontroli²e ista kompanija, ali ograni£enje operativnog sistema na jednu
hardversku platformu umanjuje neto efekat.
Olak²avanje preno²enja aplikacija sa postoje¢ih na novi operativni sistem
moºe pomo¢i novom sistemu da se uspostavi, i obrnuto, dizajniranje API-ja
operativnog sistema da oteºava prenos aplikacija van operativnog sistema moºe
spre£iti njegovo ²irenje i konkurentnost. Stoga £esto postoje komercijalni priti-
sci koji spre£avaju da interfejs operativnog sistema postane idiosinkratski. Iako
¢emo u nastavku raspravljati o problemima operativnih sistema na konceptu-
alnom nivou, vaºno je shvatiti da ¢e sami detalji poprili£no varirati za svaki
odreženi operativni sistem, zbog vaºnih, ali i pomalo haoti£nih komercijalnih
interesa.

4 Operativni sistemi sa stanovi²ta organizacije

ra£unarskog sistema
4.1 Upravljanje ra£unarskim sistemom
Savremeni ra£unarski sistem op²te namene sastoji se od jednog ili vi²e pro-
cesora i brojnih kontrolera urežaja povezanih zajedni£kom magistralom koja
omogu¢ava pristup deljenoj memoriji (slika 2). Svaki kontroler urežaja je za-
 18

Slika 3: Vremenski dijagram kombinovanog izvr²avanja korisni£kog procesa i

prekidne rutine

duºen za odreženu vrstu urežaja (na primer, diskovi, audio urežaji ili video
displeji). CPU i kontroleri urežaja rade paralelno, nadme¢u¢i se za memorijske
cikluse, obzirom na £injenicu da je memorija deljena.
Da bi ra£unar mogao da se pokrene (uklju£i ili nakon reseta), potrebno je
da se pokrene inicijalni program. Ovaj inicijalni program, ili program za pokre-
tanje sistema ( bootstrap program ), obi£no je jednostavan. Uglavnom se £uva u
ra£unarskom hardveru u memoriji isklju£ivo za £itanje (ROM) ili u elektri£no
izbrisivoj programibilnoj memoriji za £itanje (EEPROM). On inicijalizuje sve
aspekte sistema, od registara CPU-a, preko kontrolera urežaja do memorijskog
sadrºaja. Program za pokretanje sistema mora znati kako u£itati operativni si-
stem i kako zapo£eti njegovo izvr²avanje. Da bi postigao ovaj cilj, program za
pokretanje sistema mora locirati jezgro ( kernel ) operativnog sistema i u£itati
ga u memoriju.
Kada se kernel u£ita i krene izvr²avati, on moºe po£eti da pruºa servise
sistemu i svojim korisnicima. Neki servisi su obezbeženi izvan kernela, od strane
sistemskih programa koji se u£itavaju u memoriju tokom pokretanja sistema, a
zovu se sistemski procesi (system daemons ). Sistemski procesi se izvr²avaju svo
vreme dok se izvr²ava kernel operativnog sistema.
Na Unix-u (i sistemima nasleženim od njega), prvi sistemski proces se naziva
"init", a pokre¢e mnoge druge sistemske daemon procese. Kada se ova faza
zavr²i, sistem je potpuno pokrenut i £eka da se dogodi neki dogažaj.
Pojava dogažaja obi£no se signalizira prekidom bilo od strane hardvera ili
softvera. Hardver moºe u bilo kom trenutku izazvati prekid slanjem signala ka
CPU. Softver moºe izazvati prekid izvr²avanjem posebne operacije koja se zove
sistemski poziv (system call, monitor call ).
Kad se CPU prekine na ovaj na£in, on zaustavlja ono ²to radi i odmah pre-
lazi na izvr²avanje koda sa ksne lokacije. Fiksna lokacija obi£no sadrºi po£etnu
adresu na kojoj se nalazi prekidna rutina. Prekidna rutina se izvr²ava, a po zavr-
²etku, CPU nastavlja izvr²avanje na mestu gde je stao kada je bio prekinut. Vre-
menski dijagram ove operacije prikazan je na slici 3. Prekidi su izuzetno vaºan
deo ra£unarske arhitekture. Svaki dizajn ra£unara ima svoj mehanizam prekida,
ali nekoliko funkcija je zajedni£ko. Prekid mora preneti kontrolu odgovaraju¢oj
 19

rutini za obradu prekida. Najjednostavniji metod bi bio poziv generi£ke rutinu

za ispitivanje informacija o prekidu. Ona bi, zauzvrat, pozvala rutinu speci£nu
za dati prekid. Mežutim, prekidi se moraju re²iti brzo, tako da se ovakav pri-
stup ne koristi. Budu¢i da je mogu¢ samo unapred denisani broj prekida, moºe
se koristiti tabela pokazatelja na prekidne rutine, u cilju znatno brºeg rada.
Prekidna rutina se poziva indirektno kroz tabelu, bez posredne rutine. Tabela
pokazatelja se obi£no £uva na najniºim adresama u memoriji (prvih par stotina
lokacija). Ove lokacije sadrºe adrese prekidnih rutina za razli£ite urežaje. Ovaj
niz ili tzv. vektor prekida se zatim indeksira jedinstvenim brojem urežaja, datim
zahtevom za prekid, radi pruºanja adrese po£etka prekidne rutine u cilju obrade
prekida za urežaj koji je izazvao prekid. Razli£iti operativni sistemi kao ²to su
Windows i Linux, obražuju prekide na gore pomenuti na£in.
Sistem prekida mora takože da sa£uva adresu prekinute instrukcije. Mnogi
stariji dizajni jednostavno su sme²tali adresu prekida na ksnu lokaciju ili na
lokaciju koja je indeksirana brojem urežaja. Novije arhitekture £uvaju povrat-
nu adresu u okviru sistemskog steka. Ako rutina za obradu prekida treba da
promeni stanje procesora - na primer, promenom vrednosti registara - ona mo-
ra sa£uvati trenutno stanje, a zatim ga rekonstruisati pre nego ²to se prekidna
rutina zavr²i. Nakon servisiranja prekida, sa£uvana povratna adresa se u£itava
u programski broja£, a prekinuto izvr²avanje nastavlja se kao da do prekida nije
ni do²lo.

4.2 Struktura ulazno/izlaznog (U/I) podsistema

Veliki deo koda operativnog sistema namenjen je upravljanju ulazno/izla-
znim sistemom, kako zbog njegove vaºnosti za pouzdanost i performanse si-
stema, tako i zbog razli£ite prirode urežaja. Ra£unarski sistem op²te namene
sastoji se od procesora i vi²e kontrolera urežaja koji su povezani preko zajed-
ni£ke magistrale. Svaki kontroler urežaja je zaduºen za odreženu vrstu urežaja.
Zavisno od kontrolera, moºe biti priklju£eno vi²e urežaja. Na primer, sedam ili
vi²e urežaja moºe se priklju£iti na mali kontroler interfejsa ra£unarskog sistema
(SCSI). Kontroler urežaja sadrºi lokalni bafer i skup registara posebne name-
ne, kojima se upravlja njime. Kontroler urežaja je odgovoran za preme²tanje
podataka izmežu perifernih urežaja koje kontroli²e i lokalnog bafera. Obi£no
operativni sistemi imaju upravlja£ki program urežaja ( device driver ) za svaki
kontroler urežaja. Ovaj upravlja£ki program razume kontroler urežaja i pruºa
operativnom sistemu jednoli£an interfejs ka tom urežaju. Da bi pokrenuo U/I
operaciju, drajver urežaja inicijalizuje odgovaraju¢e registre unutar kontrole-
ra urežaja. Kontrolor urežaja, zauzvrat, ispituje sadrºaj ovih registara kako bi
utvrdio ²ta treba preduzeti (poput £itanja znaka sa tastature). Kontroler zatim
zapo£inje prenos podataka sa urežaja u njegov lokalni bafer. Nakon ²to je pre-
nos podataka zavr²en, kontroler urežaja putem prekida obave²tava upravlja£ki
program (drajver) urežaja da je zavr²io svoj rad. Drajver urežaja potom vra¢a
kontrolu operativnom sistemu, uglavnom obezbežuju¢i podatke ili pokaziva£ na
podatke ako je bilo zahtevano £itanje podataka iz urežaja. Za ostale operacije,
drajver urežaja vra¢a informacije o statusu.
 20

Slika 4: Prenos podataka kod modernih ra£unarskih sistema

Ovaj oblik U/I koji se bazira na prekidu je prihvatljiv za preme²tanje ma-

lih koli£ina podataka, ali moºe biti izuzetno neekasan ako se koristi za prenos
veliki koli£ine podataka, kao ²to je slu£aj kod upisa/£itanja sa diska. Da bi se
ovaj problem re²io ekasno, koristi se direktan pristup memoriji (Direct Memory
Access - DMA). Nakon pode²avanja bafera, pokaziva£a i broja£a za U/I urežaj,
kontroler urežaja prenosi £itav blok podataka direktno iz (ili u) internog bafera
u memoriju, bez posredovanja CPU-a. Samo jedan prekid se u ovom slu£aju
generi²e za prenos celog bloka, kako bi se obavestio upravlja£ki program (draj-
ver) urežaja da je operacija zavr²ena, nasuprot prekidu za svaki bajt za urežaje
male brzine. Dok kontroler urežaja izvodi ove operacije, CPU je dostupan za
obavljanje drugih poslova (slika 4).

4.3 Struktura operativnog sistema

Nakon predstavljanja osnovne organizacije i arhitekture ra£unarskog siste-
ma, spremni smo da razgovaramo o operativnim sistemima. Operativni sistem
pruºa okruºenje u kojem se programi izvr²avaju. Interno se operativni sistemi
uveliko razlikuju po svojoj strukturi, jer su organizovani sa razli£itim ciljevi-
ma dizajna i optimizacije. Mežutim, postoje mnoge zajedni£ke stvari koje ¢emo
razmatrati u ovom odeljku.
Jedan od najvaºnijih aspekata operativnih sistema je mogu¢nost multi-programiranja.
Jedan program ne moºe za stalno da zauzme ni CPU ni U/I urežaje. Takože, po-
jedina£ni korisnici £esto istovremeno koriste vi²e programa. Multi-programiranje
pove¢ava iskori²¢enost CPU-a organizovanjem zadataka (koda i podataka) tako
da CPU uvek ima jedan za izvr²enje.
 21

Ideja je slede¢a: Operativni sistem istovremeno £uva nekoliko zadataka u

memoriji, a po²to je, generalno, glavna memorija premala za prihvat svih tih
zadataka, oni se u po£etku £uvaju na disku u okviru grupe zadataka. Ova grupa
se sastoji od svih procesa koji ostaju na disku dok £ekaju dodelu glavne memo-
rije. Skup zadataka u memoriji moºe biti samo podskup zadataka koji se £uvaju
u grupi zadataka. Operativni sistem bira i zapo£inje izvr²avanje jednog od za-
dataka u memoriji. Tokom izvr²avanja tog zadatka, on ¢e eventualno morati da
sa£eka da se zavr²i neki drugi ili da se desi neki dogažaj (kao ²to je U/I operaci-
ja). U ne multi-programskom sistemu, CPU bi bio besposlen u tom periodu. U
multi-programskom sistemu operativni sistem se jednostavno prebacuje na dru-
gi zadatak i izvr²ava ga. Kada taj zadatak treba da sa£eka (opet neki dogažaj
ili drugi zadatak), CPU prelazi na tre¢i i tako dalje. Vremenom, prvi zadatak
zavr²ava svoje £ekanje i vra¢a mu se CPU na raspolaganje. Sve dok barem jedan
zadatak treba da se izvr²i, CPU nikada ne¢e biti besposlen.
Multi-programirani sistemi pruºaju okruºenje u kojem se razli£iti resursi si-
stema (na primer, CPU, memorija i periferni urežaji) ekasno koriste, ali ne
obezbežuju interakciju korisnika sa ra£unarskim sistemom. Deljenje vremena
( time-sharing, multitasking ) je logi£na nadogradnja multi-programskog sistema.
U multitasking sistemima, CPU izvr²ava vi²e zadataka zamenjuju¢i jednim dru-
ge, ali se zamene dogažaju toliko £esto da korisnici mogu da komuniciraju sa
svakim programom dok je on aktivan. Za multitasking je potreban interaktiv-
ni ra£unarski sistem koji omogu¢ava direktnu komunikaciju izmežu korisnika i
sistema. Korisnik interaguje sa operativnim sistemom ili programom direktno,
koriste¢i urežaj za unos kao ²to je tastatura, mi², ili ekran osetljiv na dodir i
£eka trenutne rezultate na izlaznom urežaju. Prema tome, vreme odziva trebalo
bi da bude kratko - obi£no kra¢e od jedne sekunde, £esto i kra¢e.
Multitasking operativni sistem omogu¢ava ve¢em broju korisnika istovre-
meno deljenje ra£unara. Po²to je svaka naredba ili instrukcija u sistemu koji
podrºava deljenje vremena obi£no kratka, potrebno je veoma malo CPU vreme-
na za svakog korisnika. Kako sistem brzo prelazi sa jednog na drugog korisnika,
svakom se korisniku pruºa utisak da je ceo ra£unarski sistem posve¢en njegovoj
upotrebi, iako se deli izmežu vi²estrukih korisnika.
Multitasking operativni sistem koristi dodeljivanje CPU-a i multi-programiranje
kako bi svakom korisniku pruºili mali deo ra£unara. Svaki korisnik ima najmanje
jedan program u memoriji. Program u£itan u memoriju i odrežen za izvr²avanje
naziva se proces . Kada se proces izvr²ava, on se obi£no izvr²ava samo kratko
vreme pre nego ²to zavr²i ili mora da zatraºi interakciju U/I jedinicom. Ula-
z/izlaz moºe biti interaktivni; to jest, izlaz ide na ekran za korisnika, a ulaz
dolazi od korisni£ke tastature, mi²a ili drugog urežaja. Budu¢i da interaktivni
U/I obi£no radi "brzinom £oveka", potrebno je dugo vremena da se dovr²i. Na
primer, unos moºe biti ograni£en brzinom unosa korisnika; sedam znakova u
sekundi je brzo za ljude, ali neverovatno sporo za ra£unare. Umesto da dozvoli
da CPU miruje u toku rada ovog interaktivnog ulaza, operativni sistem ¢e brzo
prebaciti CPU u posed procesa nekog drugog korisnika.
Deljenje vremena i multi-programiranje zahteva da se nekoliko zadataka odr-
ºava istovremeno u memoriji. Ako je vi²e zadataka spremno za upis u memoriju,
 22

a u slu£aju da nema dovoljno prostora za sve, sistem mora da bira izmežu njih.
U tom cilju, sistem vr²i rasporeživanje zadataka ( job scheduling ). Kada opera-
tivni sistem izabere zadatak iz grupe zadataka sa diska, on u£itava taj zadatak
u memoriju radi izvr²avanja. Da bismo smestili vi²e programa u memoriju is-
tovremeno, potrebno je implementirati neki oblik upravljanja memorijom, ali
to je zaseban problem o kojem ¢emo takože detaljno pri£ati. Kada su jednom
odabrani zadaci koji ¢e se upisati u memoriju, ako je nekoliko njih spremno isto-
vremeno da se izvr²ava, sistem mora odabrati koji ¢e se zadatak prvi izvr²avati.
Dono²enje ove odluke je vezano za rasporeživanje CPU-a ( CPU scheduling ) o
kome ¢emo takože op²irnije govoriti kasnije. Na kraju, izvr²avanje vi²e zada-
taka istovremeno zahteva da njihova sposobnost da uti£u jedni na druge bude
ograni£ena u svim segmentima operativnog sistema, uklju£uju¢i rasporeživanje
procesa, kori²¢enje diska i upravljanje memorijom.
U sistemu za deljenje vremena, operativni sistem mora da obezbedi razum-
no vreme odziva. Ovaj cilj se ponekad postiºe zamenom (swapping ), pri £emu
se procesi prebacuju u glavnu memoriju sa diska i obrnuto. ƒe²¢a metoda za
obezbeživanje razumnog vremena odziva je virtualna memorija, tehnika koja
omogu¢ava izvr²enje procesa koji nije u potpunosti u memoriji i o ovome ¢emo
detaljno pri£ati u jednom od zavr²nih predavanja. Glavna prednost virtualne
memorije je u tome ²to omogu¢ava korisnicima da pokre¢u programe koji su
£ak i ve¢i od stvarne zi£ke memorije. Dodatno, mehanizam virtualizacije me-
morije abstrakuje glavnu memoriju u veliki, uniformni niz lokacija, odvajaju¢i
logi£ku memoriju, kako je korisnik vidi, od zi£ke memorije. Ovaj aranºman
oslobaža programere od brige zbog ograni£enja memorije.
Multitasking sistem, takože, mora da obezbedi sistem datoteka ( le system ).
Sistem datoteka se nalazi na disku (ili vi²e njih); stoga se mora obezbediti upra-
vljanje diskom od strane operativnog sistema.
Za kraj, neophodan je mehanizam za za²titu resursa od neprimerene upotre-
be, a operativni sistem mora obezbediti i mehanizme za sinhronizaciju zadataka
i njihovu mežusobnu komunikaciju. O svemu ovome ¢emo detaljnije pri£ati na
predavanjima koja dolaze.

4.4 Funkcionisanje operativnog sistema

Kao ²to je ranije spomenuto, savremeni operativni sistemi su bazirani na
prekidima. Ako nema procesa koji se izvr²avaju, nema U/I urežaja koji bi se
servisirali i nema korisnika sa kojima bi bilo interakcije, operativni sistem ¢e
biti besposlen i £ekati da se ne²to dogodi. Dogažaji su gotovo uvek signalizira-
ni pojavom prekida ili izuzetka. Izuzetak ( trap ) je softverski generisan prekid
izazvan ili gre²kom (na primer, deljenjem sa nulom ili pristupom nedozvoljenoj
memorijskoj lokaciji) ili odreženim zahtevom korisni£kog programa da se izvr²i
usluga od strane operativnog sistema.
Budu¢i da operativni sistem i korisnici dele hardverske i softverske resurse
ra£unarskog sistema, moramo biti sigurni da ¢e eventualna gre²ka u datom ko-
risni£kom programu stvoriti probleme samo za taj konkretan program koji se
izvr²ava. Uz gore pomenuto deljenje resursa, bag u jednom programu bi mogao
 23

Slika 5: Tranzicija izmežu korisni£kog i kernel moda

da ima negativan uticaj na ostale procese. Na primer, ako se proces zaglavi u

beskona£noj petlji, ova petlja moºe da spre£i ispravan rad mnogih drugih pro-
cesa. Suptilnije gre²ke mogu se pojaviti u sistemu s vi²e programa, pri £emu
gre²ka u jednom programu moºe modikovati drugi program, podatke drugog
programa ili £ak i sam operativni sistem.
Bez za²tite od ove vrste gre²aka, ra£unar bi morao ili da izvr²ava samo jedan
program u datom trenutku ili je potrebno da svi rezultati i sve operacije budu
preispitivane i proveravane. Po²to prvi pristup uop²te nije opcija, zbog svega go-
re navedenog, pravilno dizajniran operativni sistem mora osigurati da pogre²an
(ili zlonamerni) program ne moºe nikako uzrokovati gre²ke u izvr²avanju drugih
programa.
Dualni mod izvr²avanja upravo obezbežuje ovakvu za²titu. U dualnom mo-
du izvr²avanja, razlikujemo izvr²avanje koda od strane operativnog sistema i
izvr²avanje korisni£kog koda. Ve¢ina ra£unarskih sistema obezbežuje odgovara-
ju¢u hardversku podr²ku, koja je neophodna za implementaciju dualnih (ili £ak
vi²estrukih) modova izvr²avanja.
Da bismo ovo implementirali, potrebna su nam dva odvojena reºima rada:
korisni£ki reºim i kernel reºim (koji se takože zove i nadzorni reºim - super-
visor mode, sistemski reºim - system mode ili privilegovani reºim - privileged
mode ). Zaseban bit, nazvan bit moda rada (eng. mode bit ), dodaje se hardveru
ra£unara da bi ozna£io trenutni reºim izvr²avanja: kernel (0) ili korisni£ki (1).
Pomo¢u bita moda rada moºemo razlikovati zadatke koji se izvr²avaju u kon-
tekstu operativnog sistema i zadatke koji se izvr²avaju u kontekstu korisnika.
Kada se izvr²ava kod u kontekstu korisni£ke aplikacije, sistem je u korisni£kom
reºimu. Mežutim, kada korisni£ka aplikacija zatraºi uslugu od operativnog si-
stema (putem sistemskog poziva ), sistem mora da preže iz korisni£kog u kernel
reºim da bi ispunio zahtev. To je prikazano na slici 5. Kao ²to ¢emo videti, ovo
arhitekturalno unapreženje pokaza¢e se korisno i za mnoge druge aspekte rada
sistema.
Prilikom pokretanja sistema, hardver se pokre¢e u kernel reºimu. Operativni
sistem se zatim u£itava i pokre¢e korisni£ke aplikacije u korisni£kom reºimu. Kad
god se dogodi izuzetak ili prekid, hardver prelazi iz korisni£kog reºima u reºim
kernela (tj. menja stanje bita moda rada u 0). Stoga, svaki put kada operativni
sistem preuzme kontrolu nad ra£unarom, on se nalazi u kernel reºimu. Sistem
uvek prelazi u korisni£ki reºim (postavljanjem bita moda rada na 1) pre prenosa
 24

kontrole na korisni£ki program.

Dualni na£in rada pruºa nam sredstva za za²titu operativnog sistema od
²tetnih korisnika i ²tetnih korisnika jednih od drugih. Ovu za²titu ostvarujemo
denisanjem skupa privilegovanih instrukcija, u koji spadaju sve instrukcija koje
mogu na bilo koji na£in na²koditi sistemu. Sa druge strane, hardver obezbežuje
da se privilegovane instrukcije uvek izvr²avaju isklju£ivo u kernel reºimu. Ako
se poku²a izvr²iti privilegovana instrukcija u korisni£kom reºimu, hardver ne iz-
vr²ava instrukciju, ve¢ je tretira kao nelegalnu i generi²e izuzetak za operativni
sistem. Instrukcija za prelazak u reºim kernela je primer privilegovane instruk-
cije. Sli£ne su instrukcije koje kontroli²u U/I urežaje, upravljaju tajmerom ili
prekidima. Kao ²to ¢emo videti u nastavku, postoji mnogo privilegovanih in-
strukcija koje ¢emo koristiti.
Sada kada smo denisali privilegovane instrukcije, sistemski pozivi pruºaju
mogu¢nost korisni£kom programu da od operativnog sistema zatraºi da u ime
njih obavlja zadatke rezervisane za operativni sistem. Sistemski poziv se vr-
²i na razli£ite na£ine, zavisno od funkcionalnosti koju pruºa procesor. U svim
varijantama, to je metoda koju koristi proces da bi zatraºio akciju od strane ope-
rativnog sistema. Sistemski poziv obi£no ima oblik izuzetka kojem je dodeljena
odrežena lokacija u vektoru prekida.
Kada se izvr²i sistemski poziv, hardver ga obi£no tretira kao softverski pre-
kid. Kontrola prelazi preko vektora prekida do servisne rutine u operativnom
sistemu, a mod rada je postavljen na kernel reºim. Rutina za obradu sistemskog
poziva je deo operativnog sistema. Kernel proverava instrukciju koja je dovela
do prekida kako bi utvrdio koji sistemski poziv se dogodio: parametar uz in-
strukciju ukazuje na vrstu usluge koju korisni£ki program traºi od operativnog
sistema. Dodatne informacije eventualno potrebne za zahtev mogu se proslediti
kroz registre, na steku ili u memoriji (s pokaziva£ima na memorijske lokacije
prosleženim u registrima). Kernel proverava da li su parametri ta£ni i legalni,
izvr²ava zahtev ako jesu i vra¢a kontrolu instrukciji koja sledi nakon instrukcije
sistemskog poziva. Pri£a¢emo i o ovome detaljnije u nastavku.

4.5 Bezbedan transfer kontrole

Nakon ²to kernel kreira korisni£ki proces, postavlja se pitanje kako bezbedno
prelaziti sa izvr²enja korisni£kog procesa ka izvr²enju u okviru kernela i obrnuto.
Ovi prelazi nisu retki dogažaji. Web server, na primer, moºe da obavlja ovu
tranziciju izmežu korisni£kog i kernel reºima stotine ili hiljade puta u sekundi.
Dakle, mehanizam treba da bude i brz i siguran, ne ostavljaju¢i prostora ni
jednom programu da namerno ili nenamerno na²kodi kernelu.

4.5.1 Transfer iz korisni£kog u kernel reºim

Prvo se fokusiramo na prelaze sa korisni£kog reºima na kernel reºim. Kao ²to

¢emo videti, prelazak u drugom smeru funkcioni²e tako ²to poni²tava prelazak
iz korisni£kog procesa u kernel. Postoje tri razloga zbog kojih ¢e kernel preuzeti
kontrolu nad korisni£kim procesom: izuzeci, prekidi i sistemski pozivi.
 25

ˆ Izuzeci: Izuzetak je reakcija na svako neo£ekivano stanje uzrokovano po-

na²anjem korisni£kog programa. Prilikom izuzetka, hardver ¢e zaustaviti
proces koji se trenutno izvr²ava i pokrenuti posebno namenjen program
za obradu izuzetka u okviru kernela. Kao ²to smo ranije spomenuli, izu-
zetak se generi²e svaki put kada proces poku²ava da izvr²i privilegovanu
instrukciju ili pristupi memoriji izvan memorije dodeljene tom procesu.
Ostali izuzeci se de²avaju kada proces deli ceo broj sa nulom, pristupa
memorijskoj re£i sa neporavnatom adresom ( non-aligned address ), poku-
²ava da upisuje u memoriju koja je rezervisana samo za £itanje i tako
dalje. U tim slu£ajevima, operativni sistem jednostavno zaustavlja pro-
ces i korisniku vra¢a kod gre²ke. Mežutim, izuzeci mogu biti aktivirani i
brojnim drugim, bezazlenijim, dogažajima u okviru programa. Na primer,
da bi postavio ta£ku prekida u programu ( breakpoint ), kernel zamenjuje
ma²insku instrukciju u memoriji posebnom instrukcijom koja ¢e izazva-
ti izuzetak. Kada program dože do te ta£ke tokom izvr²avanja, hardver
se prebacuje u kernel reºim. Kernel vra¢a prvobitnu instrukciju i preno-
si kontrolu debageru. Pomo¢u debagera, korisnik moºe pregledati stanje
promenljivih u okviru programa, postaviti novu ta£ku prekida i nastaviti
program po£ev²i od instrukcije koja je uzrokovala izuzetak.

ˆ Prekidi: Prekid je asinhroni signal procesoru da se dogodio neki spoljni

dogažaj koji moºe zahtevati njegovu paºnju. Prekid funkcioni²e u velikoj
meri kao izuzetak: procesor zaustavlja proces koji se trenutno izvr²ava i
zapo£inje izvr²avanje posebno namenjene rutine za obradu prekida u okvi-
ru kernela. Svaka razli£ita vrsta prekida zahteva svoju rutinu za obradu
prekida. Posebno je speci£an prekid generisan od strane tajmera, uvek
prisutan u operativnom sistemu. Kao prva uloga prekida tajmera, prekid-
na rutina proverava da li trenutni proces reaguje na unos korisnika, kako
bi otkrila da li je proces eventualno u²ao u beskona£nu petlju. Dodatno,
prekidna rutina tajmera moºe takože periodi£no prebaciti procesor nekom
drugom procesu kako bi se osiguralo da se svaki proces izvr²ava. Ako ne
postoji drugi proces koji bi se mogao izvr²avati, nakon zavr²etka prekid-
ne rutine tajmera, nastavlja se izvr²avanje na mestu prekinute instruk-
cije, potpuno transparentno sa stanovi²ta korisni£kog procesa. Prekidi se
takože koriste za obave²tavanje kernela o pristiglim ulazno/izlaznim za-
htevima. Na primer, hardver urežaja mi²a izazva¢e prekid svaki put kada
korisnik pomeri mi²a ili klikne mi²em. Kernel ¢e, zauzvrat, obavestiti o
tome odgovaraju¢i korisni£ki proces - onaj koji je bio aktivan u trenutku
dok se mi² pomerao. Skoro svaki ulazno/izlazni urežaj (Ethernet, WiFi,
hard-disk, tastatura, mi²) izaziva prekid kad god se pojavi neki dogažaj
na koji procesor treba da odreaguje i kad god se ispuni neki zahtev. Al-
ternativa prekidima je prozivanje (polling ): kernel moºe prozivati i na taj
na£in proveravati svaki ulazno/izlazni urežaj, kako bi video da li se dogo-
dio neki dogažaj koji zahteva obraživanje. Naravno, ukoliko kernel proziva
dati urežaj, u tom periodu vremena nije mogu¢e izvr²avati nijedan proces
iz korisni£kog reºima. Mežu-procesorski prekidi su takože jedan od izvora
 26

prekida sa kojima se sre¢emo. Na multiprocesorskim sistemima, procesor

moºe izazvati prekid na koji ¢e odreagovati bilo koji od ostalih procesora.
Kernel koristi ove prekide za koordinaciju akcija u okviru multiprocesor-
skog sistema. Na primer, ako se na jednom procesoru desi fatalan izuzetak,
kernel ¢e, tipi£no, generisati prekid kako bi zaustavio izvr²avanje eventu-
alno kriti£nog koda na bilo kojem drugom procesoru.

ˆ Sistemski pozivi: Korisni£ki procesi takože mogu dobrovoljno pre¢i u ker-

nel reºim operativnog sistema i zatraºiti da kernel izvr²i neku radnju u ime
korisnika. Sistemski poziv je svaka procedura koju pruºa kernel a koja se
moºe pozvati od strane korisni£kog procesa. Ve¢ina procesora implemen-
tira sistemske pozive koriste¢i posebnu instrukciju zamke (trap ). Mežu-
tim, postojanje instrukcija zamki nije obavezno; moºe se izazvati zamka
izvr²avaju¢i bilo koju instrukciju koja rezultuje izuzetkom (npr. ona sa
nepostoje¢im kodom operacije). Kao i kod prekida ili izuzetka, instrukci-
ja zamke menja reºim rada procesora iz korisni£kog u kernel i zapo£inje
izvr²avanje u kernelu, koriste¢i unapred denisanu rutinu. U cilju za²tite
kernela od lo²eg pona²anja korisni£kih programa, od su²tinskog je zna£aja
da korisni£ke aplikacije nakon generisanja zamke, uvek dospeju na unapred
denisanu adresu - nikako se ne sme dozvoliti skok na proizvoljnu adresu
unutar kernela. Operativni sistemi omogu¢avaju znatan broj sistemskih
poziva. Primeri uklju£uju one za uspostavljanje veze sa web serverom, sla-
nje ili primanje paketa preko mreºe, kreiranje ili brisanje datoteka, £itanje
ili upisivanje podataka u datoteke i kreiranje novog korisni£kog procesa. U
korisni£kom programu sistemski pozivi se pozivaju ba² kao i obi£ne pro-
cedure, sa parametrima i povratnim vrednostima. Kao i kod svake dobre
apstrakcije, pozivalac se bavi samo interfejsom - on ne treba znati da ruti-
nu zapravo izvr²ava kernel, a ne biblioteka u okviru korisni£kog prostora.
Kernel vodi ra£una o svim proverama i kopiranju argumenata, izvoženju
zahtevane operacije i kopiranja svih povratnih vrednosti nazad u memoriju
procesa. Kada je kernel zavr²io sa obradom sistemskog poziva, nastavlja
se izvr²enje procesa u korisni£kom reºimu, po£ev²i od instrukcije koja sledi
odmah nakon poziva instrukcije zamke.

4.5.2 Transfer iz kernel reºima u korisni£ki reºim

Kao ²to postoji nekoliko povoda za prelazak iz korisni£kog reºima u kernel

reºim, tako postoji i nekoliko slu£ajeva kod kojih ¢e do¢i do prelaska sa kernel
reºima na reºim korisnika.

ˆ Novi proces: Da bi se pokrenuo novi proces, kernel kopira program u me-

moriju, postavlja programski broja£ na prvu instrukciju procesa, postavlja
pokaziva£ steka na po£etnu adresu korisni£kog steka i prebacuje se u ko-
risni£ki reºim.

ˆ Nastavak rada nakon izuzetka, prekida ili sistemskog poziva: Kada kernel
zavr²i obradu zahteva, nastavlja izvr²avanje prekinutog procesa vra¢anjem
 27

njegovog sa£uvanog programskog broja£a, kao i vra¢anjem njegovih vred-

nosti registara i ponovnim aktiviranjem korisni£kog reºima.

ˆ Prebacivanje na drugi proces: U nekim slu£ajevima, na primer nakon pre-

kida tajmera, kernel ¢e odlu£iti da li treba da preže na drugi proces,
umesto da nastavi izvr²avanje onog koji se izvr²avao pre prekida. Budu¢i
da ¢e kernel, pre ili kasnije, ºeleti da nastavi prekinuti proces, on mora da
sa£uva stanje procesa (njegov programski broja£, njegove registre, ...) u
kontrolnom bloku procesa. Kernel moºe zatim nastaviti sa izvr²avanjem
drugog procesa, u£itavanjem u procesor sa£uvanog stanja (programskog
broja£a, registara, ... ) iz kontrolnog bloka novog procesa, nakon £ega se
prebacuje u reºim korisnika.

ˆ Asinhrono obave²tavanje korisni£kih procesa: Mnogi operativni sistemi

pruºaju korisni£kim programima mogu¢nost da primaju asinhrono oba-
ve²tavanje o dogažajima. Mehanizam, koji ¢emo kasnije detaljnije opisati,
vrlo je sli£an obraživanju prekida u reºimu kernela, sa izuzetkom ²to se
ovi dogažaji obražuju u korisni£kom reºimu.

4.5.3 Bezbedna zamena reºima rada

Bez obzira da li se radi o prelasku iz korisni£kog u kernel reºim, ili suprot-

no, treba voditi ra£una da nijedan korisni£ki program ne moºe o²tetiti kernel.
Iako je osnovna ideja jednostavna, implementacija ovoga na niºem nivou moºe
biti veoma zahtevna. šelimo da procesor sa£uva svoje stanje i zameni ono ²to
radi, a sve to dok nastavlja da izvr²ava instrukcije koje potencijalno mogu pro-
meniti stanje koje se upravo £uva. Analogija ovome bi bila popravka menja£a
automobila dok se on kre¢e brzinom od 100 km/h.
Ovaj prelazak iz jednog u drugi reºim rada mora biti paºljivo projektovan,
oslanjaju¢i se na odreženu hardversku podr²ku. Da bi smanjili mogu¢nost gre-
²ke, ve¢ina operativnih sistema ima zajedni£ku sekvencu instrukcija za ulaz u
kernel reºim (bilo zbog prekida, izuzetaka ili sistemskih poziva) i zajedni£ki niz
instrukcija za povratak u korisni£ki reºim, opet nezavisno od uzroka. U najma-
nju ruku, ova zajedni£ka sekvenca mora da obezbedi:

ˆ Ograni£en ulaz ( Limited entry ) - Da biste preneli kontrolu na kernel opera-

tivnog sistema, hardver mora osigurati da je ulazna ta£ka u kernel upravo
ona koja je odrežena i postavljena od strane kernela. Korisni£kim progra-
mima nije dozvoljeno da ska£u na proizvoljne lokacije u okviru kernela. Na
primer, kod kernela za rukovanje sistemskim pozivom za £itanje datoteke
prvo ¢e proveriti da li korisni£ki program ima dozvolu za to, a ako ne,
kernel vra¢a gre²ku. Bez ograni£enih ulaznih ta£aka u kernel, zlonamerni
program bi mogao jednostavno presko£iti odmah nakon koda za prove-
ru prava, omogu¢avaju¢i svakom korisniku pristup bilo kojoj datoteci u
okviru fajl sistema.

ˆ Atomi£ke promene stanja procesora - U korisni£kom reºimu, programski

broja£ i pokaziva£ na stek pokazuju na memorijske lokacije u korisni£kom
 28

procesu. Za²tita memorije spre£ava korisni£ki proces da pristupi bilo kojoj

memoriji izvan svoje zone memorije. U kernel reºimu, programski broja£ i
stek pokaziva£ pokazuju na memorijske lokacije u okviru kernel-a. U ovom
slu£aju, za²tita memorije se menja kako bi se kernelu omogu¢io ne samo
pristup sopstvenim podacima, ve¢ i podacima korisni£kog procesa. Prelaz
izmežu ova dva mora biti atomi£ki, obezbežuju¢i istovremenu promenu
reºima, programskog broja£a, steka i za²tite memorije.

ˆ Transparentno izvr²enje koje se moºe ponovo pokrenuti - Proces koji se iz-

vr²ava na korisni£kom nivou ( user-level process ) moºe biti prekinut u bilo
kojem trenutku, izmežu bilo koje dve instrukcije. Na primer, procesor je
mogao izra£unati memorijsku adresu, u£itati je u registar i spremiti se za
£uvanje podatka na toj adresi. Klju£no za sistem prekida je da operativ-
ni sistem mora biti u stanju da rekonstrui²e stanje korisni£kog programa
upravo onako kako je bilo pre prekida. Za korisni£ki proces, prekid je pot-
puno transparentan, osim ²to on privremeno odlaºe izvr²avanje programa.
Pisanje Hello world! programa ne bi trebalo da vodi ra£una o prekidima
koji bi se mogli desiti dok se on izvr²ava, iako ¢e se prekidi vrlo verovatno
desiti dok se on izvr²ava. Stoga, prilikom prekida, procesor £uva trenutno
stanje procesa u memoriji, privremeno odlaºe sve ostale dogažaje i po-
stavlja procesor da se izvr²ava u reºimu kernela, pre nego ²to presko£i
na obradu prekidne rutine ili rutine za obradu izuzetka. Kada se rutina
zavr²i, koraci se vr²e u suprotnom smeru: procesor se vra¢a u prethodno
stanje u skladu sa sa£uvanim podacima, i prekinuti program nastavlja da
se izvr²ava tamo gde je stao.