1ATTRIBUTES(7) Linux Programmer's Manual ATTRIBUTES(7)
2
6 attributes - POSIX safety concepts
7
9 Note: the text of this man page is based on the material taken from the
10 "POSIX Safety Concepts" section of the GNU C Library manual. Further
11 details on the topics described here can be found in that manual.
12 Various function manual pages include a section ATTRIBUTES that
14 describes the safety of calling the function in various contexts. This
15 section annotates functions with the following safety markings:
16 MT-Safe
18 MT-Safe or Thread-Safe functions are safe to call in the pres‐
19 ence of other threads. MT, in MT-Safe, stands for Multi Thread.
20 Being MT-Safe does not imply a function is atomic, nor that it
22 uses any of the memory synchronization mechanisms POSIX exposes
23 to users. It is even possible that calling MT-Safe functions in
24 sequence does not yield an MT-Safe combination. For example,
25 having a thread call two MT-Safe functions one right after the
26 other does not guarantee behavior equivalent to atomic execution
27 of a combination of both functions, since concurrent calls in
28 other threads may interfere in a destructive way.
29 Whole-program optimizations that could inline functions across
31 library interfaces may expose unsafe reordering, and so perform‐
32 ing inlining across the GNU C Library interface is not recom‐
33 mended. The documented MT-Safety status is not guaranteed under
34 whole-program optimization. However, functions defined in user-
35 visible headers are designed to be safe for inlining.
36 MT-Unsafe
38 MT-Unsafe functions are not safe to call in a multithreaded pro‐
39 grams.
40 Other keywords that appear in safety notes are defined in subsequent
42 sections.
43 Conditionally safe features
45 For some features that make functions unsafe to call in certain con‐
46 texts, there are known ways to avoid the safety problem other than
47 refraining from calling the function altogether. The keywords that
48 follow refer to such features, and each of their definitions indicates
49 how the whole program needs to be constrained in order to remove the
50 safety problem indicated by the keyword. Only when all the reasons
51 that make a function unsafe are observed and addressed, by applying the
52 documented constraints, does the function become safe to call in a con‐
53 text.
54 init Functions marked with init as an MT-Unsafe feature perform MT-
56 Unsafe initialization when they are first called.
57 Calling such a function at least once in single-threaded mode
59 removes this specific cause for the function to be regarded as
60 MT-Unsafe. If no other cause for that remains, the function can
61 then be safely called after other threads are started.
62 race Functions annotated with race as an MT-Safety issue oper