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 strikethrough to 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.
  • 2 Change in 1.10 [intro.multithread] paragraph 10:
    • Synchronized and atomic blocks as well as certain Certain library calls synchronize with other synchronized blocks, atomic blocks, and library calls performed by another thread.
  • 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 ]
  • 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 ]