oprendszer

[Szabolcs Szigeti]

>
> Epp az elobb kerdeztem ezt egy masik levelben. Valahogy ereztem, hogy a
> valaszido nagysaganak itt nem lehet jelentosege.

Pontosan. Az a lenyeg, hogy tudjad, hogy ha a rendszered azt erzekeli, hogy
a munkas odallt a presgep ala, akkor biztosan 1ms-on belul be tudja huzni a
feket. Ha a rendszeredben fut egy olyan taszk, hogy if (munkas a prsegep
alatt) then feketbehuz, akkor ezzel akkor tudod megoldani a feladatot, ha
beesik a munkas a presgep alatt interrupt, akkor a feketbehuz muvelet 1ms-on
belul ervenyre jut. Ezt csak ugy lehet megoldani, hogy a rendszenek
elmondod, hogy ennek a taszknak a prioritasa magasabb barmi masnal, es ha a
rendszer tudja teljesiteni, hogy interrupt utan a valaszidon belul atvallt
erre ataszkra es vegrehajtja a feketbehuzot, akkor nyert ugyed van. Ha nem
tudja, mert pl elofordul az, hogy ugyan bejon az interrupt, de taszkot
valtani csak akkor tud, ha elotte befejez valamilyen potencialisan hosszu
muveletet, akkor nem epithetsz arra, hogy a rendszer el tudja latni
feladatat.
>
> Ez is azt erositi, hogy nem a valaszido nagysaga a lenyeg, hanem a
> valaszido maximalizalt hossza.

Igen, hiszen ha jobban belegondolsz, akkor erre visszavaeztheto szinte
minden, mert a feladatod az, hogy jelre adott idon belul tudjal valaszolni,
biztosan.

> Sajnos nem ismerem elegge a multitaszk oprendszereket, de talan a
virtualis
> memoria hasznalatat le lehetne tiltani. Es nem lehet megmondani a
> kernelnek, hogy x ido letelte utan mindenkeppen adja at a vezerlest a
> kovetkezo taszknak? Mert ha igen, es meghatarozhato barmelyik esemenyre a
> komplett valaszido, akkor maris maximalizalni tudtuk az esemenyekre a
> valaszidot.

Persze, meg lehet mondani, csak altalanos rendszerekben ez eleg nehez, ehhez
ugyanis az kell, hogy ha eppen a rendszer a kernelben totymorog, akkor is at
tudjal kapcsolni mas felhasznaloi taszkra. Ez fogas kerdes, a legtobb unix
szinte egyatalan nem tudja, a windows nt felig meddig. A gyakoraltban a
valosideju rendszerek ugy mukodnek, (mint pl. a QNX), hogy van egy nagyon
kicsi kernel (QNX-ben ez szo szerint nehany kilobyte), amely kb annyit tud,
hogy taszkokat valt prioritas szerint es taszkok kozott tud uzeneteket
atvinni. Minden mas tradicionalisan kernel fukncio is tszkokba van
delegalva, tehat pl. a device-ok kezeles, a virtualis memoria, stb. Ez ha
ezekre tudunk valszidot granatalni, akkor meg van oldva a feladat.
A hagyomanyos, monolitikus kernelekben azert van gond, mert az egyes taszkok
mind sajat allapttal rendelkeznek, ha azonban belepnek a kernelbe, mert pl.
io muveletet csinalnak, akkor mar nem igaz, hogy teljesen szeparaltak, mert
sok megoszottt kernel szintu struktura, valtozo van. Ha kozben masvalaki
megkapna a vezerlest, es o is beugrana a kernelbe, akkor felul irna ezeket.
Csak kifinomult zarolasi eljarasokkal elhet ezt tobbe kevesbe kikuszobolni.

Pelda: regi unixokban a kernelben volt egy curpoc nevu valtozo, amely azt
mutatta, hogy eppen melyik processz van kernel szinten. Evidens, hogy ha egy
processz ben van, akkor azt nem lehet megszakitani, majd kesobb folytatni,
mert a kovetkezo kernelbe esetleg belepo taszk eseten a curpoc megvaltozna.
Ez a problema a multiprocesszoros rendszerekben is, hiszen itt egyszerre
tobb taszk lehet valosagban is kernel szinten es ez a felulirasos problema
itt is fent all. Legeloszor azt csinaltak, hogy volt egy nagy zar a
kernelen, amit ha egy processz belepett, akkor zarolta es addig mas nem
lephetett be, tehat kep CPU eseteben is max egy processz lehetett a
kernelben. Ez nem tul hatekony. Ha nem a fenti mikrokerneles megoldast
valasztjuk, akkor az a megoldas utja, hogy a megosztottan kezelet kernel
valtozokat felterkepezzuk, es lockokkal vedjuk oket, tehat azt modnjuk, hogy
adott kernel strukturahoz egyszerre csak egy processz nyulhat. Ez sokkal
kellemesebb, mert igy tenyleg tobb processz lehet a kernelben, de nagyon
atgondolt tervezest igenyel. Ilyen tudomason szerint a Solaris, de ilyen
lesz a keszulo FreeBSD 5.0 is.

Osszefoglalva a sok rizsat, meg lehet oldani, csat tradicionalis
rendszerekben eleg nagy munkat igenyel. A kvazi RT mukodes ("altalaban
gyorsan valaszol") sokkal konnyebben megoldhato, csak hat nem mindig eleg a
celra.

> >Attol, hogy ez a valaszido mekkora, csak az fugg, hogy mire alkalmazhato
a
> >rendszer.
>
> Tehat sem a valaszido nagysaga nem erdekes, sem a valasz bekovetkezesenek
> pillanata a megadott tartomanyon belul. Azert erdekes ez a valos ido. :-)

Dehogynem erdekes. A feladat szempotjabol erdekes, hogy 1ms-on belul
biztosan kell valasz, az meg hogy mikor jon a valasz, az szinten
megallapithato, hiszen ha tudod, hogy mondjuk az oprendszered max. 50us
alatt kapcsolja az interrupt hatasara a kiszolgalo taszkot, az pedig 450us
utan valaszol, akkor tudod, hogy legkesobb 500us mulva van valaszod. Ha
potnosan kell az idot szamitani, ez mar a taszk dolga, de felhasznalhatja a
rendszer a szolgaltatasait, mint pl. rendszerora. Ha 10mp mulva kel
valszolni, akkor megkeri a rendszert, hogy 10 mp mulvaepressze fel.

> Akkor a dos-bios paros az alaplapi interrupt vezerlovel karoltve megiscsak
> lehet realtime.

Igy van, minden tovabbi nelkul. Az RT mukodes sokkal inkabb szoftver
kerdese, arrafele sokkal tobb nem definit dolog fordul elo.

Szabolcs

(bocs a sok beszedert)