wiki.accu.org

User Tools

Site Tools

Trace:
2013:transactional_memory_for_c

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
2013:transactional_memory_for_c [2012/11/11 20:44] – jonjagger2013: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]]\\ 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\\ **Type**: Presentation\\
Line 13: Line 13:
 \\ \\
 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. \\ 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.\\ 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.\\ 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 20: 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.\\ 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\\
2013/transactional_memory_for_c.1352666655.txt.gz · Last modified: 2016/06/11 14:05 (external edit)