-
22
pages
-
English
-
Documents
Description
University of Karlsruhe (TH)Research University · founded 1825Technical Briefing Session „Multicore Software Engineering“ @ ICSE 2009Transactional Memory versus Locks - A Comparative Case StudyVictor PankratiusFaculty of Computer ScienceHead of Young Investigator Group www.ipd.uni-karlsruhe.de/~pankratius updated Sep 2, 2009Traditional Parallel Programming• Synchronize critical sections using locks• Explicit lock / unlock• Claimed to to be advantageous for performance• Problems• Very low-level• Error-prone• Burden on developersFaculty of Computer Science2Dr. Victor PankratiusTransactional Memory• Instead of explicit locks, use atomic transactionsatomic { /*critical section code*/ }• A run-time system allows threads to execute atomic blocks concurrently, while making it appear that only one thread at a time executes within an atomic block.• Intention: relieve developer from locking details, esp. in situations with many locks and complex locking protocols• A transaction is aborted and re-executed if it conflicts with another transaction (operations must be reversible)• Run-time system ensures atomicity, consistency, isolation• Sounds promising in theory, but…Faculty of Computer Science3Dr. Victor PankratiusPredjudices Against TM from the Literature• Transactional Memory is slow• only a research toy• Transactional Memory may not be applicable to more complex, non-numerical programs• Memory does not offer any real benefits for ...
-
Publié par
-
Langue
English