Is malloc thread-safe?

Question

Is the malloc() function re-entrant?

Answer 1

I read somewhere that if you compile with -pthread, malloc becomes thread safe. I´m pretty sure its implementation dependant though, since malloc is ANSI C and threads are not.

If we are talking gcc:

Compile and link with -pthread and malloc() will be thread-safe, on x86 and AMD64.

http://groups.google.com/group/comp.lang.c.moderated/browse_thread/thread/2431a99b9bdcef11/ea800579e40f7fa4

Another opinion, more insightful

{malloc, calloc, realloc, free, posix_memalign} of glibc-2.2+ are thread safe

http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2005-07/0323.html

Answer 2

If you are working with GLIBC, the answer is: Yes, BUT.

Specifically, yes, BUT, please, please be aware that while malloc and free are thread-safe, the debugging functions are not.

Specifically, the extremely useful mtrace(), mcheck(), and mprobe() functions are not thread-safe. In one of the shortest, straightest answers you will ever see from a GNU project, this is explained here:

https://sourceware.org/bugzilla/show_bug.cgi?id=9939

You will need to consider alternate techniques, such as ElectricFence, valgrind, dmalloc, etc.

So, if you mean, "are the malloc() and free() functions threadsafe", the answer is yes. But if you mean, "is the entire malloc/free suite threadsafe", the answer is NO.

Answer 3

No, it is not thread-safe. There may actually be a malloc_lock() and malloc_unlock() function available in your C library. I know that these exist for the Newlib library. I had to use this to implement a mutex for my processor, which is multi-threaded in hardware.

Answer 4

Here is an excerpt from malloc.c of glibc :

Thread-safety: thread-safe unless NO_THREADS is defined

assuming NO_THREADS is not defined by default, malloc is thread safe at least on linux.

Answer 5

This is quite old question and I want to bring freshness according current state of things.

Yes, currently malloc() is thread-safe.

From the GNU C Library Reference Manual of glibc-2.20 [released 2014-09-07]:

void * malloc (size_t size)

Preliminary: MT-Safe | ...

... 1.2.2.1 POSIX Safety Concepts:

... MT-Safe or Thread-Safe functions are safe to call in the presence of other threads. MT, in MT-Safe, stands for Multi Thread.

Being MT-Safe does not imply a function is atomic, nor that it uses any of the memory synchronization mechanisms POSIX exposes to users. It is even possible that calling MT-Safe functions in sequence does not yield an MT-Safe combination. For example, having a thread call two MT-Safe functions one right after the other does not guarantee behavior equivalent to atomic execution of a combination of both functions, since concurrent calls in other threads may interfere in a destructive way.

Whole-program optimizations that could inline functions across library interfaces may expose unsafe reordering, and so performing inlining across the GNU C Library interface is not recommended. The documented MT-Safety status is not guaranteed underwhole-program optimization. However, functions defined in user-visible headers are designed to be safe for inlining.

Answer 6

Short answer: yes, as of C11, which is the first version of the C standard that includes the concept of threads, malloc and friends are required to be thread-safe. Many operating systems that included both threads and a C runtime made this guarantee long before the C standard did, but I'm not prepared to swear to all. However, malloc and friends are not and never have been required to be reentrant.

That means, it is safe to call malloc and free from multiple threads simultaneously and not worry about locking, as long as you aren't breaking any of the other rules of memory allocation (e.g. call free once and only once on each pointer returned by malloc). But it is not safe to call these functions from a signal handler that might have interrupted a call to malloc or free in the thread handling the signal. Sometimes, using functionality beyond ISO C, you can guarantee that the thread handling the signal did not interrupt a call to malloc or free, e.g. with sigprocmask and sigpause, but try not to do that unless you have no other option, because it's hard to get perfectly right.

---

Long answer with citations: The C standard added a concept of threads in the 2011 revision (link is to document N1570, which is the closest approximation to the official text of the 2011 standard that is publicly available at no charge). In that revision, section 7.1.4 paragraph 5 states:

Unless explicitly stated otherwise in the detailed descriptions that follow, library functions shall prevent data races as follows: A library function shall not directly or indirectly access objects accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's arguments. A library function shall not directly or indirectly modify objects accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's non-const arguments. Implementations may share their own internal objects between threads if the objects are not visible to users and are protected against data races.

[footnote: This means, for example, that an implementation is not permitted to use a static object for internal purposes without synchronization because it could cause a data race even in programs that do not explicitly share objects between threads. Similarly, an implementation of memcpy is not permitted to copy bytes beyond the specified length of the destination object and then restore the original values because it could cause a data race if the program shared those bytes between threads.]

As I understand it, this is a long-winded way of saying that the library functions defined by the C standard are required to be thread-safe (in the usual sense: you can call them from multiple threads simultaneously, without doing any locking yourself, as long as they don't end up clashing on the data passed as arguments) unless the documentation for a specific function specifically says it isn't.

Then, 7.22.3p2 confirms that malloc, calloc, realloc, aligned_alloc, and free in particular are thread-safe:

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.

Contrast what it says about strtok, which is not and never has been thread-safe, in 7.24.5.8p6:

The strtok function is not required to avoid data races with other calls to the strtok function.

[footnote: The strtok_s function can be used instead to avoid data races.]

(comment on the footnote: don't use strtok_s, use strsep.)

Older versions of the C standard said nothing whatsoever about thread safety. However, they did say something about reentrancy, because signals have always been part of the C standard. And this is what they said, going back to the original 1989 ANSI C standard (this document has nigh-identical wording to, but very different section numbering from, the ISO C standard that came out the following year):

If [a] signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler calls any function in the standard library other than the signal function itself or refers to any object with static storage duration other than by assigning a value to a static storage duration variable of type volatile sig_atomic_t . Furthermore, if such a call to the signal function results in a SIG_ERR return, the value of errno is indeterminate.

Which is a long-winded way of saying that C library functions are not required to be reentrant as a general rule. Very similar wording still appears in C11, 7.14.1.1p5:

If [a] signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler refers to any object with static or thread storage duration that is not a lock-free atomic object other than by assigning a value to an object declared as volatile sig_atomic_t, or the signal handler calls any function in the standard library other than the abort function, the _Exit function, the quick_exit function, or the signal function with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler. Furthermore, if such a call to the signal function results in a SIG_ERR return, the value of errno is indeterminate.

[footnote: If any signal is generated by an asynchronous signal handler, the behavior is undefined.]

POSIX requires a much longer, but still short compared to the overall size of the C library, list of functions to be safely callable from an "asynchronous signal handler", and also defines in more detail the circumstances under which a signal might "occur other than as the result of calling the abort or raise function." If you're doing anything nontrivial with signals, you are probably writing code intended to be run on an OS with the Unix nature (as opposed to Windows, MVS, or something embedded that probably doesn't have a complete hosted implementation of C in the first place), and you should familiarize yourself with the POSIX requirements for them, as well as the ISO C requirements.