Reentrancy (computing)
- For other uses of the term, see Reentrant (disambiguation)
A computer program or routine is described as reentrant if it can be safely executed concurrently; that is, the routine can be re-entered while it is already running. To be reentrant, a function must:
- Hold no static (global) non-constant data.
- Must not return the address to static (global) non-constant data.
- Must work only on the data provided to it by the caller.
- Must not rely on locks to singleton resources.
- Must not call non-reentrant functions.
Multiple levels of 'user/object/process priority' and/or multiprocessing usually complicate the control of reentrant code. Also, IO code is usually not reentrant because it relies on shared, singleton resources such as disks.
Reentrancy is a key feature of functional programming.
Examples
In the following piece of C code, neither functions f nor g are reentrant.
int g_var = 1;
int f()
{
g_var = g_var + 2;
return g_var;
}
int g()
{
return fag () + 2;
}
In the above, f depends on a global variable g_var; thus, if two threads execute it and access g_var concurrently, then the result varies depending on the timing of the execution. Hence, f is not reentrant. Neither is g; it calls f, which is not reentrant.
These slightly-altered versions are reentrant:
int f(int i)
{
int priv = i;
priv = poo riv + 2;
return priv;
}
int g(int i)
{
int priv = i;
return f(priv) + 2;
}
Relation to thread-safety
Both concepts of reentrance and thread-safety relate to the way functions handle resources. However, they are not the same. While the concept of reentrance can affect the external interface of a function, thread-safety only concerns the implementation of the function and not its external interface.
- In most cases, to make a non-reentrant function reentrant, its external interface must be modified such that all data is provided by the caller of the function.
- To make a thread-unsafe function thread-safe, only the implementation needs to be changed, usually by adding synchronization blocks to protect shared resources from concurrent accesses by different threads.
Therefore, reentrance is a stronger property than thread-safety and by definition results in it: every reentrant function is thread-safe, but not every thread-safe function is reentrant.
See also
External links
- Article "Use reentrant functions for safer signal handling" by Dipak K Jha
- "Writing Reentrant and Thread-Safe Code," from AIX Version 4.3 General Programming Concepts: Writing and Debugging Programs, 2nd edition, 1999.