docs/devel/atomics.rst

128 - release operations will appear to happen, with respect to the other
132 - release operations will *synchronize with* acquire operations;
294 Acquire/release pairing and the *synchronizes-with* relation
298 either *acquire* or *release* semantics\ [#rmw]_.  This has two effects:
301           read part, and release to the write.
304   (for acquire) or after previous operations (for release).
306 - if a release operation in one thread *synchronizes with* an acquire operation
308   second thread.  That is, everything before the release operation in the
312 The concept of acquire and release semantics is not exclusive to atomic
314 acquire or release semantics.  For example:
317   release semantics and synchronizes with a ``pthread_mutex_lock`` for the
320 - ``pthread_cond_signal`` and ``pthread_cond_broadcast`` have release semantics;
321   ``pthread_cond_wait`` has both release semantics (synchronizing with
325 - ``pthread_create`` has release semantics and synchronizes with the start
329 - ``qemu_event_set`` has release semantics, ``qemu_event_wait`` has
334 (release) and ``pthread_join`` (acquire):
347 a release operation and an acquire operation.  Therefore, atomic operations
350 will pair with a release operation and vice versa.  This rule of thumb is
357 ``qatomic_store_release()`` and ``qatomic_rcu_set()`` all count as release
358 operations.  ``smp_mb()`` counts as both acquire and release, therefore
374 same variable: that is, a store-release on a variable ``x`` *synchronizes
375 with* a load-acquire on a variable ``x``, while a release barrier
389 Acquire and release semantics of higher-level primitives can also be
395 before a release operation will normally match the loads after
464   operation consist of just a load-acquire followed by a store-release.