Lines Matching full:strong
174 should <strong>always</strong> make this assumption when thinking about
298 memory, it only <strong>initiates</strong> the write. It does not have to wait
328 store #1 to <strong>finish</strong> being published before it can start on store
490 <p>The store/store barrier guarantees that <strong>all observers</strong> will
651 reg1 = 8 <strong>+ (reg0 & 0)</strong><br />
788 Doubleword (64-bit) accesses are <strong>not</strong> atomic, unless the
894 <strong>two</strong> independent operations. First, it issues the CPU?s full
917 <strong>before</strong> we release the lock, so that loads and stores in the
923 though, because we only need to keep the other threads <strong>out</strong>. The
945 success = atomic_<strong>acquire</strong>_cas(&lock, 0, 1)
950 atomic_<strong>release</strong>_store(&lock, 0)</pre>
1014 <p>Note that <strong>all</strong> of the operations are now happening inside the
1019 <p>In general, it is always safe to move operations <strong>into</strong> a
1020 critical section, but never safe to move operations <strong>out of</strong> a
1035 <li>A store followed by a load <strong>can</strong> be reordered, because each
1075 <p>If you think you need to declare something ?volatile?, that is a strong
1200 <code>sharedThing->x</code> <strong>after</strong> they observe the recycle
1234 <strong>not</strong> conclude that code inside a synchronized block happens
1250 <strong>any</strong> thread up to the point where it writes the field will be
