Reentrancy: Difference between revisions
 Yuron [   PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs)m (1 revision imported) |
pc>Yuron No edit summary |
||
| Line 3: | Line 3: | ||
A fragment of code is “reentrant” if it can be executed correctly more than once, simultaneously. | A fragment of code is “reentrant” if it can be executed correctly more than once, simultaneously. | ||
Typically this means that the code uses <strong>only local variables</strong> and | Typically this means that the code uses <strong>only local variables</strong> and has no side-effects on any state visible externally. (A change in external state could be something like changing a file pointer having read in a character, so be careful!) | ||
has no side-effects on any state visible externally. (A change in external state could be something like changing a file pointer having read in a character, so be careful!) | |||
You have probably experienced re-entrant code already, in the form of | You have probably experienced re-entrant code already, in the form of <strong>recursive</strong> code. During recursive execution several copies of the relevant functions may be active, even though there is ever only one | ||
<strong>recursive</strong> code. During recursive execution several copies of the | |||
relevant functions may be active, even though there is ever only one | |||
thread executing. | thread executing. | ||
<blockquote> | <blockquote> | ||
| Line 22: | Line 19: | ||
</div></div> | </div></div> | ||
</blockquote> | </blockquote> | ||
Re-entrancy is often important in operating system routines as (e.g.) | Re-entrancy is often important in operating system routines as (e.g.) the same system call can be made by multiple processes in an indeterminate order. On the other hand, sometimes <em>sections</em> of the code are not re-entrant and therefore need some form of access control. | ||
the same system call can be made by multiple processes in an | |||
indeterminate order. On the other hand, sometimes <em>sections</em> of the | |||
code are not re-entrant and therefore need some form of access control. | |||
<blockquote> | <blockquote> | ||
Always think about cases when variables <em>have</em> to be <em>private</em>. | Always think about cases when variables <em>have</em> to be <em>private</em>. | ||
</blockquote> | </blockquote> | ||
---- | ---- | ||
{{BookChapter|9.3.4|369-371}} | |||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Concepts}} | {{Category|Concepts}} | ||
{{Category|Deadlock}} | {{Category|Deadlock}} | ||
{{Category|Major concepts}} | {{Category|Major concepts}} | ||
Revision as of 10:48, 3 August 2019
| Depends on | Atomicity |
|---|
A fragment of code is “reentrant” if it can be executed correctly more than once, simultaneously.
Typically this means that the code uses only local variables and has no side-effects on any state visible externally. (A change in external state could be something like changing a file pointer having read in a character, so be careful!)
You have probably experienced re-entrant code already, in the form of recursive code. During recursive execution several copies of the relevant functions may be active, even though there is ever only one thread executing.
Puzzle: in the example
fact.c(download it here), is the recursively called ‘factorial()’ function re-entrant code?AnswerAnswer I’d say: “yes”, as the ‘global’ variable is local to this single thread/process.
but
not if the function was used in (for example) a shared library where the values could interfere.
Re-entrancy is often important in operating system routines as (e.g.) the same system call can be made by multiple processes in an indeterminate order. On the other hand, sometimes sections of the code are not re-entrant and therefore need some form of access control.
Always think about cases when variables have to be private.
| Also refer to: | Operating System Concepts, 10th Edition: Chapter 9.3.4, pages 369-371 |
|---|
