Transakční paměť

V oblasti počítačové vědy a inženýrství představuje transakční paměť způsob, jak zjednodušit paralelní programování tím, že instrukce load a store umožňuje provést atomicky (nedělitelně). To v současné výpočetní technice znamená, že mechanismus řídící souběžnost, je analogický k databázovým transakcím pro řízení přístupu ke sdílené paměti. Systém s implementovanou transakční pamětí poskytuje vysokou úroveň abstrakce, jako alternativu k systému s nízkoúrovňovou synchronizací vláken pomocí zámků. Tato abstrakce umožňuje koordinovat paralelní čtení a zápis sdílených dat v paralelních systémech.

Motivace

Atomicity mezi dvěma souběžnými transakcemi s konfliktem

V paralelním programování, pokud se paralelní vlákna pokouší o přístup ke sdílenému prostředku, je synchronizace nutná. Nízkoúrovňová synchronizace vláken, jako jsou zámky, je pesimistická a zakazuje vláknům, které jsou mimo kritickou sekci, jakékoliv změny. Navíc proces zamykání a uvolňování zámků často představuje další režii a vznik problému efekt hrdla lahve (anglicky bottleneck) mezi vlákny. Transakční paměť naopak poskytuje optimistické řízení paralelizmu tím, že vlákna probíhají souběžně s minimálním vzájemným rušením. Transakční paměť umožňuje transparentně podporovat úseky kódu, které jsou označeny jako transakční (vizte též databázová transakce) uplatněním atomicity, datové konzistence a izolace.

Transakce je soubor operací, které můžeme provést, a potvrdit s nimy související změny (COMMIT), dokud nenastane konflikt. Když je zjištěn konflikt, transakce se vrátí do svého původního stavu (ROLLBACK), a bude se opakovat, dokud všechny konflikty nebudou odstraněny. Před úspěšným dokončením transakce je výsledek jakékoliv operace v rámci transakce čistě spekulativní. V kontrastu k na zámku založené synchronizaci, kde aby se zabránilo poškození dat, jsou operace serializovány, transakce umožňují další paralelismus tak dlouho, dokud nedojde ke konfliktu, jako když se několik operací pokouší změnit sdílený prostředek. Protože programátor není zodpovědný za jednoznačně identifikující zámky nebo pořadí, ve kterém byly pořízeny, programy, které využívají transakční paměť nemohou způsobit konflikt vzniklý vzájemným čekáním, uváznutím (deadlock).

S těmito konstrukty v místě, transakční paměť poskytuje vysokou míru programové abstrakce tím, že umožňuje programátorům uzavřít jejich (sdílený) programový kód (ev. strojový kód) do transakčních bloků. Správná implementace zajišťuje, že data nemohou být sdílena mezi vlákny, aniž by byla zajištěna prostřednictvím transakce a tedy poskytují správný výsledek. Například, kód může být psán jako:

def převod_peněz(z_účtu, na_účet, množství):
    with transaction():
        z_účtu -= množství
        na_účet += množství

V tomto kódu je blok definován tím, že během "transakce" je zaručena atomicita, konzistence a izolace základní transakční paměti implementace a je transparentní pro programátora. Proměnné v rámci transakce jsou chráněny od vnějších konfliktů, ochraňují před vnějšími konflikty, zajišťují že buď bude částka převedena nebo nebude provedena vůbec žádná akce. Všimněte si, že chyby související se souběžností, jsou stále ještě možné v programech, které používají velké množství transakcí, a to zejména v softwarových implementacích, kdy knihovna poskytována jazykem není schopna prosadit správné používání. Chyby produkovány prostřednictvím transakcí může být často obtížné ladit, protože breakpointy nesmí být umístěny v rámci transakce.

Transakční paměť je omezena v tom, že vyžaduje sdílenou paměť. I když při použití transakční paměti nelze způsobit uváznutí (deadlock), programy stále mohou trpět livelockem nebo zdrojem hladovění. Například, delší transakce se může opakovaně vrátit (ROLLBACK) v reakci na více menších transakcí, což způsobuje plýtvání časem a energií.

Odkazy

Reference

V tomto článku byl použit překlad textu z článku Transactional memory na anglické Wikipedii.

Další čtení

• HARRIS, Tim; LARUS, James R.; RAJWAR, Ravi. Transactional Memory, 2nd edition. [s.l.]: Morgan & Claypool, December 2010. (Synthesis Lectures on Computer Architecture; sv. 5). S. 1–263. 
• MCKENNEY, Paul E.; MICHAEL, Maged M.; TRIPLETT, Josh; WALPOLE, Jonathan. Why the grass may not be greener on the other side: a comparison of locking vs. transactional memory. SIGOPS Oper. Syst. Rev.. New York, NY, USA: ACM, July 2010, s. 93–101. ISSN 0163-5980. 

• Dave Dice, Yossi Lev, Mark Moir, Dan Nussbaum, and Marek Olszewski. (2009) "Early experience with a commercial hardware transactional memory implementation." Sun Microsystems technical report (60 pp.) SMLI TR-2009-180. A short version appeared at ASPLOS’09. DOI: 10.1145/1508244.1508263
• Amy Wang, Matthew Gaudet, Peng Wu, José Nelson Amaral, Martin Ohmacht, Christopher Barton, Raul Silvera, and Maged Michael. "Evaluation of Blue Gene/Q hardware support for transactional memories". In Proceedings of the 21st international conference on Parallel architectures and compilation techniques, pp. 127–136. ACM, 2012.
• Jacobi, C., Slegel, T., & Greiner, D. (2012, December). "Transactional memory architecture and implementation for IBM System z". In Microarchitecture (MICRO), 2012 45th Annual IEEE/ACM International Symposium on (pp. 25–36). IEEE.
• Harold W. Cain, Maged M. Michael, Brad Frey, Cathy May, Derek Williams, and Hung Le. "Robust Architectural Support for Transactional Memory in the Power Architecture." In ISCA '13 Proceedings of the 40th Annual International Symposium on Computer Architecture, pp. 225–236, ACM, 2013. DOI: 10.1145/2485922.2485942

Související články

• Databázová transakce
  • START TRANSACTION
  • ROLLBACK
  • COMMIT
• Zámek
• Livelock
• Deadlock
• Kritická sekce
• Paměťová koherence
• Sdílená paměť

Externí odkazy

• Michael Neuling (IBM), "What's the deal with Hardware Transactional Memory!?!" introductory talk at linux.conf.au 2014
• Transactional Memory Online: Categorized bibliography about transactional memory