☜	LOCK Draft MDC Standard					☞

8.2.22 Lock

Lock provides a generalized interlock facility available to concurrently executing M[UMPS] processes to be used as appropriate to the applications being programmed. Execution of Lock is not affected by, nor does it directly affect, the state or value of any global or local variable, or the value of the naked indicator. Its use is not required to access global variables, nor does its use inhibit other processes from accessing global variables. It is an interlocking mechanism whose use depends on programmers establishing and following conventions.

An nref is either unsubscripted or subscripted; if it is subscripted, any number of subscripts separated by commas is permitted.

When nrefind is present, it is always a component of a rnref. If the value of the rnref is a subscripted form of nref, then some of its subscripts may have originated in the nrefind. In this case, the subscripts contributed by the nrefind appear as the first subscripts in the value of the resulting rnref, separated by a comma from the (non-empty) list of subscripts appearing in the rest of the rnref.

Each lockargument specifies a subspace of the total M[UMPS] Lock-UNIVERSE for the environment upon which the executing process seeks to make or release an exclusive claim; the details of this subspace specification are given below.

A special space for the lockspace is needed to create a synchronization mechanism for the executing process for each of the environments referenced by the executing process. A timeout refers to the time spent at the target environment, any time delays due to communication delays are not part of the timeout.

For the purposes of this discussion, the Lock-UNIVERSE is defined as the union of all possible nrefs in one environment after resolution of all indirection. Further, there exists for each process a Lock-LIST that contains zero or more nrefs. Execution of lockarguments has the effect of adding or removing nrefs from the process’s Lock-LIST. A given nref may appear more than once within the Lock-LIST. The nrefs in the Lock-LIST specify a subset of the Lock-UNIVERSE. This subspace, called the process’s LockSPACE, consists of the union of the subspaces specified by all nrefs in the Lock-LIST, as follows:

1. If the nref is unsubscripted, then the subspace is the set of the following points: one point for the unsubscripted variable name nref and one point for each subscripted variable name N(s₁, ... ,s_i ) where N has the same spelling as nref.
2. If the occurrence of nref is subscripted, let the nref be N(s₁ , s₂ , ... , s_n ). Then the subspace is the set of the following points: one point for N(s₁ , s₂ , ... , s_n ) and one point for each descendant (see 7.1.5.3 $Data function for a definition of descendant) of nref. A subscript may not equal the empty string.

If the Lock command is argumentless, Lock removes all nrefs from the Lock-LIST associated with the process executing the Lock command.

Execution of lockargument occurs in the following order:

1. Any expression evaluation involved in processing the lockargument is performed.
2. If the form of lockargument does not include an initial + or - sign, then prior to evaluating or executing the rest of the lockargument, Lock first removes all nrefs from the Lock-LIST associated with the process executing the Lock command. Then it appends each of the nrefs in the lockargument to the process’s Lock-LIST.
3. If the lockargument has a leading + sign, Lock attempts to append each of the nrefs in the lockargument to the process’s Lock-LIST.
4. If the lockargument has a leading - sign, then for each nref in the lockargument, if the nref exists in the Lock-LIST for the process executing the Lock command, one instance of nref is removed from the Lock-LIST.

An error occurs, with ecode = "M41", if a process within a TRANSACTION attempts to remove from its Lock-LIST any nref that was present when the TRANSACTION started. With respect to each other process, the effect of removing any nref from the Lock-LIST is deferred until the global variable modifications made since that nref was added to the Lock-LIST are available to that other process.

Lock affects concurrent execution of processes having Lock-SPACES that OVERLAP. Two Lock-SPACEs OVERLAP when their intersection is not empty. Lock imposes the following constraints on the concurrent execution of processes:

1. The Lock-SPACEs of any two processes executing commands outside the scope of a TRANSACTION may not OVERLAP.
2. All global variable modifications produced by the execution of commands by processes having Lock-SPACEs that OVERLAP must be equivalent to the modifications resulting from some execution schedule during which their Lock-SPACEs do not OVERLAP.

See the TRANSACTION Processing subclause for the definition of TRANSACTION.

The constraints imposed by Lock on the execution of processes having Lock-SPACEs that OVERLAP may cause execution of one or more processes to be delayed. The maximum duration of such a delay may be specified with a timeout.

If present, timeout modifies the execution of Lock, described above, as follows:

1. If execution of the process is delayed and cannot be resumed prior to the expiration of timeout, then the execution of the lockargument is unsuccessful. In this event the value of $Test is set to zero and any nrefs added to the Lock-LIST as a result of executing the lockargument are removed.
2. Otherwise, the execution of the lockargument is successful and $Test is set to one.

If no timeout is present, then the value of $Test is not affected by execution of the lockargument.

Copyright © Standard Documents; 1977-2024 MUMPS Development Committee;
Copyright © Examples: 1995-2024 Ed de Moel;
Copyright © Annotations: 2003-2008 Jacquard Systems Research
Copyright © Annotations: 2008-2024 Ed de Moel.

Some specifications are "approved for inclusion in a future standard". Note that the MUMPS Development Committee cannot guarantee that such future standards will indeed be published.

This page most recently updated on 15-Nov-2023, 14:45:36.

For comments, contact Ed de Moel (demoel@jacquardsystems.com)