Re-entrant vs.Thread-Safe
sparky
Can a method/function be re-entrant but not thread-safe ?
Can a method/function be thread-safe but not re-enrtrant ?
Examples would be appreciated (C/C++ for Win32). Thanks in advance.
Patrick TJ McPhee
% Please help me to clarify the terms re-entrant and thread-safe.
This definition is not formally correct, since re-entrancy isn't strictly
a thread-related concept, but here goes:
Re-entrant means that at any time while a thread is executing a
function, you can stop the thread, then start executing the same
function in another thread and the second thread will always run to
completion without having to start the original thread again.
In a re-entrant function, there is no use of shared data or resources.
All data is passed through arguments and return codes. Re-entrancy is
good because it increases concurrency (plus re-entrant functions can
be called recursively, which some people like, and they can be used
in signal handlers, which other people like, and you can cancel
them asyncrhonously, which I'm sure other people will like), but it
can make the function interfaces more complicated.
Thread-safe means that you can execute the function in two threads
concurrently, and the function will take care of any synchronisation
issues.
% Can a method/function be re-entrant but not thread-safe ?
No. However, you can use a re-entrant function in a way which isn't
thread-safe. For instance, suppose x is a global variable, and y()
is a re-entrant function, then if I have two threads, each of which
has this call:
y(&x);
then this use of y() is not thread-safe (not because of the function,
but because of the argument). (Actually, any thread-safe function which
takes arguments by reference can be used in a way that isn't thread-safe.)
% Can a method/function be thread-safe but not re-enrtrant ?
Yes. Any function which protects shared data with a mutex is not re-entrant.
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
Ziv Caspi
[...]
> % Can a method/function be re-entrant but not thread-safe ?
>
> No. However, you can use a re-entrant function in a way which isn't
> thread-safe. For instance, suppose x is a global variable, and y()
> is a re-entrant function, then if I have two threads, each of which
> has this call:
> y(&x);
> then this use of y() is not thread-safe (not because of the function,
> but because of the argument). (Actually, any thread-safe function which
> takes arguments by reference can be used in a way that isn't thread-safe.)
>
A simple variation of your example shows that the answer is actually
"yes". Here is a contrived example:
void f()
{
static int guard = 0;
int a = guard;
a = a + 10;
guard = a;
//.....
if ( ... )
f(); // Here f() is re-entered
//....
a = guard; a = a - 10; guard = a;
}
f() is not thread-safe (because the way is accesses guard - a shared
resource). However, it *is* re-entrant - the recursive call to f()
in locations where f() can be interrupted, simply because of the
way it is structured. (Had the call to f() been between reading
guard and writing it, it might not have been re-entrant.)
--------------------------------
Ziv Caspi
zi...@netvision.net.il
Patrick TJ McPhee
Ziv Caspi <zi...@netvision.net.il> wrote:
% pt...@interlog.com (Patrick TJ McPhee) wrote:
%
% [...]
% > % Can a method/function be re-entrant but not thread-safe ?
% > No. However, you can use a re-entrant function in a way which isn't
% A simple variation of your example shows that the answer is actually
% "yes". Here is a contrived example:
%
% void f()
% {
% static int guard = 0;
^^^^^ the function is not re-entrant because it uses this
% f() is not thread-safe (because the way is accesses guard - a shared
And it is not re-entrant. A re-entrant function can be restarted at any
point without failing and without re-setting its state. f() cannot.
You may dispute my definition, if you like, but there's really no point
talking about re-entrancy at all if f() is a re-entrant function, since
none of the things that make re-entrant functions useful is true of
this function.
Ziv Caspi
> A re-entrant function can be restarted at any
> point without failing and without re-setting its state. f() cannot.
> You may dispute my definition, if you like, but there's really no point
> talking about re-entrancy at all if f() is a re-entrant function, since
> none of the things that make re-entrant functions useful is true of
> this function.
We seem to be using two different definitions of re-entrancy. The one
I favor, unlike yours, is "orthogonal" to the definition of
thread-safety.
I usually avoid all debates on terminology (well, as soon as I recognise
it as one). In this particular case, however, I'd like to point out that
there is at least one very common example in which "my" definition of
re-entrancy has a strong point - In writing a WndProc (in Win32), one
should always make sure that one's WndProc is re-entrant if one intends
to call Win32 functions, because Windows may then call the WndProc
recursively. This is an example of being re-entrant (using my definition)
but usually not being thread-safe.
--------------------------------
Ziv Caspi
zi...@netvision.net.il
Zeke
The term reentrancy is overloaded. In the multithreaded universe
it means thread-safe. In the OS universe, it means non-selfmodifiing
code.
Now, the example of WndProc below, I believe it is covered by the
term idempotent.
Well, hope that's clear as mud.
:^)
Ziv Caspi
> Let me really muddy the waters.
>
> The term reentrancy is overloaded. In the multithreaded universe
> it means thread-safe. In the OS universe, it means non-selfmodifiing
> code.
>
> Now, the example of WndProc below, I believe it is covered by the
> term idempotent.
>
> Well, hope that's clear as mud.
>
> :^)
>
From the (little) I remember of mathematics, an idempotent function f
is one for which f() and f(f()) are the same. In my example, on the other
hand, the second activation of the function *does* have an effect.
--------------------------------
Ziv Caspi
zi...@netvision.net.il