From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpZSx-0001QS-6P for qemu-devel@nongnu.org; Thu, 20 Jun 2013 03:39:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpZSt-0000rQ-A0 for qemu-devel@nongnu.org; Thu, 20 Jun 2013 03:39:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8659) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpZSt-0000rD-2L for qemu-devel@nongnu.org; Thu, 20 Jun 2013 03:39:31 -0400 Date: Thu, 20 Jun 2013 09:39:24 +0200 From: Stefan Hajnoczi Message-ID: <20130620073924.GA14255@stefanha-thinkpad.redhat.com> References: <1371675569-6516-1-git-send-email-pingfank@linux.vnet.ibm.com> <1371675569-6516-3-git-send-email-pingfank@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1371675569-6516-3-git-send-email-pingfank@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v3 2/2] QEMUBH: make AioContext's bh re-entrant List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Liu Ping Fan Cc: Kevin Wolf , Paolo Bonzini , Liu Ping Fan , qemu-devel@nongnu.org, Anthony Liguori On Thu, Jun 20, 2013 at 04:59:29AM +0800, Liu Ping Fan wrote: > BH will be used outside big lock, so introduce lock to protect > between the writers, ie, bh's adders and deleter. The lock only > affects the writers and bh's callback does not take this extra lock. > Note that for the same AioContext, aio_bh_poll() can not run in > parallel yet. > > Signed-off-by: Liu Ping Fan > --- > async.c | 22 ++++++++++++++++++++++ > include/block/aio.h | 5 +++++ > 2 files changed, 27 insertions(+) qemu_bh_cancel() and qemu_bh_delete() are not modified by this patch. It seems that calling them from a thread is a little risky because there is no guarantee that the BH is no longer invoked after a thread calls these functions. I think that's worth a comment or do you want them to take the lock so they become safe? The other thing I'm unclear on is the ->idle assignment followed immediately by a ->scheduled assignment. Without memory barriers aio_bh_poll() isn't guaranteed to get an ordered view of these updates: it may see an idle BH as a regular scheduled BH because ->idle is still 0. Stefan