docs/devel/lockcnt.rst

69 - reclaiming data can be done by a separate thread in the case of RCU;
70   this can improve performance, but also delay reclamation undesirably.
96 Reads, instead, can be done without taking the mutex, as long as the
101 can happen concurrently with the read.  The RCU API ensures that the
126 Here, no frees can happen in the code represented by the ellipsis.
141 can also be more efficient in two ways:
146 - on some platforms, one can implement ``QemuLockCnt`` to hold the lock
149   :doc:`atomics`).  This can be very helpful if concurrent access to
153 Using the same mutex for frees and writes can still incur some small
154 inefficiencies; for example, a visit can never start if the counter is
170 frequent and can happen on a fast path; however: 1) it is almost never
186 Setting a variable to a non-NULL value can be done between
197 Accessing the value can be done between ``qemu_lockcnt_inc`` and
204         /* Accesses can now be done through "p".  */
208 Freeing the object can similarly use ``qemu_lockcnt_lock`` and
221 If an object has to be freed right after a visit, you can combine
228         /* Accesses can now be done through "p".  */
236 ``QemuLockCnt`` can also be used to access a list as follows::
255 Again, the RCU primitives are used because new items can be added to the
277 Here you can use ``qemu_lockcnt_dec`` instead of ``qemu_lockcnt_dec_and_lock``,