Operační systémy Přednášky pro výuku předmětu Operační systémy Ing. Antonín Vaněk, CSc. DFJP, Univerzita Pardubice září 2003.

Slides:



Advertisements
Podobné prezentace
Pascal - příklady.
Advertisements

Základy databázových systémů
SOFTWARE dálkové studium PODNIKÁNÍ 2. listopad 2006.
BLIŽŠÍ POHLED NA TŘÍDY, DĚDIČNOST - úvod
Operační systémy. OPERAČNÍ SYSTÉMY pomoc operátorovi, podpora vlastností reálného času, víceuživatelských a více úlohových systémů.
Hodnocení způsobilosti měřících systémů
Komunikace v DS Přednášky z distribuovaných systémů Ing. Jiří Ledvina, CSc.
Přínosy a druhy počítačových sítí. Jednou z nejvýznamnějších technologií používaných v oblasti výpočetních systémů jsou již řadu let počítačové sítě.
Doplňující referát k přednášce Transakce Šárka Hlušičková
Vzdělávací materiál / DUMVY_32_INOVACE_02B5 Správa pamětí AutorIng. Petr Haman Období vytvořeníčerven 2013 Ročník / věková kategorie2. ročník Vyučovací.
Vzdělávací materiál / DUMVY_32_INOVACE_02B3 Správa zařízení AutorIng. Petr Haman Období vytvořeníProsinec 2012 Ročník / věková kategorie2. ročník Vyučovací.
Řešení dynamických problémů s podmínkami Pavel Surynek Univerzita Karlova v Praze Matematicko-fyzikální fakulta.
Informatika I 3. přednáška
13AMP 6. přednáška Ing. Martin Molhanec, CSc.. Co jsme se naučili naposled Synchronizace procesů Synchronizace procesů Producent-Konzument Producent-Konzument.
Ing. Jiří Šilhán.  představuje komplex aplikačního a základního software, technických prostředků, podnikových procesů a personálních zdrojů určených.
Seminář C cvičení STL, Trolltech Ing. Jan Mikulka.
Modely konzistentnosti Ladislav Kotal PDS 2008Ladislav Kotal2 Konzistentnost Konzistentní = soudržný, neporušený, pevný Konzistenční model = dohoda.
Operační systémy Přednášky pro výuku předmětu Operační systémy Ing. Antonín Vaněk, CSc. DFJP, Univerzita Pardubice září 2003.
Operační systémy Přednášky pro výuku předmětu Operační systémy Ing. Antonín Vaněk, CSc. DFJP, Univerzita Pardubice září 2003.
Jedenácté cvičení Vlákna. Java cv112 Vlákna Operační systém Mutitasking – více úloh se v operačním programu vykonává „současně“ Java Multithreading -
Systém managementu jakosti QMS
13AMP 2. přednáška Ing. Martin Molhanec, CSc.. Stav procesu (kontext) Stav procesu je úplná informace, kterou je nutné uschovat při přerušení procesu,
A1PRG - Programování – Seminář Ing. Michal Standardní knihovní funkce pro vstup a výstup 12 Verze
Reinženýring cesta ke zvyšování výkonnosti státní správy s využitím procesního řízení Ing. Martin Čulík Notes CS a.s. Konference ISSS 2003 Hradec Králové.
13AMP 3. přednáška Ing. Martin Molhanec, CSc.. Co jsme se naučili naposled I. Co je to kontext úlohy Co je to kontext úlohy Task switching (přepnutí úlohy)
Operační systémy Přednášky pro předmět Operační systémy Ing. Antonín Vaněk, CSc. DFJP, Univerzita Pardubice září 2003.
Bezpečnost chemických výrob N Petr Zámostný místnost: A-72a tel.: 4222
7. Typ soubor Souborem dat běžně rozumíme uspořádanou množinu dat, uloženou mimo operační paměť počítače (na disku). Pascalský soubor je abstrakcí skutečného.
Pokročilé architektury počítačů (PAP_04.ppt) Karel Vlček, katedra Informatiky, FEI VŠB Technická Univerzita Ostrava.
Synchronizace Přednášky z distribuovaných systémů Ing. Jiří Ledvina, CSc.
Orbis pictus 21. století Tato prezentace byla vytvořena v rámci projektu.
Zablokování (deadlock, smrtelné objetí, uváznutí)
OPERAČNÍ SYSTÉMY (OS): Programy, které obsluhují základní rutiny počítače a bez nichž by žádný další program nemohl na počítači běžet. Konkrétní programy.
ICT – Informační a komunikační technologie Ing. Libor Měsíček, Ph.D. CN460
Tento výukový materiál vznikl v rámci Operačního programu Vzdělávání pro konkurenceschopnost 1. KŠPA Kladno, s. r. o., Holandská 2531, Kladno,
Co je to OS Správce prostředků –spravuje a přiděluje systémové zdroje systému úlohám, stará se o jejich efektivní sdílení procesoru (ů) operační paměti.
Výrok „Vypadá to, že jsme narazili na hranici toho, čeho je možné dosáhnout s počítačovými technologiemi. Člověk by si ale měl dávat pozor na takováto.
1/28 PB153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ Vlákna 06.
JUI přednáška Vstup a výstup, cykly RNDr. Jiří Dvořák, CSc.
Systém souborů. Množina souborů různých typů – Data – Spustitelné programy – Konfigurační a pomocné informace – I/O zařízení Způsob organizace množiny.
Komunikace v DS Přednášky z distribuovaných systémů Ing. Jiří Ledvina, CSc.
Základy operačních systémů Meziprocesová komunikace a synchronizace Jakub Yaghob.
Informatika (1) Počítač - základní pojmy HW a SW4 OS MS-DOS, Windows 95, 982 Org. souborů na disku, operační paměť2 Aplikace Malování, Word8 Základy programování.
SVAZEK NEDEDIKOVANÝCH PRACOVNÍCH STANIC NA BÁZI OS LINUX DANIEL LANGR DIPLOMOVÁ PRÁCE 2004.
Funkce operačního systému (11). Projekt: CZ.1.07/1.5.00/ OAJL - inovace výuky Příjemce: Obchodní akademie, odborná škola a praktická škola pro.
Zlepšení podmínek pro vzdělávání na středních školách Operačního programu Vzdělávání pro konkurenceschopnost Název a adresa školy: Integrovaná střední.
Uvedení autoři, není-li uvedeno jinak, jsou autory tohoto výukového materiálu a všech jeho částí. Tento projekt je spolufinancován ESF a státním rozpočtem.
Uvedení autoři, není-li uvedeno jinak, jsou autory tohoto výukového materiálu a všech jeho částí. Tento projekt je spolufinancován ESF a státním rozpočtem.
Operační systém (OS) Základní funkce operačního systému: – Zajištění komunikace s okolím. – Řízení a zpracování programů. – Údržba informací na externích.
Uvedení autoři, není-li uvedeno jinak, jsou autory tohoto výukového materiálu a všech jeho částí. Tento projekt je spolufinancován ESF a státním rozpočtem.
Vypracoval / Roman Málek
Zvídavé otázky 1. Prevence a detekce uváznutí
SW počítače - operační systém
Služby Windows Autorem materiálu a všech jeho částí, není-li uvedeno jinak, je Ing. Libor Otáhalík. Dostupné z Metodického portálu ISSN: 
Operační systémy - úvod
DIGITÁLNÍ UČEBNÍ MATERIÁL
1. ročník oboru Mechanik opravář motorových vozidel
VeřeJnÁ FinaNční Politika a VEŘEJNÁ FINANČNÍ ČINNOST
REFORMA VEŘEJNÉHO ZDRAVOTNÍHO POJIŠTĚNÍ Z POHLEDU ZDRAVOTNÍ POJIŠŤOVNY
Operační systémy 9. Spolupráce mezi procesy
Veřejné Finance.
Správa paměti.
Pojmy a vlastnosti operačních systémů
1. ročník oboru Mechanik opravář motorových vozidel
Segmentace Autorem materiálu a všech jeho částí, není-li uvedeno jinak, je Ing. Libor Otáhalík. Dostupné z Metodického portálu ISSN: 
Práce s procesy Centrum pro virtuální a moderní metody a formy vzdělávání na Obchodní akademii T.G. Masaryka, Kostelec nad Orlicí Autor:
Informatika – Operační systémy
Operační systémy.
Přepínání procesů Autorem materiálu a všech jeho částí, není-li uvedeno jinak, je Ing. Libor Otáhalík. Dostupné z Metodického portálu ISSN: 
Přednášky z Distribuovaných systémů
Transkript prezentace:

Operační systémy Přednášky pro výuku předmětu Operační systémy Ing. Antonín Vaněk, CSc. DFJP, Univerzita Pardubice září 2003

Kapitola 5 Konkurence procesů: vzájemné vylučování a synchronizace

Konkurence  procesy si konkurují při:  sdílení prostředků  alokaci času procesoru  komunikaci procesů  synchronizaci více procesů

Interakce procesů  procesy nevědí jeden o druhém  interakce neexistuje  procesy o sobě vědí jen nepřímo  interakci zprostředkuje OS nebo jiný program  procesy o sobě vědí přímo  je možná přímá interakce

Zájmová sféra OS  sledování aktivity procesů  alokace a dealokace prostředků  čas procesoru  paměť  I/O zařízení  soubory  ochrana dat a prostředků výsledek procesu nesmí záviset na rychlosti provádění... sdílí s ostatními procesy čas procesoru

Soutěžení procesů o prostředky  provádění jednoho procesu může ovlivnit chování soupeřících procesů  pokud přístup k jednomu prostředku požaduje více procesů současně, lze prostředek přidělit jen jednomu z nich  ostatní procesy musí čekat !  nelze vždy zaručit, že blokovaný proces získá přístup k prostředku v budoucnosti  takový proces nikdy neskončí, bude bez omezení čekat !

Problémy s konkurencí  pokud přístup ke sdíleným prostředkům není řízen, může dojít k porušení konzistence dat  výsledek akcí prováděných procesy může být závislý na pořadí, v jakém procesy dostanou přidělen procesor  přístup ke sdíleným prostředkům je nutno řídit ! To je nepřípustné!

Příklad  procesy P1 a P2 mají přístup ke stejné proměnné a a provádějí stejnou proceduru echo  procesy mohou být kdykoliv (a tedy kdekoliv) přerušeny  pokud je P1 po provedení operace vstupu přerušen, pak se provede P2 a nakonec se dokončí P1... ... proces P1 vypíše znak, načtený procesem P2 !! static char a; void echo() { cin >> a; cout << a; }

Problémy s řízením přístupu  vzájemné vylučování (Mutual Exclusion)  v každém okamžiku smí mít přistup k prostředku pouze jeden proces  smrtící objetí (Deadlock)  procesy vzájemně čekají na uvolnění prostředků, přidělených jiným procesům  vyhladovění (Starvation)  proces nemůže získat přístup k požadovanému prostředku v důsledku obsazení prostředku jinými procesy

Kooperace procesů sdílením  procesy používají a mění sdílená data  sdílené proměnné, soubory, databáze...  v daném čase může data měnit pouze jeden proces  např. textový soubor nesmí být otevřen pro zápis více editory současně  k zajištění integrity dat se používají kritické sekce

Kooperace procesů komunikací  vzájemná komunikace procesům umožňuje synchronizovat (koordinovat) různé aktivity  může nastat smrtící objetí  každý proces čeká na zprávu od některého jiného procesu ... žádný z procesů nemůže pokračovat  může nastat vyhladovění  dva procesy si stále vyměňují zprávy, zatímco jiný proces čeká na zprávu ... nikdy se jí nedočká

Kritická sekce  proces je ve (své) kritické sekci (pro daný sdílený prostředek), jestliže provádí část programu, manipulující s (tímto) sdíleným prostředkem  provádění kritické sekce musí být vzájemně výlučné (mutually exclusive)  to platí i pro multiprocesorové prostředí  každý proces musí žádat o povolení ke vstupu do kritické sekce ! v každém okamžiku smí být v kritické sekci (pro daný prostředek) pouze jeden proces

Obecná struktura procesu  část programu, implementující protokol povolení přístupu, nazýváme vstupní sekce  po vlastní kritické sekci (tj. úseku, kde dochází k vlastní manipulaci se sdíleným prostředkem) může následovat výstupní sekce  zbytek kódu se označuje jako zbytková sekce repeat entry section critical section exit section remainder section forever

Rámec pro řešení  procesy se provádějí nenulovou rychlostí  nedělají se žádné zvláštní předpoklady o relativní rychlosti procesů  může být použito i více procesorů, ale hardware paměti nesmí umožňovat současný přístup procesorů k jednomu paměťovému místu  nedělají se žádné zvláštní předpoklady o prokládaném provádění  stačí specifikovat vstupní a výstupní sekci

Požadované vlastnosti  vzájemné vylučování (Mutual Exclusion)  v kterémkoliv okamžiku může být v kritické sekci nejvýše jeden proces  pokrok v přidělování  pokud žádný proces není v kritické sekci a některé procesy tam chtějí vstoupit, na rozhodování o tom, který proces dostane povolení, se mohou podílet pouze procesy, které se nenacházejí ve zbytkové sekci  toto rozhodování se musí uskutečnit v konečném čase  omezené čekání  poté, co proces požádal o přístup, smí před ním získat přístup pouze omezený počet procesů  jinak by hrozilo vyhladovění

Typy řešení  SW řešení  algoritmy, jejichž korektnost nezávisí na dalších předpokladech (viz Rámec řešení)  HW řešení  využívá speciální instrukce procesoru  OS řešení  poskytuje programátorovi vhodné funkce a datové struktury

SW řešení: aktivní čekání Příklad:  svého šamana (kritickou sekci) může v daném čase navštívit pouze jediný eskymák (proces)  Igloo má malý vchod, takže dovnitř může vstoupit vždy jen jeden eskymák, aby si přečetl jméno napsané na tabuli  Pokud je na tabuli jeho jméno, může jít k šamanovi  Pokud je na tabuli napsáno jiné jméno, eskymák igloo opět opustí a čeká  Čas od času eskymák znovu vstoupí do igloo podívat se na tabuli

SW řešení  nejprve předpokládejme 2 procesy  algoritmy 1 a 2 jsou nesprávné  správný je algoritmus 3 (Petersonův)  potom řešení zobecníme pro n procesů  tzv. bakery algorithm  nejprve pro 2 procesy: P0 a P1 když uvažujeme proces Pi, proces Pj vždy představuje ostatní procesy (i != j)

Algoritmus 1  sdílená proměnná turn je inicializována (na 0 nebo 1) před provedením libovolného procesu Pi  kritická sekce CS procesu Pi se provádí, jestliže je turn = i  Pi aktivně čeká (busy waiting) pokud je Pj v kritické sekci: požadavek na vzájemné vylučování je splněn  požadavek pokroku není splněn, protože algoritmus vyžaduje přesné dodržení alternace kritických sekcí Process Pi: repeat while(turn!=i){}; CS turn:=j; RS forever

Algoritmus 1 - test  příklad:  předpokládejme, že P 0 má dlouhou zbytkovou sekci RS, P 1 krátkou  pokud je turn=0, P 0 vstoupí do CS a pak provádí dlouhou RS (turn=1)  zatím P 1 vstoupí do CS, provede krátkou RS (turn=0) a znovu se pokusí vstoupit do CS – ale požadavek je odmítnut ! P 1 musí čekat, dokud P 0 nedokončí RS

 jedna booleovská proměnná flag pro každý proces: flag[0] a flag[1]  signalizace připravenosti ke vstupu do CS nastavením flag[i]:=true  požadavek na vzájemné vylučování je splněn  požadavek na pokrok splněn není  po sekvenci: P1: flag[1]:=true P0: flag[0]:=true budou oba procesy neomezeně čekat – máme deadlock Process Pi: repeat flag[i]:= true; while(flag[j]){}; CS flag[i]:= false; RS forever Algoritmus 2

Algoritmus 3 (Petersonův)  Inicializace: flag[0]:=flag[1]:=false turn:= 0 nebo 1  signalizace připravenosti ke vstupu do CS nastavením flag[i]:=true  Pokud se oba procesy pokusí vstoupit do CS současně, pouze jeden bude mít potřebnou hodnotu proměnné turn  výstupní sekce: specifikuje, že Pi nechce vstoupit do sekce CS Process Pi: repeat flag[i]:=true; turn:=j; do {} while (flag[j]and turn=j); CS flag[i]:=false; RS forever

Algoritmus 3 – analýza správnosti  požadavek na vzájemné vylučování je splněn  není možné, aby P 0 a P 1 byly oba v CS  nemůže nastat flag[0] = flag[1] = true a turn = i pro každý proces Pi  plnění požadavků na pokrok a omezenost čekání  Pi nemůže vstoupit do CS, pokud není současně flag[ j] = true a turn = j  pokud Pj není připraven ke vstupu do CS, je flag[ j] = false a Pi proto může vstoupit do CS

 pokud Pj nastavil flag[ j]=true a je ve while(), pak je buďto turn=i nebo turn=j  je-li turn=i, pak Pi nevstupuje do CS (na řadě je Pj) ; pokud turn=j, pak Pj vstupuje do CS, ale při výstupu z CS nastaví flag[ j]=false a tím dovolí Pi vstoupit do CS  když Pj nastavuje flag[ j]=true, nastavil již turn=i  protože Pi po dobu čekání ve while() nemění nastavení turn, nemůže Pi vstoupit do CS, dokud nevstoupí do CS alespoň jednou také Pj (omezené čekání) Algoritmus 3 – analýza správnosti

Vliv chyb programu  pokud jsou splněna všechna 3 kriteria (vzájemné vylučování, pokrok a omezené čekání), pak je řešení odolné proti chybám ve zbytkové sekci (RS)  protože chyba v RS je vlastně totéž, co neomezeně dlouhá sekce RS  bohužel řešení nemůže zajistit odolnost proti chybám v kritické sekci (CS)  proces Pi, u kterého dojde k chybě v CS, signalizuje ostatním procesům tento fakt – Pi je pro tyto procesy stále v kritické sekci

Řešení pro n procesů t.zv. Bakery algoritmus  před vstupem do kritické sekce dostane každý proces číslo. Držitel nejmenšího čísla může vstoupit do CS  když Pi a Pj dostanou stejná čísla:  pokud je i<j, má přednost Pi, jinak Pj  ve výstupní sekci nastaví proces Pi přidělené číslo na 0

Bakery algoritmus  poznámky k zápisu:  (a,b) < (c,d) když a < c nebo když a = c a b < d  max(a 0,...a k ) je číslo b takové, že platí b >= a i pro i=0..k  sdílená data:  choosing: array[0..n-1] of boolean;  všechny prvky pole inicializovány na false  number: array[0..n-1] of integer;  všechny prvky pole inicializovány na 0  korektnost programu závisí na následujícím faktu:  jestliže je Pi v CS a Pk si právě vybral své číslo number[k] != 0, pak (number[i],i) < (number[k],k)  ale důkaz je poněkud složitý...

Process Pi: repeat choosing[i]:=true; number[i]:= max(number[0]..number[n-1])+1; choosing[i]:=false; for j:=0 to n-1 do { while (choosing[j]) {}; while (number[j]!=0 and (number[j],j)<(number[i],i)){}; } CS number[i]:=0; RS forever Bakery algoritmus

Nedostatky SW řešení  Procesy požadující přístup do kritické sekce jsou v aktivním čekání (busy waiting) a proto zbytečně spotřebovávají čas procesoru  pokud jsou kritické sekce dlouhé, může být efektivnější čekající procesy blokovat...

HW řešení  opírá se o některé základní principy:  proces běží v procesoru kontinuálně, dokud nevyvolá službu OS nebo není přerušen  k přerušení procesu může dojít pouze na hranicích instrukcí  mezi dokončením jedné a zahájením další instrukce  přístup k paměťovému místu obvykle vylučuje současný přístup ostatních procesů k tomuto místu

Zákaz přerušení  proces běží, dokud nevyvolá službu OS nebo není přerušen  u jednoprocesorového systému zákaz přerušení zaručuje vzájemné vylučování  u víceprocesorových systémů nezaručuje  jsou omezeny možnosti procesoru prokládat programy  zákaz přerušení může významně snížit efektivnost provádění programů  v době, kdy je některý proces v kritické sekci, nelze procesor přidělit jinému procesu  obecně nevhodné řešení  prodlužuje se doba latence systému  vadí tam, kde je požadována rychlá reakce (multimedia, RT systémy)

Process Pi: repeat disable interrupts CS enable interrupts RS forever Zákaz přerušení

Speciální instrukce  přístup k paměťovému místu obvykle vylučuje přístup ostatních procesů k tomuto místu  lze navrhnout instrukci procesoru, která provádí dvě akce (např. čtení a zápis) s jedním paměťovým místem jako atomickou (nedělitelnou) operaci  provedení takové instrukce nelze přerušit a proto zaručuje vzájemné vylučování  dokonce i při použití více procesorů  takovou instrukci lze velmi jednoduše použít pro řešení problému vzájemného vylučování ... ale pro řešení dalších problémů kritické sekce (pokrok, omezené čekání) je nutné použít složitější programové konstrukce

Instrukce test-and-set  jediná instrukce procesoru přečte příznak a současně ho nastaví  pokud byl příznak nastaven už před provedením instrukce, nové nastavení nic nezmění  kritická sekce je obsazena a proces proto musí čekat ... pokud ale příznak nastaven nebyl, může proces vstoupit do kritické sekce  instrukce je nepřerušitelná a proto nemůže dojít k chybnému vyhodnocení příznaku  lze použít u jedno- i víceprocesorových systémů  lze použít pro více kritických sekcí

Instrukce test-and-set  popis instrukce test-and-set v jazyce C++: bool testset(int& i) { if (i==0) { i=1; return true; } else { return false; }

Instrukce test-and-set  Nevýhody  jedná se o aktivní čekání, zabírající čas procesoru  může dojít k vyhladovění  když proces uvolní kritickou sekci, jako další získá povolení proces, který první provede instrukci  v systému může vzniknout deadlock  proces s nízkou prioritou má kritickou sekci, proces s vysokou prioritou žádá o povolení  procesor je přidělen procesu s vysokou prioritou, kde pak čeká na uvolnění  ale k tomu nemůže dojít, protože proces s nízkou prioritou nemůže získat procesor

 algoritmus přístupu ke kritické sekci, vyžívající funkci testset  sdílená proměnná b se inicializuje na 0  pouze první proces Pi (který nastaví b) vstupuje do kritické sekce Process Pi: repeat repeat{} until testset(b); CS b:=0; RS forever Instrukce test-and-set

Instrukce xchg  instrukce xchg je dostupná u platformy Intel 86  sdílená proměnná b se inicializuje na 0  každý proces Pi má lokální proměnnou k  do CS může vstoupit pouze proces, který najde b=0  tento proces Pi vyloučí přístup ostatních procesů Pj nastavením b=1 Process Pi: repeat k:=1 repeat xchg(k,b) until k=0; CS b:=0; RS forever

OS řešení: semafory  synchronizační nástroj, nevyžadující aktivní čekání  semafory poskytuje programům OS  semafor je celočíselná proměnná, která je (s výjimkou inicializace) dostupná pouze prostřednictvím dvou atomických operací:  wait(S)  signal(S)  aby se vyloučilo aktivní čekání, je proces, který musí čekat, blokován a zařazen do fronty procesů, čekajících na stejnou událost  změnu stavu příslušného semaforu

Semafory  ve skutečnosti je tedy semafor datovou strukturou typu záznam: type semaphore = record count: integer; queue: list of process end; var S: semaphore;  když proces musí čekat na semafor S, je blokován a zařazen do fronty tohoto semaforu  operce signal odstraní jeden proces z fronty a přesune ho do seznamu procesů připravených ke spuštění  způsob výběru procesu určuje zvolená strategie, např. FIFO

Operace semaforu wait(S): S.count--; if (S.count<0) { block this process place this process in S.queue } signal(S): S.count++; if (S.count<=0) { remove a process P from S.queue place this process P on ready list } proměnnou count je nutné inicializovat na nezápornou hodnotu (aktuální hodnota závisí na potřebách aplikace)

Semafory: pozorování  Když je S.count >=0, je počet procesů, které mohou provést wait(S) bez blokování roven S.count  Když je S.count<0, je počet procesů čekajících na semafor S roven |S.count|  Atomicita a vzájemné vylučování:  žádné dva procesy nemohou být ve wait(S) a signal(S) (na tentýž S) ve stejném čase (platí i pro více procesorů)  programové bloky definující wait(S) a signal(S) jsou ve skutečnosti kritické sekce

Semafory: pozorování  kritické sekce definované ve wait(S) a signal(S) jsou velmi krátké  typicky 10 instrukcí  řešení:  jednoprocesorové: zákaz přerušení po dobu provádění operace  je to velmi krátká doba  nelze použít u víceprocesorového systému  víceprocesorové: použít některé z popsaných SW nebo HW řešení  rozsah aktivního čekání nsmí být velký

Použití semaforů pro řešení problému kritické sekce  Pro n procesů  inicializuj S.count na 1  pak má pouze 1 proces povoleno vstoupit do CS (vzájemné vylučování)  obecně platí, že inicializuj S.count na k lze povolit vstup do CS současně k procesům Process Pi: repeat wait(S); CS signal(S); RS forever

Použití semaforů pro synchronizaci procesů  máme dva procesy: P1 a P2  příkaz S1 v P1 musí být proveden dříve než příkaz S2 v P2  definujeme semafor synch  inicializujeme synch na 0  správnou synchronizaci zajistíme takto:  P1: S1; signal(synch);  P2: wait(synch); S2;

Binární semafory  semafory, které jsme zatím používali, nazýváme čítací nebo celočíselné semafory (counting semaphores, integer semaphores)  můžeme však použít i binární semafory  podobné čítacím semaforům, pouze proměnná ”count” je typu boolean  čítací semafory lze implementovat pomocí binárních semaforů...  použití binárních semaforů je obvykle náročnější než čítacích  např. je nelze inicializovat na hodnotu k > 1

Binární semafory waitB(S): if (S.value = 1) { S.value := 0; } else { block this process place this process in S.queue } signalB(S): if (S.queue is empty) { S.value := 1; } else { remove a process P from S.queue place this process P on ready list }

Spinlocks  čítací semafory, používající aktivní čekání (busy waiting) místo blokování (blocking)  jsou užitečné u víceprocesorových systémů, pokud kritická sekce netrvá dlouho  aktivním čekáním sice ztratíme malé množství času CPU, ale ušetříme tím čas potřebný pro přepnutí procesů wait(S): S--; while S<0 do{}; signal(S): S++;

Problémy se semafory  semafory jsou výkonným nástrojem pro řešení vzájemného vylučování a koordinace procesů  wait(S) a signal(S) jsou rozděleny do více procesů a proto je obtížné porozumět jejich působení  použití musí být korektní ve všech procesech  jediný chybný proces může způsobit problémy s celým souborem procesů

Problém obědvajících filozofů  5 filozofů u stolu pouze jí nebo přemýšlí  při jídle každý potřebuje 2 vidličky  k dispozici je pouze 5 vidliček ilustruje obtížnost alokace prostředků procesům bez vzájemného zablokování či vyhladovění (deadlock, starvation) klasický synchronizační problém

Problém obědvajících filozofů  každý filozof představuje jeden proces  potřebujeme jeden semafor pro každou vidličku:  fork: array[0..4] of semaphores  Initialization: fork[i].count:=1 for i:=0..4 Process Pi: repeat think; wait(fork[i]); wait(fork[i+1 mod 5]); eat; signal(fork[i+1 mod 5]); signal(fork[i]); forever  první pokus:  když každý filozof začne tím, že uchopí vidličku po své levici, nastává deadlock

 řešení: dovolit začít jíst pouze 4 filozofům najednou  pak vždy alespoň 1 filozof může jíst, zatímco zbývající 3 musí čekat (s jednou vidličkou v ruce)  musíme tedy použít další semafor (např. T), který umožní omezit počet filozofů  Inicializace: T.count:=4 Process Pi: repeat think; wait(T); wait(fork[i]); wait(fork[i+1 mod 5]); eat; signal(fork[i+1 mod 5]); signal(fork[i]); signal(T); forever Problém obědvajících filozofů

Problém producenta a konzumenta  dva typy procesů:  producenti (producers)  konzumenti (consumers)  jeden nebo několik producentů produkuje data, která spotřebovává jeden nebo více konzumentů  např. programy produkují znaky, které pak jsou spotřebovány (vytištěny) tiskárnou  aby nevznikaly zbytečné čekací doby, je nutné zavést pro přechodné uskladnění produkovaných dat mezisklad - vyrovnávací paměť (buffer)  pro řízení lze použít dva semafory  jeden reprezentuje počet výrobků ve skladě  druhý signalizuje, zda lze vstoupit do skladu

Nekonečná vyrovnávací paměť b[2]b[3]b[4] outin b[1]b[5].. šedá oblast indikuje, která část bufferu je obsazena  vyrovnávací paměť (buffer) je pole, do kterého lze ukládat produkovaná data  paměť musí mít nezávislý přístup pro zápis a čtení (unbounded buffer)  in ukazuje na položku, do které se bude vkládat nový produkt  out ukazuje na položku, která bude konzumována

Funkce producenta producer: repeat produce item v; b[in] := v; in := in + 1 forever;

Funkce konzumenta consumer: repeat while in <= out do { nothing }; w := b[out]; out := out + 1; consume item w forever;

Kruhová vyrovnávací paměť out in b[1]b[5] šedá oblast indikuje, která část bufferu je obsazena  v praxi bývá velikost vyrovnávací paměti omezená  paměť je propojena do kruhu (kruhový buffer)  po n-té položce následuje opět první položka  při zaplnění bufferu musí producent čekat ! b[2] b[3] b[4] b[n] b[n-1] směr rotace

Producent s kruhovým bufferem producer: repeat produce item v; while ( (in + 1) mod n = out) do { nothing }; b[in] := v; in := (in + 1) mod n forever;

Konzument s kruhovým bufferem consumer repeat while in = out do { nothing }; w := b[out]; out := (out + 1) mod n; consume item w forever;

Potřebujete oholit?  u holiče jsou však jen 3 sedačky pro zákazníky a proto zde mohou obsluhovat pouze 3 holiči  na pohovce je místo k sezení jen pro 4 čekající zákazníky  ostatní zákazníci musí zůstat stát u dveří, dokud se neuvolní místo k sezení  do místnosti se vejde celkem nejvýše 20 zákazníků, ostatní musí čekat venku nebo odejít  pokladna pro placení je pouze jedna a inkasovat proto může pouze jeden holič

Barbershop Problem Vchod místo pro čekání ve stoje pohovka holící křesla Pokladna Východ

Barbershop Problem  když je holič volný, přesune se nejdéle čekající zákazník z pohovky na křeslo  nejdéle stojící zákazník pak usedne na pohovku  v daném okamžiku může platit jen jeden zákazník  holiči obsluhují zákazníky; pokud nečeká žádný zákazník, holiči spí

Co je nutné sledovat?  kapacitu krámu a pohovky  kapacitu holičů  umístění právě jednoho zákazníka do volného křesla  přítomnost zákazníka v křesle  placení zákazníka po opuštění křesla  přechod holiče na obsluhu pokladny

Barbershop Problem  /* program barbershop1 */  semaphore max_capacity = 20;  semaphore sofa = 4;  semaphore barber_chair = 3;  semaphore coord = 3;  semaphore cust_ready = 0, finished = 0, leave_b_chair = 0, payment= 0, receipt = 0;

Customer  void customer ()  {  wait(max_capacity);  enter_shop();  wait(sofa);  sit_on_sofa();  wait(barber_chair);  get_up_from_sofa();  signal(sofa);  sit_in_barber_chair;  signal(cust_ready);  wait(finished);  leave_barber_chair();  signal(leave_b_chair);  pay();  signal(payment);  wait(receipt);  exit_shop();  signal(max_capacity)  }

Barber  void barber()  {  while (true)  {  wait(cust_ready);  wait(coord);  cut_hair();  signal(coord);  signal(finished);  wait(leave_b_chair);  signal(barber_chair);  }

Cashier  void cashier()  {  while (true)  {  wait(payment);  wait(coord);  accept_pay();  signal(coord);  signal(receipt);  }

Monitory  konstrukce ve vyšším programovacím jazyce, poskytující stejné služby jako semafory, ale je snadněji ovladatelná  vyskytují se v řadě jazyků pro konkurenční programování (concurrent programming languages)  Concurrent Pascal, Modula-3, uC++, Java...  mohou být implementovány pomocí semaforů...

Monitor  je softwarový modul, obsahující:  jednu nebo více procedur  inicializační sekvenci  lokální datové proměnné  charakteristiky:  lokální proměnné jsou dostupné pouze prostřednictvím monitorových procedur  proces vstupuje do monitoru vyvoláním některé jeho procedury  v daném okamžiku může být v monitoru pouze jeden proces

Monitor  monitor zajišťuje vzájemné vylučování  program se tímto problémem nemusí zabývat  sdílená data jsou chráněna tím, že se nacházejí v monitoru  sdílená data jsou uzamčena v monitoru a procesy k nim mají přístup pouze prostřednictvím volání monitorových procedur  synchronizaci procesů zajišťuje programátor použitím podmínkových proměnných  reprezentují podmínky, které proces musí splnit před vstupem do monitoru

Podmínkové proměnné Condition variables  jsou lokálními proměnnými monitoru (dostupné pouze v monitoru)  lze k nim přistupovat a měnit je pouze následujícími 2 funkcemi:  cwait(a) blokuje provádění volajícího procesu podmínkou (proměnnou) a  proces může být znovu aktivován pouze když jiný proces provede csignal(a)  csignal(a) obnoví provádění některého procesu blokovaného podmínkou (proměnnou) a  pokud takových procesů existuje více, je vybrán jeden z nich  pokud žádný takový proces neexistuje, neprovede se nic

Monitor  čekající procesy jsou buď ve vstupní frontě nebo v podmínkové frontě  proces se umísťuje do podmínkové fronty c n sám provedením cwait (c n )  csignal (c n ) vpustí do monitoru jeden z procesů čekajících ve frontě c n  csignal (c n ) tedy blokuje volající proces a umísťuje ho do urgentní fronty (pokud ovšem csignal není poslední operaci monitorové procedury)

 řešíme problém producentů a konzumentů  pro synchronizaci použijeme monitor  append() a take() jsou procedury monitoru  jsou to jediné procedury, umožňující procesům přístup k vyrovnávací paměti  pokud jsou tyto procedury korektní, bude synchronizace korektní pro všechny zúčastněné producenty i konzumenty ProducerI: repeat produce v; Append(v); forever ConsumerI: repeat Take(v); consume v; forever Monitor a problém svázaných P/C

 Monitor potřebuje vyrovnávací paměť (sklad):  buffer: array[0..k-1] of items;  potřebuje dvě podmínkové proměnné:  notfull  csignal(notfull) indikuje že buffer není plný  notempty  csignal(notempty) indikuje, že buffer není prázdný  potřebuje ukazatele do bufferu a čítače:  nextin ukazuje na první volné místo pro přidávání  nextout ukazuje na aktuální položku k odebrání  count obsahuje počet položek v bufferu

Monitor boundedbuffer: buffer: array[0..k-1] of items; nextin:=0, nextout:=0, count:=0: integer; notfull, notempty: condition; Append(v): if (count=k) cwait(notfull); buffer[nextin]:= v; nextin:= nextin+1 mod k; count++; csignal(notempty); Take(v): if (count=0) cwait(notempty); v:= buffer[nextout]; nextout:= nextout+1 mod k; count--; csignal(notfull); Monitor a problém svázaných P/C

Předávání zpráv  je nutné vzájemné vylučování  dochází k výměně informací send (destination, message) receive (source, message)

 vysílač a/nebo přijímač může (ale nemusí) být blokován  neblokující send, neblokující receive  neblokující send, blokující receive  vysílač po odeslání zprávy pokračuje  aby mohl připravovat zprávy co nejrychleji  přijímač je blokován, dokud zpráva není doručena  aby mohl okamžitě reagovat na doručení zprávy  blokující send, blokující receive  na doručení zprávy čeká přijímač i vysílač (rendezvous) Synchronizace při předávání zpráv

Adresace  přímá adresace  funkce send zahrnuje specifický identifikátor cílového procesu  funkce receive může předem určit, od kterého procesu je zpráva očekávána  zprávy od jiných procesů mohou být ignorovány  speciální adresa (např. 0) specifikuje, že zpráva může přijít od kteréhokoliv procesu  funkce receive může při volání dostat parametrem hodnotu, kterou má předat, když byla zpráva přijata  to umožňuje při neblokujícím receive zjistit, že došla zpráva

Adresace  nepřímá adresace  zprávy se zasílají do sdílené datové struktury, skládající se z front  říkáme jim poštovní schránky (mailboxes)  jeden proces posílá zprávy do schránky, druhý si zprávy ze schránky vyzvedává

Mailboxy a porty  mailbox může být vlastněn jedním párem vysílač/přijímač  tentýž mailbox může být sdílen několika vysílači a přijímači  OS pak může dovolit rozlišení více typů zpráv  Port je mailbox svázaný s jedním přijímačem a více vysílači  používá se pro aplikace typu klient/server (server je přijímačem)

Vlastnictví portů a mailboxů  port je obvykle vlastněn přijímačem  port se ruší ukončením procesu přijímače  mailbox vytváří OS na žádost procesu, který se tak stává jeho vlastníkem  mailbox se ruší na žádost procesu- vlastníka nebo když je tento proces ukončen

Obecný formát zprávy Message Contents záhlaví zprávy tělo zprávy Message Type Destination ID Source ID Message Length Control Info.

Problém čtenářů a pisatelů  jakýkoliv počet čtenářů může souběžně číst obsah souboru  v daném čase může do souboru zapisovat pouze jeden pisatel  pokud pisatel zapisuje do souboru, nemůže jeho obsah číst žádný čtenář

Dosažení vzájemného vylučování přenosem zpráv  vytvoření mailboxu mutex sdíleného n procesy  send() is neblokující  receive() je blokující když je mailbox mutex prázdný  Inicializace: send(mutex, “go”);  První proces P i, který provede receive() může vstoupit do CS  ostatní procesy budou blokovány dokud P i neodešle zprávu Process Pi: var msg: message; repeat receive(mutex,msg); CS send(mutex,msg); RS forever

Problém svázaných P/C přenosem zpráv  producenti umisťují položky odesíláním zpráv do mailboxu mayconsume  mailbox mayconsume slouží jako buffer: konzument může konzumovat, jestliže je v mailboxu alespoň jedna zpráva  Na začátku je mailbox mayproduce naplněn k prázdnými zprávami (k= velikost bufferu)  počet položek v bufferu se zvětší každým příchodem zprávy a zmenší každým odebráním zprávy  může obsluhovat více producentů i více konzumentů

Producer: var pmsg: message; repeat receive(mayproduce, pmsg); pmsg:= produce(); send(mayconsume, pmsg); forever Consumer: var cmsg: message; repeat receive(mayconsume, cmsg); consume(cmsg); send(mayproduce, null); forever Problém svázaných P/C přenosem zpráv