16 Library introduction [library]

16.4 Library-wide requirements [requirements]

16.4.6 Conforming implementations [conforming]

16.4.6.10 Data race avoidance [res.on.data.races]

This subclause specifies requirements that implementations shall meet to prevent data races .

Every standard library function shall meet each requirement unless otherwise specified.

Implementations may prevent data races in cases other than those specified below.

A C++ standard library function shall not directly or indirectly access objects ([intro.multithread]) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's arguments, including this.

A C++ standard library function shall not directly or indirectly modify objects ([intro.multithread]) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's non-const arguments, including this.

[Note 1:

This means, for example, that implementations can't use an object with static storage duration for internal purposes without synchronization because doing so can cause a data race even in programs that do not explicitly share objects between threads.

— end note]

A C++ standard library function shall not access objects indirectly accessible via its arguments or via elements of its container arguments except by invoking functions required by its specification on those container elements.

Operations on iterators obtained by calling a standard library container or string member function may access the underlying container, but shall not modify it.

[Note 2:

In particular, container operations that invalidate iterators conflict with operations on iterators associated with that container.

— end note]

Implementations may share their own internal objects between threads if the objects are not visible to users and are protected against data races.

Unless otherwise specified, C++ standard library functions shall perform all operations solely within the current thread if those operations have effects that are visible to users.

[Note 3:

This allows implementations to parallelize operations if there are no visible side effects.

— end note]