Operační systémy LS 2014/ přednáška 20. dubna 2015

Operační systémy LS 2014/2015 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)

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 Souběžnost procesů

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 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) P1P1 P2P2 událost zpráva P1P1 P2P2 D

Operační systémy LS 2014/2015 Souběžnost procesů - termíny Atomic operationsAkce (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í. DeadlockSituace, kdy dva nebo více procesů nemohou pracovat, jelikož čekají na dokončení jiného procesu. LivelockSituace, 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 exclusionPokud je v kritické sekci nějaký proces, jinému je to zakázáno. Race conditionSituace, kdy proces čte nebo modifikuje sdílená data a výsledek je závislý na průběhu jejich provádění. StarvationSituace, kdy proces není přeplánován, ačkoliv má splněny všechny předpoklady.

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

Kritická sekce 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 do {entry section KS exit section zbytek programu } while(1); entry section exit section zbytek programu ZP KS

Požadavky na řešení problému kritických sekcí Vzájemné vyloučení (podmínka bezpečnosti) – Mutual Exclusion Pokud proces P i 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).

Uváznutí - množina procesů P uvázla, pokud každý proces P i 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 Uváznutí a stárnutí procesů Důsledkem snahy synchronizovat běh procesů je jejich uváznutí a stárnutí.

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

Vznik zablokování

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í P 0 while(1) { while(obsazeno) ; obsazeno=1; KS; obsazeno=0; } P 1 while(1) { while(obsazeno) ; obsazeno=1; KS; obsazeno=0; } shared int obsazeno=0;

- 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 HW řešení kritické sekce Proces P i 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

Modelování uváznutí - 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 R i má W i 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 P1P1 P2P2 požadavek V držení požadavek proces požaduje prostředek proces vlastní prostředek

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 P1P1 P3P3 P2P2 Neobsahuje cyklus R1R1 R2R2 R3R3 R4R4 P1P1 P3P3 P2P2 Obsahuje cyklus R1R1 R2R2 R3R3 R4R4

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í

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ů Princip hierarchického uspořádání prostředků

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 LS 2014/2015

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

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 LS 2014/2015

Bankéřův algoritmus požadováno, C ji přiděleno, A ji dostupné, V i i/jR1R1 R2R2 R3R3 R1R1 R2R2 R3R3 R1R1 R2R2 R3R3 P1P P2P P3P P4P máme 3 typy prostředků následujícího složení: R(1) = 9R(2) = 3R(3) = procesy s počátečním stavem S: - předpokládejme, že P 2 požaduje Q = (1, 0, 1) Operační systémy LS 2014/2015

Bankéřův algoritmus požadováno, C ji přiděleno, A ji dostupné, V i i/jR1R1 R2R2 R3R3 R1R1 R2R2 R3R3 R1R1 R2R2 R3R3 P1P P2P P3P P4P výsledný stav po uspokojení požadavku P 2 Q = (1, 0, 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í 5,1,1 1,0,1 6,1,2 + 1,1,2 1,0,1 0,1,1 - Operační systémy LS 2014/2015

Bankéřův algoritmus požadováno, C ji přiděleno, A ji dostupné, V i i/jR1R1 R2R2 R3R3 R1R1 R2R2 R3R3 R1R1 R2R2 R3R3 P1P P2P P3P P4P pokud P 1 požaduje Q = (1, 0, 1), je výsledný stav: - stav není bezpečný, každému procesu by chyběla instance prostředku R 1 - požadavek se odmítne, P 1 bude čekat 1,0,0 1,0,1 2,0,1 + 1,1,2 1,0,1 0,1,1 - Operační systémy LS 2014/2015

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

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í)

kritická sekce fronta semaforu binární semafor PROCESY kritická sekce fronta semaforu binární semafor PROCESY 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. lock unlock do READY fronty