Reentrant Function

What we mean by reentrancy and reentrant function? What is it’s significance in programming? What are the conditions that a function to be reentrant?

Reentrancy is applicable in concurrent programming. Cooperative scheduling need not to consider reentrancy. Prior to discussing on reentrant functions, we need to understand few keywords. Read atomicity and critical section posts.

If one thread tries to change the value of shared data at the same time as another thread tries to read the value, the result is not predictable. We call it as race condition.

A reentrant function guarantees it’s functionality even when the function is invoked (reentered) from concurrent multiple threads. If the function is using variables with static extent, the results will be unpredictable because of race conditions. A library developer need to care in writing reentrant code. Sometimes the bug lies in the library rather than programmer’s code. It is not easy to recreate such bugs during fix.

A Reentrant Function shall satisfy the following conditions,

  1. Should not call another non-reentrant function
  2. Should not access static life time variables (static/extern)
  3. Should not include self modifying code

Thread safety and Reentrant functions

Thread safety and reentrant functions are connected. Every thread safe function is reentrant, but the converse need not be true. A thread safe function can be called from multiple threads even when the function accessing shared data. A thread safe function is guaranteed to serialize accessing any shared data.

An example is string class (C++). Most implementations of string class are reentrant but not thread safe. One can create different instances of string class across multiple threads, but can’t access same instance atomically from multiple threads. For more details of string class see QString.

Reentrancy is key while writing critical sections, signal handlers, interrupt service routines, etc…

Reentrant Function vs Functions with Reentrancy:

The above statement may look strange. There are different memory models of processors. Some architectures use a common set of memory locations to pass arguments to functions. In such case the functions can’t maintain reentrancy when invoked multiple times.  Code development for such processors must qualify the function prototype with compiler provided keywords to ensure reentrancy.

Article compiled by Venki. Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above.

Writing code in comment? Please use, generate link and share the link here.

  • Vasant

    I came to this article to get more clarity on the concept after reading articles about this on other forums..The following statement is WRONG.”Every thread safe function is reentrant, but the converse need not be true.” I stopped reading the article here itself.

  • da3m0n
  • dwaijam

    This article should be taken down as it might teach wrong things to a new enthusiast

    • Kartik

      Could you specify what concepts are wrong in the article?

  • Someone

    “Reentrancy is applicable in concurrent programming. Cooperative scheduling need not to consider reentrancy.” – This is completely wrong! “Every thread safe function is reentrant” – this is completely wrong too! You don’t seem to understand the concept of reentrant functions yourself. You could at least have read the wikipedia page about reentrancy before writing such a misleading article.

  • Sreekanth Muralidharan

    To make it simple. Think of a C library function printf. When printf accesses your terminal to print the characters. Now say, process A runs a printf statement and it reached line 5 of printf function.(line 5 in source of printf in C library). Now consider that another process, B issues a printf at the time when A reached line 5. The context for printf for B should be from line 1, NOT from line 5. This is the case of a reentrant function, which maintains its state of execution, in multiple processes or thread. Correct me, if anything went wrong here.

  • Liviu

    Here is an example of a function that is thread-safe and not reentrant, thus not every thread-safe function is also re-entrant.
    See also discussion.

  • shashank

    A subroutine that is directly or indirectly recursive should be reentrant..why plz exsplain

    • Venki

      @shashank, the question is not clear to me. Are you considering assembly programming? A subroutine (function) should be reentrant when invoked by concurrent threads, irrespective of recursive or not.

      If it from assembly perspective, the programmer would need to take care of saving argument registers (based on processor architecture) on every recursive invocation of the routine.

      Let me know if I am missing to learn something.

  • Venki

    @Shekhu, I don’t think any relation between reentrant function and recursive function. Reentrant function deals about data consistency across multiple threads where as recursion is design technique.

    Reentrant function builds on stack of thread. If we are sure that recursive function is reentrant, it can be called by multiple threads, since each thread will have its own stack.

  • Shekhu

    Is there any relation between reenterant and recursive functions?