Resolving the Contention Problem with ASSIGN/DEFINE

Many sites have processes that modify logical names in shared logical name tables, e.g., LNM$GROUP, LNM$JOB, LNM$SYSTEM, and LNM$SYSTEM_DIRECTORY.

Parallel modification can happen through multiple subprocesses, overlapping batch jobs, and/or multiprocessors. Modifying shared logical names from simultaneous processes produces unpredictable results, see below.

What is the value of job logical name FRED? It depends. Which ASSIGN statement executed first. Did the execution of the F$TRNLNM lexical functions overlap? If Process 1 and Process 2 are executing simultaneously, the answer is unknowable. If instead of constant values, the processes are modifying the contents, e.g., inserting an element in a search list, as in the example above, the results are unpredictable. One update may override the other, or they could execute serially in any sequence, resulting in both updates. At the end, FRED may have a value of:

• "ABC,XXX"
• "ABC,YYY"
• "ABC,XXX,YYY"
• "ABC,YYY,XXX"

Such unpredictability does not lead to reliable, or reproducible outcomes.

There is no short-term fix short of single-thread execution. The problem is not code maintained by the local organization. Rather, the problem most commonly involves multiple third-party maintained software packages. What is needed to ensure safety is a new feature to the $CRELNM system service, its gateways, and the ASSIGN/DEFINE DCL commands.

Presently, there is no provision for ensuring the safety of logical name modification when multiple processes attempt to modify a logical name contained within a shared logical name table This shortcoming compromises the integrity of the logical name. Now that multiprocessors are ubiquitous, integrity in the face of multiple modifiers has increased in importance.

I rarely find shortcomings in basic OpenVMS services. Far more often, I request small adjustments to system services, such as item list additions to system services for retrieving system information, e.g., $GETSYI, $GETJPI, $GETDVI.

This suggestion concerning the ASSIGN/DEFINE commands and the underlying $CRELNM system service is an exception.¹

The solution for this problem has been known for nearly 50 years, since IBM debuted the System/370. The System/370 included the Compare and Swap instruction, for safely updating shared data in a multiprocessor system.² In short, Compare and Swap atomically updates a variable, if and only if the old value matches the compare value specified. Today’s Intel x86-64 architecture contains an equivalent instruction.³

The danger of multiple modifiers of a shared logical name can be alleviated by adopting the semantics of the Compare and Swap primitive to the $CRELNM system service, any LIB$ routines which allow the definition of a logical name, and its corresponding command-level interface, the ASSIGN and DEFINE DCL commands

At the programming level, the change is adding another parameter to:

• the item list entry to the $CRNLNM system service;
• the LIB$ gatekeeper functions; and
• the DCL commands ASSIGN/DEFINE by the addition of a /COMPARE:"" qualifier.

These changes would provide the information required to implement a Compare and Swap semantic to $CRELNM system service and its various gatekeepers. The $CRELNM system service will only update the logical name if its previous value matches the value specified by the COMPARE item list entry.

The completion codes returned by $CRELNM and its gateways would expand to include a new error code, SS$_NOMATCH.

For the user, the use of this functionality is straightforward:

The retry logic can be embedded in a DCL subroutine, ensuring that multiline DCL sequence is debugged once, rather than multiple copies, each of which must be debugged individually.

This enhancement would eliminate an entire class of non-reproducible race conditions that are difficult to isolate and remediate.

Notes

[1]	OpenVMS System Services Reference Manual, Volume I, $CRELNM
[2]	IBM System/370 Principles of Operation, Sections 5-33 “Serialization” and 7-12 “Instructions” (“COMPARE AND SWAP”)
[3]	Intel x86-64 Architecture Manual, Section 7.3.1.2

References

URLs for referencing this entry

• Home
• Services
  • OpenVMS
  • Windows
  • Printers
  • PostScript
  • Architectures
  • Networks
  • Embedded Systems
• Speaking
• Upcoming Events
• TechnicalCounsel^SM News Archive
• Ruminations – An IT Blog 
• The OpenVMS Consultant 
• Presentations
• Publications
• Technology Demonstrations
• Bookstore
• Contact Us

http://www.rlgsc.com

+1 (718) 463 1079