🚀 go-pugleaf

The foldoc definition does not mention a module not changing it's own
memory, even though that's usually the way it's implemented.  But it
does not preclude having a Compare and Swapped counter within itself.
As you point out, rentrancy does not mean the same "answer" is returned
each time.  The refreshability of the module, the fact that at any point
in its execution it may be replaced by an original copy with no change
in the validity of the results for that instantiation, precludes
changing its own memory.  But, in many IBM usages (like CICS),
reentrancy assumes refreshability.

Gary Weinhold

"David P. de Jongh" wrote:
>
> From FOLDOC (www.foldoc.org)
>  re-entrant
>  <programming> Used to describe code which can have
>     multiple simultaneous, interleaved, or nested invocations
>     which will not interfere with each other.   This is
>     important for parallel processing, recursive functions or
>     subroutines, and interrupt handling.
>
>         It is usually easy to arrange for multiple
>     invocations (e.g. calls to a subroutine) to share one
>     copy of the code and any read-only data but, for the code
>     to be re-entrant, each invocation must use its own copy
>     of any modifiable data (or synchronised access to shared
>     data). This is most often achieved using a stack and
>     allocating local variables in a new stack frame for each
>     invocation. Alternatively, the caller may pass in a
>     pointer to a block of memory which that invocation can
>     use (usually for outputting the result) or the code may
>     allocate some memory on a heap, especially if the data
>     must survive after the routine returns.
>
>         Re-entrant code is often found in system software,
>     such as operating systems and teleprocessing monitors. It
>     is also a crucial component of multithreaded programs
>     where the term "thread-safe" is often used instead of
>     "re-entrant".
>
>     (1996-12-21)
>
> The term "thread-safe" is the preferred usage for what most of us think of
> as re-entrant (i.e. code that does not modify its own program storage), as
> this is a requirement for CICS programs running in protected storage.
>
> Getting the same results each time is not solely a function of re-entrancy.
> If, for example, I have a re-entrant subroutine that gets the system time,
> it will always return a different answer if it is using the STCKE
> instruction, regardless of how many threads are accessing it simultaneously.
>
> If you have a global resource that is sensitive to asynchronous updating,
> you will have to protect it with an ENQ, or some other locking device.
>
> D de J
>
> -----Original Message-----
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of McKown, John
> Sent: Tuesday, September 20, 2005 3:26 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: IEANTRT troubles
>
> Well, if we're going to discuss "what is reentrant", then I'll put in
> the way that it was explained to me.
>
> 1) it is reentrant if the answer remains the same regardless of how many
> instruction streams are within the module during a given interval. This
> includes multiple CPUs executing the code in parallel, or one CPU
> running the module for multiple users due to task switching.
>
> The above defination says nothing about the module's "immutability"
> (unchangable). In fact, a module can be "immutable" and still not
> reentrant. Think of a time-sharing system with a "short tick". Your
> program fetches a value from a global data area and changes it in a
> register. It then calculates PI to 300 decimal places (guaranteeing
> multiple task switches). The program then stores the register value back
> into the global data area. If another user had invoked your routine
> during this interval, then it is very likely that the global data area
> has lost some updates. Even though the module itself is "immutable".
>
> 2) In the very old days of VS1, all transient SVCs (type 3 and 4) had to
> be truly immutable because they were all loaded into the same memory
> area (IIRC, it was called the SVC Transient Area). These routines were
> not just marked RENT, they were also REFR. Also, IIRC, way back in that
> day, VS1 could reload REFR modules in the case of a page frame going
> bad. The recovery logic would look at the status of the bad frame. If it
> was not modified and it existed on the paging system (which meant the
> frame data and the aux data would be identical), it would assign a new
> frame and page the data back into the new frame. If the frame was not
> modified, did not exist on AUX, but contained data from a REFR module
> (loaded from the link list?), VS1 could reload the contents of the page
> to a new frame from the original module on disk. This is a very vague
> memory.
>
> --
> John McKown
> Senior Systems Programmer
> UICI Insurance Center
> Information Technology
>
> This message (including any attachments) contains confidential
> information intended for a specific individual and purpose, and its'
> content is protected by law.  If you are not the intended recipient, you
> should delete this message and are hereby notified that any disclosure,
> copying, or distribution of this transmission, or taking any action
> based on it, is strictly prohibited.
>
> > -----Original Message-----
> > From: IBM Mainframe Assembler List
> > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Baron Carter
> > Sent: Tuesday, September 20, 2005 3:02 PM
> > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> > Subject: Re: IEANTRT troubles
> >
> >
> > Sort of reminds of the STOP sign:
> >
> > At a STOP Sign you are required to come to a 'complete stop'.
> >
> > Is there any other sort of Stop?  :-)
> >
> >
> > Baron Carter
> > Rocket Software, Inc
> > Austin, TX
> >
> > +1 (512) 275-3957 - work
> > +1 (512) 587-8903 - cell
> > +1 (617) 630-7157 - fax
> >
> > -----Original Message-----
> > From: IBM Mainframe Assembler List
> > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Gary Weinhold
> > Sent: Tuesday, 20 September, 2005 14:29
> > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> > Subject: Re: IEANTRT troubles
> >
> > One of our developers had the concept of "mostly reentrant",
> > which lead
> > to an interesting discussion of the theoretical (if not
> > implementational) difference between reentrancy and
> > refreshability.  He
> > used the term paene-reentrant to define a program that
> > modified itself,
> > but did it in a way that the modification was exactly the
> > same no matter
> > which execution instance modified it.  (It was a pointer to a common
> > memory block, set by the first execution instance to compare
> > and swap it
> > from zeros to an address).
> >
> > Gary Weinhold
> > Data Kinetics, Ltd.
> >
> > Ray Mullins wrote:
> > >
> > > > -----Original Message-----
> > > > From: IBM Mainframe Assembler List
> > > > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Craddock,
> > Chris
> > > > Sent: Tuesday September 20 2005 07:48
> > > >
> > > > Reentrancy, like pregnancy, is an all or nothing deal.
> > >
> > > BWAH!
> > >
> > > Can I file that for future reference, Chris?  I guess the corollary
> > would be
> > > that you just can't be a little bit reentrant.
> > >
> > > Later,
> > > Ray
> >