Transactional Memory in Today's C++

A tech talk at Rackspace Atlanta.

Transcript

1. Transactional Memory in Today's C++ Zhihao Yuan <zhihao.yuan@rackspace.com>
2. I have a dream atomic { ++x; ++y; }
3. Yesterday's solution { std::lock_guard<std::mutex> _(mu); ++x; ++y; }
4. A (mutual exclusive) lock is • a shared resource • waited by multiple threads • to enter a critical section.
5. A critical section is • a resource uniquely owned • across multiple threads.
6. Lock as a shared resource is the root of all the contention.[1] • Fine-grained lock • Contention vs. overhead
7. Critical section as a unique resource kills concurrency. • Slowest worker[2] • Lock convoy
8. One more thing...
9. That example blocks forever Because... X& operator++() { std::lock_guard<std::mutex> _(mu); // LOL }
10. Locking as a runtime mechanism is an enemy to generic programming. • synchronized block in Java™ • Lock hierarchy
11. I just want an atomic code block • No sharing • No waiting • Works with GP
12. There you have it __transaction_atomic { ++x; ++y; }
13. A __transaction_atomic block is • Isolated • Wait-free • Composable
14. Available in GCC >= 4.7 • -fgnu-tm • libitm (Intel TM ABI[3]) • Implemented C++ TM Draft 1.1[4] • "If you observe performance that is lower than expected, you should not assume that transactional memory is inherently slow; instead, please just file a bug. "
15. How it works? __transaction_atomic { // journal ++x; ++y; } // commit if validation passed // retry if failed
16. How it works? __transaction_atomic { // journal ++x; ++y; } // commit if validation passed // retry if failed
17. Retry?! __transaction_atomic { ++x; std::cout << x << std::endl; }
18. Short answer They are unsafe to retry. • I/O • Sleep • etc.
19. Ways to forbid • GCC partially knows • Code vs. Library Possible annotation approaches • [[transaction_safe]], [[transaction_unsafe]] • txunsafe, like noexcept
20. Long answer __transaction_atomic is atomic, thus, the grouped operations are one operation without externally visible intermediate states. • Debugging: Schrödinger's cat • Local jumps are not allowed • Exception of integral type is allowed
21. Interact with exceptions Draft 1.1 • noexcept • __transaction_cancel Wording V1 (not implemented yet) • [[noexcept]] • [[cancel_on_escape]] • [[commit_on_escape]]
22. If an intermediate state is observable then the transaction is not isolated.
23. A __transaction_relaxed block is • Isolated (globally indeterminately sequenced) • Wait-free (no longer retry) • Composable (with both atomic and relaxed transactions) Conceptually, a global lock.
24. Uses of __transaction_relaxed • Printf debugging :) ◦ Replacing __transaction_atomic with __transaction_relaxed does not change the behavior of a program. • Wrap a __transaction_atomic block to cancel an irrevocable operation
25. Take a breath...
26. Hardware TM on x86-64 • Intel Haswell architecture • Ship date: June the 1st week • XBEGIN, XEND, XABORT instructions • Fallback code path support
27. So... 2005, first x86-64 dual core CPU; 2010, first dual core cellphone; 2013, first x86-64 CPU with HTM. Wait until your cell phone gets HTM?
28. Questions?
29. Links 1. Herb Sutter, "Sharing Is the Root of All Contention" http://www.drdobbs. com/architecture-and-design/sharing-is-the-root-of-all- contention/214100002 2. Richard T. Saunders, "Thread-safe and Thread-neutral Bags" http: //cppnow.org/files/2013/04/saunders_paper_cppnow2013.pdf 3. "Intel® Transactional Memory Compiler and Runtime Application Binary Interface", v1.1 http://gcc.gnu.org/wiki/TransactionalMemory? action=AttachFile&do=get&target=Intel-TM-ABI-1_1_20060506.pdf 4. "Draft Specification of Transactional Language Constructs for C++", v1. 1 https://sites.google.com/site/tmforcplusplus/C%2B% 2BTransactionalConstructs-1.1.pdf