In UNIX systems we know malloc() is a non-reentrant function (system call). Why is that?
Similarly, printf() also is said to be non-reentrant; why?
I know the definition of re-entrancy, but I wanted to know why it applies to these functions. What prevents them being guaranteed reentrant?
Most likely because you can't start writing output while another call to printf is still printing it's self. The same goes for memory allocation and deallocation.
It's because both works with global resources: heap memory structures and console.
EDIT: the heap is nothing else than a kind linked list structure. Each malloc or free modifies it, so having several threads in the same time with writing access to it will damage its consistency.
EDIT2: another detail: they could be made reentrant by default by using mutexes. But this approach is costly, and there is no garanty that they will be always used in MT environment.
So there are two solutions: to make 2 library functions, one reentrant and one not or leave the mutex part to the user. They've choosed the second.
Also, it can be because the original versions of these functions were non-reentrant, so the've been declared so for compatibility.
If you try calling malloc from two separate threads (unless you have a thread-safe version, not guaranteed by C standard), bad things happen, because there's only one heap for two threads. Same for printf- the behaviour is undefined. That's what makes them in reality non-reentrant.
Let's understand what we mean by re-entrant. A re-entrant function can be invoked before a previous invocation has finished. This might happen if
malloc isn't re-entrant because it is managing several global data structures that track free memory blocks.
printf isn't re-entrant because it modifies a global variable i.e. the content of the FILE* stout.
malloc and printf usually use global structures, and employ lock-based synchronization internally. That's why they're not reentrant.
The malloc function could either be thread-safe or thread-unsafe. Both are not reentrant:
Any thread-unsafe function is not reentrant (reentrant functions are thread-safe by definition). Malloc operates on a global heap, and it's possible that two different invocations of malloc that happen at the same time, return the same memory block. (The 2nd malloc call should happen before an address of the chunk is fetched, but the chunk is not marked as unavailable). This violates the postcondition of malloc, so this implementation would not be re-entrant.
To prevent this effect, a thread-safe implementation of malloc would use lock-based synchronization. However, if malloc is called from signal handler, the following situation may happen:
malloc(); //initial call
lock(memory_lock); //acquire lock inside malloc implementation
signal_handler(); //interrupt and process signal
malloc(); //call malloc() inside signal handler
lock(memory_lock); //try to acquire lock in malloc implementation
// DEADLOCK! We wait for release of memory_lock, but
// it won't be released because the original malloc call is interrupted
This situation won't happen when malloc is simply called from different threads. Indeed, the reentrancy concept goes beyond thread-safety and also requires functions to work properly even if one of its invocation never terminates. That's basically the reasoning why any function with locks would be not re-entrant.
The printf function also operated on global data. Any output stream usually employs a global buffer attached to the resource data are sent to (a buffer for terminal, or for a file). The print process is usually a sequence of copying data to buffer and flushing the buffer afterwards. This buffer should be protected by locks in the same way malloc does. Therefore, printf is also non-reentrant.