qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC v5 15/26] monitor: let suspend_cnt be thread safe


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC v5 15/26] monitor: let suspend_cnt be thread safe
Date: Wed, 13 Dec 2017 18:43:58 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

On Tue, Dec 05, 2017 at 01:51:49PM +0800, Peter Xu wrote:
> Monitor code now can be run in more than one thread.  Let it be thread
> safe when accessing suspend_cnt counter.

Please add doc comments to the functions explaining which thread they
may be called from (especially public functions).  Without this
information other people will have a hard time keeping code thread-safe.

> Signed-off-by: Peter Xu <address@hidden>
> ---
>  monitor.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)

From docs/devel/atomics.txt:

  Macros defined by qemu/atomic.h fall in three camps:

  - compiler barriers: barrier();

  - weak atomic access and manual memory barriers: atomic_read(),
    atomic_set(), smp_rmb(), smp_wmb(), smp_mb(), smp_mb_acquire(),
    smp_mb_release(), smp_read_barrier_depends();

  - sequentially consistent atomic access: everything else.

The atomic_read() and atomic_set() calls in this patch aren't effective
without memory barriers.  Please use atomic_mb_read() and
atomic_mb_set() instead.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]