🚀 go-pugleaf

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
>