Proposed resolution:

Resolved 2011-03 Madrid meeting by paper N3278

Proposed resolution:

Resolved 2011-03 Madrid meeting by paper N3278

[ 2011-03-19: Detlef suggests an alternative resolution, shown below. ]

Proposed Resolution

Modify [futures.state] p10 as follows:

10 Accesses to the same shared state conflict ([intro.multithread]). [Note: This explicitely specifies that the shared state is visible in the objects that reference this state in the sense of data race avoidance [res.on.data.races]. — end note]

[ 2011-03-07: Lawrence comments and drafts wording ]

The intent of this paragraph is to deal with operations, such as shared_future::get(), that return a reference to a value held in the shared state. User code could potentially conflict when accessing that value.

Lawrence proposed resolution:

Modify [futures.state] p10 as follows:

10 Accesses to the same shared state conflict ([intro.multithread]).Some operations, e.g. shared_future::get() ([futures.shared_future]), may return a reference to a value held in their shared state. Accesses and modifications through those references by concurrent threads to the same shared state may potentially conflict ([intro.multithread]). [Note: As a consequence, accesses must either use read-only operations or provide additional synchronization. — end note]

[ 2011-03-07 Jonathan Wakely adds: ]

It's not clear which paragraph this refers to, I had to go to the ballot comments where US-195 reveals it's para 8, which in the FCD (N3092) says:

Accesses to the same associated asynchronous state conflict (1.10).

This is now para 10 in N3242:

Accesses to the same shared state conflict (1.10).

Addresses US-195

The intent and meaning of [futures.state] p10 is not apparent.

10 Accesses to the same shared state conflict (1.10).