Editing Reentrancy (computing) (section)

{{short description|Concept in computer programming}}
{{Use dmy dates|date=March 2020|cs1-dates=y}}

'''Reentrancy''' is a programming concept where a function or subroutine can be interrupted and then resumed before it finishes executing. This means that the function can be called again before it completes its previous execution. Reentrant code is designed to be safe and predictable when multiple instances of the same function are called simultaneously or in quick succession. A [[computer program]] or [[subroutine]] is called reentrant if multiple invocations can safely run [[Concurrent computing|concurrently]] on [[Multiprocessing|multiple processors]], or if on a [[Uniprocessor system|single-processor system]] its [[Execution (computing)|execution]] can be [[interrupt]]ed and a new execution of it can be safely started (it can be "re-entered"). The interruption could be caused by an internal action such as a [[Branch (computer science)|jump]] or call (which might be a [[Recursion (computer science)|recursive]] call; reentering a function is a generalization of recursion), or by an external action such as an interrupt or [[signal (computing)|signal]]. 

This definition originates from [[multiprogramming]] environments, where multiple processes may be active concurrently and where the flow of control could be interrupted by an interrupt and transferred to an [[interrupt service routine]] (ISR) or "handler" subroutine. Any subroutine used by the handler that could potentially have been executing when the interrupt was triggered should be reentrant. Similarly, code shared by two processors accessing shared data should be reentrant. Often, subroutines accessible via the operating system [[kernel (operating system)|kernel]] are not reentrant. Hence, interrupt service routines are limited in the actions they can perform; for instance, they are usually restricted from accessing the [[file system]] and sometimes even from [[Memory management|allocating memory]].

Reentrancy is neither necessary nor sufficient for [[thread-safety]] in multi-threaded environments. In other words, a reentrant subroutine can be thread-safe,{{sfn|Kerrisk|2010|p=[https://books.google.com/books?id=2SAQAQAAQBAJ&pg=PA657 657]}} but is not guaranteed to be.<ref>{{cite web |title=Writing reentrant and threadsafe code |url=https://www.ibm.com/docs/en/aix/7.2.0?topic=programming-writing-reentrant-threadsafe-code |website=Programming for AIX |publisher=IBM |access-date=12 May 2025}}</ref> Conversely, thread-safe code need not be reentrant (see below for examples).

Other terms used for reentrant programs include "sharable code".{{sfn|Ralston|2000|p=1514–1515}} Reentrant subroutines are sometimes marked in reference material as being "signal safe".<ref>{{cite web |title=pthread_cond_init()--Initialize Condition Variable |url=https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_74/apis/users_75.htm |website=IBM Knowledge Center |access-date=5 October 2019}}</ref> Reentrant programs are often{{efn|A program that serializes self-modification may be reentrant, and a pure procedure that updates global data without proper serialization may fail to be reentrant.}} "pure procedures".