12. Karakteristike sistema za rad u realnom vremenu

Transcript

1 12. Karakteristike sistema za rad u realnom vremenu - Osnovni koncepti sistema za rad u realnom vremenu - Kao što smo napomenuli RTS-ovi se grubo dele na hard i soft. RT aplikacije pokrivaju širok opseg aplikacija, a ono što je najvažnije je to da najveći broj RTS-ova danas upravo embedded tipa. RT softverske aplikacije je obično teže projektovati u odnosu na ne-rt aplikacije. U tekstu koji slede opisaćemo u kratkim crtama neke osnovne koncepte rada RTS-ova Foreground-Background sistemi Mikroračunarski sistemi se danas uglavnom realizuju kao mali sistemi niske-složenosti i u opštem slučaju su projektovani tako da rade kako je to prikazano na slici 1. Slika 1. Foreground-Background sistemi Ovakve sisteme nazivamo foreground-background sistemi, ili tzv. super-loops sistemi. Standardno, aplikaciju kod ovakvih sistema čini beskonačna petlja koja poziva module (tj. funkcije). Pri tome moduli obavljaju željene operacije u background režimu rada. Sa druge strane, ISR-ovi manipulišu sa asinhronim događajima u foreground režimu rada. Foreground se naziva interrupt-level, a background task-level. Kritične operacije se obavljaju od strane ISR-ova, kako bi se pri tome zadovoljili zahtevi u pogledu vremena izvršenja. Informacija koja je potrebna background modulu priprema se od strane ISRa. Background modul se neće izvršiti sve dok mu ne dođe red, tj. vreme za njegovo izvršenje (task-levelresponse). Najgori vremenski task-level-response zavisi od vremena izvršenja background petlje. S obzirom da vreme izvršenja tipičnog programa kod foreground-background sistema nije konstantno, to znači da i vreme prolaska kroz sukcesivne iterativne prolaze u petlji neće biti determinističko. Šta više, ako se promeni kod, promeniće se i tajming petlje. Najveći broj mikrokontrolerski baziranih aplikacija danas, kakve su mobilni telefoni, mikrotalasne peći, igračke i dr., su projektovane kao foreground-background sistemi. Kod mikrokontrolerskih aplikacija, prvenstveno sa aspekta potrošnje energije, što je od izuzetne važnosti kod baterijski napajanih uređaja, bolje je u background režimu zaustaviti (halt) rad procesora, a svo procesiranje obavljati u okviru ISR-a.

2 12.2 Kritične sekcije koda Kritična sekcija koda, nazvana critical region, je kod koga treba tretirati kao celinu koja se ne može deliti. Nakon što izvršenje kritične sekcije koda počne njeno izvršenje se ne može prekidati. Obično se ovo ostvaaruje na sledeći način: Pre početka izvršenja kritične sekcije brane se prekidi, a nakon izvršenja njihov rad se ponovo dozvoljava Resursi Resurs je bilo koja celina koja se koristi od strane zadatka. Resurs može biti neki U/I uređaj, kakav je recimo štampač, tastatura, displej, promenljiva, struktura podataka, polje podataka (1D, 2D), i dr Deljivi resursi Deljivi resurs je resurs koji se može koristiti od strane većeg broja zadataka (tasks). U cilju zaštite podataka svaki zadatak može da dobije isključivo pravo pristupa nad tim resursom. Ovaj proces se naziva mutual exclusion Multitasking Multitasking je proces planiranja-izvršenja (scheduling) i komutiranja (switching) CPU-a između nekoliko zadataka. CPU može da komutira između nekoliko sekvencijalnih zadataka. Multitasking podseća na foreground-background režim rada sa većim brojem background-a. Multitasking maksimizira korišćenje CPU-a i omogućava modularno kreiranje aplikacija, pa se kao tehnika veoma često koristi kod real-time aplikacija Zadaci Zadatak (task) je jedinstvena programska celina koja vidi CPU kao svoju privatnost. Praksa je da se kod real-time aplikacija ukupan posao deli na veći broj zadataka pri čemu je svaki od zadataka zadužen za rešavanje dela problema. Svakom zadatku je dodeljen prioritet, sopstveni skup CPU-ovih registara, i sopstvena oblast magacina (vidi sliku 2). Tipično svaki zadatak predstavlja jedna beskonačna programska celina (petlja), pri čemu se zadatak može naći u jednom od sledećih pet stanja: dormant, ready, running, waiting (na događaj), ili ISR (tj. prekid), kako je to prikazano na slici 3.

3 Slika 2. Veći broj (multipl) zadataka Slika 3. Stanja zadatka Stanje dormant odgovara zadatku koji se nalazi u memoriji, ali nije dostupan multitasking kernelu. Zadatak je u stanju ready kada može da se izvrši, ali je njegov prioritet niži od zadatka koji se tekuće izvršava. Zadatak je u stanju running kada ima pravo upravljanja nad CPU-om. Zadatak je u stanju waiting kada čeka na pojavu nekog događaja (na primer, čeka na završetak U/I operacije, dostupnost deljivog resursa, pojavu tajming impulsa, na istek vremena). Konačno, zadatak je u stanju ISR kada se javi prekid i procesor uđe u stanje opsluživanja prekida.

4 12.7 Kontekst komutacija (ili komutacija zadataka) Kada multitasking kernel odluči da izvrši neki drugi zadatak, on smešta tekuće stanje context-a (CPU-ovih registara) u tekuću context memorijsku oblast - magacin (vidi sliku 2). Nakon obavljanja ove operacije context novog zadatka se izbavlja iz magacina i nastavlja sa izvršenjem koda novog zadatka. Ovaj proces se naziva kontekst-komutacija ili komutacija-zadataka. Kontekst-komutacija unosi režijsko vreme (overhead) u aplikaciju. Što je broj CPU-ovih registara veći to je i režijsko vreme veće Kernel Kernel je deo multitasking sistema koji je odgovoran za upravljanje zadacima (tj. upravljanje CPU-ovim vremenom) i komuniciranje sa zadacima. Osnovna usluga koju pruža kernel je kontekstkomutacija. Naravno da pozivanje kernela unosi režijsko vreme, koje kod najvećeg broja sistema iznosi od 2% do 5% CPU-ovog vremena. Za instaliranje kernela potreban je dodatni RAM i ROM prostor (potreban za čuvanje struktura podataka potrebnih kernelu, svakom zadatku je potreban poseban magacin, tj. RAM prostor). Mikrokontroleri na čipu, zbog malog obima on-chip RAM-a obično ne podržavaju rad kernela. U principu, kernel obezbeđuje bolje korišćenje CPU-a putem pružanja raznih usluga kakve su upravljanje semaforima, mailbox-ovima, redovima čekanja, i vremenskim kašnjenjima. Kada projektant jedanput odluči da koristi kernel on se više nikada ne vraća na foreground-background sistem Planeri Planer (scheduler), često nazvan dispatcher, je deo kernela koji je odgovoran za određivanje koji će se zadatak kao naredni izvršavati. Najveći broj kernela se bazira na konceptu prioriteta. U zavisnosti od važnosti svakom zadatku se dodeljuje prioritet, pri čemu je taj prioritet aplikaciono specifičan. Kod kernela baziranog na prioritetu radom CPU-a upravlja zadatak koji je u stanju running iz razloga što ima najviši prioritet. Dva tipa kernela koji svoj rad baziraju na prioritetu egzistiraju na tržištu, a to su: non-preemptive - kernel bez istiskivanja i preemptive - kernel sa istiskivanjem Non-preemptive kerneli Kod non-preemptive kernela svaki zadatak obavlja određenu aktivnost kako bi stekao isključivo pravo upravljanja nad CPU-om. Non-preemptive-no planiranje-izvršenja (schedulind) često se naziva cooperative scheduling (to je slučaj kada zadaci međusobno sarađuju kako bi delili CPU). Asinhroni događaji kod non-preemptive kernela se obrađuju od strane ISR-ova. ISR može određenom zadatku da dodeli najviši prioritet i da ga postavi u stanje ready, no ISR nakon svog završetka uvek ponovo vraća pravo upravljanja nad CPU-om prekinutom zadatku. Zadatak sa najvišim prioritetom stiče pravo upravljanja nad CPU-om samo kada tekući zadatak preda CPU. Profil izvršenja non-preemptive kernela prikazan je na slici 4, a opisuje se na sledeći način: S.4(1) Zadatak koji se izvršava se prekida. S.4(2) Ako su prekidi dozvoljeni, CPU skače na izvršenje ISR-a. S.4(3) ISR obrađuje događaj i postavlja zadatak sa najvišim prioritetom u stanje ready čime zadatak postaje spreman za izvršenje. S.4(4) Nakon završetka ISR-a, izvršenjem naredbe Return From Interrupt, CPU se vraća na izvršenje prekinutog zadatka. S.4(5) Izvršenje prekinutog zadatka se nastavlja sa lokacije koja je sledila nakon prekinute instrukcije. S.4(6) Nakon završetka zadatka, poziva se kernel koji dodeljuje CPU drugom zadatku.

5 S.4(7) Kernel vidi koji ready zadatak ima najviši nivo prioriteta i obavlja kontekst komutaciju ka tom zadatku. Slika 4. Non-preemptive kernel Task-level response kod non-preemptive kernela je znatno kraće u odnosu na ono kod foregroundbackground sistema jer task-level response u najgorem slučaju zavisi od vremena izvršenja najdužeg zadatka. Ozbiljan nedostatak non-preemptive kernela je nepredvidljivost odziva. Naime, zadatak koji je u stanju ready, a ima najviši nivo prioriteta, mora da čeka sve dok zadatak koji se tekuće izvršava ne završi. To znači da je task-level response time nedeterminističko Preemptive kerneli Preemptive kerneli se koriste tamo gde je odziv sistema veoma važan. Zadatku koji je u stanju ready, a čiji je prioritet najviši, uvek se daje pravo upravljanja nad CPU-om. Naime, ako u toku izvršenja tekućeg zadatka egzistira zadatak u stanju ready čiji je prioritet viši tekući zadatak se istiskuje (suspenduje), i zadatak čiji je nivo prioriteta viši dobija pravo upravljanja nad CPU-om. Kada ISR kreira ready zadatak sa višim nivoom prioriteta, nakon završetka ISR-a, prekinuti zadatak se suspenduje, a novi zadatak višeg prioriteta počinje da se izvršava. Profil izvršenja preemptive kernela je prikazan na slici 5, i opisan je na sledeći način: S.5(1) Zadatak koji se izvršava se prekida. S.5(2) Ako su prekidi dozvoljeni, CPU skače na izvršenje ISR-a. S.5(3) ISR obrađuje događaj i postavlja zadatak sa višim prioritetom u stanje ready čime zadatak postaje spreman za izvršenje. Nakon završetka ISR-a, poziva se usluga koju treba da pruži kernel (tj. poziva se funkcija koju treba da pruži kernel). S.5(4) S.5(5) Funkcija zna da je najvažniji zadatak ready (spreman) za izvršenje, pa umesto da se obavi povratak na prekinuti program, kernel obavlja kontekst komutaciju i izvršava kod najvažnijeg zadatka. Kada se najvažniji zadatak izvrši, poziva se funkcija kernela koja postavlja zadatak u stanje waiting na događaj (tj. da se pojavi novi ISR). S.5(6) S.5(7) Kernel vidi da zadatak nižeg prioriteta treba da se izvrši, ovavlja kontekst komutaciju i nastavlja sa izvršenjem prekinutog zadatka.

6 Slika 5. Preemptive kernel Kod preemptive kernela vreme izvršenja zadatka čiji je prioritet najviši je determinističko, što znači da je task-level response time minimizirano Reentrant funkcije Reentrant funkcija se može koristiti od strane većeg broja zadataka više puta bez bojazni da dođe do narušavanja integriteta podatka. Reentrant funkcije mogu da koriste lokalne promenljive (registri CPU-a ili promenljive u magacinu) ili da štite podatke kada se koriste globalne promenljive. Primer reentrant funkcije je dat u Listingu 1. Listing 1. Reentrant funkcija S obzirom da se kopije argumenata od strcpy() smeštaju u magacin zadatka, strcpy() se može pozvati od strane većeg broja zadataka bez bojazni da će zadaci međusobno narušiti svoje pokazivače. Primer non-reentrant funkcije dat je Listingom 2. U konkretnom slučaju swap() je jednostavna funkcija koja međusobno menja sadržaj svoja dva argumenta. Pri ovoj diskusiji usvojeno je da se koristi preemptive kernel, da je rad prekidima dozvoljen, i da je Temp deklarisana kao globalni integer. Listing 2. Non-reentrant funkcija

7 Programer namerava da učini swap() korisnim za bilo koji zadatak. Na slici 6 je prikazano šta može da se desi ako u toku izvršenja swap() dođe do prekida zadatka čiji je nivo prioriteta viši. Slika 6. Non-reentrant funkcija Scenario događaja prikazan na slici 6 je sledeći: S.6.(1) Kada se swap() prekine Temp sadrži 1. S.6.(2) S.6.(3) ISR dovodi da zadatak višeg prioriteta bude u stanju ready, tako da nakon završetka ISR-a poziva se kernel i vrši komutacija novih zadataka. Zadatak višeg prioriteta postavlja Temp na vrednost 3, a zatim međusobno menja sadržaj svojih promenljivih na korektan način, tj. z = 4, t = 3. S.6.(4) Zadatak višeg prioriteta predaje upravljanje zadatku nižeg prioriteta pozivom kernel uslužne rutine OSTimeDly. S.6.(5) Zadatak nižeg prioriteta nastavlja sa izvršenjem. Uočimo da je u ovoj tački Temp = 3. Kada zadatak nižeg prioriteta nastavi sa izvršenjem imaćemo y = 3, umesto da y bude jednako 1. Naglasimo da je ovaj primer jednostavan, pa se nameće potreba da se swap() učini da bude reentrant. To se može uraditi na jedan od sledećih načina: deklarisati Temp kao lokalnu za swap() zabraniti prekid pre operacije i dozvoliti ga nakon nje koristiti semafor koristiti druge tehnike (na ove detalje se nećemo zadržavati jer izučavanje ove problematike izlazi iz okvira ovog predmeta). U svakom slučaju primenom bilo koje od tri pomenute tehnike obezbeđeno je da se u slučaju kada se javi prekid pre ili posle swap(), vrednosti x i y za oba zadatka budu korektne Round-Robin planiranje-izvršenja Kada dva ili veći broj zadataka imaju isti prioritet, kernel omogućava jednom zadatku da se izvršava za unapred-određen iznos vremena, nazvan quantum, a zatim selektuje drugi zadatak. Ovaj proces se naziva round-robin scheduling ili time-slicing. Kernel predaje upravljanje narednom zadatku u redu čekanja ako: tekući zadatak nema šta da radi u svom time-slice-u, ili tekući zadatak je završio pre kraja svog time-slice-a, ili istekao je time-slice

8 12.14 Prioritet zadataka Svakom zadatku se dodeljuje prioritet. Što je zadatak važniji njegov prioritet je viši. Kod najvećeg broja kernela, projektant odlučuje kom zadatku kakav će prioritet dodeliti Statički prioritet Ako se u toku izvršenja aplikacije prioritet zadatka ne menja tada kažemo da je prioritet statički. To znači da se u fazi kompilacije svakom zadatku dodeljuje fiksni prioritet. Svi zadaci i njihova tajming ograničenja su, u ovom slučaju, poznata u fazi kompilacije pa su zbog toga prioriteti statički Dinamički prioriteti Ako se u toku izvršenja aplikacije prioritet zadataka ne menja, tada kažemo da je njihov prioritet dinamički Inverzija prioriteta Inverzija prioriteta je problem koji se javlja kod RTS-ova, u situacijama kada se koristi RTK (Real Time Kernel). Na slici 7 prikazan je scenario inverzije prioriteta. Task 1 ima viši prioritet u odnosu na Task 2, a ovaj viši u odnosu na Task 3. Slika 7. Problem inverzije prioriteta Scenario događaja je sledeći: S.7.(1) Oba zadatka Task 1 i Task 2 čekaju da se javi događaj, a izvršava se Task 3. S.7.(2) U nekoj tački Task 3 pribavlja semafor, koji je potreban zadatku pre nego što pristupi deljivom resursu. S.7.(3) Task 3 obavlja neke operacije nad zahvaćenim resursom. S.7.(4) Događaj na koji čeka Task 1 se javio, kernel suspenduje Task 3 i počinje sa izvršenjem Task 1 jer je prioritet Task 1 viši.

9 S.7.(5) S.7.(6) Task 1 se izvršava u while petlji i pokušava da pristupi resursu (tj. on pokušava da promeni semafor koji je sopstvenost Task-a 3). Pošto Task 3 poseduje resurs, Task 1 se smešta u listu waiting zadataka kernela i čeka da se oslobodi semafor. S.7.(7) S.7.(8) Task 3 nastavlja sa izvršenjem sve dok ga ne istisne Task 2, tj. pojava događaja na koga čeka Task 2. S.7.(9) S.7.(10) Task 2 obrađuje događaj na koga je čekao, i kada završi sa obradom kernel oslobađa CPU i predaje ga Task 3. S.7.(11) S.7.(12) Task 3 završava rad sa resursom i oslobađa taj resurs. U ovom trenutku kernel zna da zadatak najvišeg prioriteta čeka na semafor, obavlja kontekst komutaciju, tako da se nastavlja sa izvršenjem Task 1. S.7.(13) U ovom trenutku Task 1 poseduje semafor i može da pristupi deljivom resursu. Prioritet Task 1 je virtuelno redukovan u odnosu na Task 3 iz razloga što Task 1 je morao da čeka na oslobađanje resursa koji je bio u tom trenutku u vlasništvu Task 3. Ova situacija je bila pogoršana kada je Task 2 istisnuo Task 3, čime se još više zakasnilo sa izvršenjem Task 1. Ova situacija se može korigovati povećanjem prioriteta Task 3, pre nego što pristupi resursu, a zatim da se obnovi prvobitno dodeljeni prioritet kada zadatak završi. Prioritet Task 3 treba povećati na nivo do ili iznad zadatka najvišeg prioriteta koji se takmiče za taj resurs. Multitasking kernel omogućava dinamičku promenu prioriteta zadataka čime se brani (štiti) od inverzije prioriteta. Ipak, za promenu prioriteta zadatka potrebno je neko vreme. Šta će se desiti ako je Task 3 završio pristup resursu pre nego što će biti istisnut od strane Task 1, a zatim od strane Task 2? Kada se pre pristupa resursu poveća prioritet Task 3, a nakon završetka zadatka se smanjuje, tada se gubi dosta od dostupnog CPU-ovog vremena. Da bi se izbegao efekat inverzije prioriteta kernel je taj koji automatski treba da promeni prioritet, koji se naziva priority inheritance, a to se obično izvodi pomoću mutual exclusion semaphores. Na slici 8 prikazan je scenario koji se odnosi na to kako kernel podržava priority inheritance. Slika 8. Kernel koji podržava priority inheritance

10 Scenario događaja je sledeći: S.8.(1) S.8.(2) Kao i u prethodnom primeru izvršava se Task 3, i istovremeno zahvata mutual exclusion semaphore (nazvan mutex) kako bi se pristupilo deljivom resursu. S.8.(3) S.8.(4) Task 3 pristupa resursu, a nakon toga istiskuje Task 1. S.8.(5) S.8.(6) Izvršava se Task 1 i pokušava da se dobije mutex. Kernel vidi da Task 3 poseduje mutex i zna da Task 3 ima niži nivo prioriteta u odnosu na Task 1. U ovom slučaju, kernel povećava prioritet Task 3 na isti nivo kao i Task 1. S.8.(7) Kernel postavlja Task 1 u mutex waiting listu a zatim nastavlja sa izvršenjem Task 3 tako da on može da produži sa korišćenjem resursa. S.8.(8) Kada je Task 3 završio sa resursom, on oslobađa resurs. U tom trenutku kernel redukuje prioritet Task 3 na prvobitnu vrednost i analizira mutex waiting listu kako bi ustanovio da li postoji zadatak koji čeka na mutex. kernel vidi da Task 1 je waiting i predaje mu mutex. S.8.(9) Task 1 je sada slobodan da pristupi resursu. S.8.(10) S.8.(11) Kada Task 1 završi sa izvršenjem, zadatak srednjeg prioriteta Task 2, dobija pravo upravljanja nad CPU-om. Naglasimo da je Task 2 bio ready za izvršenje od trenutka S.8.(3) do S.8.(10) bez da ima uticaja na krajnji ishod (outcome). Neki od nivoa priority inversion se ne mogu izbeći, ali su oni daleko manje izraženi nego u prethodnom scenariju Dodela prioriteta zadacima Dodela prioriteta zadacima nije trivijalna aktivnost, prvenstveno zbog složene prirode RTS-a. Kod najvećeg broja mikroračunarskih sistema, koji se koriste danas, svi zadaci nisu kritični sa aspekta vremena izvršenja, pa se zbog toga njima dodeljuje nizak nivo prioriteta. Veći broj RTS-ova karakteriše kombinacija soft i hard zahteva. Kod soft RTS-ova zadaci se izvršavaju što je moguće pre, ali oni ne mora da završe za neko specifično vreme. Kod hard RTS-ova zadaci mora da se izvrše korektno i na vreme. Za dodelu prioriteta zadacima koriste se brojne tehnike, ali njihovo izučunavanje izlazi iz okvira materije koja treba da se savlada ovim predmetom. Mi ćemo se ograničiti samo na jednu tehniku nazvanu rate monotonic scheduling (RMS), kod koje se dodela priooriteta vrši u odnosu na to koliko se često zadaci izvršavaju. Jednostavno kazano, zadacima koji se najčešće javljaju dodeljije se najviši prioritet opsluživanja (vidi sliku 9) Uzajamna isključivost Slika 9. Dodela prioriteta zadacima u odnosu na učestanost pojavljivanja Zadaci na najjednostavniji način komuniciraju medjusobno preko deljivih struktura podataka. Ova aktivnost se lako izvodi kada zadaci dele jedinstveni adresni prostor i kada mogu da se obraćaju

11 elementima kakvi su globalne promenljive, pokazivači, baferi, povezane liste, i kružni baferi. I pored toga što deljivi podaci pojednostavljuju razmenu informacije, neophodno je radi izbegavanja sudara (contention) i narušavanja integriteta podataka (data corruption), svakom zadatku obezbediti isključivo pravo upravljanja nad tim podacima. Najčešći metodi koji se koriste da se ostvari isključivo pravo pristupa deljivim resursima su: zabrana rada prekidima (disabling interrupts) izvršenje test-and-set operacije, zabrana planiranja izvršenja (disabling scheduling), i korišćenje semafora Zabrana i dozvola rada prekidima Najlakši i najbrži način da se ostvari isključivo pravo pristupa nad deljivim resursom se ostvaruje preko zabrane i dozvole rada prekidima (vidi Listing 3). Listing 3. Zabrana i dozvola rada prekidima Treba pri korišćenju ove tehnike biti pretpazljiv i ne zabraniti rad prekidima na duži period, jer u suštini ovaj pristup ima uticaj na interrupt latency. Ovaj metod je pogodan kada treba promeniti ili kopirati nekoliko promenljivih Test-and-Set operacije Kada se ne koriste usluge kernela, tada dve funkcije koje pristupaju deljivom resursu mora da se slože oko toga na koji način će pristupati tom resursu. Obično se pristup resursu izvodi proverom stanja jedne globalne promenljive. Ako je stanje globalne promenljive 0 tada funkcija može pristupiti resursu. Da bi se zaštitili od toga da i druga funkcija ne pristupa resursu, prva funkcija koja je dobila pravo upravljanja nad resursom postavlja globalno promenljivu u stanje 1. Ova aktivnost se obavlja izvršenjem operacije test-and-set (TAS). Operacija TAS može da obavi kao nedeljiva-operacija, ili preko zabrane rada prekida kako je to prikazano u Listingu 4 Listing 4. Korišćenje TAS radi pristupa resursu Neki od procesora, kakvi su Motorola MC 68xxx, Intel x86, i drugi, direktno, u hardveru, imaju implementirano operaciju TAS.

12 12.22 Zabrana i dozvola rada scheduler-u Ako zadatak ne deli promenljive ili strukture podataka sa ISR-om, tada je moguće dozvoliti ili zabraniti rad scheduler-u (planeru izvršenja) kako je to prikazano u Listingu 5 (izvodi se tehnikom Locking i Unlocking scheduler-a) Listing 5. Pristup deljivoj promenljivoj zabranom i dozvolom rada scheduler-a. U ovom slučaju, dva ili veći broj zadataka mogu da dele podatke bez mogućnosti da dodje do sudara. Treba, pri ovome, naglasiti da dok je scheduler zaključan (locked) rad prekidima je dozvoljen, tako da ako se javi prekid kada je zadatak u kritičnoj sekciji, tada se ISR trenutno izvršava. Na kraju ISRa, kernel uvek vraća pravo upravljanja prekinutom zadatku, čak i u slučaju kada je ISR uzrokovala da zadatak višeg nivoa prioriteta bude ready za izvršenje. S obzirom da kernel vraća pravo upravljanja prekinutom zadatku, ponašanje kernela je slično non-preemptive kernelu (čak i za slučaj da je scheduler zaključan (tj. blokiran ili locked)) Semafori Semafor je protokol mehanizam koji se nudi od strane najvećeg broja multitasking kernela sa ciljem da: kontroliše pristup deljivom resursu (mutual exclusion) signalizira na pojavu dogadjaja, i omogućava da dva zadatka sinhronizuju svoje aktivnosti Semafor predstavlja ključ koga kôd (kôd zadatka) čuva sa ciljem da produži sa svojim izvršenjem bez da bude prekidan. Kada se semafor koristi, zadatak koji zahteva pristup deljivom resursu se suspenduje sve dok se semafor ne oslobodi od strane onog zadatka koji ga tekuće poseduje. Postoje dva tipa semafora: binarni i brojački. Binarni semafor može da prima vrednosti 0 ili 1. Brojački semafor, u zavisnosti da li je implementiran nad 8, 16 ili 32 bita, može da prima vrednosti 255, , ili Stvarni obim podatka sa kojim manipuliše semafor zavisi od kernela. U principu postoje tri operacije koje se mogu obaviti nad semaforom: INITIALIZE (takodje nazvana operacija CREATE), WAIT (nazvana PEND), i SIGNAL (nazvana POST). Inicijalna vrednost semafora mora da se definiše u trenutku inicijalizacije semafora. Inicijalno, waiting lista zadataka je prazna. Zadatak koji želi da pristupi semaforu obavlja operaciju WAIT. Ako je semafor dostupan (vrednost semafora veća od 0), tada se vrednost semafora dekrementira, a zadatak koji je zahtevao semafor produžava sa izvršenjem. Za slučaj de je vrednost semafora bila 0 tada zadatak obavlja operaciju WAIT nad semaforom, a kernel smešta zadatak u waiting listu. Najveći broj kernela omogućava da se specificira timeout. To znači da ako semafor nije bio dostupan u okviru odredjenog vremenskog perioda tada zadatak koji je zahtevao pristup deljivom resursu prelazi u stanje run, a onom koji je izdao poziv (caller) signalizira da je došlo do greške (istekao je timeout). Zadatak koji oslobadja semafor obavlja operaciju SIGNAL. Ako nema zadatak koji čeka na semafor tada se vrednost semafora inkrementira. Ako pak bilo koji zadatak čeka na semafor, tada jedan

13 od zadataka prelazi u stanje run, vrednost semafora se ne inkrementira; tj, ključ se predaje jednom od zadataka koji na njega čeka. U zavisnosti od kernela, zadatak koji prima semafor može biti: zadatak sa najvišim prioritetom koji čeka na semafor, ili prvi zadatak koji je zahtevao semafor (FIFO koncept) Neki od kernela imaju mogućnost da u toku faze inicijalizacije biraju koji će od oba pristupa implementirati. Listing 6, ilustracije radi, prikazuje na koji način se može pristupiti deljivim podacima koristeći semafor. Zadatak koji treba da pristupi deljivim podacima poziva OSSemPend(), a kada zadatak manipuliše podacima poziva se OSSemPost(). Listing 6. Pristup deljivim podacima pomoću semafora Korišćenje semafora je posebno pogodno kada zadaci dele U/I uredjaje. Zamislimo sada šta će se desiti ako dva zadatka, u istom trenutku, pokušaju da pošalju podatke štampaču. Štampač će naizmenično primati podatke od svakopg zadatka. Tako na primer, ako prvi zadatak treba da odštampa Ja sam zadatak 1! a drugi zadatak treba da odštampa Ja sam zadatak 2!, tada u zavisnosti od scenario dogadjaja može da se desi da štampač odštampa J Ja samm Z Zadatak k1! k2!. Kada je semafor binarni, da ne bi došlo do konflikta, neophodno je da kada je resurs zauzet semafor da bude postavljen na vrednost 1. U konkretnom slučaju, da bi upravljao radom štampača, svaki od zadataka mora prvo da dobije pravo upravljanja nad semaforom. Na slici 10 prikazano je kako se zadaci takmiće za semafor, sa ciljem da dobiju isključivo pravo upravljanja nad štampačem. Uočimo da je semafor na simbolički način predstavljen ključem, što znači da onaj zadatak koji poseduje ključ može da koristi štampač.

14 Slika 10. Korišćenje semafora da bi se dobila dozvola pristupa štampaču Primer sa slike 10 ukazuje da svaki zadatak mora da ima spoznanje o egzistenciji semafora kako bi pristupio resursu. Kod nekih rešenja bolje je enkapsulirati semafor. Pri tome, svaki zadatak trebalo bi da zna da u trenutku pristupa resursu on je taj koji je zahvatio semafor. Ilustracije radi, RS-232C port se može koristiti od strane većeg broja zadataka za potrebe slanja komandi i prijema odziva od uredjaja koji je povezan na drugom kraju veze (vidi sliku 11). Slika 11. Skrivanje semafora od zadataka Funkcija CommSendCmd() se poziva specificiranjem sledećih triju argumenata: ASCII niz koji sadrži komandu, pokazivač na niz koji se kao odziv vraća od deljivog uredjaja, i timeout za slučaj da se deljivi uredjaj ne odazove u okviru odredjenog iznosa vremena. Pseudokôd ove funkcije je prikazan Listingom 7. Listing 7 Enkapsulacija semafora

15 Svaki zadatak koji treba da pošalje komandu uredjaju mora da pozove ovu funkciju. Za semafor se usvaja da je inicijaliziran na 1 (tj, dostupan je) od strane inicijalizacine rutine komunikacionog drajvera. Prvi zadatak koji poziva CommSendCmd()kao prvo zahvata semafor, zatim produžava da šalje komandu, i na kraju čeka na odziv. Ako drugi zadatak pokuša da šalje komandu dok je port zauzet (busy), tada se drugi zadatak suspenduje dok se semafor ne oslobodi. Ponašanje drugog zadatka je sledeće: On generiše poziv (call) za izvršenje funkcije, ali se odziv ne vraća sve dok prethodna funkcija ne obavi svoju dužnost. Kada prvi zadatak oslobodi semafor, tada drugi zadatak ga zahvata i dozvoljava mu se da koristi port RS-232C. Brojački semafor se koristi kada se resurs, istovremeno može koristiti od strane većeg broja zadataka. Na primer, brojački semafor, se koristi za upravljanje buffer-port-a kako je to prikazano na slici 12. Usvojimo da inicijlno buffer-pool sadrži 10 bafera. Zadatak dobija bafer od bafer-menadžera pozivom funkcije BufReg(). Kada bafer nije više potreban, tada zadatak vraća bafer bafer-menadžeru pozivom funkcije BufRel(). Pseudokôd ovih funkcija je prikazan u Listingu 8. Slika 12. Korišćenje brojačkog semafora Listing 8. Upravlajne baferom korišćenjem semafora

16 Bafer menadžer ispunjava zahteve koji se odnose na prvih deset bafer zahteva, iz razloga što postoje samo 10 ključeva. Kada se koriste svi semafori, zahtev za dodelom bafera se suspenduje sve dok neki od semafora ne postane slobodan. Prekidi se brane kako se ne bi dozvolilo isključivo pravo pristupa povezanoj listi (linked list). Kada zadatak završava, on poziva funkciju BufRel() i vraća bafer bafermenadžeru, tj. bafer se ubacuje u povezanu listu pre nego što se semafor oslobodi. Enkapsulacija interfejsa u bafer-manadžer pomoću BufReq() i BufRel() oslobađa onaj zadatak, koji vrši poziv, od poznavanja svih detalja koji se odnose na implementaciju ove tehnike Smrtni zagrljaj Smrtni zagrljaj (deadlock ili deadly embrace) je situacija kod koje dva različita zadatka koja ne znaju jedan o drugom čekaju na resurs koga drži onaj drugi zadatak. Neka zadatak T1 ima isključivo pravo pristupa nad resursom R1, a zadatak T2 isključivo pravo pristupa nad resursom R2. Neka je zadatku T1 potebno sada isključivo pravo pristupa nad R2, a neka zadatku T2 bude potrebno isključivo pravo pristupa nad R1. Pod ovakvim uslovom dalje izvršenje ni jednog od oba zadatka ne može napredovati i kažemo da je došlo do smrtnog zagrljaja. Najjednostavniji način da se izbegne smrtni zagrljaj kod zadataka se sastoji u sledećem: zahvataju se svi resursi pre nego što se nastavi sa daljim radom, zahvataju se resursi u definidsanom redosledu, i oslobađaju se resursi u suprotnom redosledu. Najveći broj kernela specificira timeout kada se zahteva semafor. Na ovaj način se izbegava smrtni zagrljaj. Za slučaj da semafor nije dostupan u okviru određenog vremenskog perioda, zadatak koji je zahtevao resurs nastavlja sa izvršenjem. U tom slučaju, neki oblik kodirane greške je neophodno predati zadatku koji se istiskuje čime se on obaveštava o tome da je njegov timeout istekao. Povratnakodirana-greška obaveštava istisnuti zadatak da on više ne raspolaže pravom upravljanja nad resursom koga je prethodno zahvatio Sinhronizacija Zadatak se može sinhronizovati sa ISR-om (ili drugim zadatkom ako se ne razmenjuju podaci) korišćenjem semafora (vidi sliku 13). Naglasimo da se u ovom slučaju semafor tretira kao marker (flag) koji se koristi da signalizira na pojavu događaja (a ne da obezbedi uzajamnu isključivost (mutual exclusion), slučaj kada se na slikama predstavlja pomoću simbola ključ). Kada se koristi kao sinhronizacioni mehanizam, semafor se inicijalizira na vrednost 0. Korišćenje semafora kod ovakvog tipa sinhronizacije se naziva unilateral rendezvous. Tako na primer, zadatak može da inicira U/I operaciju, a zatim da čeka na promenu stanja semafora. Kada U/I operacija završi, ISR (ili drugi zadatak) signalizira (menja stanje) semafora pa zadatak može da nastavi sa daljim radom. Slika 13. Sinhronizacija zadataka i ISR-ova

17 Kada kernel podržava rad semafora brojačkog tipa, tada semafor akumulira događaje koji još nisu procesirani. Naglasimo da i više od jednog zadatka može da čeka na pojavu nekog događaja. U ovom slučaju kernel signalizira na pojavu događaja bilo da je to izvedeno kao u slučaju da: zadatak najvišeg nivoa čeka na pojavu događaja, ili prvi zadatak iz liste čekanja čeka na događaj. U zavisnosti od aplikacije više od jedne ISR ili zadatak mogu da čekaju na pojavu događaja. Kao što se vidi sa slike 14, dva zadatka mogu sinhronizovati svoje aktivnosti korišćenjem dva semafora, koje nazivamo bilateral rendezvous. Bilateral rendezvous je sličan unilateral rendezvous sa izuzetkom što oba zadatka moraju, pre nego što produže sa daljim radom, da se sinhronizuju. Bilateral rendezvous se može obaviti između zadatka i ISR-a iz razloga što ISR ne može da čeka na semafor. Tipičan primer izvršenja dva zadatka je prikazan Listingom 9. Listing 9. Bilateral rendezvous Slika 14. Zadaci sinhronizuju svoje aktivnosti Scenario događaja kod Listinga 9 je sledeći: L.10.(1) L.10.(2) Kada prvi zadatak stigne do određene tačke u programu on signalizira drugom zadatku a zatim čeka na povratni signal. L.10.(3) L.10.(4) Na sličan način, kada drugi zadatak dođe do određene tačke u programu, on signalizira prvom zadatku i čeka na povratni signal. U toj tački oba zadatka se međusobno sinhronizuju.

18 12.26 Markeri događaja Markeri događaja (event flags) se koriste kada zadaci treba da se sinhronizuju na pojavu (dešavanje) većeg broja događaja. Zadatak se može sinhronizovati kada se bilo koji od događaja javi (desi), ovo se naziva disjunctive synchronization (logička OR). Zadatak se može, takođe sinhronizovati kada se dese svi događaji, ovaj slučaj se naziva conjuctive synchronization (logička AND). Na slici 15 prikazan je princip rada disjunctive i conjuctive synchronization. Slika 15. Disjunctive i conjuctive synchronization Zajednički događaji se mogu takođe koristiti za potrebe signaliziranja većem broju zadataka (vidi sliku 16). Praksa je da se događaji obično grupišu. U zavisnosti od kernela, grupu mogu da čine 8, 16, ili 32 događaja, pri čemu se za prezentaciju pojave događaja koriisti po jedan bit. Zadaci ili ISR-ovi mogu da setuju ili resetuju bilo koji marker događaja u grupi. Zadatak nastavlja sa daljim radom kada su se svi događaji desili (markeri događaja postavljeni). Evaluacija (procena) koja se odnosi na to koji će zadatak nastaviti sa daljim radom se obavlja kada se javi novi skup događaja (tj. u toku operacije SET). Slika 16. Markeri događaja

19 12.27 Komunikacija između zadataka Često se javlja potreba da zadatak ili ISR razmenjuje informaciju sa drugim zadatkom. Ovakav tip prenosa informacija se naziva intertask communication. Pri tome, razmena informacije između zadataka se može ostvariti na jedan od sledeća dva načina: a) prenos preko globalno promenljivih podataka (global data), ili b) putem slanja poruka (sending messages). Kada se za potrebe prenosa koriste globalne promenljive, tada svaki zadatak ili ISR mora da ostvari (ima) isključivo pravo pristupa nad tom promenljivom. Kada se koristi ISR, jedini način da se ostvari isključivo pravo pristupa deljivoj promenljivoj postiže se putem zabrane rada prekidima. Sa druge sttrane, ako dva zadatka dele podatke, tada svaki od njih može da ima isključivo pravo pristupa nad tim podacima, bilo da se to postiže zabranom ili dozvolom rada prekidima, bilo putem korišćenja semafora. Naglasimo da zadatak jedino može da prenese informaciju ISR-u preko globalno promenljivih. Pri tome zadatak nije svestan kada se globalna promenljiva promenila od strane ISR-a, osim ako ISR ne signalizira zadatku na tu promenu putem korišćenja semafora, ili ako zadatak tu promenu ne uoči putem čestog periodičnog testiranja sadržaja te promenljive. Da bi se, ipak na zadovoljavajući način, korigovali pomenuti nedostaci kernel obično koristi tehnike koje su bazirane na message mailbox ili message queue Message mailbox-ovi Poruke se mogu slati zadatku preko servisa (usluga) koje pruža kernel. Message mailbox, alternativno nazvan message exchange, predstavlja promenljiva tipa pokazivač. Preko usluga koje pruža kernel, zadatak ili ISR može da postavi message (pokazivač) u mailbox-u. Na sličan način, jedan ili veći broj zadataka može da prima message-e (poruke) preko usluga koje pruža kernel. Oba zadatka, onaj koji prima i onaj koji predaje, moraju da se slože oko toga na šta u suštini pokazivač ukazuje. Lista čekanja (waiting list) se pridružuje svakom mailbox-u za slučaj da više od jednog zadatka želi da prima poruke preko mailbox-ova. Zadatak koji želi da prihvati podatak iz praznog mailbox-a se suspenduje i smešta u listu čekanja sve dok se ne primi poruka (message). Obično kerneli, zadatku koji čeka na poruku dodeljuju timeout. Ako se poruka ne primi pre isteka timeout-a, zadatak koji je izdao zahtev se postavlja u stanje ready za izvršenje, a kod greške (ukazuje na to da je istekao timeout) se predaje tom zadatku sa ciljem da se ta informacija saopšti korisniku. U slučaju kada se poruka smesti u mailbox tada mogu, u zavisnosti od kernela, da se dese sledeća dva scenarija: a) poruka se predaje zadatku sa najvišim prioritetom koji čeka na tu poruku (priority based), b) poruka se predaje prvom zadatku koji je zahtevao datu poruku (FIFO pristup). Na slici 17 prikazan je način prenosa poruka preko mailbox-a. Slika 17. Mailbox poruke Kernel obično obezbeđuje sledeće mailbox usluge: inicijalizira sadržaj mailbox-a. Inicijalno mailbox može da sadrži ali i ne mora da sadrži poruku. poruka se postavlja u mailbox preko servisa POST. čekanje da se poruka izbavi iz mailbox-a se vrši preko servisa PEND. pribavljanje poruke iz mailbox-a, ako je prisutna, ali se pri tome ne suspenduje onaj zadatak koji je izvršio poziv za slučaj da je mailbox prazan vrši se preko servisa ACCEPT. Ako mailbox sadrži poruku, poruka se izbavlja iz mailbox-a.

20 Mailbox poruke mogu takođe simulirati rad binarnih semafora. Poruka u mailbox-u ukazuje da je resurs slobodan, dok prazni mailbox ukazuje da je resurs zauzet od strane drugog zadatka Message queue Message queue (red čekanja poruka) se koristi za slanje zadatku jedne ili više poruka. Message queue obično se realizuje kao polje mailbox-ova. Od strane servisa koje pruža kernel, zadatak ili ISR može da ostavi poruku u message queue. Na sličan način, jedan ili veći broj zadataka može da primi poruke preko usluga koje pruža kernel. Oba zadatka/zadaci moraju da se dogovore oko toga na šta pokazivač u suštini ukazuje. U opštem slučaju, prva poruka koja se ubacuje (smešta) u red čekanja je prva koja se izvlači iz reda čekanja (FIFO princip). Kao i kod mailbox-a, svakom message queue se pridružuje lista čekanja. Zadatak koji želi da primi poruku iz praznog reda čekanja se suspenduej i smešta u listu čekanja sve dok se poruka ne primi. Obično kernel dozvoljava zadatku da čeka na poruku za specificirani timeout. Ako se poruka ne primi pre isteka timeout-a, tada zadatak koji je izdao zahtev se postavlja u stanje ready, a kod o grešci (ukazuje da je istekao timeout) se predaje tom zadatku. Kada se poruka nalazi u redu čekanja tada se ta poruka predaje zadatku čiji je prioritet najviši, ili prvom zadatku koji je čekao na tu poruku. Na slici 18 prikazano je kako ISR smešta poruku u red čekanja. Broj "10" ukazuje na broj poruka koji se može akumulirati u red čekanja. Broj "0" ukazuje da će zadatak zauvek čekati na pristizanje poruke. Slika 18. Message queue Kernel obično pruža sledeće message queue usluge: inicijalizira red čekanja. Nakon inicijalizacije red čekanja treba da je prazan. smešta poruku u red čekanja (POST). čeka da poruka bude izbavljena iz reda čekanja (PEND). privlači poruku iz reda čekanja, ako je ima, ali ne suspenduje zadatak koji je izvršio poziv za slučaj da je red čekanja bio prazan (ACCEPT). Ako red čekanja sadrži poruku ona se izbavlja iz reda čekanja Prekidi Prekid je hardverski mehanizam koji se koristi da informiše CPU o tome da se javio asinhroni dogadjaj koji zahteva pažnju i treba da se opsluži. Kada se zahtev za prekid prizna, CPU pamti deo ili ceo svoj kontekst (tj, stanje svojih registara) u magacin i prenosi pravo upravljanja procesora (skače) na specijalni potprogram. Ovaj potprogram se naziva prekidni program, tj, ISR (Interrupt Service Routine). ISR procesira dogadjaj i nakon završetka ISR-a, izvršenje se vraća na: Background kod background/foreground sistema, prekinuti zadatak kod non-preemtive kernela, ili zadatak najvišeg prioriteta koji je ready za izvršenje kod preemtive kernela. Prekidi omogućučavaju mikroprocesoru da procesira dogadjaje samo kada se oni jave, što obezbedjuje mikroprocesoru da izbegne kontinualno testiranje stanja na liniji kojom se signalizira pojava dogadjaja (tzv permanentno testiranje se izvodi tehnikom poolling-a ili looking at), a odnosi se na to da se ustanovi da li se dogadjaj javio ili ne. Mikroprocesor ima izvedenu mogućnost da zabrani ili dozvoli rad prekidima. Kod RTS-ova prekidima treba zabraniti rad na što je moguće kraće vreme. Zabrana rada prekida ima uticaj na latenciju-prekida, koja ako je dugačka može da dovede do toga da se

21 analiza nekih hitnih dogadjaja propusti. Procesor, takodje, omogućava prekidima da se gnezde, što znači da kada se jedan prekid opslužuje, procesor može da prepozna i opsluži druge prekide (vidi sliku 19). Slika 19. Gneždjenje prekida Latencija prekida Verovatno najvažnija specifikacija RTS-a predstavlja iznos vremena za koga su prekidi zabranjeni. Svi RTS-ovi brane prekide u trenutku kada manipulišu sa kritičnim sekcijama koda i ponovo dozvoljavaju rad prekidima kada izvršenje kritičnih sekcija završi. Što je rad prekida na duže vreme zabranjen veća je i latentnost prekida (interrupt letency). Latencija prekida, IL, je definisana na sledeći način: IL = maksimalan_iznos_vremena_za_koji_su_prekidi_zabranjeni +vreme_potrebno_da_poče_izvršenje_prve_instrukcije_isr-a (1) Odziv na prekid Odziv na prekid (interrupt response) definiše se kao vreme od početka prijema zahteva za prekid do početka izvršenja koda koji obradjuje taj prekid. Vreme odziva na prekid uključuje sva režijska vremena koja prate obradu prekida. Obično kontekst procesora se smešta u magacin pre nego što se počne sa izvršenjem kôda prekidne rutine. Kod foreground/background sistema, kôd ISR-a se izvršava nepšosredno nakon pamćenja konteksta procesora. Vreme odziva je dato sledećom relacojom: IL + vreme_potrebno_da_se_zapamti_kontekst_cpu-a (2) Kod non-preemtive kernela, kôd ISR rutine se izvršava neposredno nakon što se zapamti kontekst procresora. Vreme odziva na prekid kod non-oreemtive sistema je definisano sledećom relacijom:

22 IL + vreme_potrebno_da_se_zapamti_kontekst_procesora (3) Kod preemtive kernela neophodno je pozvati specijalnu kernel funkciju koja obaveštava kernel da je počelo izvršenje ISR-a. Ova funkcija omogućava kernelu da vodi trag o gneždjenju prekida. Ilustracije radi, kod OS-a micro/os-ii ova funkcija se naziva OSIntEnter(). Vreme odziva kod preemtive kernela je dato sledećom relacijom: IL + vreme_potrebno_da_se_zapamti_kontekst_cpu-a + vreme_izvršenja_kernel-ovske_isr_entry_funkcije (4) Oporavljanje od prekida Oporavljanje od prekida (interrupt recovery) se definiše kao vreme koje je potrebno procesoru da se vrati prekinutom programu ili (kod preemtive kernela) zadatku sa najvišim prioritetom izvršenja. Oporavljanje od prekida kod foreground/background sistema jednostavno uključuje obnavljanje konteksta procesora i vraćanje na zadatak čije je izvršenje bilo prekinuto. Vreme potrebno da se obavi oporavljanje od prekida definisano je sledećom relacijom: vreme_potrebno_da_se_obnovi_kontekst_cpu-a + vreme_da_se_obavi_povratak_od_prekinute-instrukcije_prekida (5) Kao i kod foreground/background sistema oporavljanje od prekida kod non-preemtive kernela čini vreme potrebno da se obnovi kontekst procesora kao i vreme povratka na prekinuti zadatak, a dato je sledećom relacijom: vreme_potrebno_da_se_obnovi_kontekst_cpu-a + vreme_da_se_obnovi_povratak_od_ instrukcije_prekida (6) Kod preemtive kernela odredjivanje vremena oporavka je nešto složenije. Obično postoji funkcija koja pripada kernelu, a poziva se na kraju ISR-a. Ilustracije radi, kod OS-a microc/os-ii ova funkcija se naziva OSIntExit().Ova funkcija omogućava kernelu da odredi da li će prekidi biti ugneždjeni ili ne. Ako prekidi treba da se ugnezde (tj, povratak od prekidne rutine biće na task-level kôd) kernel će odrediti da li zadatak višeg nivoa prioriteta, kao rezultat izvršenja ISR-a, biće ready za izvršenje. Ako zadatak višeg prioriteta, kao rezultat izvršenja ISR-a, je ready za izvršenje, tada će se izvršenje zadatka nastaviti. Naglasimo da u ovom slučaju, prekinuti zadatak se nastavlja samo kada on ponovo postaje zadatak sa najvišim prioritetom koji je raedy za izvršenje. Kod preemtive kernela vreme oporavljanja od prekida je definisano kao: vreme_potrebno-da-se_odredi_da_li_zadatak_viseg_prioriteta_je_ready + vreme_da_se_obnovi_kontekst_cpu-a_zadatka_sa_najvišim_prioritetom + vreme-da_se_obavi_povratak_od_strane_prekinute_instrukcije (7) Latencija prekida, odziv i oporavljanje Na slikama 20 do 22 prikazene su latencija prekida, odziv i oporavljanje od prekida kod foreground/background sistema, non-oreemtive kernela i preemtive kernela, respektivno. Treba pri ovome naglasiti da se kod preemtive kernela, ulaz funkcije je taj koji odlučuje da li se povratak obavlja ka prekinutom zadatku [F2.22(A)], ili ka zadatku višeg prioriteta koga je ISR učinio ready za izvršenje [F2.22(B)]. U drugom slučaju, vreme izvršenja je nešto duže jer kernel treba da obavi i kontekst komutaciju.

23 Slika 20. Latencija prekida, odziv i oporavak od prekida kod foreground/background Slika 21. Latencija prekida, odziv i oporavak od prekida kod non-preemtive kernela

24 Slika 22. Latencija prekida, odziv i oporavak od prekida kod preemptive kernela Vreme procesiranja ISR-a U principu vreme obrade ISR-a treba da bude što je moguće kraće. Ipak, apsolutni limiti koji se odnose na iznos vremena procesiranja ISR-a ne postoje, tj, nisu propisani. Ne može se sa sigurnošću kazati da ISR treba da traje kraće od 100 μs, 500 μs, ili 1 ms. Ako je kôd ISR-a najvažniji kôd koji, za dati vremenski period, treba da se izvrši, tada njegovo izvrćšenje treba da traje onoliko koliko je to potrebno. U najvećem broju slučajeva, ipak, ISR treba da prepozna izvora prekida, pribavi podatke i status od uredjaja koji je inicirao prekid, i signalizira zadatku da obavi aktuelno procesiranje. Treba pri tome imati u vidu da režijsko vreme (overhead) koje se javlja zbog signalizacije zadatku da se desio dogadjaj ne sme da traje duže od obrade prekida. Signalizacija zadatku koja se obavlja od strane ISR-a (obično se signalizacija vrši preko semafora, mailbox-ova, ili queue-a) zahteva odredjeno vreme obrade Ne-maskirajući prekidi Ponekad, prekid se mora opslužiti što je moguće pre i ne može se dozvoliti da ima definisanu latentnost koja je odredjena od strane kernela. Da bi se uspešno rešio problem, kod ovakvih situacija, potrebno je koristiti non-maskable prekide (NMI). Ovi tipovi prekida su implementirani kod najvećeg broja današnjih mikroprocesora. Pošto se rad NMI-a ne može zabraniti, latencija prekida, odziv, kao i vreme opsluživanja su minimizirani. NMI je obično rezervisan za preuzimanje drastičnih mera, kao što je pamćenje važne informacije u toku nestanka napajanja sistema. Za slučaj da kod nekih sistema ne postoji izvedena ovakva mogućnost neophodno je da NMI opslužuje ISR čije je vreme izvršenja najkritičnije. Sledeće jednačine definišu kako se odredjuje latencija, jed (8), odziv sistema, jed (9), i oporavlajnje od prekida, jed (10), respektivno. latencija_prekida = vreme_izvršenja_najduže_instrukcije + vreme_početka_izvršenja_nmi_isr-a (8)

25 odziv_na_prekid = latencija_prekida + vreme_potrebno_da_se_zapamti_kontekst_cpu-a (9) oporavljanje_od_prekida = vreme_potrebno_da_se_obnovi_kontekst_cpu-a + vreme_potrebno_da_se_obavi_povratak_od_ prekinute_instrukcije (10) Kada se koriste usluge NMI-a ne mogu se koristiti kernel servisi koji se odnose na signalizaciju zadacima (signalizacija se koristi da saopšti procesoru da se desio neki dogadjaj) iz razloga što se NMI-u ne može, interno u okviru procesora, zabraniti rad, a time i zabraniti pristup kritičnoj sekciji kôda. Ipak moguće je preneti parametre ka ili iz NMI-a. Paremetri koji se pri tome prenose moraju biti globalne promenljive, a pristup ovim promenljivim, radi potrebe upisa ili čitanja, mora da se izvede kao nedeljiva read-write operacija nad celim obimom podatka (tj, obima 16 ili 32 bita), a ne na principu pristupa bajt po bajt. Rad NMI-a, kako je to prikazano na slici 23, može se zabraniti eksternom logikom. Ako usvojimo da se zahtev za prekid prihvata na pozitivni-nivo (positive level sensitive) tada je dovoljno izmedju izvora prekida i CPU-ovog NMI ulaza ugaditi logičko AND kolo. Zabrana prekida se vrši postavljanjem ulaznog porta u stanje 0. Slika 23. Zabrana NMI prekida Pretpostavimo sada sledeću situaciju. Neka NMI treba da signalizira zadatku na pojavu nekog dogadjaja nakon četrdesetog puta izvršenja NMI prekidne rutine. Ako se NMI javlja svakih 150 μs, tada da bi se signalizirao dogadjaj biće potrebno vreme od 40 * 150 μs = 6 ms. NMI ISR ne može da koristiti kernel kako bi signaliziralo zadatku na dešavanje dogadjaja, nego da bi se uspešno taj rešio problem mora da se koristi šema kao što je ona prikazana na slici 24. Slika 24. Signalizacija zadatku od strane nemaskirajućeg zadatka U ovom slučaju NMI uslužna rutina generiše hardverski prekid preko izlaznog porta (postavljanje izlaza porta na visoko). Pošto NMI uslužna rutina ima najviši nivo prioroiteta kod opsluživanja, gneždjenje prekida neće biti dozvoljeno sve dok se opslužuje NMI prekid. To znači da će se zahtev za prekid priznati tek nakon završetka NMI ISR rutine Clock tick Clock tick je specijalni prekid koji se javlja periodično. U ovom slučaju, prekid se može po analogiji posmatrati kao otkucaj srca kod čoveka, tj, nešto što daje ritam životu. Vreme izmedju prekida

26 zavisi od aplikacije, ali kod najvećeg broja rešenja nalazi se u granicama od (10-200) ms. Click tick prekid omogućava kernelu da zakani izvršenje nekog zadatka, kada se to od njega zahteva, za integer broj taktnih intervala (clock tick-ova), a takodje i da obezbedi (generiše) timeout-e kada zadaci čekaju da se neki dogadjaj javi. Pri ovome, što je frakvencija tick-a višlja to je i veće režijsko vtreme koje je potrebno za obradu tick usluge (češće se javla). Svi kerneli omogučavaju zadacima da budu zakašnjeni za odredjeni broj clock-tick-ova, pri čemu rezolucija kašnjenja iznosi jedan tick. No to ne znači i da je njegova tačnost jedan clock-tick (neki clock tick može da se desi da bude izostavljen pri analizi ako se u toku nailska tick-a izvršavao zadatak višeg nivoa prioriteta). Na slikama 25 do 27 prikazani su tajming dijagrami koji prikazuju kašnjenje zadatka za jedan clock tick. Osenčane oblasti ukazuju na vreme izvršenja svake operacije. Treba uočiti da vreme izvršenja svake operacije varira i ukazuje na tipično vreme procesiranja. Ovo vreme uklučuje vreme izvršenja iskaza tipa petlji (loops) kao i uslovnih (conditional) iskaza (tj, if / else, switch, i dr). Vreme procesiranja tick ISR-a je uveličano sa ciljem da se pokaže da je i ono podložno promeni. Slučaj 1 (slika 25) prikazuje situaciju kada se zadaci višeg prioriteta i ISR-ovi izvršavaju pre zadatka koji treba da unese kašnjenje od jedan tick. Kao što se može videti sa slike 25, zadatak pokušava da zakasni 20 ms, ali zbog njegovog prioriteta stvarno kašnjenje se menja. Promenljivo vreme izvršenja uzrokuje džiter (jitter) kod vremena izvršenja zadatka. Slika 25. Kašnjenje za jedan tick (slučaj 1) Slučaj 2 (slika 26) prikazuje situaciju kada vremena izvršenja svih zadataka viših prioriteta i ISRova su neznatno kraća (manja) od jedan tick. Ako zadatak sam sebe zakasni za upravo jedan tick, tada će se on izvršiti neposredno (odmah) nakon pojave tick-a. Zbog ovoga, ako treba zadatak zakasniti za najmanje jedan tick, tada je neophodno specificirati kašnjenje od još jednog dodatnog tick-a. Drugiim rečima, ako je potrebno zakasniti zadatak za najmanje pet tick-ova, tada moraju da se specificiraju šest tick-ova.