Editing Reentrancy (computing) (section)

==Further examples==
In the following code, neither <code>f</code> nor <code>g</code> functions is reentrant.

<syntaxhighlight lang="c">
int v = 1;

int f()
{
    v += 2;
    return v;
}

int g()
{
    return f() + 2;
}
</syntaxhighlight>

In the above, {{code|f()}} depends on a non-constant global variable {{code|v}}; thus, if {{code|f()}} is interrupted during execution by an ISR which modifies {{code|v}}, then reentry into {{code|f()}} will return the wrong value of {{code|v}}. The value of {{code|v}} and, therefore, the return value of {{code|f}}, cannot be predicted with confidence: they will vary depending on whether an interrupt modified {{code|v}} during {{code|f}}'s execution. Hence, {{code|f}} is not reentrant. Neither is {{code|g}}, because it calls {{code|f}}, which is not reentrant.

These slightly altered versions ''are'' reentrant:

<syntaxhighlight lang="c">
int f(int i)
{
    return i + 2;
}

int g(int i)
{
    return f(i) + 2;
}
</syntaxhighlight>

In the following, the function is thread-safe, but not (necessarily) reentrant:

<syntaxhighlight lang="c">
int function()
{
    mutex_lock();

    // ...
    // function body
    // ...

    mutex_unlock();
}
</syntaxhighlight>

In the above, {{code|function()}} can be called by different threads without any problem. But, if the function is used in a reentrant interrupt handler and a second interrupt arises inside the function, the second routine will hang forever. As interrupt servicing can disable other interrupts, the whole system could suffer.