Why Thread Safety and Reentrancy Matter in C++ Backend Development

Multithreading and Concurrency in C++ Server Programs

Server‑side C++ applications typically use a thread pool to handle incoming requests, improving CPU utilization and overall concurrency. All threads within the same process share most resources (memory, file descriptors, address space, global data, etc.) while each thread has its own registers, stack, thread ID, error code, and signal mask.

Key points:

Process is the unit of resource allocation; thread is the unit of CPU scheduling.

All threads in a process share the same address space.

Threads own only minimal runtime resources such as registers and stacks.

Thread‑Safety

Thread safety means that code operating on shared data can be executed concurrently without producing incorrect or unpredictable results.

The primary cause of thread‑unsafe behavior is mutable shared data (e.g., global or static variables) accessed by multiple threads without proper synchronization.

Characteristics of a thread‑safe function:

It does not use shared mutable data; all data are local to the call.

If it accesses shared data, it does so under a lock (mutex, spin‑lock, etc.).

Read‑only shared data may be accessed without locking.

Illustrative example with four worker threads:

Function A : only prints output → thread‑safe.

Function B : increments a global Count without locking → thread‑unsafe.

Function C : increments a global Factor while holding a mutex → thread‑safe.

If a thread‑safe function calls a non‑thread‑safe function, the caller becomes unsafe as well.

Typical categories of unsafe functions (from Computer Systems: A Programmer’s Perspective ):

Functions that do not protect shared data.

Functions that maintain state across calls.

Functions that return pointers to static buffers.

Functions that invoke other unsafe functions.

Common examples: rand() – maintains internal state. gethostbyname, localtime, strtok – return pointers to static data.

#include <stdio.h>
#include <time.h>

int main() {
    time_t rawtime;
    struct tm *timeinfo;
    time(&rawtime);
    timeinfo = localtime(&rawtime); // non‑reentrant, uses static buffer
    return 0;
}

Because localtime stores its result in a static buffer, concurrent calls can corrupt each other’s data, making it neither thread‑safe nor reentrant.

For a comprehensive list of thread‑unsafe POSIX functions, see the man‑page https://man7.org/linux/man-pages/man7/pthreads.7.html.

Reentrant Functions

A function is reentrant if it can be interrupted at any point, the interrupt handler can execute other code, and when control returns the original function continues correctly.

Fundamental properties of reentrant functions:

Only stack‑allocated (automatic) variables are used; no static or global state.

All results are supplied by the caller; the function does not return pointers to static data.

The function does not call non‑reentrant functions.

Two categories:

Explicitly reentrant : all parameters are passed by value and the function uses only its own stack – always safe.

Implicitly reentrant : some parameters are passed by reference; safety depends on the caller providing non‑shared buffers.

All reentrant functions are thread‑safe, but not all thread‑safe functions are reentrant.

Practical Guidance

When writing multithreaded code, avoid mutable global or static variables unless protected by synchronization primitives.

If a function must modify shared data, protect the critical section with a mutex, read‑write lock, or atomic operation.

Prefer passing buffers and state explicitly via function arguments rather than relying on internal static storage.

Audit third‑party libraries for functions that are known to be non‑reentrant (e.g., localtime, strtok, rand) and replace them with thread‑safe alternatives ( localtime_r, strtok_r, rand_r).