From: crawford@boole.mitre.org (Randy Crawford)
Subject: Re: reentrant code
Organization: The MITRE Corporation, McLean, VA
Date: Sun, 13 Dec 1992 05:16:34 GMT

In article <dak.724201089@messua> dak@messua.informatik.rwth-aachen.de (David Kastrup) writes:
>crawford@boole.mitre.org (Randy Crawford) writes:
>
>>In article <GARY.92Dec9104702@kuwait.gdfwc3> gdfwc3!gary@uunet.uu.net writes:
>>>What are the requirements for code to be reentrant?  When can
>>>non-reentrant code hurt you?  Can someone recommend a good reference
>>>on this subject?
>
>>Reentrant code must allow more than one task to concurrently execute the
>>same instructions in the same memory space.  If one thread of execution makes 
>>use of data which is the same data used by another thread, a possibility 
>>exists for one thread to overwrite the data written by the other.  [...] 

>The problems of reentrancy are a bit different from concurrency. 

True, but reentrancy is irrelevant unless concurrency in some form (like
context switching) is involved.

>Reentrancy
>may be a subject in system programming, because any subroutine an
>interrupt routine uses must work without disturbing an instance of
>the routine active before the interrupt. You can do that by saving all
>variables on some stack, restoring them afterward. Z80 Versions of Turbo
>Pascal did just that with local variables, because variables on the
>stack were not especially supported by the processor.a

Certainly reentrancy does not require that you save all variables on the 
stack, but I believe that is generally how it is managed today in most OSs
and PLs.

>
>This technique is still there in interrupt routines saving all REGISTERS
>they might use.
>
>Note that this reentrancy scheme works fine with interrupts as well as
>with recursions, with the latter NOT if you pass any variables of the
>recursion by reference.

To each iteration of a function, reference arguments _are_ global variables.

>
>It does not work with concurrency.

I did not mean to equate concurrency with reentrancy, but to point out that
reentrancy is inextricably linked with some form of concurrency, otherwise
reentrancy is unnecessary to protect data vulnerable to the form of
`concurrnncy' known as context switching.

>
>Reentrancy is also not merely a hidden OS-matter, at least not in Unix,
>because signal handlers may not use nonreentrant routines they might
>have interrupted.

A signal handler is meaningful only as a form of context switch, and is 
solely an OS matter.  That the PL allows you to write callback routines
for the OS doesn't make them separate from the OS -- they simply extend it.

>
>And the sticky bit is an entirely different thing. In older versions of
>Unix, it told the system that execution of a program was likely to
>occur that often, that the system better keep a copy of the program
>in the swap area. Note that in this blissful old time, EVERY program
>was allocated in the swap area. So the fork() system call was pretty
>simple: it swapped the process, but did not invalidate the copy in core.

In principle, I agree that the sticky bit differs from reentrancy, and that
its original use is effectively obsolete, given the evolution of VM in Unix.  
But in practice, I suspect that those who still program for it have come to 
employ it in lieu of shared libraries.  (Yes, this is hypothetical.  I've 
yet to hear of anyone write code to use the sticky bit.)  Shared libraries 
are necessarily reentrant (to be at all reliable), and there's no reason
that a program couldn't be designed to use its sticky bit to avail the 
system of a suite of resident reentrant services if that OS does not support 
shared libraries.

>
>I cannot rule out all possibility that this copy might have had an
>already altered
>data area, and so the programs with sticky bit would have to be reentrant
>on systems not supporting shared text. But I believe in the sanity of
>the early Unix system designers.
>
>By the way, concurrency or multithreadability is important for shared
>libraries.

Agreed, on both counts.
-- 

| Randy Crawford        crawford@mitre.org        The MITRE Corporation
|                                                 7525 Colshire Dr., MS Z421
| N=1 -> P=NP           703 883-7940              McLean, VA  22102