|
|
|
|
Reentrant
|
| |
|
| |
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 computer program or routine:
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.
Typically recursive subroutines need to be reentrant.
Also, subroutines that are directly or indirectly called from an interrupt handler typically need to be reentrant.
Reentrant interrupt handler
A "reentrant interrupt handler" is an interrupt handler that re-enables interrupts early in the interrupt handler.
Discussion
Ask a question about 'Reentrant' Start a new discussion about 'Reentrant' Answer questions from other users |
Encyclopedia
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 computer program or routine:
- Must hold no static (or global) non-constant data.
- Must not return the address to static (or 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 modify its own code -- no self-modifying code
- Must not call non-reentrant computer programs or routines.
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.
Typically recursive subroutines need to be reentrant.
Also, subroutines that are directly or indirectly called from an interrupt handler typically need to be reentrant.
Reentrant interrupt handler
A "reentrant interrupt handler" is an interrupt handler that re-enables interrupts early in the interrupt handler. This may reduce interrupt latency.
Jack Ganssle recommends re-enabling interrupts as soon as possible in the interrupt handler.
John Regehr recommends avoiding such early re-enabling of interrupts unless it is necessary.
Examples
In the following piece of C code, neither functions f nor g are reentrant.
int g_var = 1;
int f
int g
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 g(int i)
Relation to thread safety
Both concepts of reentrancy and thread safety relate to the way functions handle resources. However, they are not the same. While the concept of reentrancy 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, reentrancy is a more fundamental property than thread-safety and by definition, leads to thread-safety: Every reentrant function is thread-safe; however, not every thread-safe function is reentrant.
See also
- Referential transparency (computer science)
External links
- Article "" by Dipak K Jha
- "," from AIX Version 4.3 General Programming Concepts: Writing and Debugging Programs, 2nd edition, 1999.
-
|
| |
|
|
