Scope of Global Objects

The global objects for a connection library consist of all the objects that are visible to the connection library but that are declared outside of the connection block. The rules governing the scope of declarations in ALGOL are discussed under Communication through Global Objects in WFL in Using Global Objects. The same scope rules apply to NEWP programs.

Interprocess Communication and Timing

The use of global objects in connection libraries provides a flexible tool for interprocess communication, with the same advantages previously described for server libraries under Global Objects in Server Libraries. The use of global objects also makes it necessary to consider using events or other such mechanisms to regulate the timing of processes that use a global object.

Global Object Example

Procedures in a connection library can read or change the values of global objects. Any changes are visible to later invocations of the same or different procedures in the same or different connections of that library. The following DMALGOL example includes a connection library procedure PROC1 making changes to the global object GLOBINT:

BEGIN

REAL RSLT;
INTEGER GLOBINT;
EVENT GLOBACCESS;
EBCDIC ARRAY LIBF[0:23];

LIBRARY MCPSUPPORT (LIBACCESS = BYFUNCTION);

REAL PROCEDURE EVENT_STATUS(EV);
     EVENT EV;
     LIBRARY MCPSUPPORT;

DEFINE LOCKOWNERF = [42:39] #; % Lock owner field in EVENT_STATUS result

TYPE CONNECTION BLOCK CL_TYPE;
   BEGIN

   REAL PROCEDURE PROC1;
      BEGIN
      INTEGER TEMPINT;
      PROTECTED EXCEPTION PROCEDURE KLEENUP;
         BEGIN
         IF EVENT_STATUS(GLOBACCESS).LOCKOWNERF = PROCESSID THEN
            BEGIN
            IF TEMPINT = GLOBINT THEN
               GLOBINT:= * + 10;
            LIBERATE (GLOBACCESS);
            END;
         END;
      PROCURE (GLOBACCESS);
      TEMPINT:= GLOBINT;
      GLOBINT:= * + 10;
      PROC1:= GLOBINT;
      KLEENUP;
      END;
   EXPORT PROC1;
   END;

CL_TYPE LIBRARY CL1 (LIBACCESS = BYFUNCTION, FUNCTIONNAME = “TESTF.”,
                     CONNECTIONS=2);

GLOBINT:= 0;
REPLACE LIBF BY “LIB0.”;
RSLT:= LINKLIBRARY(CL1[0], INTERFACENAME = LIBF);
REPLACE LIBF BY “LIB1.”;
RSLT:= LINKLIBRARY(CL1[1], INTERFACENAME = LIBF);

END.

Explanation of Example: GLOBINT

This library links to two matching libraries. Each time either matching library invokes procedure PROC1, the procedure increments the value of GLOBINT by 10.

The current value of GLOBINT is therefore available to three different processes: the connection library program that declares GLOBINT and the two other connection library processes that link to library CL1. The event GLOBACCESS is used to ensure that no two processes perform conflicting, simultaneous updates or interrogations of GLOBINT.

Explanation of Example: KLEENUP Procedure

Procedure PROC1 includes a protected EXCEPTION procedure called KLEENUP. The purpose of KLEENUP is to make sure that the event GLOBACCESS is liberated, and GLOBINT is updated, if a process is discontinued while executing PROC1. Protected EXCEPTION procedures are the most reliable technique for performing such cleanup work, because the PROTECTED clause prevents the procedure from being discontinued. However, the PROTECTED clause is available only in DMALGOL and NEWP. For information about this use of EXCEPTION procedures, refer to Using EPILOG and EXCEPTION Procedures in Using Events and Interlocks.

Explanation of Example: EVENT_STATUS

The KLEENUP procedure itself invokes an MCP library procedure called EVENT_STATUS. The purpose of this call is to determine whether PROC1 had succeeded in procuring the event GLOBACCESS before being discontinued. KLEENUP liberates GLOBACCESS only if EVENT_STATUS indicates that the current process has already succeeded in procuring the event.