Editing Reentrancy (computing) (section)

==Rules for reentrancy==
;Reentrant code may not hold any static or global non-constant data  without [[Synchronization (computer science)|synchronization]].
:Reentrant functions can work with global data. For example, a reentrant interrupt service routine could grab a piece of hardware status to work with (e.g., serial port read buffer) which is not only global, but volatile. Still, typical use of static variables and global data is not advised, in the sense that, except in sections of code that are [[Synchronization (computer science)|synchronized]], only [[atomic (computer science)|atomic]] [[read-modify-write]] instructions should be used in these variables (it should not be possible for an interrupt or signal to come during the execution of such an instruction). Note that in C, even a read or write is not guaranteed to be atomic; it may be split into several reads or writes.{{r|Preshing (2013)}} The C standard and SUSv3 provide <code>sig_atomic_t</code> for this purpose, although with guarantees only for simple reads and writes, not for incrementing or decrementing.{{sfn|Kerrisk|2010|p=[https://books.google.com/books?id=2SAQAQAAQBAJ&pg=PA428 428]}} More complex atomic operations are available in [[C11 (C standard revision)|C11]], which provides <code>stdatomic.h</code>.
;Reentrant code may not [[self-modifying code|modify itself]] without synchronization.
:The operating system might allow a process to modify its code. There are various reasons for this (e.g., [[blitting]] graphics quickly) but this generally requires synchronization to avoid problems with reentrancy.<!--
 --><p>It may, however, modify itself if it resides in its own unique memory. That is, if each new invocation uses a different physical machine code location where a copy of the original code is made, it will not affect other invocations even if it modifies itself during execution of that particular invocation (thread).</p>
;Reentrant code may not call non-reentrant [[computer program]]s or [[Subroutine|routines]] without synchronization.
:Multiple levels of user, object, or process [[Priority queue|priority]] or [[multiprocessing]] usually complicate the control of reentrant code. It is important to keep track of any access or side effects that are done inside a routine designed to be reentrant.

Reentrancy of a subroutine that operates on operating-system resources or non-local data depends on the [[atomicity (programming)|atomicity]] of the respective operations. For example, if the subroutine modifies a 64-bit global variable on a 32-bit machine, the operation may be split into two 32-bit operations, and thus, if the subroutine is interrupted while executing, and called again from the interrupt handler, the global variable may be in a state where only 32 bits have been updated. The programming language might provide atomicity guarantees for interruption caused by an internal action such as a jump or call. Then the function {{code|f}} in an expression like <code>(global:=1) + (f())</code>, where the order of evaluation of the subexpressions might be arbitrary in a programming language, would see the global variable either set to 1 or to its previous value, but not in an intermediate state where only part has been updated. (The latter can happen in [[C (programming language)|C]], because the expression has no [[sequence point]].) The operating system might provide atomicity guarantees for [[signal (computing)|signals]], such as a system call interrupted by a signal not having a partial effect. The processor hardware might provide atomicity guarantees for [[interrupt]]s, such as interrupted processor instructions not having partial effects.