Section: 32.10.5 [futures.state] Status: Resolved Submitter: INCITS Opened: 2010-08-25 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [futures.state].
View all issues with Resolved status.
Discussion:
Addresses US-195
The intent and meaning of 32.10.5 [futures.state] p10 is not apparent.
10 Accesses to the same shared state conflict (1.10).
[ 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).
[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 32.10.5 [futures.state] p10 as follows:
10
Accesses to the same shared state conflict (6.9.2 [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 (6.9.2 [intro.multithread]). [Note: As a consequence, accesses must either use read-only operations or provide additional synchronization. — end note]
[2011-03-19: Detlef suggests an alternative resolution, shown below.]
Proposed Resolution
Modify 32.10.5 [futures.state] p10 as follows:
10 Accesses to the same shared state conflict (6.9.2 [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 16.4.6.10 [res.on.data.races]. — end note]
Proposed resolution:
Resolved 2011-03 Madrid meeting by paper N3278