Differences

This shows you the differences between two versions of the page.

--- 2013:transactional_memory_for_c [2012/10/29 07:49] – created jonjagger
+++ 2013:transactional_memory_for_c [2016/06/11 14:05] (current) – external edit 127.0.0.1
@@ Line 2: / Line 2: @@
 Back to [[conference:committee:proposals-2013]]\\
 \\
-**Title**: Transactional Memory for C Plus Plus\\
+**Title**: Transactional Memory for C++\\
-**Proposer**: [[2013:Michael Wong]]\\
+**Proposer**: [[2013:michael_wong]]\\
 **Type**: Presentation\\
 **Duration**: 90 minutes\\
@@ Line 9: / Line 9: @@
 https://sites.google.com/site/tmforcplusplus/
 This proposal supports 2 types of transactions:\\
-\\
+  * an isolated transaction that isolates from non-transactional code (as well as other transactions) through some kind of safety annotations
-an isolated transaction that isolates from non-transactional code (as well as other transactions) through some kind of safety annotations\\
+  * an ordinary transaction that allows communication with non-transactional code (but is isolated from other transactions)
-\\an ordinary transaction that allows communication with non-transactional code (but is isolated from other transactions)\\
 \\
 We further show different techniques for supporting various levels of safety annotation, from fully static compiled time checking to some levels of dynamic checking to ease the burden for programmers. \\
-It is the intention of the group to bring forward a fully worded proposal for Brisol 2013 as a Technical Specification.
+It is the intention of the group to bring forward a fully worded proposal for Bristol 2013 as a Technical Specification.
 Now some of you have wondered if it is too early for TM. Let me say that HW is coming, with Intel's recent Haswell announcement, and IBM's BG/Q, and previously Sun's Rock. SW TM support has been here for quite some time with Intel's STM support of the 1.0 Draft, and most recently GCC C++ 4.7's nearly full support of Draft 1.1.\\
 And if you think it is still too early, let me say that one of Hans Boehm's discovery was that locks are impractical for generic programming, because ordering of locks is generally not visible until instantiation. With the introduction of locking (and atomics) in C++11, this now becomes a difficult problem to avoid. Transactional memory is one way to solve the problem. It also helps for fine-grained locking on irregular data structures, and read-mostly structures.\\
@@ Line 21: / Line 20: @@
 TM is coming in many different forms (HW, SW, hybrid systems, lock elision), and for C++ to remain in a good place with the many other languages that already support TM, this is the right time to be prepared with a sound proposal.\\
 \\
+Roger: Yes - he's one of the experts\\