Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!BARILVM.BITNET!P85025
From: P85025@BARILVM.BITNET (Doron Shikmoni)
Newsgroups: comp.lang.asm370
Subject: (none)
Message-ID: <8907010023.AA16833@jade.berkeley.edu>
Date: 29 Jun 89 14:44:10 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UCF1VM.bitnet@jade.berkeley.edu>
Distribution: inet
Organization: The Internet
Lines: 50

>A module is reentrant if and only if it does not modify itself. To be
>put into a shared segment, a module must not do any moves or stores into
>itself, because shared segments are write protected.

This definition of reentrancy is invalid and incorrect. It is indeed
the requirement for "program in a DCSS", but this is not reentrancy
(although the latter term is often mixed up with "non-self-modifying
programming").

Two terms can be defined:

1. Reentrancy: The property of a program that can be executed multiple
               times concurrently, that is, the same code in the same
               storage location is executed on behalf of several
               independent processes at independent timings (*no*
               timing constraints imposed). This property is required
               for service routines and shared code, and other routines
               that can be invoked *asynchronously* (this is the buzzword).

               I can definitely write a program that is reentrant while
               updating itself in a *non* trivial manner (i.e., actually
               *changing* itself) - provided I find a mechanism to
               synchronize the modification, like "CS" instruction
               or holding a global resource. This isn't considered
               "proper behaviour", but indeed is possible and will
               be 100% reentrant.

2. Refreshability: The property of a program whose code can be
               "refreshed", that is, restored from auxilliary
               storage (or something like that), at any time.
               such a program does not have to be reentrant; however,
               it must not modify itself, because such modifications
               will be lost (overlayed) when the code is "refreshed",
               without the program's knowledge.
               MVS PLPA is an example for such a case (although programs
               in there will most probably be reentrant too) - progarms
               are never paged out, only in.

The requirement of a DCSS program is mostly that of "refreshable"
(since the segments are shared and can be paged in - and they will not
be paged out). In some cases, when a DCSS area is "modified", CP will
replace the segments with a non-shared copy - but then you lose the whole
idea of a DCSS, don't you.

A DCSS program does not necessarily have to be reentrant (in the sense
defined above). This depends on your application. CMS is (basically)
a single-thread OPSYS, so within one virtual machine, the DCSS program
may choose to be non-reentrant. All according to the application.

Doron