On the PowerPC 600 series, memory accesses to suitably-aligned locations by a single register are atomic,¹ meaning that even in the face of a conflicting operation on another processor, the result will be the entire previous value or the entire final value, never a mix of the two. <\/p>\n
To perform atomic update operations (load-modify-store, also known as interlocked operations), you use the Note that the only supported addressing mode is The The Note that the Regardless of whether the store succeeded, the reservation is cleared. <\/p>\n If you attempt to store back to a location different from the most recent preceding If you’ve seen the other RISC architecture atomic operations, this should feel very familiar. Here’s a sample interlocked increment: <\/p>\n You are allowed to abandon a reservation. For example, a compare-exchange starts with a reservation, but if the value is incorrect, it just gives up without ever storing anything. <\/p>\n As noted above, simple accesses to suitably-aligned locations are atomic, and you can use the The The The And then there’s this guy: <\/p>\n This instruction is so famous it has its own Wikipedia page<\/a>. Somebody worked really hard to backronym that mnemonic<\/a>. It’s intended as a memory barrier for memory-mapped I\/O, but it is generally useful as well. It acts like a lightweight There are other types of barriers but you’re not likely to encounter them. There are also special instructions to tell the processor that you’ve written new code to memory, so it should discard any prefetch or instruction cache. <\/p>\n When reading code, you don’t need to worry too much about the distinctions between these different types of barriers. You can assume that the compiler used the correct barrier. (Well, unless you’re chasing a compiler bug.) <\/p>\n The PowerPC permits implementations to have separate I-cache and D-cache, so you cannot assume that writing code to memory will immediately take effect at execution. You have to explicitly tell the processor that instructions have changed. This is mostly relevant only for jitters, so I won’t go into details. I never had to debug a jitter on this guy, and even if I were called upon to do it, I’d just assume that whoever wrote the memory barrier stuff knew what they were doing. <\/p>\nlwarx<\/code> and stwcx.<\/code> instructions: <\/p>\n\n lwarx rd, ra\/0, rb ; load rd from ra\/0 + rb and reserve\n stwcx. rd, ra\/0, rb ; store rd conditionally to ra\/0 + rb, update cr0\n<\/pre>\n
x<\/code>. No plain instruction, and no u<\/code> forms. <\/p>\nlwarx<\/code> instruction loads a word and creates a reservation which monitors the memory for changes. Any modification to that address or an address nearby causes the reservation to be lost. The definition of “nearby” is left up to the processor. <\/p>\nstwcx.<\/code> instruction tries to store rd<\/var> to memory. The store will succeed if the reservation is still in effect and the store is to the same address as the most recent lwarx<\/code>. The result of the operation is reported in the eq<\/var> bit of cr0<\/var>: eq<\/var> is set on success and clear on failure. The instruction also updates the other bits of cr0<\/var> by clearing the lt<\/var> and gt<\/var> bits and capturing the summary overflow bit. <\/p>\nstwcx.<\/code> instruction ends with a dot because it implicitly updates cr0<\/var>. There is no undotted form. <\/p>\nlwarx<\/code>, and the reservation is still valid, the store might or might not succeed, and the eq<\/var> bit will be unpredictable; it need not reflect the actual success of the store. So don’t do that.² <\/p>\n\n ; atomically increment the word stored at address r3\nloop:\n lwarx r4, 0, r3 ; load with reservation\n addi r4, r4, 1 ; increment\n stwcx. r4, 0, r3 ; store conditional\n bne- loop ; if failed (unlikely), try again\n ; on exit r4 contains incremented value\n<\/pre>\n
\n ; if the word at r3 is equal to r4, then replace it with r5\nloop:\n lwarx r6, 0, r3 ; load with reservation\n cmpw r6, r4 ; contains correct value?\n bne- stop ; if not, then give up\n stwcx. r5, 0, r3 ; store conditional\n bne- loop ; if failed (unlikely), try again\nstop:\n ; r6 contains previous value stored at r3\n<\/pre>\n<\/p>\n
lwarx<\/code>\/stwcx.<\/code> instructions to construct more complex atomic operations, but none of those instructions impose any memory ordering. In practice, the interlocked operations will usually erect a memory barrier before and\/or after the atomic update. <\/p>\n\n sync ; full memory barrier\n isync ; acquire\n lwsync ; release\n<\/pre>\n
sync<\/code> instruction is a full memory barrier. <\/p>\nisync<\/code> instruction officially discards prefetch, but that has a side effect of preventing future memory operations from starting (because they were discarded), which is effectively an acquire. You usually use it after taking a lock, so that reads intended to be under the lock do not get advanced to before the lock is taken. <\/p>\nlwsync<\/code> waits for preceding loads and stores to complete, but allows future loads to start. You usually use it just before releasing a lock, so that all accesses that were intended to be protected by the lock are finished before the lock is dropped. <\/p>\n\n eieio ; enforce in-order execution of I\/O\n<\/pre>\n
lwsync<\/code>: It ensures that all pending stores are completed, but it does not prevent future loads from starting or force preceding loads to complete. You can use this just before exiting a lock if the purpose of the lock was to update some data rather than to read some data. The compiler, of course, doesn’t usually have this level of insight into your code, so you’re unlikely to see this in practice. <\/p>\n