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: Peter Xu
Subject: Re: [Qemu-devel] [RFC v5 15/26] monitor: let suspend_cnt be thread safe
Date: Sat, 16 Dec 2017 14:12:11 +0800
User-agent: Mutt/1.9.1 (2017-09-22)

On Wed, Dec 13, 2017 at 06:43:58PM +0000, Stefan Hajnoczi wrote:
> 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.

The two public functions would be monitor_resume() and
monitor_suspend().  IIUC as long as these functions are using atomic
operations correctly they should be able to be called anywhere?

Could you help point out what I missed?

> 
> > 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.

Will do.  Thanks,

-- 
Peter Xu



reply via email to

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