ALTE DOCUMENTE
|
||||||||
RĪGAS TEHNISKĀ UNIVERSITĀTE
LIETISĶO DATORSISTĒMU INSTITŪTS
Atļauts aizstāvēt.
Profesors J.Osis
___________________
Automātikas un skaitļosanas tehnikas fakultāte
Datorzinātņu profils
Lietisķo datorzinātņu virziens
Bakalaura darbs
Bakalaura darba vadītājs
Dr. sc. ing.
Uzdevums
Anotācija
Annotation
1. ARHITEKTŪRAS PAKALPOJUMI 8
1.1. Pulksteņa sinhronizācija 8
1.2. Paredzamo komponensu mijiedarbība 8
1.4. Kļūdu noteiksana 10
2. PROJEKTĒSANA 12
2.1. Reālā laika tranzakcijas 12
2.2. Laicīgo parametru noteiksana 12
2.3. Bojājumpiecietīgs bloks ( BPB ) 13
2.4. Laicīga novērtēsana un pārprojektēsana 13
2.5. Izņēmumi 14
2.6. Paralelitāte 15
2.6.1. Uzdevumi un randevu 16
2.6.2. Ieejas izsaukumu apstrādāsanas kārtība 18
2.6.3. Prioritāte 19
2.7. Uzticamības nodrosināsana 19
3. PROGRAMMĒSANAS MODELIS "MARS" 20
3.1. Programmēsanas interfeiss 20
3.1.1. Uzdevuma struktūra 21
3.1.2. Sazināsanās ar ziņojumu palīdzību 21
3.1.3. Vēstures stāvokļa definēsana 22
3.1.4. Ārējās vides ieeju lasīsanas saskaņosanas protokols 23
3.2. Programmēsana laika budzetā 24
3.2.1. Programmēsanas valoda un
izpildes laika prognozēsana 24
3.2.2. Programmēsanas valodas ierobezojumi 25
3.3. Programmēsanas vide 25
4. TESTĒSANA 27
NOBEIGUMS 28
BIBLIOGRĀFISKAIS SARAKSTS 29
Mūsdienās sadalītas reāla laika sistēmas aizvieto parastas mehāniskas vai hidrauliskas kontroles sistēmas daudzās vietās. Piemēram lidojuma kontroles sistēmas lidmasīnā, automobīļa dzinēja darba kontroles sistēmas, kāda razosanas procesa kontroles sistēmas un vēl daudzas citas. Papildus so ierīcu spesificētām funkcionālām prasībām, viņām vēl ir jaievēro nefunkcionālās prasības tādas kā izturība, drosība un remonta iespejamība. Programmām kas tiek izstrādātas prieks rēāla laika sistēmām jābūt efektīvām ātruma un patērētās atmiņas ziņā, kā arī jaizpilda nepieciesamās darbības ar augstu precizitāti.
Pāslaik reāla laika sistēmu izstrādāsanas process ir nogurdinoss un palaikam arī nesistematizēts. Biezi izstrādāsanas laikā galveno uzmanību pievērs toposās sistēmas funkcionālām spējām. Rūpes par sistēmas ātrdarbību un drosumu atstājot uz pēdējo testēsanas fāzi kad visām sistēmas daļām ir jābūt integrētām. Koda realizācijas laikā speciālas transformācijas veicot datu apgabalā, biezi savij kopā uzdevumu sinhronizācijas kodu un kodu, kas paredzēts kļūdu noteiksanai un apstrādei. Kā sekas ir grūti panākt sistēmas savlaicību ar formālu spriesanu vai konstruktīvu testu metodoloģiju. Turklāt nelielas izmaiņas vienā sistēmas daļā stipri iespaidos sistēmas savlaicību kādās citās tās daļās.
Mēs apskatīsim sistēmas arhitektūru MARS, kurā stingri atsķir savā starpā tādas lietas kā sinhronizācija un savlaicība, datu transformācija, uzticamības aspekti ( kļūdu noteiksana, kļudu apstrādāsana un redundances vadība) . Par reāla laika tranzakcijām mēs apzīmēsim procesu secību un sazināsanas soļus starp ārējās vides novērosanu un sistēmas reakcijas laiku. Projektēsanas fāzē reāla laika tranzakcijas tiek izsmalcinātas secīgās uzdevumu palaisanās un ziņojumu apmaiņās. Katra uzdevuma vajadzības tiek analizētas un tā izpildes laiks tiek noteikts, tādā veidā visas tranzakcijas tiek saplānotas ņemot vērā pieejamos aparatūras resursus. Programmēsanas fāzē, lietisķais programmētājs var koncentrēt visu uzmanību viņa galvenam uzdevumam, proti rakstīt korektu programmu kuras izpildes laiks saskanēs ar paredzēto laika budzetu. Kļūdu noteiksana, kļūdu apstrādāsana un redundances vadība ir arhitektūras pakalpojumi.
Mūsu skatijumā tāds problēmu sadalījums ir iespejams tikai ja sistēmas arhitektūra ir laika trigerēta, proti, visas sistēmas aktivitātes ir iniciētas ar sekojosiem viens otram notikumiem reālā laikā. Kaut gan notikuma iestāsanās laiks ir ārpus sistēmas kontroles robezām, laika momenti kad sie notikumi var būt atpazīti ir ieprieksnoteikti laika trigerētās arhitektūrās. Tas ir pretstats notikuma trigerētām arhitekturām, kur sistēmas aktivitāte tiek inicieta ar arējo vai ieksējo notikumu iestāsanos. Notikumu trigerēta reāla laika arhitektūra ir diezgan elastīga un tapēc tai ir veltīta diezgan liela uzmanība literatūrā, bet tai ir arī daudzi trūkumi, kurus mēs sikāk neapskatīsim.
Sis raksts ir organizēts sekojosi. Nākamā nodaļā mēs gūsim nelielu pārskatu par programmēsanas modeli MARS un apskatīsim sekojosus arhitektūras piedāvātos pakalpojumus: pulksteņa sinhronizācija, kļudu noteiksana, kļudu apstrāde un redundances vadība. Otrā nodaļā būs aprakstīti projektēsanas pasākumi kuri kļūst par pamatu nākamās sistēmas savlaicībai un uzticībai. Tresā nodaļā galvenā uzmanība tiks veltīta programmēsanas modelim no lietisķā programmētāja viedokļa. Un beigās parunāsim par programmēsanas vidi un izstrādātās sistēmas testēsanu.
Kaut gan mēs apskatam programmēsanas modeli "MARS" ir nepieciesams no sākuma aprakstīt pakalpojumus kurus sniedz arhitektura un saprast, kapēc programmētājam nav jārūpējas par daziem aspektiem. Arhitektūra atbrīvo projektētāju no komunikāciju prognozēsanas un bojājumpiecietības problēmas.
Arhitektūras līmenī MARS sistēma ir sadalīta kompjuterizēta sistēma kas sastāv no autonomiem "klusiem" mezgliem, sauktiem par komponentēm. Komponentes savā starpā ir savienotas ar reāla laika tīklu. Tas tīkls sastāv no diviem vienādiem pāraides kanāliem, kuri nodrosina redundanci. Katra komponente ir neatkarīga ar savu reāla laika pulksteni un interfeisu ( ienākosām un izejosām saitēm) reāla laika tīklā.
Uzdevums ir kāds bloks, kas saņem ziņojumu kopu, izpilda kādas noteiktas darbības vai aprēķinus un arī sūta ziņojumu kopu. Nav nekādas tiesas mijiedarbības starp uzdevumiem uzdevuma ķermeņa robezās. Mijiedarbība starp komponentēm ( un uzdevumiem ) notiek tikai apmainoties ar pārraides ziņojumiem. Dazas no komponentēm, interfeisa komponentes, uztur saiti ar mērīsanas ierīcēm, proti ar sensoriem un citiem aktivētājiem ārējā vidē. Lai pretoties dazādām neveiksmēm un aparatūras atteikumiem vairākas vienādas komponentes tiek apvienotas BojājumPiecietīgos Blokos (BPB). BPB ir aktīvs tik ilgi, kamēr darbojas kaut viena no tā komponentēm.
Redundance tā kāda mezgla ( bloka, uzdevuma, komponentes.) dublēsana ar nolūku panākt drosumu, piemēram, komponente iziet no ierindas, tās darbību uzreiz turpina tās liekā kopija. Redundances vadība ir caurspīdīga prieks programmētāja, citiem vārdiem programmētājs nerūpējas pār tās nodrosināsanu.
MARS modeļa visu komponensu ieksējie pulksteņi ir sinhronizēti gan savā starpā, gan ar ārējo laiku, ar precizitāti dazas mikrosekundes [4]. Sī globālā laika sinronizācija ir par pamatu visiem arhitektūras pakalpojumiem, un arī tiek izmantota marķejot arējos notikumus kurus novēro sistēma. So ārejo notikumu marķēsanu izmantoto uzdevumi lai noteikt kādā secībā bija iestājusies novērotie notikumi.
MARS arhitektūrā nav nekādas tiesas sinhronizācijas starp uzdevumiem, piemēram lietojot semaforus, tā vietā visas komponentes tiek netiesi sinhronizētas izmantojot globālo laiku. Uzdevumi un ziņojumi tiek saplānoti pirms aplikācijas palaisanas tā, lai garantētu katra uzdevuma laicīgo izpildi.
Pirms programmas palaisanas ziņojumu saplānosana ir iespejama tapēc ka starp komponentēm tiek lietots sazināsanas protokols TDMA ( Time-Division Multiply Access ), kurs ieprieks nosak piemēroto laiku ziņojuma sūtīsanai. TDMA ne tikai nosaka pāraides joslas platumu prieks katras komponentes, bet arī garantē, ka jebkurā laika momentā jebkura sistēmas komponente zina kurai no komponentēm paslaik ir pieeja pārraides tīklam. Tas ved pie laicīgas komponentes inkapsulācijas ( germetizācijas ). Tapēc ka katra komponente veic pārraidi tikai tajā laikā kas viņai ir atvēlēts, saņēmēj komponentes var atklāt ziņojuma zaudējumu vai pārraides kļūmi.
Ziņojuma zaudēsanas gadijumā tas netiek sūtīts vēl reiz. Tā vietā sazināsanas stabilitāti nodrosina redundance. Katra komponente sūta katru ziņojumu pa diviem esosiem kanāliem. Tā kā dublējas ne tikai pāraides kanāli, bet arī komponentes, sanāk ka pa pāraides tīklu tiek sūtīti vairāki vienādi ziņojumi. Tas ļauj uzturēt drosu sazināsanos gan ziņojuma nozusanas gadījumos, gan komponentes kļumes gadijumā, gan arī gadījumā kad kanāls iziet no ierindas. Operētājsistēma atsakās no pārlieku ziņojumu kopiju izmantosanas saņēmēj komponentēs.
Mazākā sistēmas daļa ar kuru saskaras programmētājs ir BPB ( BojājumPieticīgs Bloks). BPB sastāv no divām vai trijām komponentēm, tas atkarīgs no nepieciesamās kļūdu izturības pakāpes. Divas komponentes BPB strādā kā aktīvās. Tresā komponente, tā sauktā ēnas komponente, izpilda tiesi tādas pasas darbības vai izskaitļosanas kā divas ieprieksējas, bet nesūta nevienu ziņojumu tīklā. Tālāk tekstā mēs pieņemam ka BPB visu laiku sastāv no trīm komponentēm. Gadijumā ja viena aktīva komponente iziet no ierindas, ēnas komponente pārņem izgajusās komponentes funkcijas. Sīs no ierindas izejosās komponentes noteiksanu un BPB pārkonfigurēsanu nodrosina sadalītas piederības pakalpojums. Sis pakalpojums nodrosina katru operacionālo komponenti ar informāciju par citu komponensu laicīgo stāvokli.
Redundantām komponentēm ir jaizdot ne tikai pareizs rezultāts, bet arī vienāds, lai izbēgtu pretrunību rasanos sistēmā. Sīs prasības tiek panāktas ja izpidās trīs prasības:
Redundantām komponentēm ir jasaņem tādi pasi ieejas dati kā pamatkomponentei. Sī nosacījuma izpildi garantē protokols TDMA, kas aprakstīts ieprieks, un tapēc ziņojumi atnāk tikai tiem izdalītā laikā. Tas arī garantē ka tie tiks apstrādāti ar redundantām komponentēm, uzreiz pēc tam, kad to apstrādi pabeigs pamatkomponente.
Redundantās komponentes izpilda visas tādas pasas darbības kā pamatkomponente un tiek sinhronizētas ar globālo laiku.
Redundanto komponensu ieksējais stāvoklis ir vienāds. Tas seko no ieprieks teiktā pie nosacijuma, ka dublejamo komponesu sākumstāvoklis ir vienāds. Ja sabojātā komponente tiek reintegrēta sistēmā, tai ir jāsaņem un jauzstāda pie sevis tāds pats ieksējais stāvoklis kāds ir redundantās partner komponentēs. Tapēc ka sis sabojātas komonentes reintegrācijas process ir iepriēks nosakāms tas neietekmē sistēmas laicīgumu. Lai to uzturēt katra komponente periodiski sūta informāciju par savu ieksējo stāvokli ( to vēl citādi sauc par "h-stāvokļa ziņojumu " ) ieprieks noteiktos reintegrācijas punktos reāla laika tiklā, kur so informāciju varēs saņemt redundantās partner komponentes.
Kļūdu noteiksana ir veikta divos līmeņos, komponensu līmenī un sistēmas līmenī. Komponensu līmenī tiek realizēts mehānisms, kas kontrolē aparatūras atteices. Sī mehānisma mērķis ir pataisīt komponenti par "klusu" ja tā dot nekorektus rezultātus, citiem vārdiem komponentei ir jaizdot vai nu korekti rezultāti vai nav jasniedz rezultāti vispār. Sistēmas līmenī pietiek ar komponensu sabruksanas kontroli, tas tiek darīts ar sadalītas piederības pakalpojuma palīdzību, kas aprakstīts ieprieks.
Vissvarīgākie paņēmieni kļūdu noteiksanai komponensu līmenī ir:
Redundanto uzdevumu palaisana. Arhitektūra nodrosina redundanto uzdevumu palaisanu lai novērstu īslaicīgas kļūdas. Katra redundanta uzdevuma darbība sākas ar tādu pasu ieksējo stāvokli, tas izpilda tādas pasas darbības un ar identiskiem ieejas datiem, un izdot vienādus izejrezultātus tā pat kā pamatkomponente. Ienākoso ziņojumu vienādību nodrosina pirms palaisanas plānotājs un operētājsistēma, tapēc ienākoso ziņojumu kopa nemainās palaisanas laikā redudantās kopijās, un ienākosie ziņojumi netiek iznīcināti kad tiek lasīti. Jebkuras nesakritības redundanto komponensu izejosos datos liecina par atteices rasanos aparatūras darbībā.
Ziņojumu kopsummas. Kompilātors ģenerē kodu, kas nodrosina katru izejosu ziņojumu ar kopsummu, un katra ienākosa ziņojuma kopsummas pārbaudi. Tādejādi visu ceļu no sūtītāja līdz saņēmējam ziņojums ir aizsargāts no sabojāsanas.
Pārraides laika sadalīsanas kontroliēris prieks reāla laika tīkla. Pārraides laika sadalīsanas kontrolieris ir mikro kontrolieris, kas strādā paralēli operētāj sistēmai neatkarīgi no pārējām komponentēm un izdala katrai komponentei laika intervālu kurā tā var veikt pāraidi tīklā. Tā darbība balstās uz TDMA protokolu. Viņs pasargā tīklu no kļūdainiem ziņojumiem, kurus varētu sūtīt sabojātās komponentes, kontrolējot komponensu pieeju tīklam un ja nepieciesams neizdalot sabojātai komponentei atļauju pārraidīt. Komponente var sākt pārraidi tīklā tikai tad ja atļauja ir saņemta gan no operētāj sistēmas, gan no pārraides laika sadalīsanas kontroliera.
Lietisķam programmētājam nav jārūpējas par kļūdu apstrādi komponensu līmenī. Ir tikai viena darbība prieks kļūdas apstrādes komponensu līmenī un tas notiek bez programmētāja iejauksanās: komponetne tiek neatliekami aizvērta ciet lai pārtraukt kļūdas tālāku izplatīsanos.
Sistēmas līmenī komponentes atteice ved pie atbilstosa BPB pārkonfigurēsanas. Ēnas komponente pārņem no ierindas izejosās komponentes pārraides pieeju, tādejādi aizvietojot to, kamēr sabojātā komponente mēģina pārlādēties un reintegrēt sevi sistēmā kā ēnas komponente. Pirms komponente izpilda reintegrēsanu sistēmā testa procedūras mēģina noskaidrot, vai bojājumam ir pastāvīgs vai īslaicīgs raksturs. Ja bojājums ir īslaicīgs tad komponente saņem inicializācijas stāvokli no specializētās komponentes - uzturēsanas komponentes. Un tālāk "klausās tīklā" kamēr nesaņems vēstures stāvokli no redundantās komponentes. No sī brīza komponente skaitās pilnīgi reintegrēta sistēmā un kļūst par ēnas komponenti ( tas ir gadijumā ja ir jau divas aktīvas redundantās komponentes) vai par otru aktīvu.
Projektēsanas agrākās fāzēs projektētājs nosaka operāciju rezīmus un iespejamās rezīmu maiņas. Lidmasīnā piemēram izdala dazādas sistēmas aktivitātes pacelsanās, lidojuma un nolaisanās fāzēs. Katrs rezīms tā pat kā rezīma maiņa, sastāv no vairākiem reālā laikā sadarbīgiem processiem.[3] Ir tikai viena svarīga starpība starp rezīmiem un rezīmu maiņām. Rezīmi tiek realizēti kā periodiski atkārtojama uzdevumu kopa, bet rezīma maiņu realizē uzdevuma kopa, kas tiek izpildīta tikai vienu reizi. Lai palīdzēt reāla laika sistēmu projektētājam tikt galā ar sarezģītību laicīgo paremetru noteiksanā ir izstrādāta objekt bazēta projektēsanas metodoloģija.
Viens no svarīgākiem projektēsanas objektiem ir reāla laika tranzakcijas. Reāla laika tranzakcijas ļauj veidot uzdevumu kopas kuras izpilda kādas noteiktas funkcijas. Pastāv starpība starp tranzakcijām, kas darbojas ar diskrētiem procesiem un tranzakcijām kas darbojas ar nepārtrauktiem procesiem.
Tranzakcijas kas strādā ar diskrētiem procesiem tiek aktivizētas no ārejas vides ( piemēram taustiņa nospiesana ) un ir spiestas reaģēt laika intervālā kuru diktē ārējā vide. Mēs nosauksim so laika intervālu par MART, tas ir sistēmas maksimālais reakcijas laiks. Minimālais laika intervāls starp diviem sekojosiem vienādiem notikumiem arī tiek definēts un mēs to nosauksim par MINT. MINT vēl citādi var formulēt kā maksimālo slodzi pie kuras sistēmai ir jādarbojas.
Tranzakcijas, kas strādā ar nepārtrauktiem processiem ( piemēram tempreratūras kontrole ) tiek raksturotas ar nepieciesamo kontroles kvalitāti, ne tikai ar MART un MINT vērtībām. Sie parametri, piemēram periods, prieks nepiecisamās kontroles kvalitātes tiek noteikts projektēsanas laikā.
Bez ieprieks aprakstītiem atribūtiem katra tranzakcija sastāv no funkcionālo darbību neformāla apraksta, un ieejas un iezejas datiem. Dati tiek modelēti ar, tā sauktiem, datu pantiem. Datu panti pārstāv ieejas un izejas datus, kā arī datus kas atspoguļo sistēmas ieksējo stāvokli ( aprēķinu starprezultātus kā arī vēstures informāciju).
Projektēsanas laikā tranzakcijas tiek sadalītas apakstranzakcijās. Mēs varētu iztēloties attiecības starp apakstranzakciju ieejām/izejām kā aciklisku virzītu grafu, kur virsotnes apzīmētu apakstranzakcijas un loki atspogoļotu sagaidāmas atkarības vai saites starp apakstranzakciju ieejām un izejām. Sis grafs tiek saukts par precendences ( sekosanas) grafu, jo atspoguļo apaks tranzakciju sekosanas atkarību. Sadalīsanas procesu varētu interpritēt kā secīgu virsotņu izvērsanu (paplasināsanu) jaunos apaksgrafos. Sadalīsanas procesa beigās katra atsevisķa grafa virsotne apzīmēs vienu tai atbilstosu MARS uzdevumu.
Tā kā MARS tranzakcijas tiek palaistas periodiski, projektēsanas procesa gaitā ir janovērtē periodu un MT ( maksimālo izpildes laiku ) vērtību prieks katras tranzakcijas. Prieks nepārtrauktiem procesiem pastāv vairāki labi zināmi algoritmi no kontroles teorijas, kas palīdz noteikt sīs vērtības balstoties uz zināsanām par arējo vidi ( domāta sistēmas arējā vide ) un nepieciesamo kontroles kvalitāti. Lai saprast kā laicīgo parametru novērtēsana notiek prieks diskrētiem procesiem mēs apskatīsim 2.1. attēlu.
e1 e2
|----- ----- --------|-------- ----- ------ -------|
r MT
|-------- ----- ------ ----- ----- ----------------|
MART
2.1. att. Atkarības starp laicīgiem parametriem
( r - ir maksimālais novērosanas laiks, e1 rāda laika momentu kad sensors sāka novērot arējā vidē kādu notikumu, e2 ir laika moments kad tranzakcijas reakcija tiek atgriesta arējā vidē) r tiek novērtēta ar tranzakcijas skanēsanas frekvenci ( frekvence ar kuru sensors novēro ārējo vidi )). Izmantojot ieprieks aprākstītos nosacījumus iegūstam tranzakcijas periodu.
Periods nav atkarīgs tikai no MINT vērtības, bet arī no tranzakcijas MT ( maksimālā izpildes laika). Un perioda noteiksana nav obligati jāveic ar vienkārsu no augsas uz leju strātēģiju. Tapēc metodoloģija atbalst atkārtojusas darbības un laicīgo parametru novirzi. Pāsās agrākās projektēsanas stadijās pieredzējis projektētājs ( vai projektētāju grupa ) var noteikt MT vērtību, tādā veidā nosakot aptuvenu PERIODA laiku. Papildus stratēģijas, piemēram sākt no PERIODA noteiksanas un tad pāriet pie MT vērtības noteiksanas ) arī ir iespejamas.
Atsevisķi no laicīgo parametu noteiksanas projektēsanas metodoloģija arī atbalsta BPB definēsanu un aprakstīsanu. Vienlaicīgi ar tranzakciju sadalīsanu apakstranzakcijās var būt izveidoti nepieciesamie BPB. Ir iespejaama manuāla uzdevumu sadalīsana starp BPB, tas ir kad projektētājs pats var sadalīt uzdevumus starp atbilstosām komponentēm, vai atstāt lai off - line plānotājs to izpilda automātiski.
Plānotāja ieeja sastāv no tranzakcijām (aprakstītām ar to sekosanu grafā ) un to izvietojumu BPB. Attēls 2.2. ilustrē vienkārsa precendenta ( sekosanas) grafa piemēru. Uzdevumi tiek apzīmēti kā virsotnes, bēt loki rāda to secību. Taisnstūri apkārt uzdevumiem apzīmē BPB kuros uzdevumi tiek apvienoti.
2.2. att. Vienkārs precendences grafs sadalīts trijos BPB
Balstoties uz so informāciju plānotājs mēģina sastādīt iespejamo plānu prieks katra rezīma un rezima maiņas. Ja tāds plāns netiek atrasts tad ir jāveic laicīgo parametru maiņu vai daļēju pārprojektēsanu. Sīs pārprojektēsanas tiek veiktas agrākās projektēsanas stadijās, pirms ir sākusās kādas kodēsanas aktivitātes. Bet ja tomēr projekta tālākā izstrādāsanas gaitā atklāsies ka ir nepieciesams lielāks laika intervāls nekā bija ieplānots no sākuma, citiem vārdiem programmētājs nespēj uzprogrammēt uzdevumu tā, lai tā izpildīsanās laiks iekļautos nepieciesamā MT (maksimālais izpildes laiks ) vērtībā, tad arī tiek veikta pārptojektēsana.
Izņēmumi - tie ir notikumi kuri parādās negaidīti vai arī ļoti reti, piemēram kļūda vai datu trūkums. Zemāk tiek pārskaitīti dazi no izņēmumiem: [1]
Tabulas pārpildīsana.
Dalīsana ar nulli.
Ieejas datu tipu nesakritība.
Darora pārkarsana sliktas ventilācijas dēļ.
Reāla laika sistēmas drosums ir ļoti atkarīgs no tā vai sistēma spēj reaģēt uz izņēmumiem. Lielākoties reāla laika sistēmas tiek projektētas bezgalīgam nepārtrauktam darbam. Izņēmumi pārādās agrāk vai vēlāk tapēc projektējot obligāti tiek paredzēts to apstrādes mehānisms, lai izņēmuma rasanās nenovestu pie sistēmas darba izbeigsanas.
Eksistē divi izņēmuma apstrādes veidi:
Parastā programmēsanas metodika, izmantojamā retu izņēmumu apstrādei, kuri neliecina par patstāvigo kļūdu vai bojājumu rasanos. Sajā gadijumā izņēmuma apstrādes process ir līdzīgs apaksprogrammas izsaukumam.
Programmēsanas metodika kuru izmanto galīgo kļudu apstrādei. Izņēmuma rasanas gadijumā normāla programmas izpilde tiek pārtraukta un tiek inicializēta izņēmuma apstrādātāja darbība. Pēc izņēmuma apstrādes pabeigsanas programmas darbība netiek atjaunota no tās vietas kur parādijās izņēmums.
Mēs apskatīsim otro gadījumu. Kādā veidā izņēmuma rasanās izsauc normālas programmas izpildes apturēsanu.
Process, kad tiek noteikta saite starp konkrētu kļūdas situāciju un atbilstosiem programmas operātoriem, kas apstrādā to, saucās par izņēmuma ierosināsanu. Pēc izņēmuma ierosināsanas tiek izpildīti operātori kuri apstrādā doto kļūdu. Pēc izņēmuma apstrādes programmas darbība netiek uzsākta no tās vietas kur izņēmums bija noticis. Parasti izņēmuma apstrādes operātori tiek novietoti bloka, apaksprogrammas, paketes vai uzdevuma beigās.
Programmas segmenta ( tas var būt bloks, apaksprogramma, pakete vai uzdevums ) darbība, kurā trūkst izņēmuma apstrādātāja, pie izņēmuma rasanās tiek pabeigta anormāli, vai izņēmuma apstrāde tiek veikta citā programmas daļā. Izņēmuma apstrādes nodosana citai programmas daļai saucās par izņēmuma izplatīsamu.
Daudzās programmēsanas valodās nav nepieciesamības izmantot speciālus izņēmuma apstrādes mehānismus, jo kļūdainas situācijas atklāsanai var izmantot tiesās pārbaudes. Sīs pārbaudes ievieto tajās programmas vietās kur var rasties kļūdas situācija. Bet tomēr izņēmumu apstrādes mehānismu iztrūkums programmēsanas valodā noved pie:
Programmas pārskatamības pasliktināsanās. Programmas pārskatamība pasliktinās, jo nav skaidras robezas starp izņēmuma apstrādes operātoriem un operātoriem, kas veic kaut kādus aprēķinus. Tapēc programmētājam ir grūti atdalīt galveno programmas daļu no izņēmuma apstrādāsanas koda.
Kļudainas situācijas atklāsanas neiespejamības. Prieks dazām izņēmumu klasēm (piemēram kļūdas aritmētiskos operātoros vai ievades-izvades pabeigsana) izņēmumi var rasties jebkurā programmas daļā, piemēram operātora vidū. Prieks tādiem izņēmumiem acīmredzot nav prātīgi aprakstīt apstrādi visās programmas vietās kur sie izņēmumi var rasties.
Neefektīvas programmas izmantosanas
Mēs apskatīsim kā paralelitāte tiek realizēta valodā Ada. Paraleritāte ( paralēla prosessu apstrāde ) var būt realizēta uz daudzdatoru (daudzi datori apvienoti ar tīkla palīdzību) un daudzprocessoru sistēmas, vai arī modelēta ar multiprogrammēsanas līdzekļiem (izpildot uzdevumus secīgi) uz viena fiziska processora[1]. Paraleritātes līdzekļu paredzēsana programmēsanas valodā ir ļoti vēlama sekojosu iemeslu dēļ:
Paralelitātes līdzekļi ļauj diezgan viegli aprakstīt sarezģītus algoritmus.
Uz daudzdatoru un daudzprosessoru kompleksiem programmas, kas var izmantot paraleritāti strādās daudz efektīvāk.
Aprakstamā paralelitāte balstās uz secīgo Hoara processu koncepciju, kuras pamatā paralēlo processu sinhronizācijai un datu apmaiņai starp tiem tiek izmantoti ievades/izvades operātori. Sīs paralelitātes izveidotāji atteicās no tādiem paralēlas apstrādes mehānismiem kā semafori, notikumi un signāli, par cik tie ir primitīvi.
2.6.1. Uzdevumi un randevu
Paralēlie procesi valodā Ada
saucās par uzdevumiem. Uzdevumi, apaksprogrammas, paķetes un
uzskaņojamie moduļi veido četrus moduļu veidus no kuriem
sastāv programma uzrakstītā valodā Ada. Uzdevums var
saturēt ieejas kuras izsauc citi uzdevumi. Divu uzdevumu sinhronizācija
notiek tajā momentā kad uzdevums kurs veic ieejas izsauksanu un
uzdevums saņemosais so izsaukumu var dibināt sakaru ar randevu
pālīdzību. Randevu laikā starp uzdevumiem notiek
apmaiņa ar vērtībām.
2.3. att: Shematiski attēlota randevu koncepcija
Ieejas ir svarīgs uzdevumu miejiedarbības līdzeklis. Datu apmaiņa abos virzienos notiek caur faktiskiem parametriem izsaukuma operātorā un atbilstosiem formāliem parametriem saņemsanas operātorā. Attēlā 2.3. ir attēlotas trīs situācijas. Pirmā gadijumā (a) uzdevums A izsauc ieeju E pirms uzdevums B gatavs pieņemt izsaukumu. Uzdevums gaida (tā darbība apstājas ) kamēr uzdevums B būs gatavs prieks randevu. Pēc uzdevumu sinhronizācijas uzdevumi sadarbojas notiek datu apmaiņa. Izpildot randevu uzdevumi turpina savu darbību paralēli. Otrā gadijumā (b) uzdevums B gatavs pieņemt izsaukumu no ieejas E , pirms uzdevums A ir gatavs izpildīt izsaukumu. Uzdevums B gaida kamēr uzdevums A nebūs gatavs prieks randevu.
Un tresajā gadijumā uzdevums A var izpildīt ieejas E izsaukumu tiesi tajā momentā kad uzdevums B ir gatavs pieņemt izsaukumu.
Attēlojamā 2.3. attēlā shēma tiek saukta par asimetrisku, jo uzdevums kas veic izsaukumu nosauc izsaucamā uzdevuma vārdu, bet izsauktais uzdevums nenosauc izsaucēj uzdevuma vārdu. Tāda asimetrija ļauj izveidot bibliotēkas, kuras sastāv no processiem - kalpotājiem.
Randevu starp diviem uzdevumiem vai starp vairākiem uzdevumiem var notikt jebkurā laika momentā. Vispārejā gadijumā prieks dotā uzdevuma randevu ar kādu uzdevumu ir jābeidzās pirms randevu sāksanas ar treso uzdevumu.
Bet tomēr gadās situācijas kad uzdevumam, kas veic paslaik randevu ar otru uzdevumu, jāapmainās ar datiem ar treso uzdevumu pirms randevu beigsanās ar otro uzdevumu. Piemēram lai uzdevums A izsauc uzdevumu B lai saņemtu no tā kādu informāciju, uzdevums B var sniegt so informāciju tikai pēc randevu pabeigsanas ar uzdevumu C. Ir iespeja aprakstīt tadu miejiedarbību starp uzdevumiem. Uzdevums kas saņem izsaukumu, randevu laikā var apmanīties ar datiem ar citu uzdevumu. Piemēram uzdevums A izsauc B, tajā pasā laikā uzdevums B var izsaukt C, attēls 2.4.
2.4. att. Uzdevums B izpilda randevu ar uzdevumiem A un C
Tādā situācijā
uzdevumam B ir jāpabeiz randevu ar uzdevumu C pirms randevu
pabeigsanās starp uzdevumiem A un B. No citas puses randevu izpildes
laikā starp A un B uzdevumiem, uzdevums B var saņemt vēl vienu
izsaukumu piemēram no uzdevuma T2. Tā pat uzdevums B var
apmainīties ar datiem ar uzdevumiem T , ., Tn-1, Tn, attēls
2.5.
2.5. att. Uzdevums B izpilda randevu ar uzdevumiem A, T , T ,.Tn
Sajā gadijumā uzdevumam B ir jāpabeidz randevu ar citiem uzdevumiem otrādā kārtībā nekā tie bija sākti, tātad ar Tn, ., T , A.
2.6.2. Ieejas izsaukumu apstrādāsanas kārtība
Vairāki uzdevumi var izsaukt vienu
un to pasu kāda uzdevuma ieeju. Sie izsaukumi tiek ievietoti rindā,
kura ir saistītā ar atbilstoso ieeju, un tiek apstrādāti
pēc principa FIFO ( first in first out ) pirmais ieksā pirmais
ārā. Attēlā 2.6. var redzēt, kā uzdevumi A un B
grib nodibināt randevu ar uzdevumu C caur ieeju E. Abi sie uzdevumi veic
uzdevuma C ieejas E izsaukumu ātrāk nekā tā
spējīga to apstrādāt. Bet pirmais tiks apstrādāts
uzdevums B jo, tas bija pirmais veicis izsaukumu.
2.6. att. Uzdevums C no sākuma izsauz uzdevums B, un pēc tam A
Uzdevums C vispirms apkalpo uzdevumu B, pēc tam A
Uzdevums kas pieņem ieejas izsaukumu apstādina uzdevuma izsaucēja darbību uz laiku kas nepieciesams lai apmainītos ar datiem. Uzdevums izsaucējs nevar aizturēt izsaucamā uzdevuma darbību. Tāda vienpusēja aizturēsana ir vēl viens asimetrijas piemērs, kas tiek realizēts Ada valodā. Uzdevumi var sagaidīt izsaukumus no vairākiem uzdevumiem, kā arī veikt randevu nekavējoties vai arī noteiktā laika sprīdī. Ja uzdevums izsauc pats savu ieeju rodas situācija kuru sauc par strupceļa situāciju, kaut gan uzdevums savu darbību nav pabeidzis viņs nevar turpināt darbību, jo viņs arī ir izsaucēj uzdevums, bet kā bija teikts agrāk izsaucēj uzdevuma darbība tiek piebremzēta.
2.6.3. Prioritāte
Katram uzdevumam var būt uzstādīta prioritāte. Valodā Ada prioritāte ir statisks lielums un to nevar mainīt dinamiski. Jo lielāka prioritātes vērtība jo lielāka uzdevuma prioritāte[1].
Pie randevu izpildes uzdevumam ar lielāku prioritāti tiek dota prieksroka. Apskatīsim piemeru. Lai uzdevums A un B ir gatavi izpildīt randevu ar uzdevumu C, pie kam uzdevumam A ir lielāka prioritāte nekā uzdevumam B. Ja uzdevumi A un B izsauca vienu un to pasu uzdevuma C ieeju tad tiek izvēlēts uzdevums kas bija veicis izsaukumu pirmais, sajā gadijumā prioritātei nav nekādas nozīmes. Prioritātei ir nozīme kad divi uzdevumi izsauc dazādas izsaucamā uzdevuma ieejas, tad pirmais tiek apkalpots uzdevums ar lielāku prioritāti.
Uzticamības nodrosināsana ietekmē daudzus lēmumus sistēmas projektēsanas laikā. Tapēc uzticamības analizēsanai jābūt projektēsanas procesa sāstāvdaļai un to jāveic pēc iespejas agrākās sistēmas projektēsanas fāzēs. Iekļaujot to agrākās projektēsanas fāzēs viņa nodrosina rupjus rezultātus kuri var būt novērtēti un no kuriem var būt iegūta noderīga informācija tālākai projektēsanai. Sie resultāti dot projektētājam iespeju novērtēt izstrādājamās sistēmas kritiskās vietas un vār būt izvēlēties tiem kādu alternatīvu jau projektēsanas sākumfāzēs.
MARS arhitektūrā uzticamības analīze ietekmē BPB skaitu un uzdevumu sadalīsanu starp tiem. Tas arī nosaka komponensu redundances pakāpi. Prieks lielas uzticamības nodrosināsanas BPB izveido divas aktīvas komponentes un vienu ēnas komponenti. Ja uzticamības prasības nav tik stingras tad ēnas komponenti neizveido. Centālā procesora rezervētās laikspraugas ilgums prieks uzdevuma, nosaka redundantā uzdevuma izpildīsanas iespejamību. Palielinot so laikspraugu palielinās kļūdas atklāsanas pārklājums, bet pieaug arī uzdevuma reakcijas laiks. Beidzot ir jāizvēlas uzturēsanas stratēģija kura uztur balansi starp ekspluatācijas izmaksām un sistēmas uzticamību.
Ieprieksējās sekcijās mēs iepazināmies ar arhitektūras pakalpojumiem un ar to saistību projektēsanas fāzēs. Sī nodaļa apraksta lietisķā programmētāja darbību, kurs sānemot uzdevuma specifikāciju īsteno to tādā veidā lai, tas korekti strādātu gan vērtību gan laika apgabalā.
Pirmā sis nodaļas daļā mēs aprakstīsim programmēsanas interfeisu, un kā to jalieto lai realizētie uzdevumi būtu korekti vērtību apgabalā. Otrā daļā mēs parunāsim, kā jau programmēsanas stadijā var noteikt vai realizējamais uzdevums izpildīsanas laikā iekļausiem tam noteiktos termiņos. Mēs apskatīsim laika budzeta koncepciju un to, kā si koncepcija ietekmē programmētāja darbu. Tresā daļā aprakstīta programmēsanas vide un tajā esosie rīki kuri padara programmētāja darbu ērtāku. Programmēsanas vide ietver sevī kompilātoru, rīkus kas nosaka maksimālo programmas izpildes laiku, un redaktoru ar speciālu nodrosinājumu, kas palīdz iegūt visus nepieciesamos rādītājus par uzdevuma izpildes laiku un tā mainīgiem izpildes laikā.
MARS uzdevumi tiek realizēti izmantojot uzticīgu augstlīmēņa valodu kas saucās Modula/R, tā bija izstrādāta lai nodrosinātu iespeju realizēt MARS uzdevumus zem MARS operētājsistēmas. Valoda ir valodas Modula-2 modifikācija, tā uztur MARS operētājsistēmas sazināsanas struktūru, un ļauj izveidot programmas kas darbojas noteiktā laika budzetā. Dazas valodas Modula-2 iespejas kuras uzskatija par traucējosām vai liekām bija izmestas, citas iespejas bija modificētas lai labāk atbilstu programmēsanas vajadzībām reāla laika sistēmās. Un protams bija izveidotas arī dazas jaunas iespejas.
Modula-2 bija izvēlēta par pamatvalodu tapēc ka tā ir samērā neliela un labi strukturēta pie kam tā uztur modularitāti un sadalītu kompilāciju Tapēc prieks tās varēja izveidot kompilātoru ar saprātīgu piepūli. Bez tā viņa uztur stingru tipu sakritības pārbaudi un vispār tajā uzsvars tiek likts un piesārdzīgu ( vai aizsargātu ) programmēsanu, kas jau agrākās programmēsanas fāzēs ļauj atklāt un likvidēt daudzas programmētāja kļūdas. Modura/R turpina so trādīciju un piedāvā daudzas citas pārbaudes, kuras kompilātors veic kompilēsanas laikā. Te ir pārskaitītas dazas:
Automātiska mainīgiem pieskiramo vērtību pieļaujamības pārbaude
Automātiska massīva robezu pārbaude
Automātiska pārpildīsanas pārbaude veicot aritmētiskas operācijas
Cikla iterāciju robezu pārbaude
Izpildes laikā kļūdu atklāsanas mehānisms ir realizēts sekojosi, programmas kodā vēl izstrādes laikā ir atstātas speciāli koda gabali kuri ļauj atklāt paliekosus aparatūras bojājumus.
Tālāk mēs detalizēsim kāda ir mijiedarbība starp programmētāju, kompilātoru, projektēsanas processu un operētājsistēmu no programmētāja viedokļa.
3.1.1. Uzdevuma struktūra
MARS sistēmā visu darbību un izskaitļojumu pamatvienība ir uzdevums[5]. Uzdevumi tiek palaisti periodiski. Viņi saņem ziņojumu kopu, izpilda noteiktas darbības, veic izskaitļojumus un arī sūta ziņojumu kopu. Ja uzdevumā tiek izmantotas tādas datu struktūras kurām nepieciesama inicializācija ( tas ir jāuzstāda tajās sākuma vērtības ) pirms pirmās griesanās pie tām, tad sādam uzdevumam ir jāsatur neciklisku daļu kurā tiek uzstādītas sākuma vērtības sīm struktūrām. No operētājsistēmas viedokļa uzdevums ir it kā komanda, kas sastāv no vairākiem soļiem. Prieks programmētāja katrā komandā var būt tikai divi processi: viens process ir inicializācijas process, kas tiek palaists tikai vienu reizi lai inicializētu datus, un otrs process, ciklisks, kas tiek palaists periodiski ar noteiktu laika intervālu un kurā notiek aktuālas darbības, piemēram tiek veikti izskaitļojumi reālā laikā.
Modula/R valodā komanda ir augsta līmeņa objekts. Komanda var importēt objektus (konstantes, tipus, mainīgos vai procedūras) no bibliotēkas moduļa, tādejādi uzturot sadalītu kompilāciju. Processa definēsanā tiek ietvertas arī komandas. Processa definēsana ir rādniecīga procedūru definēsanai.
Ir svārīgi saprast ka sazināsanās struktūra ir fiksēta jau projektēsanas fāzē. Ziņojumi kurus uzdevums saņem un kurus ģenerē tiek ievadīti programmēsanas fāzē[5].
Bez tā statiskās plānosanas algoritms garantē trīs lietas:
Visi ziņojumi, kas nepieciesami uzdevumam izpildes laikā, tiks saņemti.
Visi ziņojumi, kas tiek ģenerēti uzdevuma izpildes laikā, nebūs nepieciesami citiem uzdevumiem pirms tie būs izsūtīti.
Visi izsūtītie ziņojumi nonāks pie saņēmējiem.
No tā seko ka programmētājam nav jārūpējas par uzdevumu savstārpejo sinhronizāciju, jo nepastāv punkti caur kuriem varētu uzdevumus sinhronizēt. Bet tajā pasā laikā visi uzdevumi tiek sinhronizēti savā starpā un tas jau tika nodrosināts projektēsanas fāzē.
Tradicionālās sistēmās parasti programmētājam ir iespeja sūtīt un saņemt ziņojumus, norādīt ziņojumu nosaukumu un tipu, sūtīsanas vai saņemsanas buferi un pat māksimālo laika limitu kurā ziņojums var būt aizsūtīts (domāts timeout). Nepieciesamība programmētājam norādīt visus sos parametrus noved pie neizbēgāmām kļūdām, tā kā ir nepieciesams lai visi parametri (ziņojuma nosaukums, tips, bufera izmērs un laika limits) būtu pareizi.
Mūsu aprakstītā sistēmā sāda veida norādījumi ir lieki, jo ziņojuma tips un bufers ir statiski lielumi un saite notiek ārpus uzdevuma. Tādā veidā programmēsanas valoda atbalsta sazināsanos ar ziņojuma palīdzību sekojosi:
Ziņojuma tipi tiek definēti līdzīgi ierakstu tipiem. Tā kā ziņojuma tipi ir globāli objekti prieks sistēmas ir vērts apraksīt tos atsevisķā modulī. Sis modulis var būt automātiski ģenerēts izejot no projektējamiem datiem.
Ziņojuma mainīgie ir komandas objekti. Prieks katra ziņojuma mainīgais, atbilstosā ziņojuma vārds (tips), adrese un buffera izmērs tiek automātiski paziņoti operētājsistēmai. Uzdevuma "karkass" kurs satur sos parametrus tiek automātiski ģenerēts.
Pieeja uzdevuma mainīgam ir atļauta procesam tajā gadijumā ja sis mainīgais ir deklarēts processa virsraksta sūtāmo vai saņemamo mainīgo sarakstā. Kompilātors atpazīst situāciju kad notiek griesanās pie uzdevuma mainīgā un ģenerē kodu mainīgā bufera pieejai izpildes laikā. Pieeja pie uzdevuma kas nav ne sūtāmo ne saņemamo sarakstā noved pie kļūdas, kuru paziņo kompilātors. Faktiski saņemamo un izsūtamo ziņojumu saraksts arī ir uzdevuma "karkasa" sastāvdaļa.
Sai pieejai ir daudz prieksrocību salīdzinot to ar citām izziņu sūtīsanas pieejām.
Sinhronizācijas problēma ir iztirzāta atbilstosā līmenī, tā sauktā projektēsanas līmenī. Realizējot uzdevumu sinhronizāciju uzdevumu līmenī notiks pāstāvosās kārtības sajauksana tajā, tas novedīs pie sarezģītības palielināsanās un validācijas pasliktināsanās.
Ziņojumu sazināsanās nav bloķejāma. Tas dot iespeju noteikt programmas maksimālo izpildes laiku ņemot vērā tikai programmas kodu un ziņas laicīgos raksturojumus.
Ziņojumu mainīgo definēsana var būt izpildīta automātiski balstoties uz projektēsanas datiem.
Izmantojamie ziņojumi ir zināmi kompilātoram un viņs var kontrolēt lai tie būtu izmantoti korekti
Ka aprakstīts 2 nodaļā MARS rūpejas par sabojātu komponentu automātisku reintegrāciju sistēmā. Tas tiek darīts sinhronizējot visu aktīvo uzdevumu komponensu stāvokļus ar sabojātas komponentes stāvokļiem.
Vieglākais ceļs kā veikt so sinhronizāciju būtu pārkopēt visu informāciju no aktīvām komponetēm komponentē kura tiks reintegrēta. Bet sī pieeja būtu ļoti izsķērdīga, jo informācija par kompontes stāvokli ir tikai neliela daļa no visas informācijas kas atrodas komponentē. Tapēc ir izdalīti speciālie mainīgie kuri satur stāvokļa informāciju [2].
Programmētājs var associēt katru tādu globālo vēstures mainīgo ar kādu saglabājamo atribūtu. Ciklisku processu izpildes laikā tāds vēstures saglabāsanas mainīgais saglabās nepieciesamo informāciju. Parasti tādus mainīgos lieto lai saglabātu kādus izskaitļosanas rezultātus kuri būs nepieciesami nākamai cikliska processa iterācijai. Ja komponente bija sabojāta un tagad tiek reintegrēta, tad stāvokļa informācija tajā tiek kopēta no vēstures glabāsanas mainīgiem. Mainīgie kas nesatur stāvokļa informāciju netiek izmantoti processa inicializācijas daļā, tapēc informācija no tiem netiek pārkopēta jaun integrējamā komponentē. Tādus mainīgos parasti lieto starp rezultātu glabāsanai.
Kompilātors parasti izvieto vēstures saturosos mainīgos blakus viens otram atmiņā un nodot informāciju par to glabāsanas sākumadresi un glabāsanas apgabala lielumu operētājsistēmai. Operētāj sistēma veido apraides vēstures stāvokļa ziņojumus kuri satur vajadzīgā apgabala adresi un tie tiek nosūtīti reāla laika tiklā speciālos reintegrēsanas punktos.
Uzdevumiem reāla laika sistēmās biezi rodas vajadzība zināt ārējo laiku. Tradicionālas sistēmās parasti ir tāda iespeja izdarīt reāla laika pieprasijumu un pēc pieprasījuma tiek atgriesta laika vērtība ar lielu precizitāti. Diemzēl sī precizitāte ir galīgi muļķīga, tapēc ka plānotāja lēmumus ierobezo lietojamās vērtības daļas granularitāte, kura ir protams daudz lielāka par pulksteņa granularitāti.
Tas arī vēd pie kopiju determinisma problēmas. Ja divas redundantas uzdevuma kopijas tiek izpildītas paralēli tad to nolasītās laika vērtības neizbēgami atsķirsies. Un ja so uzdevumu aprēķinos ir iekļauta nolasītā laika vērtība tad skaidrs ka so redundanto uzdevumu rezultāti arī atsķirsies, tādā veidā notiek kopiju determisma prasību pārkāpsana.
Kā rezultātā MARS sistēmā netiek izmantota patvaļīgā laika nolasīsanas iespeja. Vienīgais priekstats par laiku MARS uzdevumiem ir ieplānotais griesanas laiks. So reiz ir garantēts ka visām aktīvām uzdevuma redundantām kopijām tas būs vienāds. Pat vairāk pateicoties ieprieķs saplānotai uzdevumu cikliskai palaisanai, sis laiks var būt vienādā attālumā prieks jebkurām divām veiksmīgām uzdevuma izpildīsanām. Nav nepieciesami sistēmas pieprasijumi lai uzzināt aptaujas laiku, tajā vietā laiks tiek padots kā arguments procesā.
Ir viena situācija kad programmētājam ir saskarsanās ar kopiju determinismu. Uzdevums kas saņem ieejas datus no ārējās vides, turpmāk tiks sauksts par interfeisa uzdevumu, nav pārliecināts ka tā redundantā komponente saņems tiesi tādus pasus datus. Redundantā komponente var nolasīt citus datus ja notikumi ārējā vidē notiek ļoti tuvu viens otram laika ziņā ( var teikt ar lielu frekvenci ). Teiksim ja novērojamā procesa stāvokļa maiņa notieik ļoti tuvu lasīsanai, tad var rasties situācija kad viena komponente nolasa stāvokli pirms tas pamainās, bet otra nolasa pēc tā maiņas. Un nav svarīgi cik ciesi ir sinhronizēti komponensu pulksteņi.
Sajā situācijā kopiju determinisms nevar būt uzturēts automātiski. Bet realizēt to ir iespejams , taču, so apstrādī ir jādara viena konkrēta uzdevuma robezās. Sis uzdevums tiek palaists visās komponentēs kuras saņem ziņojumu no interfeisa komponentes. Tam jālasa abus ziņojumu gadijumus un jāizpilda to saskaņosanas algoritms. Tapēc ka redundanto komponensu saskaņotie uzdevumi saņem vienādus ziņojus, izpilda vienādus apstrādes algoritmus un viņu rezultāti arī ir vienādi un saskaņotība tiek atkal ieviesta.
Katras komponentes cikliskā daļā ir jābut vismaz vienam punktam kur katram komponentes uzdevumam ir labi definēts vēstures stāvoklis, sim vēstures stāvoklim ir jābūt identiskam redundantās komponentes atbilstosā uzdevumā vēstures stāvoklim. Par cik to ir grūti panākt uz interfeisa komponentēm, tajās nav vēstures stāvokļa.
Programmētājs kas veic MARS uzdevuma realizāciju saņem funkcionālo specifikāciju ar parametriem kuros tajā skaitā ir norādīts uzdevuma izpildes laika ierobezojums, tā sauktais laika budzets prieks uzdevuma. Sie ierobezojumi tiek uzstādīti agrākos projektēsanas posmos. Programmētājam tātad ir jārealizē (jauzkodē) uzdevums stingri ievērojot funkcionālās prāsības un jāskatās vai uzdevums izpildīsanas laikā nepatērēs vairāk laika nekā bija ieplānots.
Lai palīdzētu izpildīt sīs abas prasības programmēsanas videi ir jānodrosina programmētāju ar informāciju par uzdevuma laicīgiem parametriem izpildīsanas laikā, un it īpasi par to cik laika uzdevums patērēs sliktākā izpildīsanas gadijumā. Tas viss izvirza sekojosas prasības:
Tā kā ir jābūt garantijām ka process pabeigsies ieplānotā laikā pie jebkura izpildes gadījuma, tajā skaitā arī pie sliktākā izpildes gadijuma, sliktākā gadijuma laika robezai ir jābūt izskaitļotai un pārbaudītai pie pieejamiem resursiem.
Izskaitļotām processa izpildes laika robezām ir jābūt diezgan precīzām. Citādi var likties ka maksimālais izpildes laiks pārsniedz laika budzetu, kaut gan faktiski tas izpildes laiks būs pieļaujamās robezās. Lai atvieglot sos aprēķinus programmētājam ir jābūt informētam par ierobezojumiem tādiem kā retiem ceļiem ( programmas ceļi kuri praktisli nekad netiek izmantoti ), so informāciju nevar iegūt no programmas koda.
Programmētajam jābūt iespejai iegūt detalizētu informāciju par processa sliktākā gadijuma izpildes laiku, un to daļām. Tas dot iespeju programmētajam izvēlieties piemērotāku stratēģiju, algoritmu vai optimizācijas paņēmienu lai izveidotais uzdevums iekļautos uzstādītā laika budzetā.
Sīs trīs prasības ievērojami ietekmēja MARS programmēsanas vidi. Tie stipri iespaidoja gan projektēsanas, gan programmēsanas valodu, rīku kopas un MARS programmēsanas vides izskatu. Atlikusā nodaļas daļā būs sīkāk aprakstīti laicīgie aspekti valodas Modula/R un uzdevuma programmēsanas vide.
Programmēsanas valoda pēc savas būtības kalpo it kā par sakarnieku starp programmētāju no vienas puses un kompilātoru no otras, viņa nosaka sintaksi un semantiku. Viņa sniedz visu nepieciesamo informāciju par prosessa izpildes sliktāko gadijumu, par izpildes laika robezām un pārējos parametrus, kas attiecas uz izpildes laiku( teiksim cik laka aizņems kādu noteiktu komandu, operātoru izpilde). Informācija par laicīgiem parametriem nevar būt iegūta pie dinamiskas programmas uzvedības.
Lai stingri nodrosināt iespeju prognozēt programmas izpildes laiku valodai Modula/R ir svarīgas atsķirības no valodas Modula -2.
Modula/R valodā ir ierobezotas konstrukcijas un programmēsanas tehniskie paņēmieni, tādejādi lai varētu nodrosināt programmas izpildes laika prognozējamību.
Modula/R satur dazus paplasinājumus sālīdzinājumā ar Modula-2, kuri palīdz nodrosināt informācijas ieguvi par uzdevuma dinamiskas uzvedības laika rādītājiem. Sos faktus nevar iegūt no uzdevuma struktūras.
Modula/R nepieļauj tādas konstrukcijas kurām nevarētu prognozēt izpildes laiku vai vismaz noteikt to izpildīsanas laika robezas. Netiek paredzēts "goto" operātors (beznosacījuma pāreja), aizliegtas jebkuri rekursīvi funkciju un procedūru izsaukumi, un nav paredzētas dinamiskas datu struktūras. Turklāt - un tas ir kritiski - programmēsanas laikā programmētājam ir jānorāda visos cikla operātoros ( piemēram while operātorā ) maksimālo iterāciju skaitu (cik reiz maksimāli var izpildīties cikla operātora ķermenis). Sis maksimālais iterāciju skaits ir jānorāda papildus nosacījumiem kuru izpilde tiek kontrolēta programmas darbības laikā. Apskatīsim piemēru.
While x > y max 100 times
Do
[ Cikla ķermenis ]
Endwhile;
3.1. att. While cikla piemērs
Tātad attēlā 3.1. kas satur programmas koda piemēru var redzēt ka ir norādīts gan cikla nosacījums x > y, gan maksimālais cikla izpildes skaits max 100 times.
Rēala laika sistēmu programmētājam ir jarealizē tāda programma kas darbotos noteiktā laika budzetā, laika budzets tiek noteikts agrākās projektēsanas fāzēs [6]. Tapēc ir nepieciesama detalizēta informācija par uzrakstītā koda, vai tā daļas, izpildes laiku kad programma ir palaista. MARS programmēsanas vide ne tikai sniedz detalizētu informāciju par laicīgiem parametriem, par to, cik laika aizņem kāda bloka vai tā daļas izpilde, bet arī dot iespeju novērot kā koda maiņa ietekmēs uzdevuma izpildes laiku. Sī iespeja ir ļoti vēlama kad programmē kādu kritisku procesu ar ļoti mazu laika budzetu. No programmētāja viedokļa programmēsanas vide ir kā parastais redaktors, kas ļauj viņam eksperimentēt ar processu, vai to daļu izpildes laikiem. Apaksfonā programmēsanas vide satur kompilātoru, kas spēj ģenerēt ne tikai izpildamo kodu, bet arī uztur laicīgo informāciju, kā arī sīs informācijas analizēsanas rīkus, un tajā skaitā sliktākā izpildes gadijuma laika izskaitļotāju prieks visa processa vai tā atsevisķas daļas. Redaktors, kompilātors un laicīgās informācijas analizēsanas rīki izmaina laicīgo informāciju caur tā saukto "laika koku", kas izstrādāsanas laikā attēlo processa struktūru un processa izpildīsanas laika informāciju.
3.2. att. Programmas teksts un laika lauki
Redaktors atsķiras no citiem redaktoriem ar to ka tas satur divus apvienotus redaktorus, teksta un laika redaktoru. Teksta redaktors bāzēts uz segment orientēto pieeju, proti katra programma tiek izstrādāta un interpritēta kā secīgo segmentu kopa. Katrs no programmas segmentiem ir associēts ar savu laika logu, to var redzēt attēlā 3.2. Visi laika logi kopā veido laika redaktoru.
Teksta segmenti dod iespeju programmētājam viegli strādāt un eksperementēt ar dazādiem koda variantiem. Sī tehnika, kas saucās par laika uzlabosanas tehniku, atļauj redzēt kā mainīsies visas procedūras vai tās segmenta izpildes laiks mainot kodu, tai skaitā var arī redzet kā mainīsies sliktākā gadijuma izpildes laiks. Tas viss dot iespeju ātri sameklēt programmas gabalus kuri patērē pārāk daudz laika un iespejams uzlabot tos lai realizējamais usdevums iekļautos tam paredzētajā laika budzetā.
Projektēsanas un programmēsanas fāzes ir tikai daļas no visa vesela sistēmas izstrādes procesa. Tapēc ir arī ļoti svarīgi notestēt izstrādāto sistēmu, vai arī tās atsevisķas daļas. Ir zināms ka testēsana tas ir diezgan komplicēts, laika un darba ietilpīgs process īpasi prieks reāla laika sistēmām, kur funkcionālajai pareizībai un laicīgai uzdevuma izpildei ir vienāda svarīguma pakāpe.
Taču MARS sistēmā, to unikālo īpasību dēļ, reāla laika sistēmu testēsana ir tikai nedaudz sarezģītāka par parasto sistēmu testēsanu. To var izsecināt no sekojosiem apsvērumiem.
MARS testēsanā iegūtie rezultāti nav pirmais informācijas avots par programmas laicīgiem izpildes parametriem, kā tas biezi ir citās tradicionālās sistēmās. Programmas kopumā, un katras tās procedūras laiks ir diezgan precīzi noteikts vēl projektēsanas posmā, un testēsana tas ir tikai līdzeklis ar kura pālīdzību tas tiek atkārtoti apstiprināts.
Dazādas MARS daļas ( uzdevumi, komponentes) ir savā starpā izolētas gan funkcionālā, gan laicīgā ziņā. Ja ir izdarītas izmaiņas vienā daļā, un no tā izmainās sīs daļas izpildes laiks tad sīs izmaiņas neitekmē citu daļu izpildes laiku, to sauc par laicīgo izolāciju. Sīs laicīgās izolācijas prieksrocība ir tāda, ka tiek ļoti atvieglota jaunas sistēmas daļas integrācija sistēmā.
Sistēma uztver ieejas tikai noteiktos laika momentos. Tas samazina arējās vides scenāriju skaitu, kas sistēmai ir jāatpazīst. Un tādejādi testēsanas situāciju skaits arī samazinās. Kļust reāla attieīcība pārbaudītie gadijumi / sagaidāmiem gadijumiem.
Tapēc ka MARS ir laika trigerēta sistēma ir ralatīvi viegli reproducēt testēsanas apstākļus un rezultātus. Tas biezi ir galvenā problēma citās notikumu trigerētās sadalītās sistēmās.
Tika izstrādāta testēsanas metodoloģija kura izmanto ieprieks aprakstītos arhitektūras pakalpojumus. Tā sastāv no vairākām fāzēm. Visu so testēsanas fāzu izpilde garantē to, ka pārbaudamā sistēma tiks notestēta adekvāti.
Biezi testēsana tiek veikta vēl kodēsanas laikā, pabeidzot kādu noteiktu funkcionāli patstāvīgu uzdevumu, programmētājs pats notestē uzrakstīto gabalu vai jau nodot to testēsanai neatkarīgam testētājam. Kad viss kodēsanas process tiek pabeigts tad sistēma tiek testēta kopumā, no jauna testē katru atsevisķu uzdevumu un tiek arī pārbaudīts vai savā starpā nekonfliktē kādas sistēmas atsevisķas daļas.
Lai imitētu arējās vides iedarbi uz testējamo sistēmu tiek lietots sekojoss paņēmiens. Ieejas dati tiek ierakstīti failā un sistēma datus kurus viņai pēc idejas būtu jāsaņem no ārējās vides - lasa no sī faila. Tālāk apstrādā saņemtos datus un izejas datus atkal ierakst citā failā - izejas datu failā. Izmantojot so paņēmienu vēlāk viegli veikt pamatīgu testējamās sistēmas darbības analīzit, jo visi izejas dati ( citiem vārdiem sistēmas reakcija) ir saglabāti, un no tiem var izdarīt atbilstosus secinājumus, vai veikt kļūdu analīzi. Tiek analizēta arī sistēmas reakcija uz retām vai avārijas situācijām. Viss tas smalki tiek analizēts un kļūdu vai nepilnīgumu atklāsanas gadījumā tiek veikti atbilstosi labojumi vai papildinājumi.
Kaut gan mana darba nosaukums skan "Programmēsana reālā laika sistēmās", tiesi programmēsanas aktivitātēm es veltiju tikai pusi no sava darba. Kapēc tā ? Manuprāt, no sākuma jaieskatās tipiskas reālā laika sistēmas arhitektūrā, jāizprot kādus pakalpojumus tā sniedz, un tikai tad ķerties pie programmēsanas aktivitātēm.
Vispār programmēsana reālā laika sistēmās ir saistīta ar daudzām grutībām, programmai jābūt gan funkcionāli pareizai, gan laika ziņā laicīgai, viņa nevar patērēt laika vairāk nekā tai ir paredzēts, jo biezi tiek kontolēti kritiski processi, kuru nepareiza kontrole var novest pie katastrofiskām sekām. Un pie visa augstāk teiktā programmai ir jābūt drosai, un adekvāti jāreaģē uz visām situācijām.
Darbā aprakstītie mehānismi pamatā ir orientēti uz to lai padarītu programmu laicīgu un drosu. Tika apskatīti tādi mehānismi kā reālā laika tranzakcijas, izņēmumi, paralelitāte, ziņojumi, uzdevumi. Tās ir fundamentālas lietas. Protams katrai programmēsanas valodai kas paredzēta reālā laika sistēmu programmēsanai ir savas specifiskas īpasibas, bet augstāk minētie mehānismi ir realizēti daudzās no tām, un darbojas stipri līdzīgi.
Pamatā manā darbā viss tika apskatīts uz programmēsanas valodas Modula/R piemēra, izņemot divus jēdzienus: paralelitāti un izņēmumus. Tie tika apskatīti tā, kā viņi ir realizēti programmēsanas valodā Ada.
2. Fred B.Schneider and Richard D. Schlichting. "Fault Tolerant Process Control Software". 1981 gads.
3. G. Fohler "Realizing Changes of Operation Modes with Pre Run - Time Sheduling Hard Real - Time Systems" 1992 gads.
4. H. Kopetz and W. Ochsenreiter. "Clock Synchornization in Distributed Real - Time system" 1987 gads
Real Time System Development: The programming model MARS Tehnical University of Vienna. 1993 gads.
6. P. Puscher,Ch. Koza "Calculating the Maximum Execution Time of Real - Time programs" 1989 gads.
|
