From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3lWp-0004Pw-2g for qemu-devel@nongnu.org; Mon, 29 Jul 2013 07:22:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3lWc-000123-Ho for qemu-devel@nongnu.org; Mon, 29 Jul 2013 07:22:15 -0400 Received: from mail-ye0-x22d.google.com ([2607:f8b0:4002:c04::22d]:45930) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3lWc-00011q-DJ for qemu-devel@nongnu.org; Mon, 29 Jul 2013 07:22:02 -0400 Received: by mail-ye0-f173.google.com with SMTP id m14so412446yen.18 for ; Mon, 29 Jul 2013 04:22:01 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51F65044.4040706@redhat.com> Date: Mon, 29 Jul 2013 13:21:40 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1375067768-11342-1-git-send-email-pingfank@linux.vnet.ibm.com> <1375067768-11342-4-git-send-email-pingfank@linux.vnet.ibm.com> <51F60C02.6020008@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v2 3/5] timer: make qemu_clock_enable sync between disable and timer's cb List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Kevin Wolf , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Alex Bligh , Anthony Liguori Il 29/07/2013 10:10, liu ping fan ha scritto: > On Mon, Jul 29, 2013 at 2:30 PM, Paolo Bonzini wrote: >> Il 29/07/2013 05:16, Liu Ping Fan ha scritto: >>> After disabling the QemuClock, we should make sure that no QemuTimers >>> are still in flight. To implement that, the caller of disabling will >>> wait until the last user's exit. >>> >>> Note, the callers of qemu_clock_enable() should be sync by themselves, >>> not protected by this patch. >>> >>> Signed-off-by: Liu Ping Fan >> >> This is an interesting approach. >> >>> - if (!clock->enabled) >>> - return; >>> + atomic_inc(&clock->using); >>> + if (unlikely(!clock->enabled)) { >>> + goto exit; >>> + } >> >> This can return directly, it doesn't need to increment and decrement >> clock->using. >> > Here is a race condition like the following Ah, I see. Still this seems a bit backwards. Most of the time you will have no one on the wait_using condvar, but you are almost always signaling the condvar (should be broadcast BTW)... Paolo