For other uses of the term, see 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:

  • 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 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.

Contents

[edit] 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 f() + 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)
{
  return i + 2;
}

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

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

[edit] See also

[edit] External links

http://www.ibm.com/developerworks/linux/library/l-reent.html