[res.on.objects]

# 16 Library introduction [[library]](./#library)

## 16.4 Library-wide requirements [[requirements]](requirements#res.on.objects)

### 16.4.5 Constraints on programs [[constraints]](constraints#res.on.objects)

#### 16.4.5.10 Library object access [res.on.objects]

[1](#1)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L3543)

The behavior of a program is undefined if calls to standard library functions from different
threads may introduce a data race[.](#1.sentence-1)

The conditions under which this may occur are specified
in [[res.on.data.races]](res.on.data.races "16.4.6.10 Data race avoidance")[.](#1.sentence-2)

[*Note [1](#note-1)*:

Modifying an object of a standard library type that is
shared between threads risks undefined behavior unless objects of that type are explicitly
specified as being shareable without data races or the user supplies a locking mechanism[.](#1.sentence-3)

â *end note*]

[2](#2)

[#](http://github.com/Eelis/draft/tree/9adde4bc1c62ec234483e63ea3b70a59724c745a/source/lib-intro.tex#L3553)

If an object of a standard library type is accessed, and
the beginning of the object's [lifetime](basic.life "6.8.4 Lifetime [basic.life]") does not happen before the access, or
the access does not happen before the end of the object's lifetime,
the behavior is undefined unless otherwise specified[.](#2.sentence-1)

[*Note [2](#note-2)*:

This applies even to objects such as mutexes intended for thread synchronization[.](#2.sentence-2)

â *end note*]
