This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

### 1502. Specification of [futures.state] unclear

Section: 33.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 33.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 33.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 33.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