8. přednáška 11. dubna 2016 Operační systémy 2015/2016.

Prezentace na téma: "8. přednáška 11. dubna 2016 Operační systémy 2015/2016."— Transkript prezentace:

1 8. přednáška 11. dubna 2016 Operační systémy 2015/2016

2 Prioritní RR q=1 q=2(i-1) Dynamické priority procesů Proces Vznik
Trvání 1 3 2 6 4 5 8 q=2(i-1) Operační systémy 2015/2016

3 Zpětná vazba (Feedback)
Proces Vznik Trvání 1 3 2 6 4 5 8 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 A B C D E - předem se neznají časy, které budou procesy potřebovat, penalizují se dlouho běžící procesy, dojde-li k preempci z důvodu přečerpání q, sníží se priorita, pro každou prioritu je jedna fronta, nad každou frontou běží RR, nad poslední FCFS Operační systémy 2015/2016

4 Process Arival Time Service Time
Srovnání plánovacích politik – použité procesy Process Arival Time Service Time A 3 B 2 6 C 4 D 5 E 8 Operační systémy 2015/2016

5 Srovnání plánovacích politik
5 10 15 20 A FCFS B C D E A B RR q=1 C D E A B RR q=4 C D E A B C SPN D E A B C SRT D E A B Feedback q=1 C D E Operační systémy 2015/2016

6 FCFS RR q=1 RR q=4 SPN SRT FB q=1
Process Arrival Time Service Time (Ts) A 3 B 2 6 C 4 D 5 E 8 Průměr FCFS Finish Time Turnaround Time (Tr) Tr/Ts 1,00 9 7 1,17 13 2,50 18 12 2,40 20 6,00 8,60 2,65 RR q=1 1,33 16 2,67 17 3,25 14 2,80 15 3,50 10,80 2,71 RR q=4 2,5 11 1,25 19 5,50 10,00 SPN 2,75 1,50 7,60 1,84 SRT 2,17 10 7,20 1,59 FB q=1 3,00 2,60 1,5 2,63 Operační systémy 2015/2016

7 Srovnání plánovacích politik
FCFS (First Come First Served) – nejdéle čekající proces z připravených, nonpreemptive, proces se musí ukončit sám (zvýhodnění procesorově orientovaných), snadná implementace Round Robin (cyklické plánování) – výběr stejný jako u FCFS, nonpreemptive, předem stanovené kvantum (desítky ms, při delším kvantu degradace na FCFS), favorizuje procesorově vázané, virtuální RR (pomocná fronta obsluhovaná prioritně, procesy běží pouze po zbytek časového kvanta), prioritní RR SPN (Shortest Process Next) – proces s nejmenší očekávanou dobou potřeby procesoru, nonpreemptive, varianta SRT (Shortest First) preemptivní, jakmile se objeví kratší, dojde k přerušení, zvýhodnění V/V vázaných procesů, problém odhadu potřeby procesoru, exponenciální průměrování (aproximace budoucnosti z historie, přednost novým procesům), znevýhodnění dlouhých procesů Feedback (zpětná vazba) – neznáme délky procesů, penalizace dlouho běžících procesů, pro každou prioritu jedna fronta, výběr pomocí RR, poslední fronta pomocí FCFS Operační systémy 2015/2016

8 Souběžnost procesů prvořadým úkolem operačního systému je zajistit řízení procesů a sledů multiprogramming – více procesů v jednoprocesorovém systému, multiprocessing – více procesů ve víceprocesorovém prostředí, distributed processing – více procesů v distribuovaných prostředích, stále se rozšiřující nasazování clusterů základním prvkem pro zajištění těchto činností je souběžnost procesů (sledů) komunikace procesů, sdílení prostředků (paměť, soubory, I/O, …), synchronizace činnosti procesů, alokace procesoru, … souběžnost musíme řešit nejenom ve víceprocesorovém a distribuovaném prostředí, ale i v jednoprocesorovém prostředí při multitaskingu souběžnost nastává ve třech případech: multiprogramming (běh více aplikací), strukturované aplikace (moderní aplikace bývají programovány jako množina konkurenčních procesů) a řešení struktur operačního systému (na druhé straně přináší výhody při možnosti použít vláknový přístup) Operační systémy 2015/2016

9 Souběžnost procesů problém souběžnosti vzniká v prostředí prokládání i překrývání příčinou jsou sdílená data a prostředky, procesy používají a modifikují sdílená data, operace zápisu musí být vzájemně výlučná, operace zápisu musí být vzájemně výlučná s operací čtení, operace čtení bez modifikace mohou být souběžné kooperace mezi procesy, potřeba synchronizace běhu, čekání na událost vyvolanou jiným procesem neřízeným přístupem ke sdíleným údajům mohou procesy (sledy) získat nekonzistentní pohled na data, akce prováděné souběžnými procesy jsou závislé na pořadí prokládání jejich běhů obtížná lokalizace chyb programování výsledky procesů musí být nezávislé na rychlosti běhu jednotlivých procesů část kódu, kde se přistupuje ke sdílenému prostředku, se nazývá kritické sekce procesu sdružená s tímto prostředkem většinou je potřeba zajistit, aby v kritické sekci sdružené s jistým prostředkem, byl nejvýše jeden proces

10 Kooperace mezi procesy
sdílení - procesy používají a modifikují sdílená data (soubory, proměnné, databázové záznamy), operace zápisu musí být vzájemně výlučné, zápis musí být výlučný se čtením, čtení může být realizováno souběžně, pro zabezpečení integrity dat se používají kritické sekce, sledy mají společnou datovou oblast P1 P2 D komunikace - dají se koordinovat i procesy na jiném procesoru (počítači), může dojít k uváznutí v důsledku čekání na zprávu od jiného procesu, může dojít ke stárnutí (dva procesy si posílají zprávy, třetí se nemůže dočkat) P1 P2 událost zpráva Operační systémy 2015/2016

11 Souběžnost procesů - termíny
Atomic operations Akce (sekvence jedné nebo více instrukcí), která se jeví jako nedělitelná. Žádný jiný proces ji nemůže přerušit. Critical section Část kódu, který mohou sdílet různé procesy a nesmí být přístupná druhému procesu, pokud ji provádí první. Deadlock Situace, kdy dva nebo více procesů nemohou pracovat, jelikož čekají na dokončení jiného procesu. Livelock Situace, kdy dva nebo více procesů mění svůj stav v závislosti na jiném procesu bez provádění užitečné práce. Mutual exclusion Pokud je v kritické sekci nějaký proces, jinému je to zakázáno. Race condition Situace, kdy proces čte nebo modifikuje sdílená data a výsledek je závislý na průběhu jejich provádění. Starvation Situace, kdy proces není přeplánován, ačkoliv má splněny všechny předpoklady. Operační systémy 2015/2016

12 Jednoduchý příklad void echo() { chin = getchar(); chout = chin;
putchar(chout); } Proces1 ... chin = getchar(); chout = chin; putchar(chout); Proces2 ... chin = getchar(); chout = chin; putchar(chout); Operační systémy 2015/2016

13 Kritická sekce do { entry section KS exit section zbytek programu
} while(1); entry section KS Modelové prostředí pro řešení problému kritické sekce: každý proces běží nenulovou rychlostí o relativní rychlosti procesů nelze vyslovit žádný předpoklad a řešení na nich nesmí záviset Požadavky: vzájemné vyloučení (podmínka bezpečnosti) – Mutual Exclusion - trvalost postupu (podmínka živosti) – Progress - konečné čekání (podmínka spravedlivosti) - Fairness exit section zbytek programu ZP Operační systémy 2015/2016

14 Požadavky na řešení problému kritických sekcí
Vzájemné vyloučení (podmínka bezpečnosti) – Mutual Exclusion Pokud proces Pi je ve své kritické sekci, pak žádný další proces nesmí být ve své kritické sekci sdružené s týmž prostředkem. V každém okamžiku smí být v kritické sekci pouze jeden proces. Trvalost postupu (podmínka živosti) – Progress Rozhodování o tom, který proces vstoupí do KS, ovlivňují pouze procesy, které o vstup do kritické sekce usilují. Toto rozhodnutí pro žádný proces nemůže být odkládáno do nekonečna (nedodržení této podmínky může vést ke striktní alternaci dvou procesů). Konečné čekání (podmínka spravedlivosti) – Fairness Proces smí čekat na povolení vstupu do kritické sekce jen konečnou dobu. Musí existovat omezení počtu, kolikrát může být povolen vstup do KS sdružené s jistým prostředkem jiným procesům než procesu požadujícímu vstup v době mezi vydáním žádosti a jejím uspokojením. Pokud tedy proces usiluje o vstup do KS, nemohou tomu ostatní procesy zabránit tím, že se v kritické sekci neustále střídají (vstupují do ní zpravidla jednou). Operační systémy 2015/2016

15 Uváznutí a stárnutí procesů
Důsledkem snahy synchronizovat běh procesů je jejich uváznutí a stárnutí. Uváznutí - množina procesů P uvázla, pokud každý proces Pi z množiny P čeká na událost, kterou vyvolá pouze některý z procesů z P - nutné (nepostačující) podmínky: vzájemné vyloučení (pouze jeden proces může používat prostředek), postupné uplatňování požadavků (Hold and Wait, proces může při žádosti o prostředek již něco vlastnit), nepřípustnost předbíhání (žádnému procesu se nesmí nic násilně odebrat) - postačující podmínka (důsledek nutných): cyklické čekání procesů - událost – uvolnění prostředku (paměť, soubor, I/O, …), zaslání zprávy Stárnutí - požadavky jednoho nebo více procesů nebudou splněny v konečném čase (priorita, prevence uváznutí, …) - některé operační systémy (Unix SVR4) problém uváznutí a stárnutí ignorují, tváří se, že tento problém neexistuje

16 Vznik uváznutí procesů
proces D proces A NESMÍ NASTAT Y V proces C proces B X W Operační systémy 2015/2016

17 Vznik zablokování Operační systémy 2015/2016

18 Možnosti řešení problému kritické sekce
Softwarové řešení aktivní čekání, naivní řešení, myšlenka zamykacích proměnných není zcela chybná Hardwarové řešení pomocí speciální instrukcí procesoru, opět aktivní čekání (busy waiting), snižuje se průchodnost OS Prostřednictvím operačního systému potřebné datové struktury určené k synchronizaci poskytuje OS (semafory), pasivní čekání (procesy nesoutěží o procesor), podpora volání synchronizačních služeb v programovacích systémech/jazycích (monitory, zasílání zpráv), hrozí uváznutí nebo stárnutí P0 while(1) { while(obsazeno) ; obsazeno=1; KS; obsazeno=0; } P1 shared int obsazeno=0;

19 HW řešení kritické sekce
- na monoprocesoru se dosáhne vzájemného vyloučení - na multiprocesoru se vzájemného vyloučení nedosáhne (který procesor přijímá přerušení?) - obecně neakceptovatelné řešení - řešení speciálními instrukcemi, atomicky se provádí dvě akce se stejnou buňkou paměti (čtení a testování, výměna registrů) - akce jsou výlučné i v prostředí multiprocesoru Proces Pi do { disable interrupt KS enable interrupt ZP } while (1); Proces Pi do { do {} while testset(b); KS b=0; ZP while(1); testset(i) je-li i==0, i=1 vrací true je-li i==1 vrací false Operační systémy 2015/2016

20 Modelování uváznutí A P2 P1 B
- alokační graf (graf přidělování zdrojů), znázornění přidělených a požadovaných prostředků, počet instancí každého prostředku, Resource Allocation Graph (RAG) - prostředek Ri má Wi instancí, jsou opakovaně přístupné (žádost, používání, uvolnění) - uzly: prostředky, procesy, hrany: požadavkové (orientace z procesu na prostředek), přidělovací (orientace z prostředku na proces) - pokud alokační graf neobsahuje cyklus – není uváznutí - pokud alokační graf obsahuje cyklus – jedinečné prostředky = uváznutí, násobné prostředky (více instancí) = nemusí uváznout proces prostředek se čtyřmi instancemi A B P1 P2 požadavek V držení proces vlastní prostředek proces požaduje prostředek Operační systémy 2015/2016

21 Ochrana před uváznutím
Neobsahuje cyklus R1 R2 R3 R4 P1 P3 P2 Obsahuje cyklus R1 R2 R3 R4 Ochrana před uváznutím - prevence: ruší se platnost některé nutné podmínky, k uváznutí nikdy nedojde - detekce: detekuje se existence uváznutí, řeší se následky - obcházení: zamezuje se současné platnosti nutných podmínek, prostředek se nepřidělí, pokud by hrozilo uváznutí, hrozí stárnutí - ignorace: nejjednodušší metoda („pštrosí metoda“), pokud k uváznutí dojde – reboot, nelze použít pro životně kritické systémy

22 Prevence uváznutí - konzervativní politika, omezuje se přidělování prostředků, přímé a nepřímé metody - nepřímé metody – zneplatnění některé nutné podmínky (virtualizace prostředků, přidělení všech prostředků najednou, odebírání prostředků) - přímé metody – nepřipuštění platnosti postačující podmínky (uspořádání pořadí přidělování prostředků) - virtualizace – nepřímá metoda, rušení vzájemné výlučnosti, mimo spooling nepoužitelné - požadování všech prostředků najednou – nepřímá metoda, při žádosti o prostředek nesmí proces nic vlastnit, nebezpečí stárnutí procesu, vhodné pro procesy s jednou nárazovou činností, neefektivní, možná prodleva při zahájení procesu - odebírání prostředku – jen když lze uchovat stav prostředku (odebírání procesoru, paměti), ruší se vlastnost nepředbíhatelnosti procesů při používání prostředku, dvě možnosti (odmítnutý proces uvolní vše co vlastní a požádá o vše znovu, pokud požadovaný prostředek vlastní jiný proces, je tento požádán o uvolnění všeho a o znovupožádání o vše), použitelné pro prostředky s uchovatelným a obnovitelným stavem, režijní ztráty, možnost cyklického restartu - preventivní metody jsou jednoduché, neefektivní

23 Princip hierarchického uspořádání prostředků
1 2 3 4 5 6 7 8 Uspořádané prostředky volný prostředek proces 5487 proces 1136 proces 25 - proces 5487 nemůže být zablokován, může žádat pouze o prostředek 0, 1 nezablokovatelný - hierarchická strategie se často kombinuje se strategií úplného vyhraze- ní (na jedné úrovni nebývá jeden prostředek, ale celá skupina) - stále příliš defenzívní, lze zlepšit vhodnou volbou posloupnosti pro- středků

24 Obcházení uváznutí zamezuje současné platnosti nutných podmínek
připouští se tak více souběžnosti než při prevenci dva přístupy – nespustí se proces, jehož požadavky by mohly vést k uváznutí, neprovede se přidělení prostředku, pokud by to mohlo vést k uváznutí prostředky jsou podle svého typu rozděleny do kategorií každý typ prostředku se vyskytuje v jistém počtu exemplářů, rozdělení závisí na konfiguraci systému (tiskárny podle kvality tisku, disky podle rychlosti, různé komunikační kanály, …) musí se znát maximum požadovaných prostředků každého procesu, aby mohl proces existovat, musí deklarovat předem svoje C(j, i) Operační systémy 2015/2016

25 Obcházení uváznutí nový proces smí vzniknout jen když platí
existující prostředky pro všechny typy prostředků i a procesy j požadované prostředky pro všechny typy prostředků i a procesy j počet přidělených prostředků typu i procesu j souhrnný počet dostupných prostředků typu i počet prostředků typu i potřebných pro dokončení procesu j souhrnný počet nevyžádaných prostředků typu i nový proces smí vzniknout jen když platí Operační systémy 2015/2016

26 Obcházení uváznutí - nejvýhodnější je nalezení strategie, která by neomezovala, dokud se neobjeví nebezpečí zablokování, přidělení prostředku je pozastaveno až do okamžiku, kdy se situace zlepší - bankéřův algoritmus - název úlohy ze situace v reálném světě (bankéř přidělující finanční prostředky v různých měnách, podmínkou je znalost maximálních požadavků zákazníků - operační systém zná požadavky procesů na čerpání prostředků) pokud existuje alespoň jedno pořadí požadavků, při kterém nedojde k zablokování (všichni klienti banky budou moci splnit své záměry), může operační systém toto pořadí vynutit selektivním splňováním požadavků bankéř prostředek přidělí, pokud systém po přidělení zůstane v bezpečném stavu proces vznikne jen tehdy, když lze uspokojit všechny jeho požadavky (v jakémkoli pořadí) Operační systémy 2015/2016

27 Bankéřův algoritmus máme 3 typy prostředků následujícího složení:
R(1) = 9 R(2) = 3 R(3) = 6 - 4 procesy s počátečním stavem S: požadováno, Cji přiděleno, Aji dostupné, Vi i/j R1 R2 R3 P1 3 2 1 P2 6 5 P3 4 P4 - předpokládejme, že P2 požaduje Q = (1, 0, 1) Operační systémy 2015/2016

28 Bankéřův algoritmus výsledný stav po uspokojení požadavku P2 Q = (1, 0, 1) požadováno, Cji přiděleno, Aji dostupné, Vi i/j R1 R2 R3 P1 3 2 1 P2 6 P3 4 P4 5,1,1 1,0,1 6,1,2 + 1,1,2 0,1,1 - - stav je bezpečný pro posloupnost { P2, P1, P3, P4} (po dokončení P2 máme W(V) = (6, 2, 3), což umožňuje dokončení procesu P1) - požadavek se uspokojí Operační systémy 2015/2016

29 Bankéřův algoritmus pokud P1 požaduje Q = (1, 0, 1), je výsledný stav:
požadováno, Cji přiděleno, Aji dostupné, Vi i/j R1 R2 R3 P1 3 2 1 P2 6 5 P3 4 P4 1,0,0 1,0,1 2,0,1 + 1,1,2 0,1,1 - - stav není bezpečný, každému procesu by chyběla instance prostředku R1 - požadavek se odmítne, P1 bude čekat Operační systémy 2015/2016

30 Detekce zablokování - liberální politika, každý dostává co chce a kdy chce, existenci uváznutí periodicky testuje operační systém - výhoda: žádný proces nemusí čekat na své zahájení, nevýhoda: nutnost řešit uváznutí a posteriori - řešení: zrušení všech uváznutých procesů (nejčastěji použitá metoda), návrat uváznutých procesů k poslednímu kontrolnímu bodu (možnost opakování situace), postupně rušit uváznuté procesy (podle spotřebovaného času procesoru, podle času do dokončení procesu, podle priority, podle množství vlastněných prostředků), postupně předbíhat uváznuté procesy Operační systémy 2015/2016

31 Semafory - programový prostředek, který je umístěn na začátku kritické sekce. Pokud kolem něj projede proces, semafor reaguje změnou stavu. Semafory mohou být binární - první proces nastaví semafor na červenou, ostatní po dobu jejího trvání ztrácí procesor a odchází do fronty semaforu nebo obecné - stav se mění na hodnotu celého čísla - tradiční jméno binárního semaforu je mutex (mutual exclusion) - synchronizační prostředek poskytovaný operačním systémem - nahrazuje režim "busy waiting" pasivním čekáním - jedná se o zobecnění instrukce TST, nahrazení dvoustavové proměnné čítačem (v případě obecného semaforu) - poprvé popsal Edsger Wybe Dijkstra (1965) - původní pojmenování operací proberen (testovat) a verhogen (zvětšit) - stav semaforu >= 0 – počet procesů, které mohou plně provést službu wait (nepřejdou do fronty semaforu) - stav semaforu < 0 – počet čekajících procesů - pro stejný semafor nesmí být žádné dva procesy současně ve wait a signal, i v případě více procesorů - wait i signal jsou vlastně KS (typicky pouze desítky instrukcí) Operační systémy 2015/2016

32 Synchronizace binárním semaforem
- binární semafor je implementován pomocí služeb lock a unlock. Lock zjistí hodnotu semaforu a nastaví jej - musí být implementováno jako nepřerušitelné. Pokud již je semafor nastaven (nějaký proces je v kritické sekci), uloží identifikační číslo aktivního procesu do fronty semaforu a suspenduje ho (proces suspenduje sám sebe). - unlock nejprve zkontroluje stav fronty, pokud je prázdná, nastaví semafor na zelenou. Každý proces tak vyvolá při vstupu do kritické sekce lock, při opouštění unlock. Parametrem služeb je semafor sekce. kritická sekce fronta semaforu binární semafor PROCESY 11 110 587 binární semafor 587 lock PROCESY 11 kritická sekce 110 fronta semaforu unlock do READY fronty Operační systémy 2015/2016