Re: Reentrancy
Doug Harrison [MVP] wrote:
On Fri, 10 Apr 2009 00:45:56 +0300, "K?rsat" <kursattheking@gmail.com>
wrote:
I suspect that I does'nt comprehend reentrancy, thread safety and
their relation. Would you please explain briefly?
As I think of it, "reentrancy" describes a function that can be
called in a nested way within a single thread, due to direct or
indirect recursion, such that a nested function call doesn't corrupt
any data being used by an antecedent function call. The term "thread
safety" describes a function that won't corrupt data when called
simultaneously by multiple threads; usually this involves the use of
a mutex to protect the data. Reentrancy sort of comes from the
inside, in the sense that a reentrant function F calls some other
function that causes F to be called recursively. OTOH, the issue of
thread safety arises due to outside factors, namely, multiple threads
calling the same function simultaneously.
Also, different environments may have synchronous or asynchronous signal
handling. With synchronous signal handling, like on Windows, only functions
that call user-defined callbacks have to be designed for re-entrancy. With
asynchronous signal handling, like Unix, a signal can arrive at anytime and
a signal handler can start executing almost anywhere, so even if your
function does not call any callbacks, it still needs to be concerned with
re-entrancy. asctime is a classic example -- it is not re-entrant, but on
Windows this is never a problem, because there's no way to re-enter it. On
Unix, you'd better avoid calling asctime from inside a signal handler
because it might have been running when the signal arrived.
Of course, your callback/signal handler has to also not make assumptions
about the state of global variables... who knows what piece of code was
running when the signal came in. Doing any operation on a global variable
from inside a callback or signal handler needs to be done with extreme care,
whether it is passing its address to a function or even just incrementing,
it could mess up functions further down the call stack. Especially in an
environment with asynchronous signal handling, where the suspended code has
absolutely no way to know when/where it will be interrupted.