Metódy implementácie aplikačného softvérového prostredia. Aplikačný softvér Metódy implementácie aplikačného softvéru
Prečítajte si tiež
Zatiaľ čo mnohé architektonické prvky OS sa priamo týkajú iba systémových programátorov, koncept viacerých aplikačných (prevádzkových) zariadení priamo súvisí s potrebami koncových používateľov – schopnosťou operačný systém spúšťať aplikácie napísané pre iné operačné systémy. Táto vlastnosť operačného systému sa nazýva kompatibilita.
Kompatibilita aplikácií môže byť na binárnej úrovni a na úrovni zdroja [ 13 ]. Aplikácie sú zvyčajne uložené v OS ako spustiteľné súbory obsahujúce binárne obrázky kódu a údajov. Binárna kompatibilita sa dosiahne, keď môžete vziať spustiteľný program a spustiť ho v inom prostredí operačného systému.
Kompatibilita na úrovni zdroja vyžaduje prítomnosť vhodného kompilátora ako súčasti softvéru počítača, na ktorom má bežať túto aplikáciu, ako aj kompatibilitu na úrovni knižnice a systémových volaní. V tomto prípade je potrebné prekompilovať zdrojový kód aplikácie do nového spustiteľného modulu.
Kompatibilita na zdrojovej úrovni je dôležitá hlavne pre vývojárov aplikácií, ktorí majú k dispozícii zdrojový kód. Pre koncových používateľov má však praktický význam iba binárna kompatibilita, pretože iba v tomto prípade môžu používať rovnaký produkt na rôznych operačných systémoch a na rôznych počítačoch.
Typ možnej kompatibility závisí od mnohých faktorov. Najdôležitejšou z nich je architektúra procesora. Ak procesor používa rovnakú inštrukčnú sadu (možno s doplnkami, ako v prípade IBM PC: štandardná sada + multimédiá + grafika + streaming) a rovnaký rozsah adries, potom sa dá binárna kompatibilita dosiahnuť úplne jednoducho. Aby to bolo možné, musia byť splnené nasledujúce podmienky:
API, ktoré aplikácia používa, musí byť podporované operačným systémom;
Vnútorná štruktúra spustiteľného súboru aplikácie musí zodpovedať štruktúre spustiteľných súborov daného OS.
Ak majú procesory rôzne architektúry, potom je okrem vyššie uvedených podmienok potrebné zorganizovať emuláciu binárneho kódu. Napríklad emulácia príkazov procesora Intel na procesore Motorola 680x0 počítača Macintosh je široko používaná. Softvérový emulátor v tomto prípade postupne vyberá binárnu inštrukciu procesor Intel a vykoná ekvivalentnú rutinu napísanú v inštrukciách procesora Motorola. Keďže procesor Motorola nemá úplne rovnaké registre, príznaky, interné ALU atď., ako v procesoroch Intel, musí všetky tieto prvky simulovať (emulovať) aj pomocou svojich registrov alebo pamäte.
Je to jednoduché ale veľmi pomalá práca, pretože jedna inštrukcia Intel sa vykonáva oveľa rýchlejšie ako sekvencia procesora Motorola, ktorá ju emuluje. Riešením v takýchto prípadoch je použitie takzvaných aplikačných softvérových prostredí alebo operačných prostredí. Jednou zo súčastí takéhoto prostredia je súbor funkcií API, ktoré OS poskytuje svojim aplikáciám. Aby sa skrátil čas potrebný na spustenie cudzích programov, aplikačné prostredia simulujú volania funkcií knižnice.
Efektívnosť tohto prístupu je spôsobená skutočnosťou, že väčšina dnešných programov beží pod GUI (grafické používateľské rozhrania) Typ Windows, MAC alebo UNIX Motif, pričom aplikácie trávia 60-80 % svojho času vykonávaním funkcií GUI a iných volaní knižníc OS. Práve táto vlastnosť aplikácií umožňuje aplikačným prostrediam kompenzovať veľké množstvo času stráveného emuláciou programu za príkazom. Starostlivo navrhnuté prostredie softvérových aplikácií zahŕňa knižnice, ktoré napodobňujú knižnice GUI, ale sú napísané v natívnom kóde. Dosahuje sa tak výrazné zrýchlenie vykonávania programov pomocou API iného operačného systému. Tento prístup sa inak nazýva preklad, aby sa odlíšil od pomalšieho procesu emulácie jedného príkazu naraz.
Napríklad pre program Windows spustený na počítači Macintosh pri interpretácii príkazov procesora Výkon Intel môže byť veľmi nízka. Ale keď sa zavolá funkcia GUI, otvorí sa okno atď., modul OS, ktorý implementuje aplikáciu Prostredie Windows, môže zachytiť toto volanie a presmerovať ho na rutinu otvárania okna prekompilovanú pre procesor Motorola 680x0. Výsledkom je, že v takýchto častiach kódu môže rýchlosť programu dosiahnuť (a možno aj prekročiť) rýchlosť práce na jeho natívnom procesore.
Aby sa zabezpečilo, že program napísaný pre jeden OS môže byť spustený v inom OS, nestačí zabezpečiť kompatibilitu API. Koncepty, ktoré sú základom rôznych operačných systémov, môžu byť vo vzájomnom konflikte. Napríklad v jednom OS môže byť aplikácii povolené ovládať I/O zariadenia, zatiaľ čo v inom sú tieto akcie výsadou OS.
Každý OS má svoje vlastné mechanizmy ochrany zdrojov, svoje vlastné algoritmy na spracovanie chýb a výnimočných situácií, špeciálnu štruktúru procesora a schému správy pamäte, vlastnú sémantiku a grafiku prístupu k súborom. používateľské rozhranie. Na zabezpečenie kompatibility je potrebné zorganizovať bezkonfliktnú koexistenciu viacerých metód správy počítačových zdrojov v rámci jedného OS.
Existujú rôzne možnosti na vytváranie prostredí viacerých aplikácií, ktoré sa líšia vlastnosťami architektonických riešení a funkčnosťou, ktorá poskytuje rôzne stupne prenosnosti aplikácií. Jedna z najzrejmejších možností implementácie prostredia viacerých aplikácií je založená na štandardnej viacvrstvovej štruktúre OS.
Zapnuté ryža. 1.9 OS1 OS podporuje okrem svojich natívnych aplikácií aj aplikácie z operačných systémov OS2 a OS3. Na tento účel obsahuje špeciálne aplikácie, aplikačné softvérové prostredia, ktoré prekladajú rozhrania „cudzích“ operačných systémov API OS2 a API OS3 do rozhrania ich „natívneho“ OS – API OS1. Ak by teda napríklad OS2 bol UNIX a OS1 bol OS/2, na vykonanie systémového volania na vytvorenie procesu fork() v aplikácii UNIX musí softvérové prostredie kontaktovať jadro operačného systému OS/2 s systém volá DOS ExecPgm().
Ryža. 1.9. Organizácia viacerých aplikačných prostredí
Bohužiaľ, správanie takmer všetkých funkcií, ktoré tvoria API jedného OS, sa spravidla výrazne líši od správania zodpovedajúcich funkcií iného OS. Napríklad, aby funkcia vytvárania procesov v OS/2 Dos ExecPgm () plne zodpovedala funkcii vytvárania procesov fork () v systémoch podobných UNIX, bolo by potrebné ju zmeniť a napísať novú funkcionalitu: podpora pre schopnosť kopírovať adresný priestor nadradeného procesu do priestoru podriadeného procesu [ 17 ].
Ďalší spôsob budovania viacerých aplikačných prostredí je založený na mikrokerneli. Zároveň je veľmi dôležité uvedomiť si základný rozdiel, spoločný pre všetky aplikačné prostredia, medzi mechanizmami operačného systému a vysokoúrovňovými funkciami špecifickými pre každé aplikačné prostredie, ktoré riešia strategické problémy. V súlade s architektúrou mikrojadra sú všetky funkcie OS implementované servermi mikrojadra a používateľského režimu. Dôležité je, aby bolo prostredie aplikácie navrhnuté vo forme samostatný server užívateľský režim a nezahŕňa základné mechanizmy.
Aplikácie využívajúce API robia systémové volania do zodpovedajúceho aplikačného prostredia cez mikrokernel. Prostredie aplikácie spracuje požiadavku, vykoná ju (možno tak, že na to zavolá základné funkcie mikrojadra) a pošle výsledok späť do aplikácie. Pri vykonávaní požiadavky musí aplikačné prostredie pristupovať k základným mechanizmom operačného systému implementovaným mikrokernelom a inými servermi OS.
Tento prístup k navrhovaniu prostredí s viacerými aplikáciami má všetky výhody a nevýhody mikrojadrovej architektúry, najmä:
je veľmi jednoduché pridávať a vylučovať aplikačné prostredia, čo je dôsledkom dobrej rozšíriteľnosti operačných systémov s mikrojadrom;
ak jedno z aplikačných prostredí zlyhá, ostatné ostanú funkčné, čo prispieva k spoľahlivosti a stabilite systému ako celku;
nízky výkon mikrokernelových operačných systémov ovplyvňuje rýchlosť aplikačných nástrojov, a tým aj rýchlosť aplikácií.
V dôsledku toho je potrebné poznamenať, že vytvorenie niekoľkých aplikačných nástrojov v rámci jedného OS na spúšťanie aplikácií z rôznych OS je spôsob, ktorý umožňuje mať jednu verziu programu a prenášať ju medzi rôznymi operačnými systémami. Viaceré aplikačné prostredia poskytujú binárnu kompatibilitu daného operačného systému s aplikáciami napísanými pre iné operačné systémy.
Vytvorenie kompletného aplikačného prostredia, ktoré je plne kompatibilné s prostredím iného operačného systému, je celkom jednoduché náročná úloha, úzko súvisí so štruktúrou operačného systému. Existujú rôzne možnosti budovania viacerých aplikačných prostredí, ktoré sa líšia vlastnosťami architektonických riešení a funkčnosť poskytujúce rôzne stupne prenosnosti aplikácií.
V mnohých verziách OS UNIX je prekladač aplikačného prostredia implementovaný ako bežná aplikácia. V operačných systémoch vytvorených pomocou koncepcie mikrojadra, ako je Windows NT, aplikačné prostredia bežia ako servery v užívateľskom režime. A v OS/2 s jednoduchšou architektúrou sú prostriedky na organizáciu aplikačných prostredí zabudované hlboko do operačného systému.
Jedna z najzrejmejších možností implementácie prostredia viacerých aplikácií je založená na štandardnej viacvrstvovej štruktúre OS. Na obr. 3. 8 operačný systém OS1 podporuje okrem svojich „natívnych“ aplikácií aj aplikácie operačného systému OS2. Na tento účel obsahuje špeciálnu aplikáciu - aplikačné softvérové prostredie, ktoré prekladá rozhranie „cudzieho“ operačného systému – API OS2 do rozhrania jeho „natívneho“ operačného systému – API OS1.
Ryža. 3. 8. Prostredie aplikačného softvéru, ktoré vysiela
systémové volania
V inom uskutočnení prostredia viacerých aplikácií má operačný systém niekoľko rozhraní na programovanie partnerských aplikácií. Na zobrazenom obrázku. 3. V tomto príklade operačný systém podporuje aplikácie napísané pre OS1, OS2 a OS3. Za týmto účelom sú aplikačné programové rozhrania všetkých týchto operačných systémov umiestnené priamo v priestore jadra systému: API OS1, API OS2 a API OS3.
Ryža. 3. 9. Implementácia kompatibility na základe viacerých
peer API
V tejto možnosti funkcie na úrovni API pristupujú k funkciám na základnej úrovni operačného systému, ktorý musí podporovať všetky tri všeobecne nekompatibilné aplikačné prostredia. Rôzne operačné systémy spravujú systémový čas odlišne, používajú rôzne formáty denného času, rozdeľujú čas procesora na základe vlastných algoritmov atď. Funkcie každého API sú implementované jadrom s prihliadnutím na špecifiká príslušného operačného systému, aj keď majú podobný účel.
Ďalší spôsob budovania viacerých aplikačných prostredí je založený na mikrokerneli. Zároveň je veľmi dôležité oddeliť základné mechanizmy operačného systému, spoločné pre všetky aplikačné prostredia, od vysokoúrovňových funkcií špecifických pre každé aplikačné prostredie, ktoré riešia strategické problémy.
V súlade s architektúrou mikrojadra sú všetky funkcie OS implementované servermi mikrojadra a používateľského režimu. Je dôležité, aby každé aplikačné prostredie bolo navrhnuté ako samostatný server v užívateľskom režime a neobsahovalo základné mechanizmy (obr. 3. 10). Aplikácie využívajúce prístup API systémové volania do zodpovedajúceho aplikačného prostredia cez mikrokernel. Prostredie aplikácie spracuje požiadavku, vykoná ju (možno tak, že na to zavolá základné funkcie mikrojadra) a pošle výsledok späť do aplikácie. Pri vykonávaní požiadavky musí aplikačné prostredie pristupovať k základným mechanizmom operačného systému implementovaným mikrokernelom a inými servermi OS.
Ryža. 3. 10. Mikrokernelový prístup k implementácii viacerých
aplikačné prostredia
Tento prístup k navrhovaniu prostredí s viacerými aplikáciami má všetky výhody a nevýhody architektúry mikrojadra, najmä:
· je veľmi jednoduché pridávať a vylučovať aplikačné prostredia, čo je dôsledkom dobrej rozšíriteľnosti operačných systémov s mikrojadrom;
· spoľahlivosť a stabilita sú vyjadrené v skutočnosti, že ak jedno z aplikačných prostredí zlyhá, všetky ostatné zostanú funkčné;
· nízky výkon mikrokernelových operačných systémov ovplyvňuje rýchlosť aplikačných prostredí, a tým aj rýchlosť vykonávania aplikácií.
Vytvorenie viacerých aplikačných prostredí v rámci jedného operačného systému na spúšťanie aplikácií z rôznych operačných systémov je spôsob, ktorý vám umožňuje mať jednu verziu programu a prenášať ju medzi operačnými systémami. Viaceré aplikačné prostredia poskytujú binárnu kompatibilitu daného operačného systému s aplikáciami napísanými pre iné operačné systémy. V dôsledku toho majú používatelia väčšiu slobodu pri výbere operačných systémov a ďalšie ľahký prístup na kvalitný softvér.
Samotestovacie otázky
- Čo znamená architektúra OS?
- Aké sú tri hlavné vrstvy v štruktúre výpočtového systému?
- Akú úlohu hrá OS v rozhraní systémového volania?
- Aké podmienky musia byť splnené pri návrhu OS, aby bol OS ľahko prenosný?
- Aký je rozdiel medzi architektúrou mikrojadra a tradičnou architektúrou OS?
- Prečo je mikrokernel vhodný na podporu distribuovaných výpočtov?
- Čo znamená pojem prostredia s viacerými aplikáciami?
- Čo je podstatou metódy knižničného prekladu?
Koniec práce -
Táto téma patrí do sekcie:
Operačný systém, procesy, hardvér
OS operačný systém v najväčšej miere určuje vzhľad celého výpočtového systému ako celku, OS vykonáva dve v podstate málo súvisiace... OS ako virtuálny rozšírený stroj využitie väčšiny počítačov... z užívateľského hľadiska je funkciou OS napr. poskytnúť používateľovi nejaký rozšírený alebo virtuálny...
Ak potrebujete ďalší materiál k tejto téme, alebo ste nenašli to, čo ste hľadali, odporúčame použiť vyhľadávanie v našej databáze diel:
Čo urobíme s prijatým materiálom:
Ak bol tento materiál pre vás užitočný, môžete si ho uložiť na svoju stránku v sociálnych sieťach:
| Tweetujte |
Všetky témy v tejto sekcii:
Vlastnosti hardvérových platforiem
Vlastnosti operačného systému sú priamo ovplyvnené hardvérom, na ktorom je navrhnutý. Operačné systémy sú klasifikované podľa typu hardvéru. osobné počítače, mi
Úlohy a cvičenia
1. Ktoré udalosti vo vývoji technickej základne počítačov sa stali míľnikmi v histórii operačných systémov? 2. Aký bol zásadný rozdiel medzi monitormi prvého dávkového spracovania a
Architektúra operačného systému
Akýkoľvek dobre organizovaný komplexný systém má jasnú a racionálnu štruktúru, to znamená, že je rozdelený na časti - moduly, ktoré majú úplne kompletný funkčný účel s
Správa hlavnej pamäte
Pamäť je veľké pole slov alebo bajtov, z ktorých každé má svoju vlastnú adresu. Toto je dátové úložisko, ku ktorému sa pristupuje rýchly prístup, distribuovaný medzi procesorom a
Správa externej pamäte
Keďže hlavná pamäť (primárna pamäť) je volatilná a príliš malá na to, aby mohla natrvalo uložiť všetky dáta a programy, BC musí poskytnúť sekundárnu pamäť na uloženie hlavnej pamäte. Bol
Subsystém správy súborov
Súbor je súborom súvisiacich informácií definovaných pri vytváraní. Okrem samotných údajov predstavujú súbory programy v zdrojovej aj objektovej forme. Subsystém
Sieťová podpora
Distribuovaný systém je množina procesorov, ktoré nezdieľajú pamäť alebo každý procesor má vlastnú lokálnu pamäť. Procesory v systéme sú pripojené cez počítačová sieť a poskytovanie
Moduly jadra a pomocných OS
Najvšeobecnejším prístupom k štruktúrovaniu operačného systému je rozdelenie všetkých jeho modulov do dvoch skupín: jadro – moduly OS, ktoré vykonávajú základné funkcie;
Jadro a privilegovaný režim
Na spoľahlivé riadenie priebehu aplikácií musí mať operačný systém určité privilégiá nad aplikáciami. V opačnom prípade aplikácia nemusí fungovať správne
Viacvrstvová štruktúra OS
Výpočtový systém s operačným systémom založeným na jadre možno považovať za systém pozostávajúci z troch hierarchicky usporiadaných vrstiev: spodná vrstva tvorí hardvér
Štruktúra jadra
Nástroje na podporu hardvéru OS. Doteraz sa o operačnom systéme hovorilo ako o súbore programov, no niektoré funkcie OS dokáže vykonávať aj hardvér. Básnik
Hardvérová závislosť a prenosnosť OS
Mnohé operačné systémy úspešne bežia na rôznych hardvérových platformách bez výrazných zmien v ich zložení. Je to do značnej miery spôsobené tým, že napriek rozdielom
Prenosnosť operačného systému
Ak je možné pomerne ľahko preniesť kód operačného systému z jedného typu procesora na iný typ procesora a z jedného typu hardvérovej platformy na hardvérovú platformu
koncepcia
Architektúra mikrojadra je alternatívou ku klasickému spôsobu budovania operačného systému. V tomto prípade klasická architektúra znamená štrukturálny orgán diskutovaný vyššie.
Binárna a zdrojová kompatibilita
Je potrebné rozlišovať medzi kompatibilitou na binárnej úrovni a kompatibilitou na úrovni zdroja. Aplikácie sú zvyčajne uložené v OS ako spustiteľné súbory obsahujúce binárne obrázky.
Knižničné vysielanie
Riešením v takýchto prípadoch je použitie tzv aplikačné programy nyh prostrediach. Jedným z komponentov, ktorý tvorí prostredie aplikačného softvéru, je súbor funkcií
Procesný koncept
Proces je nejaká aktivita bežiaca na procesore. Procesor v v širokom zmysle nazýva sa akékoľvek zariadenie, ktoré je súčasťou počítača
Koncept zdrojov
Jednou z funkcií operačného systému je poskytovať efektívny a bezkonfliktný spôsob spravovania zdrojov počítačového systému. Zdroj sa často chápe ako indikátor
Koncept virtualizácie
Virtualizácia konkrétneho zdroja sa vykonáva v rámci centralizovanej schémy distribúcie zdrojov. Prostredníctvom virtualizácie sa vykonávajú dve formy klamania používateľov:
Disciplíny obsluhy jedného frontu
a) FIFO (First In -- First Out) - služobná disciplína v poradí príchodu. Všetky aplikácie idú na koniec poradia. Prihlášky na začiatku poradia sú doručené ako prvé. Schematicky
Systém prerušenia
Situácia, ktorá vzniká v dôsledku vplyvu nejakej nezávislej udalosti, ktorá vedie k dočasnému ukončeniu vykonávania sekvencie príkazov v jednom programe s cieľom
Procesný koncept
Proces (úloha) je program v režime vykonávania. Každý proces je spojený s adresným priestorom, z ktorého môže čítať a
Procesný model
V multitaskingovom systéme sa skutočný procesor prepína z procesu na proces, ale pre zjednodušenie modelu uvažujeme o množine procesov prebiehajúcich paralelne (pseudoparalelne). Uvažujme
Ukončenie procesu
(ukončenie hovoru alebo ExitProcess): Plánované ukončenie (koniec vykonávania) Naplánované ukončenie pri známej chybe (napríklad chýbajúci súbor)
Hierarchia procesov
Systémy UNIX majú pevnú hierarchiu procesov. Každý nový proces vytvorený systémovým volaním fork je potomkom predchádzajúceho procesu. Podriadený proces získava výhody z nadradeného procesu.
Stav procesu
Tri stavy procesu sú: Beží (zaberá CPU) Pripravený (proces je dočasne pozastavený, aby mohol bežať iný proces) Čaká (proces
Pojem prúdenia
Každý proces má adresný priestor a jedno vlákno spustiteľných príkazov. V systémoch s viacerými používateľmi je vždy, keď pristupujete k rovnakej službe, príchod
Prietokový model
Každé vlákno je spojené s: Počítadlom vykonávania pokynov Registrami pre aktuálne premenné Stav zásobníka Vlákna medzi sebou zdieľajú prvky
Výhody používania vlákien
Zjednodušenie programu v niektorých prípadoch použitím spoločného adresného priestoru. Rýchlosť vytvárania prúdu v porovnaní s procesom je približne 100-násobná. Povýšený
Implementácia vlákien v užívateľskom priestore, jadre a zmiešaných
A - vlákna v užívateľskom priestore B
Vlastnosti implementácie systému Windows
Používajú sa štyri pojmy: Úloha - súbor procesov so spoločnými kvótami a limitmi Proces - kontajner zdrojov (pamäť...), obsahuje aspoň jedno vlákno. Poto
Komunikácia medzi procesmi
Situácie, keď procesy musia vzájomne pôsobiť: Prenos informácií z jedného procesu do druhého Kontrola aktivít procesov (napríklad: keď bojujú o informácie)
Prenos informácií z jedného procesu do druhého
Prenos je možné vykonať niekoľkými spôsobmi: Zdieľaná pamäť Kanály (rúry), ide o pseudosúbor, do ktorého jeden proces zapisuje a druhý číta.
Rasový stav
Súčasnosť je situácia, keď viaceré procesy čítajú alebo zapisujú údaje (do pamäte alebo súboru) súčasne. Pozrime sa na príklad, kde sa o to pokúšajú dva procesy
Kritické oblasti
Kritická oblasť je časť programu, ktorá pristupuje k zdieľaným údajom. Podmienky na vyhýbanie sa konkurencii a efektívnu prácu procesy: Dva procesy nie
Uzamykacie premenné
Zavádza sa pojem zámkovej premennej, t.j. ak je hodnota tejto premennej napríklad 1, potom je zdroj obsadený iným procesom a druhý proces prejde do pohotovostného režimu (zablokuje sa), kým
Prísne striedanie
V tomto modeli môžu byť procesy vykonávané striktne postupne pomocou premennej.
Procesné komunikačné primitívy
Zavádzajú sa pojmy dvoch primitív. spánok je systémová požiadavka, ktorá spôsobí zablokovanie volajúceho procesu, kým ho nespustí iný proces. wak
Semafory
Semafory sú premenné na počítanie spúšťacích signálov uložených pre budúce použitie. Boli navrhnuté dve operácie: dole a hore (analógy spánku a bdenia
Plánovanie v systémoch dávkového spracovania
6.2.1 „First in – first out“ (FIFO – First In Fist Out) Procesy sa pri príchode zaraďujú do frontu. Výhody:
Cyklické plánovanie
Najjednoduchší a často používaný plánovací algoritmus. Každému procesu je pridelený časový úsek procesora. Keď kvantum skončí, proces prenesie plánovač na koniec procesu.
Prioritné plánovanie
Každý proces má priradenú prioritu a riadenie sa prenesie na proces s najvyššou prioritou. Priorita môže byť dynamická alebo statická. Dynamický
Plánovanie v systémoch v reálnom čase
Systémy v reálnom čase sa delia na: rigidné (prísne termíny pre každú úlohu) - riadenie pohybu flexibilné (porušenie časového harmonogramu nie je žiaduce, ale prijateľné) - unitárne
Všeobecné plánovanie v reálnom čase
Používa sa model, v ktorom každý proces súťaží o procesor s vlastnou úlohou a harmonogramom jeho vykonávania. Plánovač musí vedieť: frekvenciu, s ktorou by mal každý človek pracovať
Zablokovanie procesu
Zablokovanie procesu môže nastať, keď viacero procesov súťaží o rovnaký zdroj. Zdroje môžu byť stránkované alebo nestránkované, hardvérové alebo softvérové.
Simulácia uviaznutia
Modelovanie slepých uličiek pomocou grafov. Legenda Na tomto modeli veľmi
Detekcia a rozlíšenie uviaznutia
Systém sa nesnaží zabrániť zablokovaniu, ale snaží sa ho odhaliť a vyriešiť. Detekcia zablokovania, keď existuje jeden zdroj každého typu
Dynamické vyhýbanie sa zablokovaniu
Pri tejto metóde OS potrebuje vedieť, či je poskytovanie zdroja bezpečné alebo nie. Trajektórie zdrojov Uvažujme model dvoch procesov a dvoch zdrojov
Predchádzanie štyrom podmienkam vyžadovaným pre uviaznutie
Vyhýbanie sa podmienkam vzájomného vylúčenia Môžete minimalizovať počet procesov, ktoré súťažia o zdroje. Napríklad pomocou zaraďovania tlačiarne, keď
Princípy I/O hardvéru
Dve nižšie úrovne I/O riadiaceho systému sú hardvérové: samotné zariadenia, ktoré priamo vykonávajú operácie a ich radiče, ktoré slúžia na organizáciu spolupráce zariadenie
Ovládače zariadení
I/O zariadenia sa zvyčajne skladajú z dvoch častí: mechanická (neberte to doslovne) - disk, tlačiareň, monitor elektronická - radič resp.
Pamäťový adresný priestor mapovaný I/O
Každý radič má niekoľko registrov, ktoré slúžia na komunikáciu s centrálnym procesorom. Pomocou týchto registrov OS riadi (číta, zapisuje, zapína atď.) a určuje
Priamy prístup do pamäte (DMA)
Priamy prístup do pamäte je realizovaný pomocou radiča DMA. Kontrolér obsahuje niekoľko registrov: pamäťová adresa register bajtový čítač
Prerušenia
Keď I/O zariadenie začne pracovať, procesor sa prepne na iné úlohy. Na signalizáciu procesoru, že práca sa skončila, zariadenie iniciuje prerušenie,
I/O softvérové úlohy
Hlavné úlohy, ktoré treba vyriešiť softvér I/O: Nezávislosť na zariadení – napríklad program, ktorý číta dáta zo súboru, nemusí rozmýšľať kde
Softvérový vstup/výstup
V tomto prípade robí všetku prácu centrálny procesor. Pozrime sa na proces tlače reťazca ABCDEFGH pomocou tejto metódy.
I/O riadené prerušením
Ak sa v predchádzajúcom príklade nepoužíva vyrovnávacia pamäť a tlačiareň tlačí 100 znakov za sekundu, každý znak bude trvať 10 ms, počas ktorých bude procesor nečinný a čaká, kým bude tlač pripravená.
Ovládače prerušení
Prerušenia by mali byť skryté čo najhlbšie v hĺbke operačného systému, aby sa s nimi musela vysporiadať čo najmenšia časť OS. Najlepšie je zablokovať ovládač, ktorý spustil I/O. Algo
Ovládače zariadení
Ovládač zariadenia – vyžaduje sa pre každé zariadenie. Rôzne operačné systémy vyžadujú rôzne ovládače. Ovládače musia byť súčasťou jadra (v monolitickom systéme), aby mali prístup k riadiacim registrom
I/O softvér nezávislý od zariadenia
Funkcie softvéru I/O nezávislé od zariadenia: Konzistentné rozhranie pre ovládače zariadení, hlásenia o chybách ukladania do vyrovnávacej pamäte
Súhrn úrovní a funkcií I/O
Úrovne a hlavné funkcie vstupno-výstupného systému Base
Blokovanie, neblokovanie a asynchrónne systémové volania
Všetky systémové volania spojené s realizáciou I/O operácií možno rozdeliť do troch skupín podľa spôsobov realizácie interakcie medzi procesom a I/O zariadením. · K prvému, na
Ukladanie do vyrovnávacej pamäte a vyrovnávacia pamäť
Vyrovnávacia pamäť sa zvyčajne chápe ako určitá oblasť pamäte na ukladanie informácií pri výmene údajov medzi dvoma zariadeniami, dvoma procesmi alebo procesom a zariadením. Výmena
Spoolovanie a únos zariadenia
O koncepte spoolingu sme hovorili v prvej prednáške nášho kurzu ako o mechanizme, ktorý po prvýkrát umožnil spojiť reálne I/O operácie jednej úlohy s vykonaním inej úlohy.
Spracovanie prerušení a chýb
Ak počítačový systém pri práci s externým zariadením nepoužíva metódu dotazovania jeho stavu, ale používa mechanizmus prerušenia, potom keď dôjde k prerušeniu, ako sme už urobili
Plánovanie dopytov
Pri použití neblokujúceho systémového volania to možno zistíte požadované zariadenie je už zaneprázdnený vykonávaním niektorých operácií. V tomto prípade môže neblokovaný hovor okamžite
Princípy, na ktorých je založený I/O riadiaci subsystém v UNIX
1. Tento subsystém je vytvorený jednotným spôsobom so subsystémom správy údajov (súborovým systémom). Používateľovi je poskytnutý jednotný spôsob prístupu k používateľskému rozhraniu aj súborom. Pod súborom v OS
Správa pamäte v OS
4.1. Koncepcia organizácie a riadenia fyzická pamäť v operačných systémoch 4.2. Metódy súdržného prideľovania hlavnej pamäte 4.2.1. Pripojené distribuované
Koncept organizácie a správy fyzickej pamäte v operačných systémoch
Organizácia a správa hlavnej (primárnej, fyzickej, reálnej) pamäte počítača je jedným z najdôležitejších faktorov určujúcich konštrukciu operačných systémov. V anglicky hovoriacej technike
Súdržná alokácia pamäte pre jedného používateľa
Koherentné prideľovanie pamäte pre jedného používateľa, nazývané aj jediné nepretržité prideľovanie, sa používa v počítačoch pracujúcich v dávkovom režime jedného programu pod kontrolou najjednoduchších
Kohézna alokácia pamäte pre multiprogramové spracovanie
Pri multiprogramovom spracovaní je do pamäte počítača umiestnených niekoľko úloh naraz. Distribúciu pamäte medzi úlohy v tomto prípade možno vykonať nasledujúcimi spôsobmi:
Stratégie ukladania informácií do pamäte
Stratégie umiestňovania pamäte sú navrhnuté tak, aby určili, kde v hlavnej pamäti majú byť umiestnené prichádzajúce programy a dáta pri prideľovaní pamäte bez premiestnenia.
Základné koncepty virtuálnej pamäte
Pojem virtuálna pamäť sa zvyčajne spája so schopnosťou adresovať pamäťový priestor oveľa väčší ako je kapacita primárnej (reálnej, fyzickej) pamäte konkrétneho výpočtového stroja.
Organizácia stránky virtuálnej pamäte
Virtuálna adresa s čisto organizáciou pamäte stránok je usporiadaný pár (p, d), kde p je číslo stránky v virtuálna pamäť a d je posun v rámci strany p. Proces je možné vykonať
Segmentová organizácia virtuálnej pamäte
Virtuálna adresa v segmentovanej organizácii virtuálnej pamäte je usporiadaný pár n = (s, d), kde s je číslo segmentu virtuálnej pamäte a d je posun v rámci tohto segmentu. Proces môže
Organizácia segmentov stránky virtuálnej pamäte
Systémy s organizáciou segmentov stránok majú výhody oboch metód implementácie virtuálnej pamäte. Segmenty zvyčajne obsahujú celočíselný počet stránok a nie všetky stránky musia byť
Stratégie správy virtuálnej pamäte
Stratégie správy virtuálnej pamäte, podobne ako stratégie správy fyzickej pamäte, spadajú do troch kategórií: stratégie push, stratégie umiestnenia a stratégie push.
Push (pump) stratégie
Na ovládanie pushovania sa používajú nasledujúce stratégie: · pushing (stránkovanie) na požiadanie (na požiadanie); · tlačenie (pumpovanie) s očakávaním (pokročilé).
Stratégie umiestnenia
V systémoch so stránkovanou virtuálnou pamäťou sa rozhodnutie o umiestnení novo načítaných stránok robí celkom jednoducho: nová stránka možno umiestniť do ľubovoľného voľného
Push stratégie
V multiprogramových systémoch je zvyčajne celá primárna pamäť obsadená. V tomto prípade musí program správy pamäte rozhodnúť, ktorá stránka alebo segment sa má odstrániť z primárnej
Pomenovanie súboru
Dĺžka názvu súboru závisí od operačného systému, môže byť od 8 (MS-DOS) do 255 (Windows, LINUX) znakov. Operačné systémy dokážu rozlišovať medzi veľkými a malými písmenami. Napríklad WINDOWS a Windows pre MS-DOS sú rovnaké
Štruktúra súboru
Tri základné štruktúry súborov: 1. Poradie bajtov – OS nezaujíma obsah súboru, vidí len bajty. Hlavnou výhodou takéhoto systému je flexibilita
Typy súborov
Hlavné typy súborov: · Bežné – obsahujú informácie o používateľovi. Používa sa na Windows a UNIX. · Katalógy - systémové súbory, poskytovanie
Atribúty súboru
Základné atribúty súboru: · Ochrana – kto a ako môže pristupovať k súboru (používatelia, skupiny, čítanie/zápis). Používa sa na Windows a UNIX. · Heslo - heslo pre fa
Súbory mapované do adresného priestoru pamäte
Niekedy je vhodné zobraziť súbor v pamäti (na prácu so súborom nemusíte používať I/O systémové volania) a pracovať s pamäťou a potom zapísať upravený súbor na disk. Pri použití
Jednoúrovňové katalógové systémy
V tomto systéme sú všetky súbory obsiahnuté v jednom adresári. Od
Názov cesty
Ak chcete usporiadať strom adresárov, musíte nejakým spôsobom určiť súbor. Dva hlavné spôsoby určenia súboru: absolútny názov cesty – označuje cestu z koreňového súboru
Implementácia adresárov
Pri otváraní súboru sa názov cesty používa na nájdenie položky adresára. Záznam adresára ukazuje na adresy blokov disku. V závislosti od systému to môže byť: diskové peklo
Implementácia dlhých názvov súborov
Predtým operačné systémy používali krátke názvy súborov, MS-DOS do 8 znakov, UNIX verzia 7 do 14 znakov. Teraz sa používajú dlhšie názvy súborov (až 255 znakov alebo viac).
Zrýchlite vyhľadávanie súborov
Ak je adresár veľmi veľký (niekoľko tisíc súborov), postupné čítanie adresára nie je veľmi efektívne. 1 Použitie hašovacej tabuľky na zrýchlenie vyhľadávania súborov.
A - zdieľaný súbor
Takýto súborový systém sa nazýva riadený acyklický graf (DAG, Directed Acyclic Graph). Problém nastáva, ak sú adresy diskov obsiahnuté v samotných adresárových súboroch.
Veľkosť bloku
Ak sa rozhodne uložiť súbor do blokov, potom vyvstáva otázka veľkosti týchto blokov. Existujú dva extrémy: · Veľké bloky - napríklad 1 MB, potom súbor aj 1 bajt zaberie celý blok
Účtovanie voľných blokov
Existujú dva hlavné spôsoby účtovania voľných blokov: · Prepojený zoznam diskových blokov, každý blok obsahuje toľko voľných blokov, koľko môže byť zahrnutých v bloku. Často na rezervný zoznam
Diskové kvóty
Na obmedzenie používateľa existuje mechanizmus kvót. Dva typy limitov: · Tvrdé – nemožno ho prekročiť · Flexibilné – možno ho prekročiť, ale pri výstupe užívateľa
Zálohovanie
Prípady, pre ktoré je potrebné zálohovanie: · Núdzové situácie vedúce k strate dát na disku · Náhodné vymazanie alebo softvérové poškodenie súborov Basic
Konzistencia súborového systému
Ak systém zlyhá pred zapísaním upraveného bloku, súborový systém môže skončiť v nekonzistentnom stave. Najmä ak ide o blok i-uzla, adresára a
Ukladanie do vyrovnávacej pamäte
Block cache (buffer cache) je množina blokov uložených v pamäti, ale logicky patriacich disku. Všetky požiadavky na čítanie na disk sú zachytené a dostupnosť požadovaného
Systém súborov ISO 9660
Viac detailné informácie- http://ru.wikipedia.org/wiki/ISO_9660 Norma bola prijatá v roku 1988. Podľa normy možno disky rozdeliť na logické partície, ale budeme uvažovať o diskoch s
Vstup do katalógu ISO 9660
Umiestnenie súboru je číslo počiatočného bloku, pretože bloky sú usporiadané postupne. L - dĺžka názvu súboru v bajtoch Názov súboru - 8 znakov, 3 znaky rozšírenia (kvôli kompatibilite
Rozšírenia Rock Ridge pre UNIX
Toto rozšírenie bolo vytvorené, aby umožnilo reprezentáciu súborového systému UNIX na disku CD-ROM. Na to slúži pole System use. Rozšírenia obsahujú nasledujúce polia: 1. PX -
Súborový systém UDF (Universal Disk Format)
Podrobnejšie informácie - http://ru.wikipedia.org/wiki/Universal_Disk_Format Pôvodne vytvorené pre DVD, od verzie 1.50 pridali podporu pre CD-RW a CD-R. Teraz najnovšia verzia
Súborový systém MS-DOS (FAT-12,16,32)
V prvých verziách bol iba jeden adresár (MS-DOS 1.0). Od MS-DOS 2.0 sa uplatňuje hierarchická štruktúra. Záznamy v adresári sú pevne stanovené na 32 bajtov. Názvy súborov -
Budú sa používať v systéme Windows 98
Pre programy je potrebný atribút archívu Rezervovať kópiu, pomocou neho určujú, či sa má súbor skopírovať alebo nie. Časové pole (16 bitov) je rozdelené do troch podpolí:
Windows 98 rozšírenie pre FAT-32
Na expanziu bolo použitých 10 voľných bitov. Formulár
Hlavným doplnkom oproti FAT-32 sú dlhé názvy súborov
Ku každému súboru sa začali priraďovať dva názvy: 1. Krátke 8+3 kvôli kompatibilite s MS-DOS 2. Dlhé meno súbor vo formáte Unicode K súboru môže pristupovať ktokoľvek
Napíšte formát adresára s dlhým fragmentom názvu súboru v systéme Windows 98
Pole "Atribúty" vám umožňuje rozlíšiť fragment dlhého názvu (hodnota 0x0F) od deskriptora súboru. Staré položky adresára programu MS-DOS s hodnotou poľa atribútu 0x0
súborový systém NTFS
Súbor systém NTFS bol vyvinutý pre Windows NT. Vlastnosti: · 64-bitové adresy, t.j. teoreticky môže podporovať 264 * 216 bajtov (1 208 925 819 M
Nájdite súbor podľa názvu
Pri vytváraní súboru program volá procedúru knižnice CreateFile("C:windowsreadmy.txt", ...) Toto volanie prejde na úroveň zdieľanej knižnice p
Kompresia súborov
Ak je súbor označený ako komprimovaný, systém ho pri zápise automaticky komprimuje a pri čítaní dekomprimuje. Algoritmus práce: 1. Prvých 16 blokov súboru sa odoberie na štúdium (č
Šifrovanie súborov
Akékoľvek informácie, ak nie sú zašifrované, je možné prečítať získaním prístupu. Preto najviac spoľahlivú ochranu informácie z neoprávneného prístupu – šifrovanie. Aj keď vás niekto kradne
Súborový systém UNIX V7
Hoci ide o starý súborový systém, základné prvky sa stále používajú v moderných systémoch UNIX. Vlastnosti: · Názvy súborov sú obmedzené na 14 znakov ASCII, okrem lomky "/&q"
štruktúra i-uzla
Pole Bajty Popis Režim Typ súboru, bezpečnostné bity, setuid a setgid bity Nlinky
Vytváranie a práca so súborom
fd=creat("abc", režim) - Príklad vytvorenia súboru abc s režimom ochrany špecifikovaným v premennej režim (ku ktorému majú používatelia prístup). Používa sa systém
súborový systém BSD
Základom je klasický súborový systém UNIX. Vlastnosti (rozdiel od predchádzajúci systém): · Zvýšená dĺžka názvu súboru na 255 znakov · Reorganizované adresáre
Umiestnenie súborového systému EXT2 na disk
Ďalšie funkcie: · Veľkosť bloku 1 KB · Veľkosť každého i-uzla 128 bajtov. i-uzol obsahuje 12 priamych a 3 nepriame adresy, dĺžka adresy v i-uzle narástla na 4 bajty, čo
súborový systém EXT3
Na rozdiel od EXT2, EXT3 je žurnálovací súborový systém, t.j. po neúspechoch neskončí v nesúrodom stave. Ale je plne kompatibilný s EXT2.
súborový systém XFS
XFS je žurnálovací súborový systém vyvinutý spoločnosťou Silicon Graphics, ale teraz vydaný ako open source. Oficiálne informácie na http://oss.sgi.com/projec
súborový systém RFS
RFS (RaiserFS) je žurnálovací súborový systém vyvinutý spoločnosťou Namesys. Oficiálne informácie o RaiserFS Niektoré funkcie: · Pracujte efektívnejšie
Súborový systém JFS
JFS (žurnál Systém súborov) je žurnálovaný súborový systém vyvinutý spoločnosťou IBM pre operačný systém AIX, ale teraz vydaný ako open source. Oficiálne informácie o Journaled File S
Štruktúra vrstvy systému súborov NFS
VFS (Virtual File System) - virtuálny súborový systém. Vyžaduje sa na správu tabuľky otvorených súborov. Vstupy pre všetkých otvorený súbor sa nazývajú v-uzly
Alternatíva emulácie - viaceré aplikačné prostredia, ktorý obsahuje súbor funkcií aplikácie API rozhranie. Simulujú prístup ku knižničným funkciám prostredia aplikácie, ale v skutočnosti pristupujú k svojim interným knižniciam. To sa nazýva knižničné vysielanie. Toto je čisto softvérový balík.
Aby program napísaný pod jedným OS fungoval pod iným OS, je potrebné zabezpečiť bezkonfliktnú interakciu metód riadenia procesov v rôznych OS.
Metódy implementácie aplikačného softvérového prostredia
V závislosti od architektúry:
1. Prostredie aplikačného softvéru vo forme aplikácie (vrchná vrstva jadra natívneho OS).
Užívateľský režim prevádzky, preklad systémových volaní (API volaní) na volania „natívneho“ OS. Zodpovedá klasickému viacvrstvovému OS (Unix, Windows).
2. Prítomnosť niekoľkých aplikačných prostredí, ktoré fungujú rovnako. Každý vo forme samostatnej vrstvy jadra.
Privilegovaný prevádzkový režim. API pristupuje k funkciám základnej (privilegovanej) vrstvy OS. Systém má za úlohu rozpoznať a prispôsobiť hovor. Požadovaný veľké množstvo zdrojov. Sada identifikačných charakteristík sa odovzdá jadru na rozpoznanie.
3. Mikrojadrový princíp.
Akékoľvek aplikačné prostredie je navrhnuté ako samostatný server v užívateľskom režime. Aplikácie využívajúce API uskutočňujú systémové volania do zodpovedajúceho aplikačného prostredia cez mikrokernel. Prostredie aplikácie spracuje požiadavku a vráti výsledok cez mikrokernel. Mohli by sa použiť funkcie mikrojadra. K ďalším zdrojom je možné pristupovať viackrát (pokiaľ je mikrokernel spustený).
Rozhrania OS
rozhranie OS je systém programovania aplikácií. Regulované pomocou noriem (POSIX, ISO).
1. Používateľské rozhranie– realizované pomocou špeciálnych softvérové moduly, ktoré prekladajú požiadavky používateľov v špeciálnom príkazovom jazyku na požiadavky do OS.
Súbor takýchto modulov sa nazýva tlmočník. Vykonáva lexikálnu analýzu a analýzu a príkaz buď vykoná sám, alebo ho odovzdá do API.
2. API– navrhnuté tak, aby aplikačným programom poskytovali prostriedky OS a implementovali ďalšie funkcie. Rozhranie API popisuje sadu funkcií a procedúr patriacich k jadru OS a doplnkom. Použitie API systémové programy v rámci OS aj mimo neho, pomocou aplikačných programov prostredníctvom programovacieho prostredia.
Základom poskytovania prostriedkov OS je v konečnom dôsledku softvérové prerušenie. Ich implementácia v závislosti od systému (vektorová, tabuľková). Existuje niekoľko možností implementácie API na úrovni OS (najrýchlejšie, najnižšie), na programovanie systému(abstraktnejšie, menej rýchlo) a na úrovni externej knižnice procedúr a funkcií (malá množina).
Rozhrania operačného systému Linux:
· softvér (bez sprostredkovateľov – v skutočnosti vykonávajúci systémové volania);
· príkazový riadok(prostredníkom je shell interpreta Shell, ktorý presmeruje hovor);
· grafický (sprostredkovatelia – Shell + grafický shell).
Systém súborov je časť operačného systému navrhnutá tak, aby používateľom poskytovala užívateľsky prívetivé rozhranie práca so súbormi a zabezpečenie používania súborov uložených na externých médiách ( HDD+ RAM) viacerými používateľmi a procesmi.
Podľa zloženia FS:
· súhrn všetkých súborov na disku na všetkých médiách,
· súbory dátových štruktúr používaných na správu súborov, ako sú adresáre súborov, deskriptory súborov, tabuľky na pridelenie voľného a použitého miesta na disku,
· komplex systému softvér, implementujúca správu súborov, najmä: vytváranie, ničenie, čítanie, zápis, pomenovanie, vyhľadávanie a iné operácie so súbormi.
Jedným z atribútov súboru sú názvy súborov, spôsob identifikácie súboru pre používateľa. V systémoch, kde sú povolené viaceré názvy, je súbor priradený inode, ktorý používa jadro OS. Názvy sú v rôznych operačných systémoch nastavené inak.
Zatiaľ čo mnohé architektonické prvky OS sa priamo týkajú iba systémových programátorov, koncept viacerých operačných systémov priamo súvisí s potrebami koncových používateľov – schopnosťou operačného systému spúšťať aplikácie napísané pre iné operačné systémy. Táto vlastnosť operačného systému sa nazýva kompatibilita.
Kompatibilita aplikácií môže byť na binárnej úrovni a na úrovni zdroja. Aplikácie sú zvyčajne uložené v OS ako spustiteľné súbory obsahujúce binárne obrázky kódu a údajov. Binárna kompatibilita sa dosiahne, keď môžete vziať spustiteľný program a spustiť ho v inom prostredí operačného systému.
Kompatibilita na úrovni zdroja vyžaduje prítomnosť vhodného kompilátora ako súčasti softvéru počítača, na ktorom sa má aplikácia spustiť, ako aj kompatibilitu na úrovni knižníc a systémových volaní. V tomto prípade je potrebné prekompilovať zdrojový kód aplikácie do nového spustiteľného modulu.
Kompatibilita na zdrojovej úrovni je dôležitá hlavne pre vývojárov aplikácií, ktorí majú k dispozícii zdrojový kód. Pre koncových používateľov má však praktický význam iba binárna kompatibilita, pretože iba v tomto prípade môžu používať rovnaký produkt na rôznych operačných systémoch a na rôznych počítačoch.
Typ možnej kompatibility závisí od mnohých faktorov. Najdôležitejšou z nich je architektúra procesora. Ak procesor používa rovnakú inštrukčnú sadu (možno s doplnkami, ako v prípade IBM PC: štandardná sada + multimédiá + grafika + streaming) a rovnaký rozsah adries, potom sa dá binárna kompatibilita dosiahnuť úplne jednoducho. Aby to bolo možné, musia byť splnené nasledujúce podmienky:
- API, ktoré aplikácia používa, musí byť podporované operačným systémom;
- Vnútorná štruktúra spustiteľného súboru aplikácie musí zodpovedať štruktúre spustiteľných súborov daného OS.
Ak majú procesory rôzne architektúry, potom je okrem vyššie uvedených podmienok potrebné zorganizovať emuláciu binárneho kódu. Napríklad emulácia príkazov procesora Intel na procesore Motorola 680x0 počítača Macintosh je široko používaná. Softvérový emulátor v tomto prípade postupne vyberie binárnu inštrukciu z procesora Intel a vykoná ekvivalentnú rutinu zapísanú v inštrukciách z procesora Motorola. Keďže procesor Motorola nemá úplne rovnaké registre, príznaky, interné ALU atď., ako v procesoroch Intel, musí všetky tieto prvky simulovať (emulovať) aj pomocou svojich registrov alebo pamäte.
Toto je jednoduchá, ale veľmi pomalá úloha, pretože jedna inštrukcia Intel sa vykonáva oveľa rýchlejšie ako sekvencia procesora Motorola, ktorá ju emuluje. Riešením v takýchto prípadoch je použitie takzvaných aplikačných softvérových prostredí alebo operačných prostredí. Jednou zo súčastí takéhoto prostredia je súbor funkcií API, ktoré OS poskytuje svojim aplikáciám. Aby sa skrátil čas potrebný na spustenie cudzích programov, aplikačné prostredia simulujú volania funkcií knižnice.
Efektívnosť tohto prístupu pramení zo skutočnosti, že väčšina programov dnes beží pod GUI (grafické používateľské rozhrania), ako sú Windows, MAC alebo UNIX Motif, pričom aplikácie trávia 60 – 80 % svojho času vykonávaním funkcií GUI a iných volaní knižníc OS. Práve táto vlastnosť aplikácií umožňuje aplikačným prostrediam kompenzovať veľké množstvo času stráveného emuláciou programu za príkazom. Starostlivo navrhnuté prostredie softvérových aplikácií zahŕňa knižnice, ktoré napodobňujú knižnice GUI, ale sú napísané v natívnom kóde. Dosahuje sa tak výrazné zrýchlenie vykonávania programov pomocou API iného operačného systému. Tento prístup sa inak nazýva preklad, aby sa odlíšil od pomalšieho procesu emulácie jedného príkazu naraz.
Napríklad pre program Windows spustený na počítači Macintosh pri interpretácii príkazov procesora Intel výkon môže byť veľmi nízka. Ale keď sa uskutoční volanie funkcie GUI, otvorí sa okno atď., modul OS, ktorý implementuje prostredie aplikácie Windows, môže toto volanie zachytiť a presmerovať ho na rutinu otvárania okna prekompilovanú pre procesor Motorola 680x0. Výsledkom je, že v takýchto častiach kódu môže rýchlosť programu dosiahnuť (a možno aj prekročiť) rýchlosť práce na jeho natívnom procesore.
Aby bol program napísaný pre jeden OS spustený v inom OS, nestačí len zabezpečiť kompatibilitu API. Koncepty, ktoré sú základom rôznych operačných systémov, môžu byť vo vzájomnom konflikte. Napríklad v jednom OS môže byť aplikácii povolené ovládať I/O zariadenia, zatiaľ čo v inom sú tieto akcie výsadou OS.
Každý OS má svoje vlastné mechanizmy ochrany zdrojov, svoje vlastné algoritmy spracovania chýb a výnimiek, vlastnú štruktúru procesora a schému správy pamäte, vlastnú sémantiku prístupu k súborom a grafické používateľské rozhranie. Na zabezpečenie kompatibility je potrebné zorganizovať bezkonfliktnú koexistenciu viacerých metód správy počítačových zdrojov v rámci jedného OS.
Existujú rôzne možnosti na vytváranie prostredí viacerých aplikácií, ktoré sa líšia vlastnosťami architektonických riešení a funkčnosťou, ktorá poskytuje rôzne stupne prenosnosti aplikácií. Jedna z najzrejmejších možností implementácie prostredia viacerých aplikácií je založená na štandardnej viacvrstvovej štruktúre OS.
Ďalší spôsob budovania viacerých aplikačných prostredí je založený na mikrokerneli. Zároveň je veľmi dôležité uvedomiť si základný rozdiel, spoločný pre všetky aplikačné prostredia, medzi mechanizmami operačného systému a vysokoúrovňovými funkciami špecifickými pre každé aplikačné prostredie, ktoré riešia strategické problémy. V súlade s mikrokernelová architektúra Všetky funkcie operačného systému sú implementované servermi mikrojadra a používateľského režimu. Je dôležité, aby prostredie aplikácie bolo navrhnuté ako samostatný server v užívateľskom režime a neobsahovalo základné mechanizmy.
Aplikácie využívajúce API robia systémové volania do zodpovedajúceho aplikačného prostredia cez mikrokernel. Prostredie aplikácie spracuje požiadavku, vykoná ju (možno tak, že na to zavolá základné funkcie mikrojadra) a pošle výsledok späť do aplikácie. Pri vykonávaní požiadavky musí aplikačné prostredie pristupovať k základným mechanizmom operačného systému implementovaným mikrokernelom a inými servermi OS.
Tento prístup k navrhovaniu prostredí s viacerými aplikáciami má všetky výhody a nevýhody mikrojadrovej architektúry, najmä:
- je veľmi jednoduché pridávať a vylučovať aplikačné prostredia, čo je dôsledkom dobrej rozšíriteľnosti operačných systémov s mikrojadrom;
- ak jedno z aplikačných prostredí zlyhá, ostatné ostanú funkčné, čo prispieva k spoľahlivosti a stabilite systému ako celku;
- nízky výkon mikrokernelových operačných systémov ovplyvňuje rýchlosť aplikačných nástrojov, a tým aj rýchlosť aplikácií.
V dôsledku toho je potrebné poznamenať, že vytvorenie niekoľkých aplikačných nástrojov v rámci jedného OS na spúšťanie aplikácií z rôznych OS je spôsob, ktorý umožňuje mať jednu verziu programu a prenášať ju medzi rôznymi operačnými systémami. Viaceré aplikačné prostredia poskytujú binárnu kompatibilitu daného operačného systému s aplikáciami napísanými pre iné operačné systémy.
1.9. Virtuálne stroje ako moderný prístup k implementácii viacerých aplikačných prostredí
Koncept "virtual machine monitor" (VMM) vznikol koncom 60. rokov ako softvér úroveň abstrakcie, ktorý rozdelil hardvérovú platformu na niekoľko virtuálnych strojov. Každý z týchto virtuálnych strojov (VM) bol taký podobný základnému fyzickému stroju, že existujúci softvér by sa na ňom dalo vykonávať bez zmeny. V tom čase problémy s výpočtovou technikou všeobecný boli riešené na drahých sálových počítačoch (napríklad IBM /360) a používatelia chválili schopnosť VMM distribuovať obmedzené zdroje medzi viaceré aplikácie.
V 80-90 rokoch náklady výrazne klesli počítačové vybavenie a efektívne multitasking OS, čo znížilo hodnotu MVM v očiach používateľov. Sálové počítače ustúpili minipočítačom a potom počítačom a VMM už neboli potrebné. V dôsledku toho jednoducho zmizli z počítačovej architektúry. hardvér pre ich efektívnu realizáciu. Koncom 80. rokov boli MVM vo vede a priemysle vnímané len ako historická kuriozita.
Dnes je MVM opäť v centre pozornosti. Spoločnosti Intel, AMD, Sun Microsystems a IBM vytvárajú virtualizačné stratégie a vo vedeckých laboratóriách a univerzitách sa vyvíjajú prístupy založené na virtuálnych strojoch s cieľom riešiť problémy mobility, bezpečnosti a spravovateľnosti. Čo sa stalo medzi rezignáciou MVM a ich oživením?
V 90. rokoch začali výskumníci na Stanfordskej univerzite skúmať možnosť využitia virtuálnych počítačov na prekonanie obmedzení hardvéru a operačného systému. Problémy nastali s počítačmi s masívne paralelným spracovaním (Massively Parallel Processing, MPP), ktoré boli náročné na programovanie a nedokázali spustiť existujúci OS. Výskumníci zistili, že pomocou virtuálnych strojov môžu túto nepohodlnú architektúru dostatočne priblížiť existujúcim platformám, aby mohli využívať výhody bežných operačných systémov. Z tohto projektu vzišli ľudia a nápady, ktoré sa stali zlatým fondom spoločnosti VMware (www.vmware.com), prvého dodávateľa VMM pre počítače na masovom trhu.
Napodiv, vývoj moderných operačných systémov a zníženie nákladov na hardvér viedli k vzniku problémov, ktoré vedci dúfali vyriešiť pomocou VMM. Lacné vybavenie prispelo k rýchlemu rozšíreniu počítačov, ale často boli nedostatočne využívané a vyžadovali si dodatočný priestor a úsilie na údržbu. A dôsledkom rastu funkčnosti OS bola ich nestabilita a zraniteľnosť.
Ak chcete znížiť vplyv zlyhaní systému a chrániť sa pred hackermi, správcov systému sa vrátil k jednorazovej úlohe výpočtový model(s jednou aplikáciou na jednom stroji). To viedlo k dodatočným nákladom v dôsledku zvýšených požiadaviek na vybavenie. Presun aplikácií z rôznych fyzických strojov na VM a konsolidácia týchto VM na niekoľkých fyzických platformách zlepšilo využitie hardvéru a znížilo náklady na správu a podlahovú plochu. Schopnosť VMM multiplexovať hardvér – tentoraz v mene konsolidácie serverov a utility computingu – ho teda opäť priviedla k životu.
V súčasnosti sa MVM nestal ani tak prostriedkom na organizáciu multitaskingu, ako sa kedysi zamýšľalo, ale skôr riešením problémov so zaistením bezpečnosti, mobility a spoľahlivosti. VMM v mnohých ohľadoch dáva tvorcom operačných systémov možnosť vyvinúť funkcie, ktoré nie sú možné v dnešných zložitých operačných systémoch. Funkcie, ako je migrácia a bezpečnosť, sa oveľa jednoduchšie implementujú na úrovni VMM, čo podporuje spätnú kompatibilitu pri nasadzovaní inovácií operačného systému pri zachovaní starších vylepšení.
Virtualizácia je vyvíjajúca sa technológia. Vo všeobecnosti vám virtualizácia umožňuje oddeliť softvér od základnej hardvérovej infraštruktúry. V skutočnosti preruší spojenie medzi špecifickou sadou programov a konkrétnym počítačom. Monitor virtuálneho počítača sa oddelí softvér z hardvéru a tvorí medzistupeň medzi spusteným softvérom virtuálne stroje a hardvér. Táto úroveň umožňuje VMM plne kontrolovať používanie hardvérových prostriedkov hosťujúce operačné systémy (GuestOS), ktoré sa vykonávajú na VM.
VMM vytvára jednotný pohľad na základný hardvér, takže fyzické stroje od rôznych dodávateľov s rôznymi I/O subsystémami vyzerajú rovnako a virtuálne počítače bežia na akomkoľvek dostupnom hardvéri. Bez toho, aby sa museli starať o jednotlivé stroje s ich tesným prepojením medzi hardvérom a softvérom, môžu správcovia vidieť hardvér jednoducho ako súbor zdrojov na poskytovanie akejkoľvek služby na požiadanie.
Vďaka úplné zapuzdrenie stavu softvéru na VM, monitor VMM môže mapovať VM na akékoľvek dostupné hardvérové prostriedky a dokonca ho preniesť z jedného fyzického počítača na druhý. Úloha vyváženia záťaže naprieč skupinou strojov sa stáva triviálnou a objavujú sa spoľahlivé spôsoby riešenia porúch zariadení a rozširovania systému. Ak potrebujete vypnúť zlyhaný počítač alebo uviesť do prevádzky nový, VMM dokáže zodpovedajúcim spôsobom prerozdeliť virtuálne počítače. Virtuálny stroj sa ľahko replikuje, čo umožňuje správcom rýchlo poskytovať nové služby podľa potreby.
Zapuzdrenie tiež znamená, že správca môže kedykoľvek pozastaviť alebo obnoviť VM, ako aj uložiť aktuálny stav virtuálneho počítača alebo ho vrátiť do predchádzajúceho stavu. Vďaka univerzálnej možnosti vrátenia späť možno ľahko riešiť nehody a chyby v konfigurácii. Zapuzdrenie je základom všeobecného modelu mobility, pretože pozastavený VM možno replikovať cez sieť, uložiť a preniesť na vymeniteľné médium.
VMM sprostredkováva všetky interakcie medzi VM a základným hardvérom, podporuje spustenie viacerých virtuálnych strojov na jednej hardvérovej platforme a zabezpečuje ich spoľahlivú izoláciu. VMM vám umožňuje zostaviť skupinu VM s nízkymi požiadavkami na zdroje na samostatnom počítači, čím sa znížia náklady hardvér a potreba výrobných priestorov.
Pre spoľahlivosť a bezpečnosť je dôležitá aj úplná izolácia. Aplikácie, ktoré predtým bežali na jednom počítači, je teraz možné distribuovať na rôznych VM. Ak jeden z nich spôsobí pád OS v dôsledku chyby, ostatné aplikácie budú od neho izolované a budú pokračovať v práci. Ak je niektorá z aplikácií ohrozená externým útokom, útok bude lokalizovaný v rámci „kompromitovaného“ VM. VMM je teda nástrojom na reštrukturalizáciu systému, aby sa zlepšila jeho stabilita a bezpečnosť, bez potreby dodatočného priestoru a administratívneho úsilia, ktoré sú potrebné pri spúšťaní aplikácií na samostatných fyzických počítačoch.
VMM musí pripojiť hardvérové rozhranie k VM, pričom si musí zachovať plnú kontrolu základný stroj a postupy na interakciu s jeho hardvérom. Na dosiahnutie tohto cieľa existujú rôzne metódy založené na určitých technických kompromisoch. Pri hľadaní takýchto kompromisov sa berú do úvahy základné požiadavky na MVM: kompatibilita, výkon a jednoduchosť. Kompatibilita je dôležitá, pretože hlavnou výhodou VMM je jeho schopnosť spúšťať staršie aplikácie. Výkon určuje množstvo réžie pre virtualizáciu - programy na VM musia byť vykonávané rovnakou rýchlosťou ako na skutočnom stroji. Jednoduchosť je nevyhnutná, pretože zlyhanie VVM bude mať za následok zlyhanie všetkých VM bežiacich na počítači. Spoľahlivá izolácia vyžaduje najmä to, aby VMM neobsahoval chyby, ktoré môžu útočníci použiť na zničenie systému.
Namiesto toho, aby ste museli riešiť zložité prepracovanie kódu hosťujúceho operačného systému, môžete vykonať nejaké zmeny v hostiteľskom operačnom systéme zmenou niektorých najnepríjemnejších častí jadra. Tento prístup sa nazýva paravirtualizácia. Je jasné, že v tomto prípade dokáže prispôsobiť jadro OS iba autor a napríklad Microsoft neprejavuje žiadnu túžbu prispôsobiť obľúbené jadro Windows 2000 realite konkrétnych virtuálnych strojov.
Pomocou paravirtualizácie vývojár VMM predefinuje rozhranie virtuálneho stroja a nahradí podmnožinu pôvodnej inštrukčnej sady, ktorá nie je vhodná pre virtualizáciu, za pohodlnejšie a efektívnejšie ekvivalenty. Všimnite si, že hoci operačný systém musí byť portovaný, aby mohol bežať na takýchto VM, väčšina bežných aplikácií môže bežať nezmenená.
Najväčšou nevýhodou paravirtualizácie je nekompatibilita. akýkoľvek operačný systém, navrhnutý tak, aby bežal pod kontrolou paravirtualizovaného monitora VMM, musí byť portovaný na túto architektúru, pre ktorú je potrebné dohodnúť spoluprácu s predajcami OS. Okrem toho nie je možné použiť staršie operačné systémy a existujúce stroje nemožno jednoducho nahradiť virtuálnymi strojmi.
Dosiahnuť vysoký výkon a kompatibilitu s virtualizáciou architektúry x86, ktorú vyvinul VMware nová metóda virtualizácia, ktorá kombinuje tradičné priame vykonávanie s rýchlym prekladom binárneho kódu za behu. Vo väčšine moderných operačných systémov sa režimy činnosti procesora pri vykonávaní bežných aplikačných programov ľahko virtualizujú, a preto môžu byť virtualizované priamym vykonávaním. Privilegované režimy nevhodné pre virtualizáciu môže vykonávať prekladač binárneho kódu, opravujúci „nepohodlné“ x86 príkazy. Výsledkom je vysoký výkon virtuálny prístroj, ktorý plne zodpovedá hardvéru a podporuje úplná kompatibilita BY .
Prevedený kód je veľmi podobný výsledkom paravirtualizácie. Bežné príkazy sa vykonávajú nezmenené, ale príkazy, ktoré vyžadujú špeciálne zaobchádzanie(ako sú POPF a príkazy na čítanie registra kódových segmentov), prekladač ich nahradí sekvenciami príkazov, ktoré sú podobné tým, ktoré sú potrebné na vykonanie na paravirtualizovanom virtuálny prístroj. Je tu však dôležitý rozdiel: namiesto zmeny zdroj operačný systém alebo aplikácie, prekladač binárneho kódu upraví kód pri jeho prvom spustení.
Aj keď preklad binárneho kódu predstavuje určitú réžiu, pri bežnej záťaži je zanedbateľná. Prekladač spracuje iba časť kódu a rýchlosť vykonávania programu je porovnateľná s rýchlosťou priameho vykonávania - hneď ako je vyrovnávacia pamäť plná
Kompatibilita a viaceré aplikačné prostredia
Koncept viacerých aplikačných prostredí súvisí s potrebami koncových používateľov – schopnosťou operačného systému spúšťať aplikácie z iných operačných systémov. Táto vlastnosť operačného systému sa nazýva kompatibilita.
Binárna a zdrojová kompatibilita
Existuje kompatibilita na binárnej úrovni a kompatibilita na úrovni zdroja. Aplikácie sú zvyčajne uložené v OS ako spustiteľné súbory obsahujúce binárne obrázky kódu a údajov. Binárna kompatibilita sa dosiahne, keď môžete vziať spustiteľný program a spustiť ho v inom prostredí operačného systému.
Kompatibilita na úrovni zdroja vyžaduje prítomnosť vhodného kompilátora ako súčasti softvéru počítača, na ktorom má aplikácia bežať, ako aj kompatibilitu na úrovni knižníc a systémových volaní. V tomto prípade je potrebné skompilovať existujúce zdrojové texty do spustiteľného modulu.
Kompatibilita na zdrojovej úrovni je dôležitá hlavne pre vývojárov aplikácií, ktorí majú k dispozícii zdrojový kód. Pre koncových používateľov má praktický význam iba binárna kompatibilita, pretože iba vtedy môžu používať rovnaký komerčný produkt v binárnej forme. spustiteľný kód v rôznych operačných prostrediach.
To, či sú operačné systémy binárne alebo zdrojovo kompatibilné, závisí od mnohých faktorov. Tou hlavnou je architektúra procesora, na ktorom beží nový OS. Ak procesor používa rovnakú inštrukčnú sadu (možno s nejakými doplnkami) a rovnaký rozsah adries, potom sa dá binárna kompatibilita dosiahnuť úplne jednoducho. Na to stačí splniť nasledujúce podmienky:
Volania funkcií API, ktoré aplikácia obsahuje, musia byť podporované operačným systémom;
Vnútorná štruktúra spustiteľného súboru aplikácie sa musí zhodovať so štruktúrou spustiteľných súborov OS.
Je ťažšie dosiahnuť binárnu kompatibilitu pre operačné systémy navrhnuté tak, aby bežali na procesoroch rôznych architektúr. Okrem splnenia vyššie uvedených podmienok je potrebné zorganizovať emuláciu binárneho kódu, čo povedie k pomerne pomalému vykonávaniu programu.
Vytvorenie kompletného aplikačného prostredia, ktoré je plne kompatibilné s prostredím iného operačného systému, je úloha úzko súvisiaca so štruktúrou operačného systému. Existujú rôzne možnosti na vytváranie prostredí viacerých aplikácií, ktoré sa líšia vlastnosťami architektonických riešení a funkčnosťou, ktorá poskytuje rôzne stupne prenosnosti aplikácií.
Jedna z najzrejmejších možností implementácie prostredia viacerých aplikácií je založená na štandardnej viacúrovňovej štruktúre OS a poskytuje preklad systémových volaní.
Na obrázku 6 operačný systém OS1 podporuje okrem svojich aplikácií aj aplikácie z operačných systémov OS2 a OS3.
Na tento účel obsahuje špeciálne aplikácie - aplikačné softvérové prostredia, ktoré prekladajú rozhrania „cudzích“ operačných systémov API OS2 a API OS3 do rozhrania vlastného operačného systému - API OS1.
Obrázok 6 – Prostredia aplikačného softvéru, ktoré prekladajú systémové volania
V inom uskutočnení prostredia s viacerými aplikáciami má operačný systém niekoľko rozhraní na programovanie partnerských aplikácií (obrázok 7). V uvedenom príklade operačný systém podporuje aplikácie pre OS1, OS2 a OS3.
Za týmto účelom sú aplikačné programové rozhrania všetkých týchto operačných systémov umiestnené priamo v priestore jadra systému: API OS1, API OS2 a API OS3.
Obrázok 7 - Implementácia kompatibility na základe viacerých partnerských API
V tejto možnosti funkcie na úrovni API pristupujú k funkciám na základnej úrovni operačného systému, ktorý musí podporovať všetky tri všeobecne nekompatibilné aplikačné prostredia. Funkcie každého API sú implementované jadrom s prihliadnutím na špecifiká zodpovedajúceho OS, aj keď majú podobný účel. Aby si jadro vybralo požadovanú implementáciu systémového volania, každý proces musí jadru odovzdať sadu identifikačných charakteristík.
Ďalší spôsob budovania viacerých aplikačných prostredí je založený na mikrokerneli. V súlade s architektúrou mikrojadra sú všetky funkcie OS implementované servermi mikrojadra a používateľského režimu. Každé aplikačné prostredie je navrhnuté ako samostatný server v užívateľskom režime a neobsahuje základné mechanizmy (obrázok 8). Aplikácie uskutočňujú systémové volania do ich príslušného aplikačného prostredia cez mikrokernel. Prostredie aplikácie požiadavku spracuje, vykoná a výsledok odošle do aplikácie. Pri vykonávaní požiadavky musí aplikačné prostredie pristupovať k základným mechanizmom operačného systému implementovaným mikrokernelom a inými servermi OS.
Tento prístup k navrhovaniu prostredí s viacerými aplikáciami má všetky výhody a nevýhody architektúry mikrojadra, najmä:
Je veľmi jednoduché pridávať a vylučovať aplikačné prostredia, čo je dôsledok dobrej rozšíriteľnosti mikrokernelov operačných systémov;
Spoľahlivosť a stabilita sú vyjadrené v skutočnosti, že ak jedno z aplikačných prostredí zlyhá, všetky ostatné zostanú funkčné;
Nízky výkon mikrokernelových operačných systémov ovplyvňuje rýchlosť aplikačných prostredí, a teda aj rýchlosť vykonávania aplikácií.
Obrázok 8 - Mikrokernelový prístup k implementácii viacerých aplikačných prostredí
Vytvorenie niekoľkých aplikačných prostredí v rámci jedného operačného systému na spúšťanie aplikácií z rôznych operačných systémov je spôsob, ktorý vám umožňuje mať jednu verziu programu a prenášať ju medzi operačnými systémami.