Reentrant - From Wikipedia, the free encyclopedia

Reentrant

From Wikipedia, the free encyclopedia

Jump to: navigation, search

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.

Contents [hide] 1 Examples 2 Relation to thread-safety 3 See also 4 External links

[edit] Examples

In the following piece of C code, neither functions f nor g are reentrant.

int g_var = 1;

int f()
{
  return g_var + 2;
}

int g()
{
  return f() + 2;
}

int main()
{
  g();
  return 0;
}

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)
{
  return i + 2;
}

int g(int i)
{
  return f(i) + 2;
}

int main()
{
  g(1);
  return 0;
}

[edit] Relation to thread-safety

Reentrance and thread-safety are separate concepts: a function can be reentrant, thread-safe, both, or neither. However, both these concepts are related to the way functions handle resources.

A thread-safe function protects shared resources from concurrent access by locks. Thread-safety concerns only the implementation of a function and does not affect its external interface. In case of reentrancy, the external interface itself should be such that all data is provided by the caller of the function.

In most cases, to make a non-reentrant function reentrant, it must be replaced by a function with a modified interface. To make a thread-unsafe function thread-safe, only the implementation needs to be changed, usually by adding synchronization blocks.

Non-reentrant functions are not thread-safe. Furthermore, it may be impossible to make a non-reentrant function thread-safe.

[edit] See also

• Referential transparency

[edit] 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.

Retrieved from "http://en.wikipedia.org/wiki/Reentrant"

Category: Articles with example C code