Movatterモバイル変換

This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2025-12-20

1953. Data races and common initial sequence

[Accepted as a DR at the November, 2024 meeting.]

According to 6.8.1 [intro.memory] paragraph 3,

Amemory location is either an object of scalar type or amaximal sequence of adjacent bit-fields all having non-zerowidth. [Note: Various features of the language, suchas references and virtual functions, might involveadditional memory locations that are not accessible toprograms but are managed by theimplementation. —end note] Two or more threadsof execution (6.10.2 [intro.multithread]) can update andaccess separate memory locations without interfering witheach other.

It is not clear how this relates to the permissiongranted in 11.4 [class.mem] paragraph 18 to inspectthe common initial sequence of standard-layout structs thatare members of a standard-layout union. If one thread iswriting to the common initial sequence and another isreading from it via a different struct, that shouldconstitute a data race, but the current wording does notclearly state that.

Additional notes (October, 2024)

(From submission#621.)

A similar concern arises for the following example:

  union U { int x, y; } u;  (u.x = 1, 0) + (u.y = 2, 0);

Possible resolution [SUPERSEDED]:

Change in 6.8.1 [intro.memory] paragraph 3 as follows:

Amemory location isthe storage occupied by the objectrepresentation of either an object of scalar type that is not abit-field or a maximal sequence of adjacent bit-fields all havingnonzero width. ...

CWG 2024-10-25

Subclause 6.10.1 [intro.execution] paragraph 10 does not coverunsequenced object creation that does not change any bits of storage,such as a placement new invoking a trivial default constructor. Theoriginal concern in this issue was addressed by P0137R1, adding thefollowing in 11.4.2 [class.mfct] paragraph 28:

In a standard-layout union with an active member(11.5 [class.union]) of struct type T1, it is permitted to reada non-static data member m of another union member of struct type T2provided m is part of the common initial sequence of T1 and T2; thebehavior is as if the corresponding member of T1 were nominated.

Proposed resolution (approved by CWG 2024-11-08):

1. Change in 6.8.1 [intro.memory] paragraph 3 as follows:

   Amemory location isthe storage occupied by the objectrepresentation of either an object of scalar type that is not abit-field or a maximal sequence of adjacent bit-fields all havingnonzero width. ...

2. Change in 6.10.1 [intro.execution] paragraph 10 and add bullets asfollows:

   ... The value computations of the operands of an operator aresequenced before the value computation of the result of theoperator.IfThe behavior is undefined if

   • a side effect on a memory location(6.8.1 [intro.memory])or
   • starting or ending the lifetime of an object in a memory location

   is unsequenced relative toeither

   • another side effect on the same memory location,
   • starting or ending the lifetime of an object occupyingstorage that overlaps with the memory location, or
   • a value computation using the value of any object in thesame memory location,

   andtheythe two evaluations are not potentiallyconcurrent (6.10.2 [intro.multithread]), the behavior is undefined.[ Note: Starting the lifetime of an object in a memory locationcan end the lifetime of objects in other memory locations(6.8.4 [basic.life]). -- end note ]

   [ Note: ... ]

   [ Example:

     void g(int i) {    i = 7, i++, i++;     // i becomes 9    i = i++ + 1;   // the value of i is incremented    i = i++ + i;   // undefined behavior    i = i + 1;     // the value of i is incremented    union U { int x, y; } u;    (u.x = 1, 0) + (u.y = 2, 0);   // undefined behavior  }

   -- end example ]

3. Change in 6.10.2.2 [intro.races] paragraph 2 as follows, addingbullets:

   Two expression evaluationsconflict if one of them

   • modifies (3.1 [defns.access]) a memory location(6.8.1 [intro.memory])or
   • starts or ends the lifetime of an object in a memorylocation

   and the other one

   • reads or modifies the same memory locationor
   • starts or ends the lifetime of an object occupying storagethat overlaps with the memory location.

   [Note 2: A modification can still conflict even if it does notalter the value of any bits. —end note]