CONTROL=SERIAL - specifies that control returns to the sender
after the function is complete. CONTROL=SERIAL is the only
parameter that you can use with the emergency signals. You cannot
specify CONTROL=SERIAL for the external calls and direct signals. CONTROL=P ARALLEL -specifies that control returns to the sender
even though the function may not be complete. You can use CON­ TROL=P ARALLEL with the external calls and direct signals; it is the
default for these signals. CONTROL=AUTO - specifies that the signal is sent to the issuing
processor. You can use CONTROL=AUTO with the external calls and
direct signals.
Time-oj-Day (TOD) Clock Synchronization Check I Fetching and Storing
If more than one TOD clock exists in a tightly-coupled configuration, the clocks
must be synchronized. If the time-of-day (TOD) clocks are not in high order
synchronization during system initialization of an AP IMP system, the system issues
a message to the system operator to enable the TOD clock set key. If the clocks
are out of low order synchronization, that is bits 32 to 63 of the two clocks do not
match, the system receives a time-of-day-clock-sync-check when external inter­
ruptions are enabled. Then the system synchronizes the clocks. Since main storage is shared, there is a possibility that both processors may be
accessing the same location in storage simultaneously. The control program must
prevent simultaneous updates to the same storage location. In a tightly-coupled
multiprocessor environment certain instructions cannot safely execute if there is a
chance that their execution might change storage that the other processor is also
using. Fetch and store instructions such as 01, NI, and NC could cause one
processor to update storage that the other processor is also using. To prevent this
type of error in a multiprocessing environment, the following fetch and store
instructions have interlocks: CDS - compare double and swap CS - compare and swap TS - test and set
The following example shows how you could use the compare and swap instruction
to set a flag in a multiprocessing environment.
CP in Attached Processor and Multiprocessor Modes 213

Processor A
LA RX,FLAGS load Rx with address of FLAGS byte
LA Ry,X'80' load Ry with byte to set FLAGS SLL Ry,24 line up fields
L Rz,O(Rx) load Rz with FLAGS byte . RETRY LR RW,Rz load Rw with contents of Rz OR Rw,Ry load Rw with reset value of FLAGS CS Rz,Rw,O(Rx) reset FLAGS byte if =; otherwise load Rz from FLAGS
BNE RETRY if contents of Rz FLAGS, branch to RETRY
FLAGS DC X'20' initial setting of field
Processor B
LA Ra,FLAGS load Ra with address of FLAGS byte
LA Rb,X'40' load Rb with byte to set FLAGS SLL Rb,24 line up fields
L Rc,O(Ra) load Rc with FLAGS byte
RETRY LR Rd,Rc load Rd with contents of Rc OR Rd,Rb load Ra with reset value of FLAGS CS Rc,Rd,O(Ra) reset FLAGS byte if =; otherwise load Rc from FLAGS
BNE RETRY if contents of Rc FLAGS, branch to RETRY
FLAGS DC X'20' Figure 30. Sample of the Correct Way to Set a Flag in an AP/MP Environment
Locks and Serialization of Functions
Locking Hierarchy
If VM/SP is executing in AP /MP mode, critical sections of code must be
serialized. A critical section of code is code that is executing on one processor and
must appear as one indivisible operation to the other processor. An example of a
critical section of code would be code that updates a queue. The other processor
should not have access to the queue until the element is either added or deleted and
all pointers are updated. VM/SP uses locks to accomplish serialization of critical
functions. A lock is an area of storage. It is initialized to a value, usually zero, to
signify that the lock is not held. Before entering a critical section of code, the
processor requests the lock to serialize the operation. The operating system deter­
mines if a lock is free and gives it to the processor requesting the lock by means of
a hardware interlocked update operation such as compare and swap (CS). When
exit is made from the critical section of code, the system releases the lock by chang­
ing its value back to zero.
The introduction of a locking structure makes the avoidance of processor deadlock
a prime concern. A deadlock occurs if both processors each have a different lock
and want to obtain the lock that the other processor holds. VM/SP uses a locking
hierarchy to avoid these deadlock situations. A locking hierarchy provides for the
ordering of the set of locks. If a processor holds a given lock, it can only request a
214 VM/SP System Programmer's Guide