From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLhzz-0002Za-6k for qemu-devel@nongnu.org; Thu, 24 May 2018 00:37:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLhzw-0006Ye-3c for qemu-devel@nongnu.org; Thu, 24 May 2018 00:37:11 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:57570 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fLhzv-0006YF-TM for qemu-devel@nongnu.org; Thu, 24 May 2018 00:37:08 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 200927C6DE for ; Thu, 24 May 2018 04:37:07 +0000 (UTC) Date: Thu, 24 May 2018 12:37:02 +0800 From: Peter Xu Message-ID: <20180524043702.GF756@xz-mi> References: <20180509041734.14135-1-peterx@redhat.com> <20180509041734.14135-4-peterx@redhat.com> <87zi0ylaab.fsf@dusky.pond.sub.org> <20180518102143.GO2569@xz-mi> <87muwqixla.fsf@dusky.pond.sub.org> <20180523084712.GA2540@xz-mi> <87h8mye73l.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87h8mye73l.fsf@dusky.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH v5 3/4] monitor: more comments on lock-free fleids/funcs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , qemu-devel@nongnu.org, Stefan Hajnoczi , "Dr . David Alan Gilbert" On Wed, May 23, 2018 at 05:15:26PM +0200, Markus Armbruster wrote: > Peter Xu writes: > > > On Wed, May 23, 2018 at 10:29:37AM +0200, Markus Armbruster wrote: > >> Peter Xu writes: > >> > >> > On Thu, May 17, 2018 at 02:46:36PM +0200, Markus Armbruster wrote: > >> >> Peter Xu writes: > >> >> > >> >> > Add some explicit comment for both Readline and cpu_set/cpu_get helpers > >> >> > that they do not need the mon_lock protection. > >> >> > >> >> Appreciated! > >> >> > >> >> > Signed-off-by: Peter Xu > >> >> > --- > >> >> > monitor.c | 5 +++-- > >> >> > 1 file changed, 3 insertions(+), 2 deletions(-) > >> >> > > >> >> > diff --git a/monitor.c b/monitor.c > >> >> > index d6c3c08932..ae5bca9d7c 100644 > >> >> > --- a/monitor.c > >> >> > +++ b/monitor.c > >> >> > @@ -207,7 +207,7 @@ struct Monitor { > >> >> > int suspend_cnt; /* Needs to be accessed atomically */ > >> >> > bool skip_flush; > >> >> > bool use_io_thr; > >> >> > - ReadLineState *rs; > >> >> > + ReadLineState *rs; /* Only used in parser, so no lock needed. */ > >> >> > >> >> Pardon the ignorant question: why does "only used in parser" imply "no > >> >> lock needed"? > >> > > >> > Since even if the monitors can be run in multiple threads now, the > >> > monitor parser of a specific Monitor will still only be run in either > >> > the main thread or the monitor iothread. My fault to be unclear on > >> > the comment. Maybe this one is better: > >> > > >> > It is only used in parser, and the parser of a monitor will only be > >> > run either in main thread or monitor IOThread but never both, so no > >> > lock is needed when accessing ReadLineState. > >> > >> One further question, just to help me understand how this stuff works: > >> what are the conditions for the parser running in the main thread, and > >> what are the conditions for it running in the monitor IOThread? > > > > For QMP parsers, the place is decided by Monitor.use_io_thr. If set, > > Aside: spelling it use_io_thread would buy us a bit of readability at a > total cost of some 30 characters :) Sorry for the bad names... Please feel free to change that as follow up patches on any of the namings. I am never good at that. :( > > > the parser runs in monitor IOThread; otherwise it still runs in main > > thread. > > Commit a5ed352596a and 3fd2457d18e. I see. > > > For HMP parsers, they should always been run in the main thread. > > > > After replying I just noticed that ReadLineState should only be used > > by HMP, or to be more explicit, when MONITOR_USE_READLINE is set. So > > maybe the comment is not really accurate above - actually it never > > runs in monitor iothread! However the conclusion is still the same - > > we don't need to protect it. > > Flags MONITOR_USE_READLINE and MONITOR_USE_CONTROL are independent. > However, our CLI currently supports mode=readline (MONITOR_USE_READLINE) > and mode=control (MONITOR_USE_CONTROL). Yeah, so it seems to me the truth is that they are dependent no matter how we implemented the flags. > > If relying on "MONITOR_USE_CONTROL implies !MONITOR_USE_READLINE" makes > things simpler, no objections from me, but we should add an assertion. > > Back to the comment on member @rs. What about > > /* > * State used only in the thread "owning" the monitor. > * If @use_io_thr, this is mon_global.mon_iothread. > * Else, it's the main thread. > * These members can be safely accessed without locks. > */ > ReadLineState *rs; > // other members that aren't shared, if any Sure! Thanks for offering. -- Peter Xu