Hans Boehm
Justin Gottschlich
Victor Luchangco
Jens Maurer
Paul McKenney
Maged Michael
Mark Moir
Torvald Riegel
Michael Scott
Tatiana Shpeisman
Michael Spear
Michael Wong
passed EWG, CWG, LWG review. LEWG did not need to review the PDTS comment N4410
Move to approve N4513 as the Transactional Memory TS working paper and direct the Convener to transmit N4514 for publication as the Transactional Memory TS. Approvde unaimously in Lenexa
N4513 is the latest TM TS Working Draft. It contains changes to the TM TS as directed by the committee at the Lenexa meeting based on the PDTS ballot comments.
N4514 is document N4513 reformatted as a PDTS ballot document.
N4515 is this document - TM TS Editor's report, post Lenexa.
N4396 is the PDTS 19841 NB comments
N4410 is SG5's responses to the PDTS comments in N4396>
N4301 is the latest TM TS Working Draft. It contains changes to the TM TS as directed by the committee at the Urbana meeting combining N4272 and N4265.
N4302 is document N4301 reformatted as a PDTS ballot document.
N4338 is this document - TM TS Editor's report, post Urbana.
Move to create a working paper for the Technical Specification on C++ Extensions for Transactional Memory with N4272, "Technical Specification on C++ Extensions for Transactional Memory, Working Draft Header" and N4265, "Transactional Memory Support for C++: Wording (revision 3)" as its initial content.
N4272 has the Working Draft front matter.
N4265 presents the wording proposal including changes from Urbana (both core and library) for integrating transactional memory support into C++. For motivation and introductory overview, see the predecessor paper N3999 "Standard Wording for Transactional Memory Support for C++".
The companion paper N4180 motivates and explains the additional features that have been integrated since the Rapperswil meeting. Those were approved by EWG in Urbana.
N4179 presents the pre-Urbana integrated TM wording for core and library.
N3999 presents a concise set of introduction, motivation, syntax, semantics and initial wording.
N4000 documents our effort to transactionalize a C++ Standard Template Library (STL) container to demonstrate the feasibility of the transactional language constructs.
transaction_safe
transaction_safe noinherit
for virtual
functions (non-viral)tx_exception
transaction_safe
on lambdas
transaction_safe noinherit
function overriding a transaction_safe
function is ill-formedmaybe transaction_safe
to transaction_safe noinherit
tx_exception
to trivially copyable
typesstd::exception
is the base of the exception
hierarchy. Should we declare its virtual what() function
transaction_safe
? [no; instead review definition of
derived classes such as length_error] This has serious ripple effects
to user code, in particular if that user code is totally unaware of
transactions. Telco 2014-08-11 and 2014-09-08: introduce "maybe
transaction_safe" for virtual functions, which is not viral, but
accepts undefined behavior.template<class T> class tx_exception : exception { ... };with a transaction-safe "what()" function and where "T" can be memcpy'd.