Lines Matching +full:- +full:- +full:-
1 .. _atomics-ref:
8 but this can be a problem for CPU-CPU interaction (including interactions
9 between QEMU and the guest). Multi-threaded programs use various tools
17 the most performance-critical parts of QEMU in particular require
26 - compiler barriers: ``barrier()``;
28 - weak atomic access and manual memory barriers: ``qatomic_read()``,
33 - sequentially consistent atomic access: everything else.
36 used data structures (e.g. the lock-free singly-linked list operations
39 atomic operations and memory barriers should be limited to inter-thread
70 ``qemu/atomic.h`` provides the following set of atomic read-modify-write
118 - atomic accesses will not cause data races (and hence undefined behavior);
124 - acquire operations will appear to happen, with respect to the other
128 - release operations will appear to happen, with respect to the other
132 - release operations will *synchronize with* acquire operations;
137 - ``qatomic_read()`` and ``qatomic_set()``; these prevent the compiler from
143 - ``qatomic_load_acquire()``, which guarantees the LOAD to appear to
149 - ``qatomic_store_release()``, which guarantees the STORE to appear to
162 - ``smp_rmb()`` guarantees that all the LOAD operations specified before
170 - ``smp_wmb()`` guarantees that all the STORE operations specified before
178 - ``smp_mb_acquire()`` guarantees that all the LOAD operations specified before
183 - ``smp_mb_release()`` guarantees that all the STORE operations specified *after*
188 - ``smp_mb()`` guarantees that all the LOAD and STORE operations specified
199 - ``smp_read_barrier_depends()`` is a weaker kind of read barrier. On
207 weakly-ordered architectures such as Arm or PPC\ [#alpha]_.
216 needs a processor barrier. On strongly-ordered architectures such
224 +----------------------------------+----------------------------------+
231 +----------------------------------+----------------------------------+
242 +------------------------------------------+----------------------------------+
251 +------------------------------------------+----------------------------------+
257 +------------------------------------------+----------------------------------+
261 +------------------------------------------+----------------------------------+
273 +------------------------------------------+----------------------------------+
278 +------------------------------------------+----------------------------------+
289 +------------------------------------------+----------------------------------+
294 Acquire/release pairing and the *synchronizes-with* relation
295 ------------------------------------------------------------
300 .. [#rmw] Read-modify-write operations can have both---acquire applies to the
303 - within a thread, they are ordered either before subsequent operations
306 - if a release operation in one thread *synchronizes with* an acquire operation
313 operations; almost all higher-level synchronization primitives also have
316 - ``pthread_mutex_lock`` has acquire semantics, ``pthread_mutex_unlock`` has
320 - ``pthread_cond_signal`` and ``pthread_cond_broadcast`` have release semantics;
325 - ``pthread_create`` has release semantics and synchronizes with the start
329 - ``qemu_event_set`` has release semantics, ``qemu_event_wait`` has
333 thread 2 is relying on the *synchronizes-with* relation between ``pthread_exit``
336 +----------------------+-------------------------------+
344 +----------------------+-------------------------------+
361 +----------------------+------------------------------+
371 +----------------------+------------------------------+
373 Note that a load-store pair only counts if the two operations access the
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
379 +--------------------------------+--------------------------------+
387 +--------------------------------+--------------------------------+
389 Acquire and release semantics of higher-level primitives can also be
403 +----------------------+------------------------------+
410 | x->i = 2; | |
414 | | y = x->i; |
417 +----------------------+------------------------------+
425 - atomic operations in Linux are always on a 32-bit int type and
429 - Originally, ``atomic_read`` and ``atomic_set`` in Linux gave no guarantee
439 since we assume the variables passed are machine-word sized and
445 - atomic read-modify-write operations in Linux are of three kinds:
456 - different atomic read-modify-write operations in Linux imply
461 - however, according to the C11 memory model that QEMU uses, this order
463 read-modify-write operation. As far as those are concerned, the
464 operation consist of just a load-acquire followed by a store-release.
466 still be reordered and will happen *in the middle* of the read-modify-write
471 +----------------------------------+--------------------------------+
478 +----------------------------------+--------------------------------+
489 +--------------------------------+
497 +--------------------------------+
502 +--------------------------------+
510 +--------------------------------+
515 - ``Documentation/memory-barriers.txt`` from the Linux kernel