Using Isolated Procedures in Libraries

The ISOLATED procedure attribute specifies that when an isolated procedure runs on a different stack than the stack that declared the procedure, the isolated procedure should be protected from DS (Discontinue) and ST (Stop) actions applied to the second stack.

A DS of the stack that declares a procedure results in a DS of all stacks running its procedures, including its ISOLATED procedures.

The “stack that declared the procedure” is the task or library that was started when the code file containing the procedure code was initiated. For example, for library procedures, the stack that declared the procedure is the library stack.

When an isolated procedure is running on a stack other than its own stack and that stack is DSed or STed, the second stack is DSed or STed below the isolated stack frame or frames. If those frames continue to run for five seconds of CPU time after a DS operation, a message is displayed indicating that the DS operation has been delayed while running “isolated” code from a specified task. If those frames continue to run for five seconds of CPU time on a STed stack, the ST operation takes effect as if ISOLATED was not specified, and a message is displayed describing the situation. If those frames continue to run for five seconds of CPU time on a resource DSed stack, an RSVP allows the operator to use the OK command to override the resource limit and indicates that the alternative is to terminate the task that owns the “isolated” environment.

Thus, a library or other IPC program that uses ISOLATED can assume that the ISOLATED procedures will not be interrupted by DS actions when running on other stacks. In addition, the ISOLATED procedures will not be delayed by ST commands, provided that those procedures do not consume more than 5 seconds of CPU time before exiting.

If an ISOLATED procedure fails to exit cleanly while running on a stack other than the stack that declared it, the stack that declared it is DSed. Failure to exit cleanly includes such events as

  • Fatal errors in the ISOLATED procedure or in procedures invoked above the ISOLATED procedure

  • A GO TO statement that cuts back the stack environment of the ISOLATED procedure.

When a stack is running ISOLATED code from another stack, asynchronous actions such as software interrupts, signals, approval and change procedures, and so on, are delayed until the ISOLATED code exits. (If this restriction were not enforced, a software interrupt or other asynchronous action could do a GO TO that would cut back the stack environment of the ISOLATED procedure. The stack could also take actions that lock or locks held by the ISOLATED procedure were designed to prevent. In either case, invariants that make the ISOLATED procedure work correctly could be violated.)

Note: Software interrupts declared within ISOLATED procedures or declared within procedures invoked above ISOLATED procedures will never run.)

When a stack is running ISOLATED code from another stack, stack stretch up to the limits imposed by the hardware is permitted—assuming that the hardware limit is not reached—and a DS action for stack overflow is postponed until the ISOLATED code exits.

A library or IPC program that uses ISOLATED procedures and that uses waits and/or locking can use DSABLE waits and DSABLE interlocks—such that the wait or lock attempt will terminate and return a DSed indication on DS. When such an indication is returned, the code should cleanly terminate the operation and exit the procedure.

When running in an ISOLATED procedure (or in a non-ISOLATED procedure invoked above an ISOLATED procedure) on a DSed stack different than the stack that declared the ISOLATED procedure, most system interfaces continue to function as if the stack had not been DSed. For example, files can be opened, read, written, and so on, with the following exceptions:

  • Any RSVP situation that normally lists DS as an acceptable reply will take the DS action. For example, an attempt to open a nonexistent file produces an open result of DSEDINFINDV. This result is documented as meaning “An open attempt by a non-discontinuable task was discontinued (DS system command) while trying to find the file.”

  • DSABLE WAIT and LOCK statements will terminate immediately and return a DSed message, except in the following situation:

    Wait on time only (WHEN in ALGOL; WAIT(<arithmetic expression>) in NEWP) will be interrupted when the DS command is entered but will be performed if begun after the DS operation. This is true whether or not DSABLE is specified. (To get fully DSABLE or non-DSABEL wait on time, use WAIT[DSABLE](<arithmetic expression>,E) or WAIT(<arithmetic expression>,E), where E is an EVENT which is never caused.)

    When a stack is running an ISOLATED procedure on a stack other than the stack that declared the procedure, the ISOLATED semantics apply to that stack until that procedure exits or the task or library that declared the procedure is DSed. Thus, when such an ISOLATED procedure invokes a non-ISOLATED procedure, the non-ISOLATED procedure experiences ISOLATED semantics. This is true regardless of how many ISOLATED or non-ISOLATED procedures, or both, are invoked above the first ISOLATED procedure.

    When a stack is running multiple ISOLATED procedures declared by multiple different stacks, the ISOLATED semantics apply down to the lowest of the stack frames of an ISOLATED procedure from a task or library that has not been DSed.

    An ISOLATED procedure can cause some system operations (for example, DS and ST) to be delayed. Therefore, code an isolated procedure so that the procedure runs quickly and efficiently and does not consume excessive system resources.

    It is anticipated that ISOLATED will usually be used in the context of shared libraries that have global data protected by locking mechanisms. However, ISOLATED can be used in any situation where procedure or procedures from one stack run on another stack or stacks.

Example of an Isolated Procedure

The following library stores configuration data, updating it and searching it in response to invocations of its exported procedures. The INTERLOCK and ISOLATED procedures are used to ensure that updates and searches do not overlap, that partial updates to the configuration data never occur, and that the INTERLOCK is never left locked, even if client tasks are DSed while running procedures from the library. 

$ SHARING = SHAREDBYALL
BEGIN
	<global configuration data declarations>
	INTERLOCK CONFIG_LOCK;

	PROCEDURE UPDATE_CONFIG(<parameters>);
	BEGIN
		<local configuration data declarations>

		PROCEDURE UPDATE_GLOBAL;
		BEGIN [ISOLATED]
			LOCK(CONFIG_LOCK);
			<copy from local configuration data to
			global configuration data>
			UNLOCK(CONFIG_LOCK);
		END UPDATE_GLOBAL;

		<build local configuration, using
		parameters, data from files, etc.>
		UPDATE_GLOBAL;
END UPDATE_CONFIG;

	PROCEDURE SEARCH_CONFIG(<parameters>);
	BEGIN [ISOLATED]
		LOCK(CONFIG_LOCK);
		<using data from parameters,
		search global configuration data>
		<store results of search in other parameters>
		UNLOCK(CONFIG_LOCK);
END SEARCH_CONFIG;

EXPORT UPDATE_CONFIG, SEARCH_CONFIG;

FREEZE(PERMANENT);

END
Prev  Up  Next
Process Stacks  Home  Library Task Attributes