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.

1329. Data races on vector<bool>

Section: 23.2.3 [container.requirements.dataraces] Status: Resolved Submitter: Jeffrey Yaskin Opened: 2010-03-09 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [container.requirements.dataraces].

View all issues with Resolved status.

Discussion:

The common implementation of vector<bool> is as an unsynchronized bitfield. The addition of 23.2.3 [container.requirements.dataraces]/2 would require either a change in representation or a change in access synchronization, both of which are undesireable with respect to compatibility and performance.

[ 2010 Pittsburgh: Moved to NAD EditorialResolved. Rationale added below. ]

Rationale:

Solved by N3069.

Proposed resolution:

Container data races 23.2.3 [container.requirements.dataraces]

Paragraph 1 is unchanged as follows:

1 For purposes of avoiding data races (17.6.4.8), implementations shall consider the following functions to be const: begin, end, rbegin, rend, front, back, data, find, lower_bound, upper_bound, equal_range, and, except in associative containers, operator[].

Edit paragraph 2 as follows:

2 Notwithstanding (17.6.4.8), implementations are required to avoid data races when the contents of the contained object in different elements in the same sequence, excepting vector<bool>, are modified concurrently.

Edit paragraph 3 as follows:

3 [Note: For a vector<int> x with a size greater than one, x[1] = 5 and *x.begin() = 10 can be executed concurrently without a data race, but x[0] = 5 and *x.begin() = 10 executed concurrently may result in a data race. As an exception to the general rule, for a vector<bool> y, y[i] = true may race with y[j] = true. —end note]