Dom > Izložba > Sadržaj

Operativni sistem u realnom vremenu Komunikacija u interakciji i dijeljenje resursa

Mar 08, 2019

Multitasking operativni sistem kao što je Unix je loš u zadacima u realnom vremenu. Planer daje najviši prioritet poslovima sa najnižom potražnjom na računaru, tako da ne postoji način da se osigura da posao koji je kritičan za vrijeme ima pristup dovoljno resursa. Sistemi za obavljanje više zadataka moraju upravljati dijeljenjem podataka i hardverskih resursa između više zadataka. Obično je nesigurno za dva zadatka da istovremeno pristupaju istim specifičnim podacima ili hardverskim resursima. [6] Postoje tri uobičajena pristupa rješavanju ovog problema:


Privremeno maskiranje / onemogućavanje prekida

Operativni sistemi opće namjene obično ne dozvoljavaju korisničkim programima da maskiraju (onemogućuju) prekide, jer korisnički program može kontrolirati CPU onoliko dugo koliko želi. Neki moderni procesori ne dozvoljavaju kodu korisničkog načina da onemogući prekide jer se takva kontrola smatra ključnim resursom operativnog sistema. Mnogi ugrađeni sistemi i RTOS-ovi, međutim, dozvoljavaju samoj aplikaciji da radi u kernel modu za veću efikasnost sistemskih poziva i da dozvoli aplikaciji da ima veću kontrolu nad radnim okruženjem bez potrebe za intervencijom OS-a.


Na sistemima s jednim procesorom, aplikacija koja se izvodi u modu jezgre i prekidima maskiranja je najniža metoda opterećenja kako bi se spriječio simultani pristup dijeljenom resursu. Dok su prekidi maskirani i trenutni zadatak ne vrši blokiranje OS poziva, trenutni zadatak ima isključivo korištenje CPU-a jer nijedan drugi zadatak ili prekid ne može preuzeti kontrolu, tako da je kritična sekcija zaštićena. Kada zadatak izađe iz kritične sekcije, mora da raskine prekide; Prekidi na čekanju, ako ih ima, će se izvršiti. Privremeno maskiranje prekida treba da se obavi samo kada je najduža staza kroz kritičnu sekciju kraća od željene maksimalne latencije prekida. Obično se ovaj način zaštite koristi samo kada je kritična sekcija samo nekoliko instrukcija i ne sadrži petlje. Ovaj metod je idealan za zaštitu hardverskih bit-mapiranih registara kada se bitovi kontroliraju različitim zadacima.


Mutexes

Kada se zajednički resurs mora rezervisati bez blokiranja svih drugih zadataka (kao što je čekanje na pisanje Flash memorije), bolje je koristiti mehanizme koji su također dostupni na operativnim sistemima opće namjene, kao što su mutex i interprocess poruke koje nadziru OS. Takvi mehanizmi uključuju sistemske pozive, i obično pozivaju OS-ov dispečerski kôd na izlazu, tako da obično uzimaju stotine CPU instrukcija za izvršavanje, dok maskiranje prekida može potrajati samo nekoliko instrukcija na nekim procesorima.


(Ne-rekurzivni) mutex je ili zaključan ili otključan. Kada je zadatak zaključao mutex, svi drugi zadaci moraju čekati da mutex bude otključan od strane njegovog vlasnika - izvorne niti. Zadatak može postaviti timeout na čekanju za mutex. Postoji nekoliko dobro poznatih problema sa mutex baziranim dizajnom kao što su prioritetna inverzija i zastoji.


U inverziji prioriteta, zadatak visokog prioriteta čeka jer zadatak niskog prioriteta ima mutex, ali zadatku nižeg prioriteta ne daje CPU vrijeme da završi svoj posao. Tipično rješenje je da zadatak koji posjeduje mutex na, ili 'naslijedi', bude prioritet zadatka koji najviše čeka. Ali ovaj jednostavan pristup postaje složeniji kada postoji više nivoa čekanja: zadatak A čeka mutex zaključan zadatkom B, koji čeka mutex zaključan zadatkom C. Rukovanje višestrukim nivoima nasljeđivanja uzrokuje pokretanje drugog koda u kontekstu visokog prioriteta i stoga može uzrokovati izgladnjivanje niti srednjeg prioriteta.


U mrtvoj petlji, dva ili više zadataka zaključavaju mutex bez vremenskih ograničenja i onda zauvijek čekaju mutex drugog zadatka, stvarajući cikličku ovisnost. Najjednostavniji scenarij zastoja nastaje kada dva zadatka naizmjenično zaključavaju dva mutexa, ali u suprotnom redoslijedu. Zastoj se sprečava pažljivim dizajnom.


Prenos poruke

Drugi pristup dijeljenju resursa je da zadaci šalju poruke u shemi organiziranog slanja poruka. U ovoj paradigmi, resursom se upravlja samo jednim zadatkom. Kada drugi zadatak želi ispitati ili manipulirati resursom, šalje poruku upravljačkom zadatku. Iako je njihovo ponašanje u realnom vremenu manje oštro od semaforskih sistema, jednostavni sistemi zasnovani na porukama izbjegavaju većinu opasnosti od zastoja protokola i općenito se bolje ponašaju nego sustavi semafora. Međutim, mogući su problemi poput onih iz semafora. Inverzija prioriteta se može pojaviti kada zadatak radi na poruci niskog prioriteta i zanemaruje poruku višeg prioriteta (ili poruku koja potječe posredno iz zadatka visokog prioriteta) u svom dolaznom redu poruka. Blokada protokola može se pojaviti kada dva ili više zadataka čekaju jedan drugog da pošalju poruke odgovora.