Compare and Swap (CMPSW)


Op Code (Hex) Extender Operand 1 Operand 2 Operand 3 Operand 4 [5]
CMPSWB 1C37 Branch options Compare operand 1 Compare operand 2 Swap operand Branch target


CMPSWI 1837 Indicator options Compare operand 1 Compare operand 2 Swap operand Indicator target
Operand 1: Character(1,2,4,8) variable scalar.

Operand 2: Character(1,2,4,8) variable scalar.

Operand 3: Character(1,2,4,8) scalar.

Operand 4 [4-5]:

Bound program access

Built-in number for CMPSWP is 156. CMPSWP ( op1 : address of a scalar(1,2,4,8) value op2 : address of a scalar(1,2,4,8) value (has alignment restrictions based on the length of the scalar - see description below) op3 : scalar(1,2,4,8) value cntl : signed binary(4) literal value (this operand is optional -- see description below) ) : signed binary(4)

If the values of op1 and op2 are equal, the value 1 is returned. Otherwise, the value 0 is returned.

Description  The value of the first compare operand is compared with the value of the second compare operand. If they are equal, the swap operand is stored in the second compare operand's location. If they are unequal, the second compare operand is stored into the first compare operand's location. Based on the comparison, the resulting condition is used with the extender field to:

When an equal comparison occurs, it is assured that no access by another Compare and Swap instruction will occur at the second compare operand location between the moment that the second compare operand is fetched for comparison and the moment that the swap operand is stored at the second compare operand location.

When an unequal comparison occurs, no atomicity guarantees are made regarding the store to the first compare operand location and other Compare and Swap instruction access. Thus only the second compare operand should be a variable shared for concurrent processing control.

Both compare operands must be 1, 2, 4 or 8 byte character variable scalars and the swap operand must be a 1, 2, 4 or 8 byte character scalar. All three operands must have the same length. Failure to have the operands the same length will not be detected and the results of the Compare and Swap instruction are undefined when this occurs. The second operand must be aligned based on its length:

Failure to have the second operand aligned properly will not be detected, but the results of the Compare and Swap instruction are undefined when this occurs.

For bound program access, the cntl operand is optional, and does not need to be specified. If the cntl operand is specified, it has the following effect depending on the value:

If the cntl operand is not specified, the instruction proceeds as if the default value had been specified.

The machine does not enforce that only the values enumerated above are used for the cntl operand. When specified, use of any value other than those enumerated above may result in unpredictable behavior.

Storage Synchronization

Unless explicitly disabled with the no storage synchronization is performed control option (disabling is possible only using bound program access), this instruction synchronizes storage both before and after the swap operand is stored to op2. Synchronized operation provides the following guarantees:

When synchronization is disabled for CMPSW, storage synchronization can be accomplished using other storage synchronizing MI instructions, such as SYNCSTG.

See Storage Synchronization Concepts for additional information on storage synchronization.

Usage Note

Note that the compare and swap construct (including both this CMPSW instruction and support found on other architectures) simply compares values; it cannot determine whether the presence of the same value indicates that the data object for which an update is being synchronized is in fact the intended data object.

For example, CMPSW is insufficient for modifications to data structures comprised of multiple data objects, when an equal comparison of the value of one data object does not necessarily mean that the whole data structure is unchanged. In that case, finding an equal value for one data object may not mean that you are operating on the intended data structure element; other data objects in the data structure may have been independently changed.

A similar example is that CMPSW might not be sufficient for dequeueing an element from a queue residing in shared storage. More specifically, consider a queue that has an identified "head" offset value and some number of elements that each include a "next" offset field (a binary data object). Just because the element currently at the head of the queue has the same offset value as was previously copied to local storage for use in a CMPSW does not mean that the element's current value of "next" is the same as the "next" value copied to local storage when the "head" offset value was copied. That is, multiple elements may have been dequeued and the element with the saved "head" offset, but a different "next" value, may have been enqueued since the local copies were made. Setting the new queue head value with the copied "next" value would thus be invalid. Update of the queue data structure clearly has not been properly synchronized by such a use of CMPSW. Instead, a CMPSW of a data object that consists of two smaller data objects: an offset and a use count that is incremented every time the element is used, would be a safe approach if the use count values will always be different.

Resultant Conditions 

Authorization Required

Lock Enforcement

Exceptions

06 Addressing

08 Argument/Parameter

10 Damage Encountered

1C Machine-Dependent

20 Machine Support

22 Object Access

24 Pointer Specification

2C Program Execution

36 Space Management

44 Protection Violation