store_conditional(2) DG/UX R4.11MU05 store_conditional(2)
NAME
storeconditional - indivisible compare and swap
SYNOPSIS
tb0 0,r0,400
DESCRIPTION
Storeconditional is an extended operation (XOP) that does the
following:
· Fetches the value of a user memory location
· Compares it with a value in a register
· Either stores a new value into the memory location (if the
proper conditions are met), or sets error code 2
The fetch-compare-store sequence executes indivisibly with respect to
any simultaneous store_conditional operation, to the same memory
location, that may be executing on another processor.
Input registers are:
r2 The target address: a 32-bit user memory location, aligned on
a 4-byte boundary.
r3 The old value against which the value of the memory location
will be compared.
r4 The new value to store into the memory location if the proper
conditions are met.
r5 A mask used to compute the conditions that govern whether the
new value is stored.
Return registers are:
r1 Unchanged
r2 Unchanged
r3 Unchanged
r4 Unchanged
r5 Unchanged
r6 Undefined
r7 Status: 0 means success (memory location was set to the new
value), 1 means some fault occurred when accessing the memory
location, 2 means the condition was not met and hence the new
value was not stored.
r8 Old value of the memory location
r9 Undefined
r10 through r31
Unchanged
The value of the memory location pointed to by r2 is read. If the
value read is equal to the value in r3 in all bit positions for which
the corresponding bit in the mask (r5) is set, then the new value
(r4) is stored into the memory location. More precisely, the value
in the memory location is XORed with r3 and ANDed with r5; if the
result is 0, the new value is stored into the memory location. If
the result is not 0, the new value is not stored, and error code 2 is
returned in r7. If any fault (including a page fault) occurs when
accessing the memory location, error code 1 is returned and the
memory location is not modified.
The storeconditional XOP executes indivisibly with respect to all
other storeconditional operations running on any processor in the
system that may be going on simultaneously to the same physical
memory location. It does not necessarily execute indivisibly with
respect to storeconditional operations to other memory locations, or
with respect to other XOPs to the same memory location, or with
respect to normal loads and stores or I/O traffic to the memory
location.
While the XOP is being executed, the user process will not be
descheduled, will not page fault, and will not be terminated. If a
fault of any kind (page fault, protection fault, misaligned access
fault, for example) occurs when the XOP references user data, the XOP
terminates and returns an error. User code is responsible for
catching the error, touching the data item so that the fault can be
handled, and then retrying the XOP. The execution time of the XOP is
charged to user mode, not kernel mode. User profiling ticks that
occur while the XOP is in progress are accounted to the instruction
following the trap instruction.
Storeconditional must be invoked with an assembly language trap
instruction. Typically the trap instruction is done from an assembly
language routine that is linked with the application and called as a
standard subroutine in the high level language in which the
application is written.
EXAMPLE
See example at fetchandadd(2).
SEE ALSO
fetchandadd(2).
Licensed material--property of copyright holder(s)