Reentrant

Reentrant describes a property of a program unit, typically a function or routine, that can be safely entered again before its previous invocation has completed. A reentrant function can be interrupted in the middle of execution (by an interrupt, a signal, or a recursive call) and invoked again, with each invocation remaining correct regardless of interleaving.

To be reentrant, a function must not rely on static or global data that can be modified by another invocation. Any state it uses should be local to the current invocation or passed in via parameters. It must not maintain per-call state in non-reentrant globals or in resources such as files, sockets, or memory that could be accessed concurrently without proper synchronization. If shared resources are required, they must be accessed through reentrant mechanisms, such as per-call contexts or lock-free designs, and without using non-reentrant library calls.

In practice, reentrancy is a core concern in interrupt handlers and signal handlers, where code may be invoked asynchronously. It is related to, but distinct from, thread-safety: reentrancy is a stronger requirement, ensuring correctness under asynchronous re-entry, while thread-safety concerns concurrent calls from multiple threads; a function can be thread-safe without being reentrant if it uses non-recursive locks or shared mutable state.

Common examples include using strtok_r instead of strtok, and avoiding reliance on non-reentrant resources like static buffers. Some libraries document reentrancy guarantees for functions they provide. In embedded and systems programming, achieving reentrancy often influences allocator behavior, I/O design, and the separation of state into caller-provided contexts.