C++事务型内存技术规范:第1章(英文)
来源:互联网 发布:打码识别软件 编辑:程序博客网 时间:2024/05/04 03:31
1 General
[intro]
Language: English. Chinese edition is here.
1.1 Scope
[general.scope]
- 1 This Technical Specification describes extensions to the C++ Programming Language (1.3) that enable the specification of Transactional Memory. These extensions include new syntactic forms and modifications to existing language and library.
- 2 The International Standard, ISO/IEC 14882, provides important context and specification for this Technical Specification. This document is written as a set of changes against that specification. Instructions to modify or add paragraphs are written as explicit instructions. Modifications made directly to existing text from the International Standard use green to represent added text and
strikethroughto represent deleted text. - 3 This Technical Specification is non-normative. Some of the functionality described by this Technical Specification may be considered for standardization in a future version of C++, but it is not currently part of any C++ standard. Some of the functionality in this Technical Specification may never be standardized, and other functionality may be standardized in a substantially changed form.
- 4 The goal of this Technical Specification is to build widespread existing practice for Transactional Memory. It gives advice on extensions to those vendors who wish to provide them.
1.2 Acknowledgements
[general.ack]
- 1 This work is the result of collaboration of researchers in industry and academia, including the Transactional Memory Specification Drafting Group and the follow-on WG21 study group SG5. We wish to thank people who made valuable contributions within and outside these groups, including Hans Boehm, Justin Gottschlich, Victor Luchangco, Jens Maurer, Paul McKenney, Maged Michael, Mark Moir, Torvald Riegel, Michael Scott, Tatiana Shpeisman, Michael Spear, Michael Wong, and many others not named here who contributed to the discussion.
1.3 Normative references
[general.references]
- 1 The following referenced document is indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
- — ISO/IEC 14882:2014, Programming Languages - C++
- 2 ISO/IEC 14882:2014 is hereinafter called the C++ Standard. Beginning with section 1.10 below, all clause and section numbers, titles, and symbolic references in [brackets] refer to the corresponding elements of the C++ Standard. Sections 1.1 through 1.5 of this Technical Specification are introductory material and are unrelated to the similarly-numbered sections of the C++ Standard.
1.4 Implementation compliance
[intro.compliance]
- 1 Conformance requirements for this specification are the same as those defined in section 1.4 [intro.compliance] of the C++ Standard.
[ Note: Conformance is defined in terms of the behavior of programs. — end note ]
1.5 Feature testing
[intro.features]
- 1 An implementation that provides support for this Technical Specification shall define the feature test macro in Table 1.
- Table 1 – Feature Test Macro
1.10 Multi-threaded executions and data races
[intro.multithread]
- 1 Add a paragraph 9 to section 1.10 [intro.multithread] after paragraph 8:
- The start and the end of each synchronized block or atomic block is a full-expression (1.9 [intro.execution]). A synchronized block (6.9 [stmt.sync]) or atomic block (6.10 [stmt.tx]) that is not dynamically nested within another synchronized block or atomic block is called an outer block. [ Note: Due to syntactic constraints, blocks cannot overlap unless one is nested within the other. ] There is a global total order of execution for all outer blocks. If, in that total order, T1 is ordered before T2,
- — no evaluation in T2 happens before any evaluation in T1 and
- — if T1 and T2 perform conflicting expression evaluations, then the end of T1 synchronizes with the start of T2.
- The start and the end of each synchronized block or atomic block is a full-expression (1.9 [intro.execution]). A synchronized block (6.9 [stmt.sync]) or atomic block (6.10 [stmt.tx]) that is not dynamically nested within another synchronized block or atomic block is called an outer block. [ Note: Due to syntactic constraints, blocks cannot overlap unless one is nested within the other. ] There is a global total order of execution for all outer blocks. If, in that total order, T1 is ordered before T2,
- 2 Change in 1.10 [intro.multithread] paragraph 10:
- Synchronized and atomic blocks as well as certain
Certainlibrary calls synchronize with other synchronized blocks, atomic blocks, and library calls performed by another thread.
- Synchronized and atomic blocks as well as certain
- 3 Change in 1.10 [intro.multithread] paragraph 21:
- The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior. [ Note: It can be shown that programs that correctly use mutexes, synchronized and atomic blocks, and
memory_order_seq_cst
operations to prevent all data races and use no other synchronization operations behave as if the operations executed by their constituent threads were simply interleaved, with each value computation of an object being taken from the last side effect on that object in that interleaving. This is normally referred to as “sequential consistency”. However, this applies only to data-race-free programs, and data-race-free programs cannot observe most program transformations that do not change single-threaded program semantics. In fact, most single-threaded program transformations continue to be allowed, since any program that behaves differently as a result must perform an undefined operation. – end note ]
- The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior. [ Note: It can be shown that programs that correctly use mutexes, synchronized and atomic blocks, and
- 4 Add a new paragraph 22 after 1.10 [intro.multithread] paragraph 21:
- [ Note: Due to the constraints on transaction safety (8.4.4 [dcl.fct.def.tx]), the following holds for a data-race-free program: If the start of an atomic block T is sequenced before an evaluation A, A is sequenced before the end of T, and A inter-thread happens before some evaluation B, then the end of T inter-thread happens before B. If an evaluation C inter-thread happens before that evaluation A, then C inter-thread happens before the start of T. These properties in turn imply that in any simple interleaved (sequentially consistent) execution, the operations of each atomic block appear to be contiguous in the interleaving. -- end note ]
阅读全文
0 0
- C++事务型内存技术规范:第1章(英文)
- C++事务型内存技术规范:第2章(英文)
- C++事务型内存技术规范(英文)
- C++事务型内存技术规范:第1章
- C++事务型内存技术规范:表格及代码块(英文)
- C++事务型内存技术规范
- C++事务型内存技术规范:表格及代码块
- J2EE技术规范(七)——JTA(理解JTA,编写简单的事务客户程序)
- 第七天(c内存)
- 第14章 事务
- 第19章 事务
- Objective-C第2版第9章 内存管理
- 高质量C++/C编程指南 -- 第7章 内存管理 (1)
- 高质量C++/C编程指南 -- 第7章 内存管理 (1)
- 高质量C++/C编程指南 -- 第7章 内存管理 (1)
- c语言程序设计(英文第三版-Stephen G.Kochan)习题-更新到第9章
- 技术规范(TS)的进展
- JAVA笔记(一)技术规范
- Angular 动画
- 《维特根斯坦—天才之为责任》读书笔记 -- Tell them I've had a wonderful life
- kmp 模板
- 图像分割单词
- 闰年
- C++事务型内存技术规范:第1章(英文)
- Kotlin学习笔记(3)-when
- 二叉树的遍历规则
- JSP:Java Server Page(1)
- 放大器的作用随谈
- MySQL查询语句练习题45题版
- 类创建时,变量及构造器初始化顺序
- Java多文件打包为一个压缩包下载
- 欢迎使用CSDN-markdown编辑器