Thread Safety & Reentrancy

A function is thread-safe if it works correctly when called simultaneously by multiple threads. A function is reentrant if it can be interrupted (e.g., by a signal handler) and called again before the first call completes.

Thread Safety Levels

Level	Description	Example
Unsafe	Uses shared state without synchronization	A global counter without a lock
Conditionally safe	Safe only if called in specific patterns	strtok() — unsafe, uses internal state
Thread-safe	Uses synchronization (mutex, atomic) to protect shared state	pthread_mutex_lock around critical section
Reentrant	No shared state at all — pure function or thread-local state only	strtok_r() (reentrant version)

Reentrancy

A function is reentrant if:

• It uses only local variables (no static/global state)
• It does not modify its own code (self-modifying code)
• It does not call non-reentrant functions

// NOT reentrant — uses global state
int counter = 0;
int next_id() {
    return counter++;  // interrupted here → bad
}

// Reentrant — caller provides state
int next_id_r(int *counter) {
    return (*counter)++;
}

Thread-Safe vs Reentrant

	Thread-safe	Reentrant
Multiple threads	Yes	Yes
Interrupted and re-entered	Maybe	Yes
Uses locks	Maybe	Never
Uses shared state	Yes (with protection)	No

A reentrant function is always thread-safe (no shared state to protect), but a thread-safe function is not necessarily reentrant (it might hold a mutex and deadlock if re-entered from a signal handler).

Making Code Thread-Safe

1. Avoid global/static state — prefer parameters and return values
2. Use mutexes to protect shared state
3. Use atomic operations for simple counters/flags
4. Use Thread-Local Storage (TLS) — each thread gets its own copy of a variable

// Thread-local: each thread has its own copy
__thread int thread_local_var;

// Now safe — no shared state
int get_id() {
    static __thread int id = 0;
    return id++;
}