c - 可见的副作用顺序

Question

我对 5.1.2.4(p22) 中定义的visible sequence of side effects 概念感到困惑:

The visible sequence of side effects on an atomic object M, with respect to a value computation B of M, is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first side effect is visible with respect to B, and for every subsequent side effect, it is not the case that B happens before it.

这是我目前对这个概念的理解:

由于关于 B 的可见副作用应该是“最接近的发生在 B 之前”的副作用，我可以想象以下情况:

_Atomic int i = 10;

void *increment(void *ignored){
    i++;
    printf("%d\n", i); //<<----- B
}

void *decrement(void *ignored){
    i--;
    printf("%d\n", i);
}

int main(void){
   i = 100;
   //start two threads with increment and decrement correspondingly
}

考虑到上述情况，我假设 B 是 increment 函数中的值计算，因此可见的副作用序列与 B 是“i++, i--”。由于 i = 100 在创建线程之前被排序，因此它不属于关于 B 的可见副作用序列。

我的解释是真的吗？

Answer 1

working draft C2x 标准的一部分包含了在 C17(“错误修复”)标准中所做的更改。本节更改的主要目的是调整 C++ 和 C 之间的内存一致性模型，并删除 DR406 中指出的冗余。缺陷报告。

如您所见，委员会竭尽全力尝试澄清内存一致性模型并简化构成“数据竞争”的内容。

棘手的部分是 C17 错误修复中只有一个更改是“规范性的”，这意味着在 C2x 标准最终确定之前，符合标准的实现不必考虑对此部分的更改。

就您对当前标准的现有 部分的解释而言，我不得不说这是一个有争议的问题。标准委员会承认当前版本中的困惑和歧义，您最好等到本节有机会在新的 C2x 标准下安定下来，然后再担心太多。

16 An evaluation A inter-thread happens before an evaluation B if A synchronizes with B, A is dependency-ordered before B, or, for some evaluation X:

• A synchronizes with X and X is sequenced before B,
• A is sequenced before X and X inter-thread happens before B, or

• A inter-thread happens before X and X inter-thread happens before B.

  ---

  15)The "carries a dependency" relation is a subset of the "sequenced before" relation, and is similarly strictly intra-thread.
  16)The "dependency-ordered before" relation is analogous to the "synchronizes with" relation, but uses release/consume in place of release/acquire.

17 NOTE 7 The "inter-thread happens before" relation describes arbitrary concatenations of "sequenced before", "synchronizes with", and "dependency-ordered before" relationships, with two exceptions. The first exception is that a concatenation is not permitted to end with "dependency-ordered before" followed by "sequenced before". The reason for this limitation is that a consume operation participating in a "dependency-ordered before" relationship provides ordering only with respect to operations to which this consume operation actually carries a dependency. The reason that this limitation applies only to the end of such a concatenation is that any subsequent release operation will provide the required ordering for a prior consume operation. The second exception is that a concatenation is not permitted to consist entirely of "sequenced before". The reasons for this limitation are (1) to permit "inter-thread happens before" to be transitively closed and (2) the "happens before" relation, defined below, provides for relationships consisting entirely of "sequenced before".

18 An evaluation A happens before an evaluation B if A is sequenced before B or A inter-thread happens before B. The implementation shall ensure that no program execution demonstrates a cycle in the "happens before" relation.

19 NOTE 8 This cycle would otherwise be possible only through the use of consume operations.

20 A visible side effect A on an object M with respect to a value computation B of M satisfies the conditions:

• A happens before B, and
• there is no other side effect X to M such that A happens before X and X happens before B. The value of a non-atomic scalar object M, as determined by evaluation B, shall be the value stored by the visible side effect A.

21 NOTE 9 If there is ambiguity about which side effect to a non-atomic object is visible, then there is a data race and the behavior is undefined.

22 NOTE 10 This states that operations on ordinary variables are not visibly reordered. This is not actually detectable without data races, but it is necessary to ensure that data races, as defined here, and with suitable restrictions on the use of atomics, correspond to data races in a simple interleaved (sequentially consistent) execution.

23 The value of an atomic object M, as determined by evaluation B, shall be the value stored by some side effect A that modifies M, where B does not happen before A.

24 NOTE 11 The set of side effects from which a given evaluation might take its value is also restricted by the rest of the rules described here, and in particular, by the coherence requirements below.

25 If an operation A that modifies an atomic object M happens before an operation B that modifies M, then A shall be earlier than B in the modification order of M.

26 NOTE 12 The requirement above is known as "write-write coherence".

27 If a value computation A of an atomic object M happens before a value computation B of M, and A takes its value from a side effect X on M, then the value computed by B shall either be the value stored by X or the value stored by a side effect Y on M, where Y follows X in the modification order of M.

28 NOTE 13 The requirement above is known as "read-read coherence".

29 If a value computation A of an atomic object M happens before an operation B on M, then A shall take its value from a side effect X on M, where X precedes B in the modification order of M.

30 NOTE 14 The requirement above is known as "read-write coherence".

31 If a side effect X on an atomic object M happens before a value computation B of M, then the evaluation B shall take its value from X or from a side effect Y that follows X in the modification order of M.

32 NOTE 15 The requirement above is known as "write-read coherence".

33 NOTE 16 This effectively disallows compiler reordering of atomic operations to a single object, even if both operations are "relaxed" loads. By doing so, it effectively makes the "cache coherence" guarantee provided by most hardware available to C atomic operations.

34 NOTE 17 The value observed by a load of an atomic object depends on the "happens before" relation, which in turn depends on the values observed by loads of atomic objects. The intended reading is that there exists an association of atomic loads with modifications they observe that, together with suitably chosen modification orders and the "happens before" relation derived as described above, satisfy the resulting constraints as imposed here.