Why are reentrant library and system call interfaces good?

There are two approaches to providing system calls and library interfaces that will work with multithreaded programs. One is to simply wrap all the appropriate code with mutexes, thereby guaranteeing that only one thread will execute any such routine at a time.

While this approach mostly works, it provides terrible performance. For functions that maintain state across multiple invocations (e.g. strtok() and friends), this approach simply doesn’t work at all, hence the existence of _r interfaces on many Unix systems (see below).

A better solution is to ensure that library calls can safely be performed by multiple threads at once.

If your Unix system provides threads, it will probably provide a set of thread-safe variants of standard C library routines. A small number of these are mandated by the POSIX standard, and many Unix vendors provide their own useful supersets, including functions such as gethostbyname_r().

Unfortunately, the supersets that different vendors support do not necessarily overlap, so in code that you intend to be portable, you can only safely use the standard POSIX-mandated functions. The thread-safe routines are conceptually “cleaner” than their stateful counterparts, though, so it is good practice to use them wherever and whenever you can.