— Syllabus — Software Transactional Memory

“Transactional memory” means that, instead of using explicit locks to protect from data races (like the Java synchronized construct), a programmer could declare a block of code atomic and rely on the underlying software and hardware system to ensure that code within the block executes as if atomic. The transactional memory system might use any of several concurrency control protocols, with some combination of transaction logging and locking, but all such systems provide some means for a transaction (the code within the atomic section) to abort and retry when conflicts are detected. In this sense transaction support is at least somewhat optimistic or speculative, because transactions are allowed to begin execution without a priori guarantees that they will be able to finish. Speculative execution can take advantage of multicore and other parallel processors by providing a higher degree of concurrency, without requiring programmers to design delicate and error-prone fine-grain locking schemes. Transactional memory is a leading candidate to replace explicit locks and monitorstyle synchronization in future programming languages. It is currently a hot research topic in both hardware architecture and programming language design. At the very least we can expect some hardware support for transactions in the near future. Whether transactions as a programming construct is widely adopted in mainstream programming languages, and when, remains an open question. In this short course for Ph.D. students we will read and discuss several research papers on software transactional memory systems. The course will be accessible to students who have some familiarity with concurrency (multi-threading or parallel processing) but who are completely unfamiliar with transactional memory.