The only standard that speaks about this is C11 (since there was no notion of multithreading before), which says (7.22.3/2):
For purposes of determining the existence of a data race, memory allocation functions
behave as though they accessed only memory locations accessible through their
arguments and not other static duration storage. These functions may, however, visibly
modify the storage that they allocate or deallocate. A call to free
or realloc
that
deallocates a region p
of memory synchronizes with any allocation call that allocates all
or part of the region p
. This synchronization occurs after any access of p
by the
deallocating function, and before any such access by the allocating function.
In short, "it's all fine".
However, specific implementations like Linux will surely have been providing their own, strong guarantees for a long time (since ptmalloc2
I think), and it's basically always been fine. [Update, thanks to @ArjunShankar: Posix does indeed require that malloc
be thread-safe.]
(Note, though, that other implementations such as Google's tcmalloc
may have better performance in multithreaded applications.)
(For C++, see C++11: 18.6.1.4.)