Řízení souběžnosti - Concurrency control

V informačních technologiích a informatice , zejména v oblastech počítačového programování , operačních systémů , více procesorů a databází , řízení souběžnosti zajišťuje, že jsou generovány správné výsledky pro souběžné operace a tyto výsledky jsou získány co nejrychleji.

Počítačové systémy, software i hardware , se skládají z modulů nebo komponent. Každá součást je navržena tak, aby fungovala správně, tj. Dodržovala určitá pravidla konzistence. Když komponenty, které pracují současně, zasílají zprávy nebo sdílejí přístupová data (v paměti nebo úložišti ), může být jiná součást narušena konzistence určité komponenty. Obecná oblast řízení souběžnosti poskytuje pravidla, metody, metodiky návrhu a teorie pro udržení konzistence komponent pracujících souběžně při interakci, a tedy konzistence a správnosti celého systému. Zavedení řízení souběžnosti do systému znamená použití provozních omezení, která obvykle vedou k určitému snížení výkonu. Konzistence a správnosti provozu by mělo být dosaženo s co nejlepší účinností, aniž by došlo ke snížení výkonu pod rozumnou úroveň. Řízení souběžnosti může vyžadovat významnou další složitost a režii v souběžném algoritmu ve srovnání s jednodušším sekvenčním algoritmem .

Například selhání v řízení souběžnosti může mít za následek poškození dat z roztržených operací čtení nebo zápisu .

Řízení souběžnosti v databázích

Komentáře:

  1. Tato část je použitelná pro všechny transakční systémy, tj. Pro všechny systémy, které používají databázové transakce ( atomové transakce ; např. Transakční objekty ve správě systémů a v sítích chytrých telefonů, které obvykle implementují soukromé specializované databázové systémy), nejen pro univerzální databázi systémy řízení (DBMS).
  2. DBMS se musí vypořádat také s problémy řízení souběžnosti, které nejsou typické jen pro transakce s databázemi, ale spíše pro operační systémy obecně. Tyto problémy (např. Viz Řízení souběžnosti v operačních systémech níže) jsou mimo rozsah této části.

Řízení souběžnosti v systémech pro správu databází (DBMS; např. Bernstein et al. 1987 , Weikum a Vossen 2001 ), dalších transakčních objektech a souvisejících distribuovaných aplikacích (např. Grid computing a Cloud computing ) zajišťuje souběžné provádění databázových transakcí bez porušení integrita dat příslušných databází . Řízení souběžnosti je tedy základním prvkem správnosti v každém systému, kde dvě nebo více databázových transakcí prováděných s časovým překrytím mohou přistupovat ke stejným datům, např. Prakticky v jakémkoli databázovém systému pro všeobecné účely. Od vzniku databázových systémů na začátku 70. let se proto nashromáždil obrovský soubor souvisejícího výzkumu. Dobře zavedená teorie řízení souběžnosti pro databázové systémy je uvedena ve výše zmíněných referencích: teorie serializovatelnosti , která umožňuje efektivně navrhovat a analyzovat metody a mechanismy řízení souběžnosti. Alternativní teorie pro řízení souběžnosti atomových transakcí nad abstraktními datovými typy je uvedena v ( Lynch et al. 1993 ) a níže se nepoužívá. Tato teorie je propracovanější, složitější a má širší rozsah a v literární databázi byla méně využívána než klasická teorie výše. Každá teorie má své klady a zápory, důraz a vhled . Do jisté míry se doplňují a jejich sloučení může být užitečné.

Aby byla zajištěna správnost, RDBMS obvykle zaručuje, že jen serializovatelné transakční plány jsou generovány, pokud sériovost je záměrně uvolnil ke zvýšení výkonu, ale pouze v případech, kdy se správnosti aplikace není poškozeni. Pro zachování správnosti v případech neúspěšných (přerušených) transakcí (k nimž může vždy dojít z mnoha důvodů) musí mít plány také vlastnost obnovitelnosti (z přerušení). DBMS také zaručuje, že žádný vliv potvrzených transakcí je ztracen, a žádný vliv přerušena ( vrácena zpět ) transakce zůstává v příslušném databázi. Celková charakterizace transakce je obvykle shrnuta níže uvedenými pravidly ACID . Jelikož se databáze začaly distribuovat nebo je potřeba spolupracovat v distribuovaných prostředích (např. Federované databáze na počátku roku 1990 a v současné době Cloud computing ), byla zvláštní pozornost věnována efektivní distribuci mechanismů řízení souběžnosti.

Transakce databáze a pravidla ACID

Hlavní články: Databázová transakce a KYSELINA

Koncept databázové transakce (nebo atomové transakce ) se vyvinul s cílem umožnit jak dobře pochopené chování databázového systému ve vadném prostředí, kde může dojít k selhání kdykoli, tak zotavení z havárie do dobře pochopeného stavu databáze. Transakce databáze je jednotka práce, obvykle zapouzdřující řadu operací nad databází (např. Čtení databázového objektu, zápis, získávání zámku atd.), Abstrakce podporovaná v databázi a také v jiných systémech. Každá transakce má dobře definované hranice, pokud jde o to, které exekuce programu / kódu jsou do této transakce zahrnuty (určeno programátorem transakce pomocí speciálních transakčních příkazů). Každá databázová transakce se řídí následujícími pravidly (podporou v databázovém systému, tj. Databázový systém je navržen tak, aby jim zaručil transakce, které provádí):

  • Atomicita - Podokončení transakce ( potvrzené nebo zrušené )buď zůstanou účinky všech nebo žádné z jejích operací (sémantika „vše nebo nic“). Jinými slovy, vůči vnějšímu světu se potvrzená transakce jeví jako nedělitelná (atomická) (její účinky na databázi) a zrušená transakce vůbec neovlivní databázi. Buď jsou provedeny všechny operace, nebo žádná.
  • Konzistence - Každá transakce musí opustit databázi v konzistentním (správném) stavu, tj. Udržovat předem stanovená pravidla integrity databáze (omezení na objekty databáze a mezi nimi). Transakce musí transformovat databázi z jednoho konzistentního stavu do jiného konzistentního stavu (je však odpovědností programátora transakce, aby se ujistil, že samotná transakce je správná, tj. Provádí správně to, co má v úmyslu provést (z hlediska aplikace zobrazení), zatímco předdefinovaná pravidla integrity jsou vynucována systémem DBMS). Jelikož databázi lze normálně změnit pouze transakcemi, jsou všechny stavy databáze konzistentní.
  • Izolace - Transakce se nemohou navzájem ovlivňovat (jako konečný výsledek jejich provádění). Navíc obvykle (v závislosti na metodě řízení souběžnosti) účinky neúplné transakce nejsou viditelné ani pro jinou transakci. Poskytování izolace je hlavním cílem řízení souběžnosti.
  • Trvanlivost - Účinky úspěšných (potvrzených) transakcí musí přetrvávat při selhání (obvykle zaznamenáním účinků transakce a její události potvrzení do energeticky nezávislé paměti ).

Koncept atomových transakcí byl v průběhu let rozšířen na to, co se stalo obchodními transakcemi, které ve skutečnosti implementují typy Workflow a nejsou atomové. Také takové vylepšené transakce však obvykle využívají atomové transakce jako komponenty.

Proč je potřeba řízení souběžnosti?

Pokud jsou transakce prováděny sériově , tj. Postupně bez překrývání v čase, neexistuje žádná souběžnost transakcí. Pokud jsou však souběžné transakce s operacemi prokládání povoleny nekontrolovaným způsobem, mohou nastat některé neočekávané a nežádoucí výsledky, například:

  1. Ztracený problém s aktualizací: Druhá transakce zapíše druhou hodnotu datové položky (datum) nad první hodnotu zapsanou první souběžnou transakcí a první hodnota se ztratí u ostatních transakcí, které běží souběžně a které potřebují, podle jejich priority , pro načtení první hodnoty. Transakce, které přečetly nesprávnou hodnotu, končí nesprávnými výsledky.
  2. Problém špinavého čtení: Transakce načtou hodnotu zapsanou transakcí, která byla později zrušena. Tato hodnota zmizí z databáze při přerušení a neměla být přečtena žádnou transakcí („špinavé čtení“). Čtení transakcí končí nesprávnými výsledky.
  3. Problém s nesprávným souhrnem: Zatímco jedna transakce přebírá souhrn nad hodnotami všech instancí opakované datové položky, druhá transakce aktualizuje některé instance této datové položky. Výsledné shrnutí neodráží správný výsledek pro žádné (obvykle nutné pro správnost) pořadí priorit mezi těmito dvěma transakcemi (pokud je jedna provedena před druhou), ale spíše nějaký náhodný výsledek, v závislosti na načasování aktualizací a zda určité výsledky aktualizace byly zahrnuty do souhrnu nebo ne.

Většina vysoce výkonných transakčních systémů potřebuje ke splnění svých požadavků na výkon souběžné provádění transakcí. Bez kontroly souběžnosti tedy takové systémy nemohou poskytovat správné výsledky ani důsledně udržovat své databáze.

Mechanismy řízení souběžnosti

Kategorie

Hlavní kategorie mechanismů řízení souběžnosti jsou:

  • Optimistické - Zpoždění kontroly, zda transakce splňuje izolační a jiná pravidla integrity (např. Serializovatelnost a obnovitelnost ), až do konce, aniž byste blokovali jakoukoli z jejích operací (čtení, zápis) („... a buďte optimističtí ohledně pravidel met ... “), a poté přeruší transakci, aby zabránila porušení, pokud mají být při jejím spáchání porušena požadovaná pravidla. Přerušená transakce je okamžitě restartována a znovu provedena, což má za následek zjevnou režii (oproti jejímu provedení pouze jednou). Pokud není zrušeno příliš mnoho transakcí, pak je optimismus obvykle dobrá strategie.
  • Pesimistické - zablokuje operaci transakce, pokud může způsobit porušení pravidel, dokud nezmizí možnost porušení. Blokování operací je obvykle spojeno se snížením výkonu.
  • Polooptimistické - zablokování operací v některých situacích, pokud mohou způsobit porušení některých pravidel, a neblokování v jiných situacích při zpoždění kontroly pravidel (je-li to nutné) do konce transakce, jak je tomu u optimismu.

Různé kategorie poskytují odlišný výkon, tj. Různé průměrné míry dokončení transakce ( propustnost ), v závislosti na mixu typů transakcí, výpočetní úrovni paralelismu a dalších faktorech. Pokud je k dispozici výběr a znalosti o kompromisech, měla by být vybrána kategorie a metoda, která zajistí nejvyšší výkon.

Vzájemné blokování mezi dvěma transakcemi (kde každá blokuje druhou) nebo více má za následek zablokování , kdy jsou příslušné transakce pozastaveny a nemohou být dokončeny. Většina neoptimistických mechanismů (s blokováním) je náchylná k zablokování, které se vyřeší úmyslným přerušením zablokované transakce (která uvolní další transakce v tomto zablokování) a jeho okamžitým restartem a opětovným provedením. Pravděpodobnost zablokování je obvykle nízká.

Blokování, zablokování a přerušení mají za následek snížení výkonu, a tedy kompromisy mezi kategoriemi.

Metody

Existuje mnoho metod pro řízení souběžnosti. Většinu z nich lze implementovat v kterékoli z výše uvedených hlavních kategorií. Mezi hlavní metody, které mají každou z mnoha variant, a v některých případech se mohou překrývat nebo je lze kombinovat, patří:

  1. Zamykání (např. Dvoufázové zamykání - 2PL) - Řízení přístupu k datům pomocí zámků přiřazených k datům. Přístup transakce k datové položce (databázovému objektu) uzamčené jinou transakcí může být blokován (v závislosti na typu zámku a typu operace přístupu) až do uvolnění zámku.
  2. Kontrola grafu serializace (nazývaná také Serializovatelnost nebo Konflikt nebo Kontrola grafu priority) - Kontrola cyklů v grafu plánu a jejich rozbití přerušením.
  3. Časové razítko uspořádání (TO) - Přiřazení časových razítek na transakce a řízení nebo kontrolu přístupu k datům pomocí časového razítka pořadí.
  4. Objednávka závazku (nebo Objednávka závazku ; CO) - Řízení nebo kontrola chronologického pořadí transakcí událostí potvrzení, aby byla kompatibilní s jejich příslušným pořadím priorit .

Mezi další hlavní typy řízení souběžnosti, které se používají ve spojení s výše uvedenými metodami, patří:

  • Multiversion concurrency control (MVCC) - Zvýšení souběžnosti a výkonu generováním nové verze databázového objektu pokaždé, když je objekt zapsán, a povolením operací čtení transakcí několika posledních relevantních verzí (každého objektu) v závislosti na metodě plánování.
  • Řízení souběžnosti indexu - synchronizace operací přístupu k indexům , nikoli k uživatelským datům. Specializované metody poskytují podstatné zvýšení výkonu.
  • Model soukromého pracovního prostoru ( odložená aktualizace ) - Každá transakce udržuje soukromý pracovní prostor pro svá přístupová data a její změněná data se stanou viditelnými mimo transakci pouze při jejím potvrzení (např. Weikum a Vossen 2001 ). Tento model poskytuje různé chování řízení souběžnosti s výhodami v mnoha případech.

Nejběžnějším typem mechanismu v databázových systémech od jejich počátků v 70. letech byl Silný přísný dvoufázový zámek (SS2PL; nazývaný také Rigorózní plánování nebo Rigorózní 2PL ), což je speciální případ (varianta) obou Dvoufázového blokování (2PL ) a objednávání závazků (CO). Je to pesimistické. Navzdory svému dlouhému názvu (z historických důvodů) je myšlenka mechanismu SS2PL jednoduchá: „Uvolněte všechny zámky použité transakcí až po ukončení transakce.“ SS2PL (nebo Rigorousness) je také název sady všech plánů, které lze generovat tímto mechanismem, tj. Jsou to plány SS2PL (nebo Rigorousness), mají vlastnost SS2PL (nebo Rigorousness).

Hlavní cíle mechanismů řízení souběžnosti

Mechanismy řízení souběžnosti musí nejprve fungovat správně, tj. Udržovat pravidla integrity každé transakce (související s souběžností; pravidlo integrity specifické pro aplikaci je zde mimo rozsah), zatímco transakce probíhají souběžně, a tedy integrita celého transakčního systému . Správnosti je třeba dosáhnout s co nejlepším výkonem. Kromě toho stále více existuje potřeba efektivně fungovat, zatímco transakce jsou distribuovány přes procesy , počítače a počítačové sítě . Další předměty, které mohou ovlivnit řízení souběžnosti, jsou zotavení a replikace .

Správnost

Serializovatelnost
Hlavní článek: Serializovatelnost

Pro správnost je běžným hlavním cílem většiny mechanismů řízení souběžnosti generování plánů s vlastností Serializability . Bez serializovatelnosti mohou nastat nežádoucí jevy, např. Peníze mohou zmizet z účtů nebo být generovány odnikud. Serializovatelnost plánu znamená ekvivalenci (ve výsledných hodnotách databáze) k nějakému sériovému plánu se stejnými transakcemi (tj. U nichž jsou transakce sekvenční bez časového překrývání, a tedy od sebe zcela izolované: Žádný souběžný přístup jakýmikoli dvěma transakcemi stejná data možná). Serializovatelnost je považována za nejvyšší úroveň izolace mezi databázovými transakcemi a za hlavní kritérium správnosti pro souběžné transakce. V některých případech jsou ohroženy uvolněné formy serializovatelnosti pro lepší výkon (např. Populární izolační mechanismus Snapshot ) nebo pro splnění požadavků na dostupnost ve vysoce distribuovaných systémech (viz Eventuální konzistence ), ale pouze v případě, že relaxace neporuší správnost aplikace ( např. u peněžních transakcí není povoleno uvolnění , protože uvolněním mohou peníze zmizet nebo se objevit odnikud).

Téměř všechny implementované mechanismy řízení souběžnosti dosahují serializovatelnosti poskytnutím Serializovatelnosti konfliktů , což je široký speciální případ serializovatelnosti (tj. Pokrývá, umožňuje většinu serializovatelných plánů a neukládá významná další omezení způsobující zpoždění), které lze efektivně implementovat.

Vymahatelnost
Viz Obnovitelnost v Serializovatelnosti

Komentář: Zatímco v obecné oblasti systémů může pojem „obnovitelnost“ označovat schopnost systému zotavit se po selhání nebo z nesprávného / zakázaného stavu, v řízení souběžnosti databázových systémů získal tento pojem specifický význam.

Řízení souběžnosti obvykle také zajišťuje Recoverability vlastnost plánů pro udržení správnosti v případech přerušených transakcí (což se může vždy stát z mnoha důvodů). Obnovitelnost (z přerušení) znamená, že žádná potvrzená transakce v plánu nenačetla data zapsaná přerušenou transakcí. Taková data zmizí z databáze (při přerušení) a jsou součástí nesprávného stavu databáze. Čtení takových dat porušuje pravidlo konzistence ACID. Na rozdíl od Serializability nelze Obnovitelnost v žádném případě ohrozit, uvolnit, protože jakékoli uvolnění má za následek rychlé narušení integrity databáze při přerušení. Hlavní metody uvedené výše poskytují mechanismy serializace. Žádný z nich ve své obecné podobě automaticky neposkytuje obnovitelnost a pro podporu obnovitelnosti jsou zapotřebí zvláštní úvahy a vylepšení mechanismů. Běžně využívaným zvláštním případem obnovitelnosti je Strictness , který umožňuje efektivní obnovení databáze po selhání (ale vylučuje optimistické implementace; např. Strict CO (SCO) nemůže mít optimistickou implementaci, ale má semioptimistické ).

Komentář: Všimněte si, že vlastnost Obnovitelnost je nutná, i když nedojde k selhání databáze a není nutné zotavení databáze po selhání. Je spíše nutné správně automaticky zpracovat přerušení transakcí, které nemusí souviset se selháním databáze a obnovou z ní.

Rozdělení

S rychlým technologickým vývojem výpočetní techniky se rozdíl mezi místními a distribuovanými výpočty v sítích nebo sběrnicích s nízkou latencí stírá. Poměrně efektivní využití místních technik v takových distribuovaných prostředích je tedy běžné, např. V počítačových klastrech a vícejádrových procesorech . Místní techniky však mají svá omezení a k škálování používají více procesů (nebo vláken) podporovaných více procesory (nebo více jádry). To často přeměňuje transakce na distribuované, pokud samy potřebují překlenout více procesů. V těchto případech se většina technik řízení lokální souběžnosti nemění správně.

Distribuovaná serializace a objednávání závazků
Viz Distribuovaná serializovatelnost v Serializovatelnosti
Hlavní článek: Globální serializovatelnost
Hlavní článek: Objednávka závazků

Jakmile se databázové systémy začaly distribuovat nebo začaly spolupracovat v distribuovaných prostředích (např. Federované databáze na počátku 90. let a dnes Grid computing , Cloud computing a sítě se smartphony ), došlo k distribuci některých transakcí. A distribuované transakce znamená, že transakce se klene nad procesy , a může být rozdělen do počítače a zeměpisných lokalit. To generuje potřebu efektivních mechanismů řízení distribuované souběžnosti . Dosažení vlastnosti Serializability harmonogramu distribuovaného systému (viz Distribuovaná serializovatelnost a Globální serializovatelnost ( Modular serializability )) skutečně představuje speciální výzvy, které většina běžných mechanismů serializovatelnosti, původně navržených pro místní provoz, obvykle nesplňují. Je to zejména kvůli potřebě nákladné distribuce informací o řízení souběžnosti uprostřed komunikace a latence počítače . Jedinou známou obecně účinnou technikou distribuce je Commitment ordering, která byla zveřejněna v roce 1991 (poté, co byla patentována ). Objednávání závazků (Commit ordering, CO; Raz 1992 ) znamená, že chronologické pořadí transakčních událostí transakcí je udržováno kompatibilní s jejich příslušným pořadím priorit . CO nevyžaduje distribuci informací o řízení souběžnosti a poskytuje obecné efektivní řešení ( spolehlivé , vysoce výkonné a škálovatelné ) pro distribuovanou i globální serializovatelnost, také v heterogenním prostředí s databázovými systémy (nebo jinými transakčními objekty) s různými ( jakýkoli) mechanismy řízení souběžnosti. CO je lhostejné ke kterému mechanismu se používá, protože nezasahuje do jakéhokoli plánování transakčních operací (které většina mechanismů řídí) a určuje pouze pořadí událostí potvrzení. CO tedy umožňuje efektivní distribuci všech ostatních mechanismů a také distribuci kombinace různých (jakýchkoli) místních mechanismů pro dosažení distribuované a globální serializovatelnosti. Existence takového řešení byla až do roku 1991 považována za „nepravděpodobnou“ a mnoho odborníků i později, kvůli nepochopení řešení CO (viz Quotations in Global serializability ). Důležitou vedlejší výhodou CO je automatické rozlišení distribuovaného zablokování . Na rozdíl od CO jsou prakticky všechny ostatní techniky (pokud nejsou kombinovány s CO) náchylné k distribuovaným zablokováním (nazývaným také globální zablokování), která vyžadují speciální zacházení. CO je také název výsledné vlastnosti plánu: Plán má vlastnost CO, pokud je chronologické pořadí událostí potvrzení transakcí kompatibilní s prioritním (částečným) pořadím příslušných transakcí .

SS2PL zmíněný výše je variantou (zvláštním případem) CO, a tedy také efektivní pro dosažení distribuované a globální serializovatelnosti. Poskytuje také automatické rozlišení distribuovaného zablokování (což je ve výzkumné literatuře přehlíženo i po publikaci CO), stejně jako přísnost a tedy obnovitelnost. Vlastnit tyto požadované vlastnosti společně se známými efektivními implementacemi založenými na zamykání vysvětluje popularitu SS2PL. SS2PL se používá k efektivnímu dosažení distribuované a globální serializovatelnosti od roku 1980 a stal se pro něj de facto standardem . SS2PL však blokuje a omezuje (pesimisticky), a vzhledem k šíření distribuce a využití systémů odlišných od tradičních databázových systémů (např. Jako v cloudových výpočtech ) mohou být pro uživatele zapotřebí méně omezující typy CO (např. Optimistic CO ). lepší výkon.

Komentáře:

  1. Vlastnost Distribuovaný konflikt serializovatelnosti ve své obecné podobě je obtížné dosáhnout efektivně, ale je to efektivně dosaženo prostřednictvím jejího zvláštního případu Distribuovaný CO : Každá místní komponenta (např. Místní DBMS) potřebuje jak poskytnout určitou formu CO, tak vynutit speciální strategie objednávání hlasů pro dvoufázový protokol potvrzení (2PC: používá se k potvrzení distribuovaných transakcí ). Na rozdíl od obecného Distribuovaného CO Distribuovaný SS2PL existuje automaticky, když jsou všechny místní komponenty založeny na SS2PL (v každé komponentě CO existuje, implicitně a strategie objednávání hlasů je nyní splněna automaticky). Tato skutečnost je známá a využívána od 80. let (tj. Že SS2PL existuje globálně, aniž by věděl o CO) pro efektivní Distributed SS2PL, což implikuje Distribuovanou serializovatelnost a přísnost (např. Viz Raz 1992 , strana 293; implikuje se také v Bernstein et al., 1987 , strana 78). Méně omezené Distribuované serializace a přísnosti lze efektivně dosáhnout pomocí Distributed Strict CO (SCO) nebo kombinací lokálních komponent založených na SS2PL a SCO.
  2. O referencích a objednávání závazků: ​​( Bernstein et al. 1987 ) byl publikován před objevením CO v roce 1990. Vlastnost harmonogramu CO se nazývá Dynamic atomicity in ( Lynch et al. 1993 , strana 201). CO je popsáno v ( Weikum a Vossen 2001 , strany 102, 700), ale popis je částečný a postrádá podstatu CO . ( Raz 1992 ) byl prvním recenzovaným a přijatým pro publikační článek o algoritmech CO (publikace o ekvivalentní vlastnosti Dynamic atomicity lze vysledovat až do roku 1988). Následovaly další články o CO . (Bernstein a Newcomer 2009) poznamenávají CO jako jednu ze čtyř hlavních metod řízení souběžnosti a schopnost CO poskytovat interoperabilitu mezi jinými metodami.
Distribuovaná obnovitelnost

Na rozdíl od Serializability lze Distribuovanou obnovitelnost a Distribuovanou přísnost efektivně dosáhnout přímým způsobem, podobně jako je dosaženo Distribuovaného CO: V každém databázovém systému je třeba je aplikovat lokálně a použít strategii objednávání hlasů pro dvoufázový protokol potvrzení (2PC; Raz 1992 , strana 307).

Jak již bylo zmíněno výše, Distributed SS2PL , včetně Distribuované přísnosti (obnovitelnosti) a Distribuovaného objednávání závazků (serializovatelnosti), automaticky využívá potřebnou strategii objednávání hlasů a je dosaženo (globálně) při místním použití v každém (lokálním) databázovém systému (jako má byla známá a využívána po mnoho let; ve skutečnosti je lokalita definována hranicí účastníka 2PC ( Raz 1992 )).

Další hlavní předměty pozornosti

Návrh mechanismů řízení souběžnosti je často ovlivněn následujícími předměty:

Zotavení
Hlavní článek: Obnova dat

Všechny systémy jsou náchylné k poruchám a zpracování zotavení po selhání je nutností. Vlastnosti generovaných plánů, které jsou diktovány mechanismem řízení souběžnosti, mohou ovlivnit účinnost a efektivitu obnovy. Například vlastnost Strictness (uvedená v části Obnovitelnost výše) je často žádoucí pro efektivní obnovení.

Replikace
Hlavní článek: Replikace (informatika)

Pro vysokou dostupnost jsou databázové objekty často replikovány . Aktualizace replik stejného databázového objektu je třeba udržovat synchronizované. To může ovlivnit způsob řízení souběžnosti (např. Gray et al. 1996).

Viz také

Reference

  • Philip A. Bernstein , Vassos Hadzilacos, Nathan Goodman (1987): Concurrency Control and Recovery in Database Systems (free PDF download), Addison Wesley Publishing Company, 1987, ISBN  0-201-10715-5
  • Gerhard Weikum , Gottfried Vossen (2001): Transactional Information Systems , Elsevier, ISBN  1-55860-508-8
  • Nancy Lynch , Michael Merritt, William Weihl, Alan Fekete (1993): Atomic Transactions in Concurrent and Distributed Systems , Morgan Kaufmann (Elsevier), srpen 1993, ISBN  978-1-55860-104-8 , ISBN  1-55860-104- X
  • Yoav Raz (1992): „Princip objednávání závazků nebo zaručení serializovatelnosti v heterogenním prostředí více autonomních správců zdrojů využívajících atomový závazek.“ ( PDF ), Proceedings of the Eighteenth International Conference on Very Large Data Bases (VLDB), pp. 292-312, Vancouver, Canada, August 1992. (také DEC-TR 841, Digital Equipment Corporation , listopad 1990)

Citace

Řízení souběžnosti v operačních systémech

Multitaskingové operační systémy, zejména operační systémy v reálném čase , musí udržovat iluzi, že všechny úkoly běžící nad nimi běží všechny současně, přestože v daném okamžiku skutečně běží pouze jedna nebo několik úloh z důvodu omezení hardwaru, na kterém běží operační systém. Takový multitasking je poměrně jednoduchý, když jsou všechny úkoly na sobě nezávislé. Když se však několik úkolů pokusí použít stejný prostředek nebo když se úkoly pokusí sdílet informace, může to vést ke zmatku a nekonzistenci. Úkolem souběžného výpočtu je tento problém vyřešit. Některá řešení zahrnují „zámky“ podobné zámkům používaným v databázích, ale riskují, že způsobí jejich vlastní problémy, například zablokování . Další řešení jsou neblokující algoritmy a aktualizace Read-copy-update .

Viz také

Reference