Operacinė sistema

1. Operacinės sistemos sąvoka Operacinė sistema – tai svarbi kompiuterio įrangos sudėtinė dalis. Nagrinėdani kompiuterio įrangą, visų pirma skiriame jo techninę ir programinę įrangą. Kompiuterio techninė įranga (hardware) – tai visuma techninių priemonių, reikalingų informacijos apdorojimui ir saugojimui – integruotos mikroschemos, laidai, maitinimo šaltiniai ir kt. Tam, kad techninė įranga veiktų, reikalingos ją valdančios programos (software). Visa programinė įranga skaidoma į 2 grupes: 1. Sisteminė programinė įranga (System software), 2. Taikomoji programinė įranga (Application software). Taikomajai programinei įrangai priskiriamos programos, kurios atlieka specialius veiksmus, reikalingus vartotojo taikomiesiems uždaviniams spręsti. Pvz., taikomajai programinei įrangai yra priskiriami finansinės apskaitos sistema, kompiuterizuoto projektavimo (CAD) programų paketas ir t.t. Sisteminė programinė įranga nėra orientuota į vieną konkretų taikomąjį uždavinį. Ji yra skirta tam, kad sudaryti sąlygas taikomųjų programų kūrimui ir vykdymui. Operacinė sistema (OS) yra svarbiausia sisteminės programinės įrangos dalis. OS apibrėžimas priklauso visų pirma nuo to, kokiu požiūriu ji nagrinėjama: 1) Vartotojo požiūriu OS gali būti apibrėžiama kaip virtualus kompiuteris, paslepiantis nuo vartotojo techninės kompiuterio įrangos detales, ir vietoj jų pateikiantis vartotojui patogesnes abstrakcijas ir priemones. Disko atveju tokios abstrakcijos pavyzdys yra failas. Vartotojui dirbti su failais yra žymiai patogiau, negu kiekvienai skaitymo-rašymo operacijai nurodyti daug techninės įrangos detalių - absoliutų disko adresą, sektorių skaičių, takelį ir t.t. 2) Kompiuterio techninės įrangos požiūriu OS gali būti apibrėžiama kaip resursų valdytoja. Ji organizuoja bendrą visų kompiuterio techninės įrangos komponenčių (mikroprocesoriaus, atminties, diskinių įrenginių, terminalų, spausdintuvų, tinklo interfeiso plokščių ir kt.) darbą. Jei kelios programos varžosi dėl bendro naudojimo resursų (spausdintuvas, atmintis), OS uždavinys yra tvarkingai juos paskirstyti. Dėl resursų gali varžytis ne tik kelios programos, bet ir keletas vartotojų. OS negalima vertinti kaip kažkokio išorinio reguliatoriaus. Tai tokia pat programa, kaip ir kitos, tik skirta visos kompiuterinės sistemos valdymui ir todėl turinti dideles teises. Svarbiausios operacinės sistemos, kaip resursų valdytojos, atliekamos funkcijos yra: 1. Procesų valdymas. 2. Atminties valdymas. 3. Įvedimo-išvedimo valdymas. 4. Failų sistemos valdymas. 2. Operacinių sistemų evoliucija OS evoliucijos varomosios jėgos buvo techninis progresas ir vartotojų lūkesčiai. Evoliucijos proceso apžvalga padeda įvertinti svarbiausias šiuolaikinės OS savybes. OS evoliuciją apžvelgsime, susipažindami su problemomis ir jų sprendimais, skatinusiais šią evoliciją. 1) Programos užkrovimas (loading) ir autoužkrovimas (bootstraping). Pirmuosiuose kompiuteriuose buvo mažai galvojama apie vartotoją – jungikliai ir lemputės buvo šių kompiuterių įvedimo-išvedimo (I/O) įrenginiai. Programa buvo įvedama, jungikliais nurodant atminties adresą, o po to ir komandinį žodį. Taip kartojant, būdavo įvedama visa programa. Tada programos skaitliukas nustatomas ties pirmąja programos komanda ir spaudžiamas “Pradžios” mygtukas. Siekiant palengvinti darbą su kompiuteriu, visų pirma buvo sprendžiama programos užkrovimo (loading) problema. Buvo nuspręsta programą paruošti iš anksto ir specialiu įvedimo įrenginiu (perfojuostų ar perfokortų nuskaitymo) įvesti į kompiuterio atmintį. Tačiau perforuotų kortelių arba juostų nuskaitymui reikalinga speciali programa – užkrovėjas (loader), kurią taip pat reikia užkrauti į atmintį. Kaip užkrauti užkrovėją? Sprendžiant šį uždavinį, buvo sukurtas prietaisas, kompiuterio įjungimo metu automatiškai nuskaitantis mažą užkrovimo programą (pvz. vienos perfokortos apimties), kuri vėliau nuskaito didesnę užkrovimo programą. Programinių užkrovėjų įdiegimas ir buvo pirmasis žingsnis link šiuolaikinių operacinių sistemų. 2) Perfokortų era. Perfokortos buvo pradėtos naudoti dar XIX a. pab. elektromechaniniuose skaičiavimo įtaisuose. Tačiau jų era iš tiesų prasidėjo apie 1950–sius ir tęsėsi iki pat 1980–ųjų. Šiuo laikotarpiu atsirado ir “užduoties” (job) sąvoka. Užduotimi buvo vadinama programą ir duomenis aprašančių perfokortų kaladė. Toks principas buvo ypač patogus programų paketo įvedimui. Perfokortos taipogi buvo panaudojamos ir rezultatų išvedimui. 3) Terminalai ir printeriai. Kitas svarbus žingsnis į priekį buvo terminalo panaudojimas. Terminalu suprantamas įvedimo ir išvedimo įrenginių rinkinys. Įvedimui buvo panaudota klaviatūra, o rezultatai buvo išvedami į displėjaus ekraną arba printerį. Ilgainiui klaviatūra + displėjus gavo pavadinimą “valdymo pultas” (control console) ir tapo pagrindiniu vartotojo sąsajos įrenginiu ateities operacinėse sistemose. 4) Procesoriaus išnaudojimo efektyvumas. 1950-siais kompiuteriai ir jų darbo laikas buvo labai brangūs, todėl labai svarbūs buvo procesoriaus išnaudojimo efektyvumo padidinimo uždaviniai, tokie kaip: a) Užduočių užkrovimo laiko minimizavimas; b) Procesoriaus prastovų minimizavimas tuo metu, kai atliekamos lėtos įvedimo-išvedimo operacijos. Apie šių problemų sprendimą šiek tiek vėliau. 5) I/O valdymo sistema (input – output control system – IOCS). Buvo pastebėta, kad kiekvienoje naujoje programoje didelę dalį užima tokie patys veiksmai, pvz. įvedimo- išvedimo veiksmai. Tai paskatino sukurti standartinių programinių priemonių rinkinį, kurį galima būtų įkrauti į atmintį kompiuterio darbo pradžioje ir sudaryti galimybę prie jo prieiti visoms programoms. Tokiu principu pagrįstas įvedimo–išvedimo valdymo sistemų (IOCS) veikimas. 6) Nauji periferiniai įrenginiai. Pradėta naudoti magnetinio įrašymo technologija - magnetinės juostos ir vėliau magnetiniai diskai. Ši naujovė turėjo įtakos IOCS sudėtingumui. Dabartiniu metu plačiai naudojami optiniai diskai. 7) Nauja programinė įranga. Pirmosios programos buvo rašomos mašininiu kodu. Tobulėjant kompiuteriams ir plečiantis jų pritaikymo sričiai, reikėjo rašyti vis sudėtingesnes programas ir padaryti šį procesą kuo spartesnį. Taip atsirado Asemblerio programavimo kalba. Po Asemblerio sekė kitų programavimo kalbų ir kompiliatorių sukūrimas - FORTRAN, Algol ir t.t.. Asemblerių ir kompiliatorių įdiegimas turėjo įtakos užduoties (job) struktūros sudėtingumui. Dabar, pvz., užduotis turėjo susidėti iš tokių veiksmų sekos: a) užkrauti asemblerį, b) nuskaityti programą, parašytą asemblerio kalba, c) sukompiliuoti programą atmintyje, d) vykdyti programą, e) perduoti programai duomenis iš duomenų perfokortų. Tai buvo gana sudėtinga procedūra, vertusi ateityje ieškoti lengvesnių priemonių. 8) Naujos idėjos. Apie 1960-uosius bendromis Mančesterio Universiteto ir Ferranti kompanijos pastangomis buvo sukurtas kompiuteris Atlas, kuriame buvo panaudotos tokios naujos idėjos, kaip pertraukimų mechanizmas ir virtualios atminties sistema. Šis kompiuteris jau buvo kuriamas, galvojant apie OS darbo efektyvumą. 1964 m. IBM kompanija išleido System 360 kompiuterių seriją, kuri vėliau išsivystė į seriją System 370. Šoise serijose pirmą kartą panaudotas suderinamumo principas, t.y. tos pačios programinės priemonės palaikomos įvairiuose kompiuteriuose, nes šie kompiuteriai naudoja tą pačią architektūrą ir komandų rinkinį. Apibendrinant, pagrindiniai impulsai, sukuriant ir tobulinant pirmasias OS, buvo: • Būtinumas sumažinti užduoties užkrovimo laiką (set-up time, job loading time); • Poreikis efektyviau išnaudoti procesoriaus darbą, vykstant lėtam I/O procesui; • Standartinių IOCS funkcijų sukūrimas; • Magnetinių juostų ir diskų panaudojimas; • Naujos sisteminės programinės įrangos sukūrimas; • Naujos techninės įrangos įdiegimas (pvz. pertraukimai). Kaip šie impulsai veikė OS vystymosi raidą? 9) Nuoseklus paketinis apdorojimas (single stream batch processing). Siekiant sumažinti prastovas dėl naujų užduočių užkrovimo (set-up), programa-užkrovėjas buvo sukurtas tam, kad automatiškai iš perfokortų (arba perfojuostų) nuskaitymo įrenginio užkrauti nuoseklų užduočių srautą į kompiuterio atmintį, kur jos po to būtų viena po kitos nuosekliai vykdomos. Tokia ankstyva OS forma buvo vadinama “supervizoriumi’ arba “monitoriumi”. Nors ir paprastos savo sudėtimi, tačiau tai buvo vienos pirmųjų operacinių sistemų. Tam, kad atskirti užduotis sraute ir aiškiau apibrėžti, ką viena ar kita užduotis turi įvykdyti, perfokortų kaladėje buvo naudojamos spec. valdymo kortos (dažniausiai prasidedančios ženklais //). Šios kortos ir buvo pirma ryšio priemonė tarp vartotojo ir kompiuterio. Vėliau valdymo perfokortos tapo sudėtingesnės ir jų sistema buvo pavadinta Užduočių valdymo kalba (Job Control Language - JCL). 10) Multiprogramavimas (multiprogramming). Tolimesnis žingsnis, vystant OS, buvo multiprogramavimo įdiegimas, t.y. įgyvendinta galimybė kelioms programoms vykti vienu metu, procesoriui “persijunginėjant” nuo vienos programos prie kitos.Tokiu būdu tapo įmanoma išnaudoti procesoriaus laiką kitai programai, kai einamoji programa vykdydavo I/O funkcijas. Paketinė multiprograminė sistema dirbdavo taip: į atmintį buvo pakraunamas užduočių paketas. Kol viena iš užduočių vykdydavo I/O, procesorius pradėdavo vykdyti kitą, parinkdamas ją pagal užduotą prioriteto numerį. Vėliau multiprogramavimas buvo panaudotas ir terminaliniame (on-line) darbo režime, t.y. vartotojui dirbant prie terminalo ir tiesiogiai bendraujant su kompiuteriu. Šiuo atveju yra užtikrinamas keleto vartotojų darbas prie terminalų vienu metu, ir toks darbo principas yra vadinamas “laiko paskirstymu”. Žinoma, buvo naudojamas ir mišrus (terminalinis + paketinis) multiprograminis darbas. 11) Spooling (Simultaneous Peripheral Operations On-line) - tai I/O duomenų kaupimas, prieš perduodant juos kitai užduočiai. Svarbus patobulinimas buvo I/O duomenų tarp užduočių perdavimas per diską. Toks veiksmas leido žymiai pagreitinti tokias operacijas. Spooling buvo vienas iš ankstyviausių muliprogramavimo pritaikymų. Šiuo atveju, nuskaitymo, taikomoji ir spausdinimo programos galėjo dirbti vienu metu. 12) Realaus laiko sistemos. Plečiantis kompiuterių taikymo sferai, atsirado speciali taikomųjų uždavinių klasė - realaus laiko sistemos. Tai sistemos, kurios turi pakankamai greitai reaguoti, norėdamos paveikti aplinką. Tokių sistemų pavyzdžiu gali būti įvairios valdymo, dispečerinės sistemos, o taip pat informacinės sistemos, pateikiančios operatyvią informaciją, pvz. apie laisvas vietas lėktuvuose ar traukiniuose. Operacinės sistemos turi turėti priemones, užtikrinančias greitą tokių sistemų atsaką. Saugumo ir patikimumo aspektai taip pat labai svarbūs tokiose sistemose. 13) Dabartinės OS vystymosi kryptys. Pagrindiniai 3 momentai, lemiantys OS vystymąsi dabartiniu metu yra: a) Darbo stotys (workstations), b) Paskirstytos sistemos (distributed systems), c) Grafinis vartotojo interfeisas (graphical user interface-GUI). Darbo stotyse stengiamasi sukoncentruoti kuo didesnę skaičiuojamąją galią asmeniniam vartotojo naudojimui. Tai turėtų prieštarauti paskirstyto skaičiavimo idėjai, pagristai tinklo organizavimo principais, kur skaičiuojamoji galia ir duomenų saugojimo talpos paskirstytos tarp keleto kompiuterių. Tačiau šie du principai gali būti sėkmingai derinami tarpusavyje. 3. Operacinių sistemų struktūros principai Įvairios operacinės sistemos turi įvairią struktūrą. Šiame skyrelyje apžvelgsime 4 pagrindinius operacinių sistemų struktūros tipus. 3.1. Monolitinės sistemos Šis OS struktūros tipas kitaip dar gali būti vadinamas “betvarke”. Toks pavadinimas tinka todėl, kad monolitinių sistemų atveju beveik nėra jokios struktūros. Šio tipo OS – tai tiesiog procedūrų rinkinys. Kiekviena iš šių procedūrų, kai jai reikia, gali iškviesti bet kurią kitą procedūrą. Kiekviena procedūra turi pilnai apibrėžtą interfeisą, nusakomą perduodamais parametrais ir grąžinamais rezultatais. Monolitinė OS sukuriama, papraščiausiai sukompiliuojant ir “surišant” (“link” operacija) visas procedūras. Vis tik ir monolitinę sistemą galima pertvarkyti, įvedant bent šiek tiek struktūros. OS servisai, kitaip dar vadinami sisteminiais kreipiniais (system calls), yra iškviečiami, padedant perduodamus parametrus į sutartą vietą (pvz. į steką) ir iškviečiant specialią komandą (taip vadinamą “spąstais” – “trap”). Ši komanda perjungia kompiuterį iš vartotojo darbo režimą į supervizoriaus, arba kitaip branduolio, darbo režimą ir perduoda valdymą operacinei sistemai. Branduolio (supervizoriaus) darbo režimas yra skirtas būtent operacinei sistemai, jame leidžiamos visos komandos, skirtingai nuo taikomosioms programoms skirto vartotojo darbo režimo, kuriame kai kurios komandos yra uždraustos. Operacinė sistema, gavusi valdymą, paima perduotus parametrus ir pagal juos atpažįsta, kuris sisteminis kreipinys yra kviečiamas, ir iškviečia atitinkamą servisą. Aukščiau aprašytą nesudėtinga struktūra gali būti aprašyta 3 sluoksniais (1 pav.): 1. Pagrindinė OS procedūra, iškviečianti reikalingą servisą. 2. Servisų procedūros. 3. Pagalbinės procedūros, kurias naudoja servisai. Pagrindinė OS procedūra Servisų procedūros Pagalbinės procedūros 1 pav. 3.2. Sluoksniuotos sistemos Monolitinėse sistemose sutinkama 3 sluoksnių struktūra (1 pav.) jau yra žingsnis link griežtai sluoksniuotos struktūros operacinių sistemų, kuriose sutinkamas griežtesnis suskirstymas lygiais. Sluoksniuotoje sistemoje kiekvienas sluoksnis valdo jam skirtą sritį, leisdamas tuo nebesirūpinti aukščiau jo esantiems sluoksniams. Tokios sistemos pavyzdžiu gali būti THE operacinė sistema, sukurta Olandijoje, Eindhoveno Aukštojoje technikos mokykloje 1968 metais. Ši OS buvo skirta olandiškam kompiuteriui Electrologica X8, turinčiam 32K operatyvinę atmintį. THE operacinės sistemos struktūrą sudarė 6 sluoksniai (2 pav.). Sluoksnis Atliekama funkcija 5 Operatorius 4 Vartotojo programos 3 Įvedimo-išvedimo valdymas 2 Operatoriaus-proceso ryšys 1 Atminties ir būgno valdymas 0 Procesoriaus laiko skirstymas ir multiprograminio darbo valdymas 2 pav. 0 sluoksnis užsiima procesoriaus laiko skirstymu, suteikdamas visiems procesams paeiliui po 1 centrinio procesoriaus laiko kvantą. Visuose aukštesniuose sistemos lygiuose atskiri procesai dirba, nesirūpindami tuo, kad sistemoje yra tik vienas procesorius, kuriuo turi dalintis keletas procesų. 1 sluoksnis valdo pagrindinę operatyvinę kompiuterio atmintį ir būgną. Būgnas – tai Electronica kompiuterio išorinė atmintis, suskirstyta 512K žodžiais ir naudojama tada, kai pritrūksta pagrindinės atminties. Sluoksniuose, esančiuose virš 1-ojo, procesai nesirūpina tuo, ar jie yra pagrindinėje atmintyje, ar būgne. 1 sluoksnis visais atvejais pasirūpina, kad visą laiką pagrindinėje atmintyje būtų reikalingi puslapiai. 2 sluoksnis valdo ryšį tarp kiekvieno proceso ir operatoriaus konsolės. Virš šio sluoksnio kiekvienas procesas jaučiasi lyg turėtų savo operatorisus konsolę. 3 sluoksnis valdo įvedimo-išvedimo operacijas, o virš jo procesai nebesirūpina įvedimo-išvedimo detalėmis, naudodami abstrakčius įrenginius. 4 sluoksnyje dirbo vartotojo programos, nesirūpindamos nei procesų, nei atminties, nei konsolės, nei įvedimo-išvedimo valdymu. Galiausiai, 5 lygyje dirba specialus sistemos operatoriaus procesas. THE sistema nebuvo vienintelė, naudojusi sluoksniuotą struktūrą. Ši struktūra taip pat buvo naudojama MULTICS operacinėje sistemoje, iš kurios vėliau išsivystė ir šiandien plačiai naudojama UNIX OS. Daugelyje šiuolaikinių OS, sluoksniuotos architektūros principas naudojamas, derinant jį su kitais struktūriniais principais. Dažniausiai sluoksniuota struktūra pasižymi įvedimo-išvedimo posistemės. 3.3. Virtualios mašinos Vystantis dideliems kompiuteriams, atsirado galimybė daugelio vartotojų darbui prie terminalų vienu metu. Tokiam darbui valdyti buvo kuriamos paskirstyto laiko operacinės sistemos. Tokių sistemų sėkmė priklauso nuo sugebėjimo suteikti kiekvienam atskirai paimtam vartotojui virtualią darbo aplinką. Sėkminga OS, kurioje buvo panaudotas virtualių mašinų principas, yra laikoma IBM sukurta CP/CMS (vėliau pavadinta VN/370) operacinė sistema. Šioje sistemoje buvo aiškiai atskirtos multiprograminio darbo organizavimo ir virtualios mašinos suteikimo vartotojui funkcijos. Sistemos šerdis yra apatiniame lygyje dirbantis virtualių mašinų monitorius, valdantis multiprograminį darbą sistemoje, ir leidžiantis panaudoti virtualias mašinas aukštesniame sluoksnyje (3 pav.). CMS CMS CMS VMS/370 – virtualių mašinų monitorius IBM 370 kompiuterio techninė įranga 3 pav. Vartotojui suteikiama virtuali mašina šiuo atveju yra ne kas kita, kaip 370 kompiuterio techninės įrangos kopija, turinti savo operacinę sistemą (CMS). 3.4. Kliento-serverio modelis Virtualių mašinų atveju išryškėjo tendencija didelę dalį OS nukelti į aukštesnį lygį, žemesniajame paliekant tik svarbiausią dalį – tam tikrą sistemos branduolį. Vis tik virtualių mašinų sistemose šis branduolys dar yra didelis ir sudėtingas. Toliau vystant operacines sistemas, buvo siekiama branduolį padaryti kiek galima mažesnį, didžiąją sistemos dalį organizuojant vartotojo procesų pavidalu. Šiuo atveju, operacinės sistemos moduliai, veikiantys kaip vartotojo procesai, yra vadinami serveriais, atliekančiais tam tikras sistemines funkcijas, tuo tarpu įprasti vartotojo procesai yra vadinami klientais, naudojančiais serverių paslaugas (4 pav.). Kliento procesas Kliento procesas Procesų serveris Terminalo serveris . . . Failų serveris Atminties serveris Mikrobranduolys 4 pav. Norėdamas gauti tam tikrą servisą, pavyzdžiui perskaityti tam tikrą disko bloką, kliento procesas siunčia užsakymą serverio procesui, kuris jį įvykdo ir siunčia atgal atsakymą. Toks atskirų sistemos suskaidymas į mažesnes funkcines dalis daro sistemą paprastesne, patikimesne ir lengviau valdoma. Pavyzdžiui, sutrikus failų serverio darbui, nesutrinka visos sistemos darbas. Be to, kliento-serverio modelis leidžia išnaudoti paskirstytų sistemų privalumus. Paskirstytoje sistemoje atskirus operacinę sistemą sudarančius serverius galima vykdyti skirtinguose sistemos kompiuteriuose. 4. Procesai 4.1. Proceso sąvoka Procesas – tai programa jos vykdymo metu. Procesą sudaro pati programa, jos duomenys ir steaks, programos skaitliukas, steko nuoroda, registrai bei kita tarnybinė informacija, reikalinga programai vykdyti. Multiprograminėse sistemose vienu metu dirba daug procesų, kuriems centrinio procesoriaus laiką skirsto operacinės sistemos dalis, vadinama procesų planuotoju. Procesui išnaudojus jam skirtą procesoriaus darbo laiko kvantą, planuotojas laikinai sustabdo procesą ir perduoda valdymą kitam procesui. Kaip procesas laikinai sustabdomas, turi išlikti galimybė vėliau jį pratęsti vykdyti lygiai toje pačioje būsenoje, kurioje jis buvo jų sustabdžius. Tokiu būdu, turi būti išsaugota visa informacija apie procesą jo sustabdymo metu. Pavyzdžiui, būtina išsaugoti informaciją apie skaitymo žymes kiekviename proceso naudojamame faile, kad READ kreipinys, pratęsus proceso vykdymą, nuskaitytų teisingus duomenis. Paprastai, su procesu susijusi išsaugoma informacija susideda iš jo užimamos adresų erdvės turinio (core image) ir atitinkamo elemento procesų lentelėje. Procesų lentelė – tai struktūrų masyvas arba susietas struktūrų sąrašas, kuriame kiekviena struktūra aprašo vieną iš egzistuojančių procesų. Daugelio procesų vykdymas vienu metu, turint vieną procesorių ir planuotojui skirstant jo laiką, yra vadinamas pseudolygiagrečiu procesų darbu. Nors iš tikrųjų tam tikru konkrečiu momentu centrinį procesorių naudoja tik vienas procesas, visi procesai, dirbdami pakaitomis, “stumiasi” į priekį po laiko kvantą ir vartotojui susidaro iliuzija, kad visi procesai vyksta tuo pačiu metu, t.y. lygiagrečiai. Procesų darbui valdyti yra skirti įvairūs servisai, iškviečiami atitinkamais sisteminiais kreipiniais. Svarbiausi sisteminiai kreipiniai procesų valdymui yra šie: ▪ FORK – procesų-vaikų sukūrimui (sukuriamas procesas, identiškas procesui-tėvui), ▪ EXEC – proceso kodo perrašymui, iškviečiant norimą programą, ▪ SIGNAL, KILL – signalų priėmimui ir siuntimui, procesams bendraujant tarpusavyje. FORK sisteminis kreipinys leidžia sistemoje sukurti procesų medį. Šiame medyje kiekvienas procesas turi vieną procesą-tėvą, tačiau gali turėti kelis procesus-vaikus. 4.2. Proceso būsenos Nors kiekvienas procesas yra nepriklausomas vienetas, procesams dažnai tenka bendrauti su kitais procesais. Pavyzdžiui, vienas procesas gali generuoti išėjimo duomenis, kurių savo įėjime laukia kitas procesas. Tarkime, turime UNIX operacinės sistemos komandą: cat chap1 chap2 chap3 | grep tree Šioje komandoje panaudotos 2 operacijos: “cat” sujungia 3 failus (“chap1”, “chap2” ir “chap3”), o “grep” jungtiniame faile ieško eilučių, kuriose yra žodis “tree”. Paleidus vykdyti tokią komandinę eilutę, sistemoje iš karto gimsta 2 procesai, vykdantys atitinkamai “cat” ir “grep” operacijas. Greičiausiai šioje situacijoje nutiks taip, kad “grep” kurį laiką negalės dirbti, kol nesulauks duomenų iš “cat”. Jį reikės užlokuoti, kol bus paruošti duomenys. Paprasatai procesas yra blokuojamas, kai jis logiškai negali tęstis (pvz., neturi duomenų). Taip pat galimas atvejas, kai procesas pasiruošęs ir gali vykti, tačiau yra sustabdomas, nes planuotojas nusprendė skirti centrinio procesoriaus laiką kitam procesui. Galimos procesų būsenos pavaizduotos 5 pav. diagramoje. 5 pav. 5 pav. diagramoje pavaizduotos 3 procesų būsenos: 1. Aktyvus procesas – tuo metu naudoja centrinį procesorių. 2. Blokuotas procesas – logiškai negali būti vykdomas, kol neįvyks tam tikras išorinis įvykis (pvz. bus paruošti duomenys). 3. Pasiruošęs procesas – gali būti vykdomas, tačiau yra laikinai sustabdytas, planuotojui užleidus centrinį procesorių kitam procesui. 5 pav. diagramoje taip pat pavaizduoti 4 galimi perėjimai tarp įvairių proceso būsenų: ▪ Perėjimas 1. Procesas pamato, kad negali tęsti darbo ir užsiblokuoja, dažnaiusiai iškviesdamas blokavimą atliekantį sisteminį kreipinį. ▪ Perėjimai 2 ir 3. Juos atlieka procesų planuotojas, procesams nežianant. ▪ Perėjimas 4. Atliekamas, įvykus proceso laukiamam išoriniam įvykiui. 4.3. Procesų tarpusavio sąveika Natūralu, kad procesams tenka bendrauti tarpusavyje. Pavyzdžiui, taikant konvejerio principą, pirmojo proceso išėjimo duomenys turi būti perduoti antrajam procesui. Šioje paskaitoje ir nagrinėjami procesų tarpusavio sąveikos (interprocess communication) būdai ir su šia sąveika susijusių problemų sprendimai. 4.3.1. Procesų lenktynės Operacinėje sistemoje kartu dirbantys procesai paprastai yra priversti bendrai naudoti tam tikrą atminties sritį, kurioje jie gali tiek skaityti, tiek ir rašyti. Tai gali būti tam tikra operatyvinės atminties sritis arba bendro naudojimo failas. Nepriklausomai nuo bendrai naudojamos atminties tipo, problemos yra tos pačios. Pats papraščiausias tokio bendro atminties naudojimo atveju iškylančios problemos pavyzdys yra spausdinimo buferizacijos (print spooling) atvejas. Kai procesas nori atspausdinti failą, jis įrašo jo vardą į specialų katalogą (spooler directory). Tarnybinis procesas, vadinamas spausdinimo demonu (printer daemon), periodiškai patikrina, ar yra failų, parengtų spausdinimui. Jei tokių failų yra, jie atspausdinami, o jų vardai ištrinami iš šio specialaus katalogo. Įsivaizduokite, kad minėtą specialų katalogą sudaro daug sunumeruotų ląstelių 0, 1, 2, …, iš kurių kiekvienoje galima įrašyti spausdinamo failo vardą (6 pav.). Taip pat įsivaizduokite, kad turime 2 bendro naudojimo kintamuosius: out, kuris rodo į sekantį spausdintiną failą, ir in, kuris rodo į sekančią laisvą ląstelę specialiajame kataloge. Šie 2 kintamieji, pavyzdžiui, gali būti saugomi dviejų žodžių faile, prieinamame visiems procesams. Tarkime, kad tam tikru laiko momentu ląstelės 0 - 3 yra tuščios (failai jau atspausdinti), o ląstelės 4 - 6 užimtos failų, kuriuos dar reikia atspausdinti, vardais. Maždaug tuo pačiu metu procesai A ir B nusprendžia, kad jie norėtų į eilę patalpinti po spausdinimui skirtą failą. 6 pav. Visiškai įmanoma tokia situacija. Procesas A nuskaito kintamojo in reikšmę (7) ją išsaugo savo vidiniame kintamajame next_free_slot. Tuo metu įvyksta laiko pertraukimas, ir OS nusprendžia, kad procesas A jau buvo vykdomas pakankamai ilgai, tad jis sustabdomas ir aktyviu tampa procesas B. B taip pat perskaito in, taip pat gauna reikšmę 7, išsaugo savo spausdintino failo vardą ląstelėje Nr. 7, po to padidina in reikšmę vienetu, t.y. ši tampa lygi 8. Tada procesas B tęsia kitus savo darbus. Kai po kurio laiko procesas A vėl tampa aktyvus, jis tęsia savo darbą iš tos būsenos, kurioje jis buvo sustabdytas. Taigi, jis pasižiūri į kintamojo next_free_slot reikšmę, pamato, kad ji lygi 7, ir išsaugo savo spausdintino failo vardą 7-oje ląstelėje, ištrindamas ten jau anksčiau proceso B įrašytą failo vardą. Tada procesas A suskaičiuoja next_free_slot+1, gauna 8, ir įrašo šią reikšmę į kintamąjį in. Tokiu būdu, specialusis spausdinimo katalogas vėl sutvarkytas, todėl spausdinimo demonas jokios klaidos nematys, tačiau procesas B niekuomet nesulauks savo spausdinimo rezultatų. Aukščiau paminėta problema atsitinka, susidarius taip vadinamoms procesų lenktynių sąlygoms (race conditions). Programas, kuriose tokia situacija gali nutikti, yra labia sunku derinti. Paprastai tokiu atveju testai rodo skirtingus rezultatus, tačiau vykdant šią programą gali nutikti netikėčiausių situacijų. 4.3.2. Kritinės zonos Kaip išvengti procesų lenktynių? Akivaizdus sprendimas būtų uždrausti daugiau negu vienam procesui tuo pačiu metu skaityti arba rašyti bendro naudojimo duomenis. Tokia priemonė vadinama tarpusavio eliminavimu (mutual exclusion) - kol vienas procesas naudoja bendrą kintamąjį, kiti procesai yra eliminuojami, t.y. jiems uždraudžiama šį kintamąjį naudoti. Skyrelio 4.1 pavyzdyje problema buvo ta, kad procesas B pradėjo naudoti vieną iš bendrų kintamųjų, procesui A dar nebaigus darbo su juo. Atitinkamų tarpusavio eliminavimo veiksmų pasirinkimas yra vienas iš svarbiausių klausimų operacinių sistemų projektavime. Apie tokius veiksmus toliau ir bus kalbama šiame skyriuje. Procesų lenktynių išvengimo problemą galima suformuluoti abstrakčiai. Dalį laiko procesas atlieka vidines operacijas, kurios nesukelia procesų lenktynių. Tačiau tam tikrais momentais procesui gali tekti dirbti su bendro naudojimo duomenimis arba atlikti kitus kritinius veiksmus, kurie gali sukelti procesų lenktynes. Programos dalis, kurioje atliekami veiksmai su bendro naudojimo atmintimi, vadinama kritine zona (critical section). Jei būtų įmanoma sutvarkyti taip, kad tuo pačiu metu jokie 2 procesai nebūtų savo kritinėse zonose, būtų galima išvengti procesų lenktynių. Nors minėtas reikalavimas ir leidžia išvengti procesų lenktynių, tačiau jo nepakanka, kad procesai teisingai ir efektyviai bendradarbiautų, naudodami bendrus duomenis. Norint turėti gerą sprendimą, reikia patenkinti 4 sąlygas: 1) Jokie 2 procesai tuo pačiu metu negali būti savo kritinėse zonose. 2) Negalima daryti jokių prielaidų apie centrinių procesorių skaičių ir greičius kompiuterio sistemoje. 3) Joks procesas, esantis už savo kritinės zonos ribų, negali užblokuoti kito proceso. 4) Joks procesas neturi laukti be galo ilgai, kad įeiti į savo kritinę zoną. 4.3.3. Tarpusavio eliminavimas su aktyviu laukimu Šiame skyrelyje nagrinėjami įvairūs metodai procesų tarpusavio eliminavimui atlikti, nurodomi jų privalumai ir trūkumai. Kadangi dažniausiai, atlikdamai tarpusavio eliminavimo veiksmą, procesai priversti atlikti laukimo ciklus, be reikalo naudojančius kompiuterio centrinio procesoriaus laiką, tokie metodai vadinami tarpusavio eliminavimo su aktyviu laukimu (Mutual exclusion with Busy waiting) metodais. 4.3.3.1. Pertraukimų uždraudimas Papraščiausias tarpusavio eliminavimo sprendimas gali būti įdiegtas, leidžiant procesui uždrausti visus pertraukimus tuoj po to, kai jis įeina į savo kritinę zoną, ir vėl juos atlaisvinti prieš pat jam išeinant iš kritinės zonos. Uždraudus pertraukimus, negali įvykti ir laiko pertraukimas, o tai yra vienintelis būdas OS sustabdyti vieno proceso vykdymą ir perduoti centrinį procesorių kitam procesui. Toks sprendimas yra labai nepriimtinas, kadangi neprotinga vartotojo procesui suteikti galią uždrausti pertraukimus. Sakykim, vienas iš jų uždraudė pertraukimus, tačiau po to užmiršo juos atlaisvinti? Tai sustabdytų visos OS darbą. Taip pat toks sprendimas yra blogas tuo atveju, kai sistemoje yra keli procesoriai, nes šiuo atveju draudimas galioja tik procesoriui, kuris įvykdė uždraudimo komandą. Tačiau toks sprendimas be problemų gali būti naudojamas pačios operacinės sistemos reikmėms. OS branduolys (kernel) dažnai naudoja šį metodą, pavyzdžiui uždraudžia pertraukimus kelių instrukcijų vykdymo metu, kol pertvarkomi sistemos naudojami kintamieji, lentelės arba sąrašai. 4.3.3.2. Užrakto kintamieji Programinis problemos sprendimas yra galimas, panaudojant taip vadinamus užrakto kintamuosius (lock variables). Tegul turime vieną bendro naudojimo kintamąjį – užrakto kintamąjį, kurio reikšmė pradiniu laiko momentu lygi 0. Kai procesas nori įeiti į savo kritinę zoną, jis visų pirma patikrina užraktą. Jei jis lygus 0, procesas pakeičia jo reikšmę į 1 ir įeina į kritinę zoną. Jei užraktas jau lygus 1, procesas tiesiog laukia, kol jis taps lygus 0. Tokiu būdu, 0 reiškia, kad joks procesas nėra savo kritinėje zonoje, tuo tarpu kai 1 žymi, jog kažkuris procesas yra savo kritinėje zonoje. Deja, šis metodas turi tą patį trūkumą, kaip ir anksčiau pateiktas spausdinimo buferizavimo pavyzdys. Tarkime, jog vienas procesas perskaito užrakto reikšmę ir pamato, kad ji lygi 0. Prieš jam spėjant pakeisti užrakto reikšmę į 1, OS perduoda centrinį procesorių kitam procesui, ir jau šis procesas nustato užrakto reikšmę į 1. Kai pirmasis procesas vėl tampa aktyviu, jis taip pat nebetikrinęs nustato užrakto reikšmę į 1, ir vėl abu procesai tuo pačiu metu patenka į savo kritines zonas, sudarydami lenktynių situaciją. Taigi, reikia galvoti apie papildomas priemones, kurias derinant kartu su užrakto kintamųjų panaudojimu, galima būtų išvengti lenktynių situacijos. 4.3.3.3. Griežtas pakaitumas Vienas iš galimų sprendimų yra griežto pakaitumo (strict alteration) metodas, kurį geriausia iliustruoti pavyzdyje pateikiamu programos fragmentu (7 pav.). while (TRUE) { while (TRUE) { while (turn != 0) /* wait */ while (turn != 1) /* wait */ critical_section (); critical_section (); turn = 1; turn = 0; noncritical_section (); noncritical_section (); } } (A) (B) 7 pav. Šiame pavyzdyje sveiko tipo kintamasis turn, kurio pradinė reikšmė lygi 0, seka kurio proceso eilė įeiti į kritinę zoną ir dirbti su bendro naudojimo atmintimi. Pradžioje procesas A patikrina turn, randa jį lygų 0 ir įeina į kritinę zoną. Procesas B taip pat pamato, kad šis kintamasis lygus 0, ir suka ciklą, nuolat tikrindamas turn ir laukdamas, kol jo reikšmė taps lygi 1. Toks laukimas, kai yra nuolatos tikrinamas kintamasis, vadinamas aktyviu laukimu (busy waiting). Aktyvaus laukimo kiek įmanoma reikėtų vengti, kadangi jo metu naudojamas brangus centrinio procesoriaus laikas. Kai procesas A išeina iš kritinės zonos, jis nustato turn reikšmę į 1, tuo būdu leisdamas procesui B įeiti į jo kritinę zoną. Tarkime, kad procesas B greitai baigė darbą savo kritinėje zonoje, ir tam tikru momentu abu procesai yra savo nekritinėse zonose, o turn reikšmė lygi 0. Po to procesas A įeina į kritinę zoną, greitai atlieka darbus joje, ir vėl grįžta į nekritinę zoną, nustatęs turn reikšmę į 1. Tarkime, kad šioje situacijoje procesas A vėl dirba greičiau už B ir prieina tašką, kai jam vėl reikia įeiti į kritinę zoną. Tačiau jis to padaryti negali, kadangi turn reikšmė lygi 1, o procesas B dar tebedirba savo nekritinėje zonoje. Pavyzdys rodo, kad griežto pakaitumo metodas nėra geras, kai vienas iš procesų yra žymiai lėtesnis už kitą. Šioje situacijoje pažeidžiama ankčiau įvardinta sąlyga – procesą A blokuoja (neleidžia dirbti) kitas procesas, nesantis savo kritinėje zonoje. 4.3.3.4. Petersono sprendinys Suderinęs pakaitinio darbo ir užrakto kintamųjų idėjas, olandų matematikas T.Dekker pirmasis pasiūlė programinį tarpusavio eliminavimo problemos sprendimą, nereikalaujantį griežto pakaitumo. Deja, jo algoritmas buvo per daug sudėtingas, kad jį būtų galima taikyti praktikoje. 1981 m. G.L.Petersonas pasiūlė panašų, tačiau paprastesnį sprendimą, kuris pateikiamas 8 pav. esančiame programos fragmente. # include “prototypes.h” # define FALSE 0 # define TRUE 1 # define N 2 /* procesų skaičius */ int turn; /* kieno eilė? */ int interested[N]; /* pradžioje visos reikšmės = 0 (FALSE) */ void enter_region (int process) /* process: kas įeina (0 ar 1) */ { int other; /* kito proceso numeris */ other = 1 – process; /* priešinga nei ‘process’ */ interested [process] = TRUE; /* parodome, kad esame suinteresuoti */ turn = process; /* nustatome požymį */ while (turn == process && interested [other] == TRUE); } void leave_region (int process) /* process: kas išeina (0 ar 1) */ { interested {process] = FALSE; /* parodome, kad išeiname iš kritinės zonos */ } 8 pav. Prieš panaudojant bendrus kintamuosius, t.y. prieš įeinant į kritinę zoną, kiekvienas procesas iškviečia enter_region, perduodamas šiai procedūrai kaip parametrą savo proceso numerį (0 arba 1). Šiuo kreipiniu priverčiama, jei reikia, laukti, kol bus saugu įeiti į kritinę zoną. Baigus darbą su bendro naudojimo kintamaisiais, procesas iškviečia leave_region, nurodydamas, kad jis baigė, ir leisdamas kitam procesui įeiti jei reikia. 4.3.3.5. TSL instrukcija Įdomus yra TSL instrukcijos panaudojimo sprendimas, tačiau jis reikalauja specialių priemonių techninėje įrangoje. Daugelis kompiuterių, ypač tie, kuriuose numatytas keleto procesorių panaudojimas, turi instrukciją TEST AND SET LOCK (TSL), kuri atlieka sudėtinę funkciją. Ji nuskaito atminties žodžio turinį į registrą ir tuo pačiu atminties adresu įrašo nenulinę reikšmę. Garantuojama, kad nuskaitymo ir įrašymo operacijos atliekamos vienu nedalomu veiksmu – joks kitas procesorius negali prieiti prie atminties žodžio, kol TSL instrukcija nebaigė darbo. Procesorius, vykdantis šią instrukciją, užrakina atminties magistralę, kad uždrausti kitiems procesoriams prieiti prie atminties kol jis nebaigė darbo. Taikant TSL instrukciją, priėjimui prie bendro naudojimo atminties koordinuoti naudojamas kintamasis (pvz. flag). Kai flag lygus 0, bet kuris procesas jį gali nustatyti į 1, panaudodamas TSL instrukciją, ir tada naudoti bendrą atmintį. Baigęs darbą, procesas nustato flag į 0 paprasta MOVE komanda. 9 pav. pateiktas programos fragmentas, parodantis, kaip galima panaudoti TSL instrukciją, uždraudžiant 2 procesams tuo pačiu metu įeiti į savo kritines zonas. enter_region: tsl register, flag | nukopijuojame ‘flag’ į registrą ir nustatome lygų 1 cmp register, #0 | ar ‘flag’ buvo lygus 0? jnz enter_region | jei nebuvo lygus 0, užraktas buvo įjungtas, todėl sukame ciklą ret | grįžtame įėję į kritinę zoną leave_region: mov flag, #0 | įrašyti 0 į ‘flag’ ret | grįžtame 9 pav. 4.3.4. “Miegoti ir pažadinti” grupės metodai Tiek Petersono sprendinys, tiek ir sprendinys, panaudojant TSL instrukciją, yra naudotini, tačiau abu turi tą patį trūkumą, kai tenka naudoti aktyvų laukimą. Tai ne tik veltui naudoja brangų centrinio procesoriaus laiką, bet ir gali atvesti į aklavietę kai kuriais atvejais. Pavyzdžiui, tarkime, kad turime 2 procesus – H su aukštu prioritetu ir L su žemu prioritetu. Procesų planavimo taisyklės yra tokios, kad procesas H vykdomas visada, kai tik yra pasiruošęs. Tegul, procesui L esant jo kritinėje zonoje, procesas H pereina į pasiruošusio proceso būseną (pvz. baigia įvedimo-išvedimo operaciją). Tokiu atveju, H pereina į aktyvų laukimą, tačiau tuo metu L nebegali dirbti, nes jam neleidžia procesų planuotojas tol, kol dirba H. Taigi, L negali išeiti iš kritinės zonos, o H be galo suka ciklą. “Miegoti ir pažadinti” (Sleep and Wakeup) bgrupės metodai, pristatomi šiame skyrelyje, vietoje aktyvaus laukimo naudoja blokavimą, kai negalima įeiti į kritinę zoną. Blokavimo atlikimo pavyzdys – sisteminių kreipinių SLEEP ir WAKEUP pora. SLEEP priverčia šį kreipinį iškvietusį procesą užsiblokuoti, kol kitas procesas su WAKEUP jo nepažadins. 4.3.4.1. Gamintojo-vartotojo uždavinys Geru pavyzdžiu, kaip galima naudoti anksčiau paminėtus blokavimo ir žadinimo sisteminius kreipinius, yra gamintojo-vartotojo uždavinys. Įsivaizduokime riboto dydžio sandėlį. Vienas iš procesų, gamintojas, deda gaminius į sandėlį, o kitas, vartotojas, ima gaminius iš sandėlio. Problema kyla tada, kai gamintojas nori padėti naują gaminį į sandėlį, o šis pilnas. Tada gamintojui reikia užmigti ir laukti, kol vartotojas jį pažadins po to, kaik paims iš sandėlio vieną ar kelis gaminius. Panašiai, jei vartotojas nori paimti gaminį iš sandėlio, o šis tuščias, jis užmiega, kol gamintojas jo nepažadins po to kai ką nors padės į sandėlį. 10 pav. pateiktas vienas iš gamintojo-vartotojo uždavinio sprendimų. Jame naudojamas kintamasis count, kuris seka, kiek gaminių yra sandėlyje. # include “prototypes.h” # define N 100 /* vietų skaičius sandėlyje */ int count = 0; /* gaminių skaičius sandėlyje */ void producer (void) { int item; while (TRUE) { /* begalinis ciklas */ produce_item(&item); /* pagaminti naują gaminį */ if (count == N) sleep(); /* jei sandėlys pilnas, užmiegama */ enter_item (item); /* padėti gaminį į sandėlį */ count = count + 1; /* padidinti gaminių skaitliuką vienetu */ if (count == 1) wakeup (consumer); /* ar sandėlys buvo tuščias? */ } } void consumer (void) { int item; while (TRUE) { /* begalinis ciklas */ if (count == 0) sleep (); /* jei sandėlys tuščias, užmiegama */ remove_item(&item); /* paimti gaminį iš sandėlio */ count = count - 1; /* sumažinti gaminių skaitliuką vienetu */ if (count == N-1) wakeup (producer); /* ar sandėlys buvo pilnas? */ consumer_item (item); /* sunaudoti gaminį */ } } 10 pav. Šiame pavyzdyje lenktynės vis tik gali įvykti. Tarkime, kad sandėlys tuščias, ir vartotojas ką tik nuskaitė kintamojo count reikšmę, kad patikrinti ar ji lygi 0. Tuo momentu procesų planuotojas sustabdo vartotojo procesą ir aktyvizuoja gamintoją. Gamintojas pagamina vieną gaminį, padidina count ir pamato, kad šis lygus 1. Galvodamas, kad count ką tik buvo 0, ir vartotojas gali miegoti, gamintojas iškviečia WAKEUP kreipinį, norėdamas pažadinti vartotoją. Tuo tarpu vartotojas logiškai nemiega, tad žadinimo signalas prarandamas. Kai vartotojas vėl aktyvizuojamas, jis pasitikrina anksčiau nuskaitytą count reikšmę, pamato, kad ji lygi 0, ir užmiega. Anksčiau ar vėliau gamintojas pripildo sandėlį ir taip pat užmiega. Abu miega amžinai. Problemą galima išspręsti, papildomai panaudojus žadinimo laukimo bitą (wakeup waiting bit). Jei žadinimas siunčiamas procesui, kuris nemiega, šis bitas nustatomas į 1. Vėliau, kai procesas nori užmigti, jis pasitikrina ar šis bitas nelygus 1, ir jei taip, neužmiega. 4.3.4.2. Semaforai 1965 m. olandų matematikas E.W.Dijkstra pasiūlė panaudoti sveiką kintamąjį žadinimų saugojimui, siekiant juos panaudoti vėliau. Jis įvedė naujo tipo kintamąjį – semaforą, kuris galėjo įgyti reikšmę 0 (nėra žadinimų) arba teigiamą reikšmę (yra žadinimų). Dijkstra taip pat pasiūlė 2 semaforams skirtas operacijas – DOWN ir UP (SLEEP ir WAKEUP analogai). DOWN operacija semaforui patikrina, ar jo reikšmė yra didesnė už 0. Jei taip, ji sumažinama 1 ir darbas tęsiamas. Jei ji lygi 0, procesas užmigdomas. Visa tai atliekama nedalomu atominiu veiksmu, t.y. procesas tame intervale negali būti sustabdomas. UP instrukcija padidina semaforo reikšmę 1-u. Jei prie šio semaforo tuo metu miega vienas arba keli procesai, nrgalėdami atlikti DOWN operacijos, iš jų atsitiktinai parenkamas vienas ir jam leidžiama atlikti DOWN. Šios operacijos taip pat atliekamos vienu nedalomu veiksmu. Semaforai leidžia išspręsti prarastų žadinimų problemą. Svarbu tai, kad semaforams taikomos UP ir DOWN operacijos yra nedalomos. Natūralu UP ir DOWN įdiegti kaip sisteminius kreipinius, kurių veikimo metu OS uždraudžia pertraukimus, kol tikrianamas semaforas, užmigdomas procesas ir atliekami kiti veiksmai. Visi šie veiksmai užima tik keletą komandų, todėl pertraukimų uždraudimas žalos nepadaro. 11 pav. pateikiamas gamintojo-vartotojo uždavinio sprendimas, panaudojant semaforus. # include “prototypes.h” # define N 100 /* vietų skaičius sandėlyje */ semaphore mutex = 1; /* valdo priėjimą prie kritinės zonos */ semaphore empty = N; /* skaičiuoja sandėlyje esančias laisvas pozicijas*/ semaphore full = 0; /* skaičiuoja sandėlyje esančius gaminius*/ void producer (void) { int item; while (TRUE) { /* begalinis ciklas */ produce_item (&item); /* pagaminam naują gaminį */ down (&empty); /* dekrementuojam skaitliuką ‘empty’ */ down (&mutex); /* įeiname į kritinę zoną */ enter_item (item); /* padedame gaminį į sandėlį */ up (&mutex); /* išeiname iš kritinės zonos */ up(&full); /* inkrementuojame gaminių skaitliuką ‘full’ */ } } void consumer (void) { int item; while (TRUE) { /* begalinis ciklas */ down (&full); /* dekrementuojam skaitliuką ‘full’ */ down (&mutex); /* įeiname į kritinę zoną */ remove_item (item); /* paimame gaminį iš sandėlio */ up (&mutex); /* išeiname iš kritinės zonos */ up(&empty); /* inkrementuojame gaminių skaitliuką ‘empty’ */ produce_item (&item); /* sunaudojame gaminį */ } } 11 pav. Sprendžiant gamintojo-vartotojo uždavinį, panaudojami 3 semaforai: “full” – skaičiuoja gaminius, “empty” – skaičiuoja laisvas vietas sandėlyje, “mutex” – užtikrina, kda gamintojas ir vartotojas nesikreipia į sandėlį vienu metu. Pradžioje full=0, empty=N, mutex=1. Semaforai, kuriuos naudoja vienas ar keli procesai, kad užtikrinti tik vieno proceso įėjimą į kritinę zoną vienu metu, vadinami dvejetainiais semaforais. Jie gali įgyti tik 2 reikšmes: 0 ir 1. Tokie semaforai paprastai naudojami procesų tarpusavio eliminavimui. Jei kiekvienas procesas įvykdys DOWN prieš įeidamas į kritinę zoną, ir UP tuoj pat po išėjimo iš kritinės zonos, procesų tarpusavio eliminavimas garantuotas. Naudojant semaforus, kompiuterių sistemose valdomas pertraukimų mechanizmas. Kiekvienas įvedimo-išvedimo įrenginys turi su juo susietą semaforą, kurio pradinė reikšmė lygi 0. Tik paleidus įvedimo-išvedimo įrenginį, su juo susietas serverio procesas įvykdo komandą DOWN, ir, kadangi semaforas lygus 0, tuoj pat užmiega. Atėjus atitinkamam pertraukimo signalui, pranešančiam apie poreikį pasinaudoti įrenginiu, pertraukimų tvarkymo programa atitinkamam semaforui įvykdo komandą UP ir tuo būdu perveda serverio procesą į parengties būseną. 4.3.4.3. Įvykių skaitliukai Šalia semaforų, procesų tarpusavio sąveikos uždaviniuose taip pat yra naudojami ir įvykių skaitliukai (event counters). Tai taip pat specialūs kintamieji, kurie nuo semaforų skiriasi tuo, kad jų reikšmės visą laiką tik didėja, tuo tarpu kai semaforo reikšmė gali ir didėti, ir mažėti. Naudodami įvykių skaitliukus, išvengiame tiesioginio procesų tarpusavio eliminavimo. Pradinė skaitliuko reikšmė visada yra 0. Su įvykių skaitliukais yra siejamos 3 operacijos: 1. READ (E) – nuskaityti įvykių skaitliuko E reikšmę. 2. ADVANCE (E) – padidinti įvykių skaitliuko E reikšmę 1. 3. AWAIT (E, v) – laukti, kol įvykių skaitliuko E reikšmė taps ne mažesnė už ‘v’. Panagrinėsime tą patį gamintojo-vartotojo uždavinį, Tegul turime 2 įvykių skaitliukus. Pirmasis, ‘in’, kaupia į buferį padėtų įrašų skaičių nuo pat darbo pradžios. Antrasis, ‘out’, atitinkamai kaupia iš buferio paimtų įrašų skaičių. Aišku, kad in >= out, tačiau visada in-out j, tai A nebegali prašyti j, ir priešingai, jei i

Daugiau informacijos...

★ Klientai rekomenduoja

Šį rašto darbą rekomenduoja mūsų klientai. Ką tai reiškia?

Mūsų svetainėje pateikiama dešimtys tūkstančių skirtingų rašto darbų, kuriuos įkėlė daugybė moksleivių ir studentų su skirtingais gabumais. Būtent šis rašto darbas yra patikrintas specialistų ir rekomenduojamas kitų klientų, kurie po atsisiuntimo įvertino šį mokslo darbą teigiamai. Todėl galite būti tikri, kad šis pasirinkimas geriausias!