From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54250) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9FzS-00010Q-FQ for qemu-devel@nongnu.org; Tue, 13 Aug 2013 10:54:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9FzK-0004wn-UW for qemu-devel@nongnu.org; Tue, 13 Aug 2013 10:54:30 -0400 Received: from david.siemens.de ([192.35.17.14]:26077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9FzK-0004wZ-Jd for qemu-devel@nongnu.org; Tue, 13 Aug 2013 10:54:22 -0400 Message-ID: <520A4897.3090407@siemens.com> Date: Tue, 13 Aug 2013 16:54:15 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <5209E6A1.6060308@siemens.com> <520A467E.6000406@redhat.com> In-Reply-To: <520A467E.6000406@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Using aio_poll for timer carrier threads List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Anthony Liguori , Stefan Hajnoczi , qemu-devel , liu ping fan , Alex Bligh , MORITA Kazutaka , Richard Henderson On 2013-08-13 16:45, Paolo Bonzini wrote: > Il 13/08/2013 09:56, Jan Kiszka ha scritto: >> Hi Stefan, >> >> in the attempt to use Alex' ppoll-based timer rework for decoupled, >> real-time capable timer device models I'm now scratching my head over >> the aio_poll interface. I'm looking at dataplane/virtio-blk.c, just finding >> >> static void *data_plane_thread(void *opaque) >> { >> VirtIOBlockDataPlane *s = opaque; >> >> do { >> aio_poll(s->ctx, true); >> } while (!s->stopping || s->num_reqs > 0); >> return NULL; >> } >> >> wondering where the locking is. Or doesn't this use need any at all? Are >> all data structures that this thread accesses exclusively used by it, or >> are they all accessed in a lock-less way? > > There is some locking in aio_bh_poll. It is pretty lightweight because > adding elements and deleting them is done under a lock, while the list > is walked without taking it (because deletion is only done by the thread > that walks). We could do something similar for file descriptors; timers > are more complicated because insertions happen for every mod_timer. > > Using an AioContext lock for timers is somewhat complicated for lock > ordering, because context A could try to modify a timer from context B, > at the same time when context B is modifying a timer from context A. > This would cause a deadlock. That's like MMIO access on device A triggers MMIO access on B and vice versa - why should we need this, so why should we support this? I think the typical case is that timers (and their lists) and data structures they access have a fairly close relation, thus can reuse the same lock. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux