qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v6 14/27] monitor: let suspend_cnt be thread safe


From: Peter Xu
Subject: Re: [Qemu-devel] [RFC v6 14/27] monitor: let suspend_cnt be thread safe
Date: Mon, 22 Jan 2018 15:43:13 +0800
User-agent: Mutt/1.9.1 (2017-09-22)

On Fri, Jan 12, 2018 at 03:48:10PM -0600, Eric Blake wrote:
> On 12/19/2017 02:45 AM, Peter Xu wrote:
> > Monitor code now can be run in more than one thread.  Let it be thread
> > safe when accessing suspend_cnt counter.
> > 
> > Signed-off-by: Peter Xu <address@hidden>
> > ---
> >  monitor.c | 13 +++++++------
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> > 
> > diff --git a/monitor.c b/monitor.c
> > index cf1e5d881c..844508d134 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -3862,7 +3862,7 @@ static int monitor_can_read(void *opaque)
> >  {
> >      Monitor *mon = opaque;
> >  
> > -    return (mon->suspend_cnt == 0) ? 1 : 0;
> > +    return (atomic_mb_read(&mon->suspend_cnt) == 0) ? 1 : 0;
> 
> Worth a comment at the declaration of suspend_cnt that it must be
> accessed atomically?

Sure.

> 
> I find anything that does '(boolexpr) ? 1 : 0' to be a pointless waste
> of typing.  It is semantically equivalent and shorter to write either of:
> 
> return atomic_mb_read(&mon->suspend_cnt) == 0;
> return !atomic_mb_read(&mon->suspend_cnt);

Sure, will use the latter.

> 
> At any rate, I checked that all uses of suspend_cnt were converted over
> to atomic API, so this looks correct, whether or not you add my tweaks.
> 
> Reviewed-by: Eric Blake <address@hidden>

Thanks for reviewing.

-- 
Peter Xu



reply via email to

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