Title
Data races and common initial sequence
Status
review
Section
6.7.1 [intro.memory]
Submitter
Faisal Vali

Created on 2014-06-23.00:00:00 last changed 1 week ago

Messages

Date: 2024-10-30.07:02:02

CWG 2024-10-25

Subclause 6.9.1 [intro.execution] paragraph 10 does not cover unsequenced object creation that does not change any bits of storage, such as a placement new invoking a trivial default constructor. The original concern in this issue was address by P0137R1, adding the following 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 read a non-static data member m of another union member of struct type T2 provided m is part of the common initial sequence of T1 and T2; the behavior is as if the corresponding member of T1 were nominated.

Possible resolution:

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

    A memory location is the storage occupied by the object representation of either an object of scalar type that is not a bit-field or a maximal sequence of adjacent bit-fields all having nonzero width. ...
  2. Change in 6.9.1 [intro.execution] paragraph 10 and add bullets as follows:

    ... The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. If
    • a side effect on a memory location (6.7.1 [intro.memory]) or
    • starting or ending the lifetime of an object in a memory location
    is unsequenced relative to either
    • another side effect on the same memory location,
    • starting or ending the lifetime of an object occupying storage that overlaps with the memory location, or
    • a value computation using the value of any object in the same memory location,
    and they are not potentially concurrent (6.9.2 [intro.multithread]), the behavior is undefined. [ Note: Starting the lifetime of an object in a memory location can end the lifetime of objects in other memory locations (6.7.3 [basic.life]). -- end note ]
  3. Change in 6.9.2.2 [intro.races] paragraph 2 as follows, adding bullets:

    Two expression evaluations conflict if one of them
    • modifies (3.1 [defns.access]) a memory location (6.7.1 [intro.memory]) or
    • starts or ends the lifetime of an object in a memory location
    and the other one
    • reads or modifies the same memory location or
    • starts or ends the lifetime of an object occupying storage that overlaps with the memory location.
    [Note 2: A modification can still conflict even if it does not alter the value of any bits. —end note]
Date: 2024-10-15.00:00:00

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.7.1 [intro.memory] paragraph 3 as follows:

A memory location is the storage occupied by the object representation of either an object of scalar type that is not a bit-field or a maximal sequence of adjacent bit-fields all having nonzero width. ...
Date: 2014-06-23.00:00:00

According to 6.7.1 [intro.memory] paragraph 3,

A memory location is either an object of scalar type or a maximal sequence of adjacent bit-fields all having non-zero width. [Note: Various features of the language, such as references and virtual functions, might involve additional memory locations that are not accessible to programs but are managed by the implementation. —end note] Two or more threads of execution (6.9.2 [intro.multithread]) can update and access separate memory locations without interfering with each other.

It is not clear how this relates to the permission granted in 11.4 [class.mem] paragraph 18 to inspect the common initial sequence of standard-layout structs that are members of a standard-layout union. If one thread is writing to the common initial sequence and another is reading from it via a different struct, that should constitute a data race, but the current wording does not clearly state that.

History
Date User Action Args
2024-10-25 21:02:00adminsetmessages: + msg7853
2024-10-25 21:02:00adminsetstatus: open -> review
2024-10-14 10:09:26adminsetmessages: + msg7842
2014-06-23 00:00:00admincreate