reentrancy vs thread safety
Ad van Gestel
Can someone tell me what the exact difference is between
reentrancy and thread safety. The Solaris Multithreading guide
gives the following definitions of each.
I quote:
"A procedure is thread safe when it is logically correct when
executed simultaneously by several threads"
"A reentrant function is one that behaves correctly if it is called
simultaneously by several threads"
I am totally confused.
Thanks
Douglas C. Schmidt
In article <342d24cf...@news.scruznet.com>,
Gilbert W Pilz, Jr. <gwp...@pobox.com> wrote:
++ A routine that is thread safe is almost certainly re-entrant.
This doesn't necessarily follow. For instance, implementations of
malloc()/free() in multi-threaded operating systems are commonly
thread-safe, but are often non-reentrant (i.e., they don't protect
against corruption of internal data structures due to asynchronous
signals).
Doug
--
Dr. Douglas C. Schmidt (sch...@cs.wustl.edu)
Department of Computer Science, Washington University
St. Louis, MO 63130. Work #: (314) 935-4215; FAX #: (314) 935-7302
http://www.cs.wustl.edu/~schmidt/
Gilbert W Pilz, Jr.
On Thu, 25 Sep 1997 13:16:23 +0200, Ad van Gestel <adg...@win.tue.nl>
wrote:
>Can someone tell me what the exact difference is between
>reentrancy and thread safety. The Solaris Multithreading guide
>gives the following definitions of each.
This gets into semantics so everyone has their own take on the meaning
of these terms. Here's mine:
Re-entrancy means just what it sounds like; it is safe to re-enter the
procedure before it has returned from the first time you called it.
Procedure A is re-entrant if A--calls-->B--calls-->A doesn't break
things because A was in the middle of something when it called B. You
don't need the presence of threads to have problems with re-entrancy
In addition to nested calls, things like signal handlers,
setjmp/longjmp etc. can raise re-entrancy issues.
Thread safety just means that the routine can be called
"simultaneously" by multiple threads without causing any problems.
Thread safety and re-entrancy are related because having a routine
called by one thread while another is executing that same routine is
*similar* to having a single thread re-enter a routine after having
partially executed that routine at some point in the past.
Thread safety is a stronger requirement than re-entrancy because
re-entrancy does not involve the sort of timing problems that multiple
threads bring about; no matter how many times you re-enter a procedure
the order of execution is serial.
A routine that is thread safe is almost certainly re-entrant. A
routine that is not re-entrant is almost certainly not thread-safe. A
routine that is re-entrant may or may not be thread-safe.
Gilbert W. Pilz Jr.
Systems Software Consultant
gwp...@pobox.com
Casper H.S. Dik - Network Security Engineer
[[ Reply by email or post, don't do both ]]
gwp...@pobox.com (Gilbert W Pilz, Jr.) writes:
>Thread safety is a stronger requirement than re-entrancy because
>re-entrancy does not involve the sort of timing problems that multiple
>threads bring about; no matter how many times you re-enter a procedure
>the order of execution is serial.
I think it';s the otehr way around; re-rentrancy means that it doesn't have
side effects, shared state, whatever. It doesn't needs to protect anything
with a lock. A routine that is re-entrant is thread-safe.
A thread-safe routine doens't need to be reentrant; e.g., it may not
be able to call itself (like malloc() can't call malloc() if it holds
the arena lock).
So a thread safe-function can be called conncurrently, but the actual work
may be serialized because of a lock on global state.
Re-entrancy, on the other hand, has a mathematical definition which enables
calling it at anytime from anywhere.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.