SIGNALING
During certain critical periods, the locking mechanism alone is not
enough. In these situations one processor must signal the other to
request a specific action. As part of initialization, the main processor issues a SIGP to activate the attached processor. Some critical functions, such as machine check handling or extending free
storage, require that one processor be quiesced for a time and then
reactivated. This is done with the SIGNAL macro. LOCKING To provide system integrity, VM/370 attached processor support is
designed around one global system lock, a VMBLOK local lock, and several
system local locks for specifically identified queues or modules.
All of CP runs under the global system lock except for specifically
identified paths. If the lock cannot be obtained, the function will be
deferred by storing the necessary information in the VMBLOK appendage
and stacking that VMBLOK for later processing. ihat processor will then
take a special unlocked path through the dispatcher to dispatch a new virtual machine.
In some situations, the processor cannot defer the requested function
and will spin on the lock until it becomes available.
To ensure system integrity along the special unlocked paths, various
local locks have been defined. These locks are tasically spin locks and
are held for short periods of time.
The VMBLOK lock is obtained by the dispatcher before dispatching a
virtual machine in problem program state or before performing any system
service for that virtual machine. This lock will prevent a virtual
aachine from being serviced by CP while it is running in problem program
state. !gte: This lock is not a spin lock.
The free storage lock is a spin lock obtained by for all FREE and
FRET requests for free storage.
There are several other locks used by CP in situations where the
global system lock is not held. All of the locks used by CP are
described in detail in 1Qgl£ 180 IBM VM/310 System Programmer's Guide

April 1, 1981
If you have user-defined areas that used by more than one virtual
machine, you will need to define your own locking conventions. You can
use the LOCK macro to obtain and release a PRIVATE lock. The format of
the LOCK macro is: r- I I (label] I I i
label OBTAIN RELEASE LOCK {
OBTAIN },TYPE=PRIVATE,[SPIN={YES}][,SAVE] RELEASE NO is any desired use label.
is a required positional operand indicating whether the lock
is to be obtained or released. TY PE=PRI VATE is a required operand that indicates that the lock is a user
lock. SPIN=YESINO SAVE specifies whether control is to be without the lock
being held. The default is SPIN=YES. is an optional keyword that indicates 1, 14 and
15 are to be saved before the rest of the macro expansion.
These are saved in the PSA of the processor that is executinq
this macro. The registers are restored before exit from the
macro expansion.
The condition code (cc) is set as a result of the invocation of the LOCK macro. cc=O OBTAIN - lock obtained RELEASE - lock released
cc=l OBTAIN,SPIN=NO - lock owned by another processor.
A failure to release a lock results in a LOK003 abend.
The address of the lockword must be specified in register 1 and the lockword must be a fullword aligned on a fullword boundary. Spin time
for private locks is kept in the DMKLOKSI timer value for all non-DMKLOK locks. AFFINITY If one processor has a feature that the other processor does not
have, you can tell the system that you always want to execute on that processor. This is done by requesting affi-ni-t-y ,-ei-ther in the d-ireGtory or with a SET AFFINITY command. See the !2£ Q§g[§ for details on the SET AFFINITY command. Part 2. Control Program (CP) 181