This document is an attempt to define multi-threaded safety (MT-safe) for glibc and all of it's provided functions. We will define MT-safe by using the C11 memory model and reasoning with that model about what is the definition of safe. It is the hope that this document is used as the basis for a revision of the POSIX standard that glibc can adopt to adjust it's own safety documentation.
What does mean for all of the functions provided by glibc libraries?
If we can precisely define MT-safe then we can use this information to help programmers reason about their threaded programs that have concurrent execution.
We can then also write tools to help programmers detect defects in their code that could lead to undefined or unintended behaviour from their programs.
In practice the definition of safety can only be well defined given a memory model upon which the reasoning of safety can be described.
At present the POSIX and ISO C99 standards do not define a memory model and therefore it is difficult for glibc to document precisely what MT-safe means without one.
It is likely that in the future POSIX will have to adopt a memory model in order to allow developers to reason about the safety of the provided functions (as we will here).
It can be argued that the expected definition of MT-safe in the library is that of sequential consistency. That is to say that to the program running on the SMP system it appears as if the system is UP. In practice sequential consistency requires that all writes are seen instantaneously throughout the system and that instructions execute in order. This is not reality though, but it should appear this way to the program.
At present we roughly document this: MT-Safe functions are safe to call in the presence of other threads, i.e., that will behave as documented regardless of what other threads are doing, as long as they all refrain from invoking undefined behavior.
At present the Linux write syscall is not MT-safe. Multiple threads racing to the write may get the same file position value and write to the same position resulting in the loss of data. (http://lwn.net/Articles/180387/)