From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T64tr-0003A6-Sn for qemu-devel@nongnu.org; Mon, 27 Aug 2012 15:23:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T64tn-0006US-3X for qemu-devel@nongnu.org; Mon, 27 Aug 2012 15:23:03 -0400 Received: from david.siemens.de ([192.35.17.14]:22776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T64tm-0006Tl-QF for qemu-devel@nongnu.org; Mon, 27 Aug 2012 15:22:59 -0400 Message-ID: <503BC90C.4070804@siemens.com> Date: Mon, 27 Aug 2012 21:22:52 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1345801763-24227-1-git-send-email-qemulist@gmail.com> <1345801763-24227-11-git-send-email-qemulist@gmail.com> <874nnoh3pg.fsf@codemonkey.ws> <503B8C1E.6090800@siemens.com> <87pq6cfjtm.fsf@codemonkey.ws> <503B91A9.7010507@siemens.com> <87k3wkjobd.fsf@codemonkey.ws> <503BBDFC.8070806@redhat.com> <87d32cxhy4.fsf@codemonkey.ws> In-Reply-To: <87d32cxhy4.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "qemu-devel@nongnu.org" , Paolo Bonzini , Liu Ping Fan , Avi Kivity , Liu Ping Fan On 2012-08-27 21:17, Anthony Liguori wrote: > Avi Kivity writes: > >> On 08/27/2012 09:24 AM, Anthony Liguori wrote: >>>> >>>> I'm sure we should leave existing code alone wherever possible, focusing >>>> on providing alternative versions for those paths that matter. Example: >>>> Most timers are fine under BQL. But some sensitive devices (RTC or HPET >>>> as clock source) will want their own timers. So the approach is to >>>> instantiate a separate, also prioritizeable instance of the timer >>>> subsystem for them and be done. >>> >>> I disagree. I think we conver the timer subsystem to be lockless and >>> then let some devices acquire the BQL during dispatch. >> >> I agree with your disagreement but disagree with the rest. The timer >> subsystem should have its own internal locking that callers will not be >> aware of. Requiring devices to acquire the bql will lead to >> deadlocks. > > Err, I completely mispoke there. > > I meant, to say, we should convert the timer subsystem to be re-entrant > and then let some devices acquire the BQL during dispatch. > > Existing users of the time API should get the BQL acquired automagically > for them. The new API would not hold the BQL during dispatch but the > old API, implemented in terms of the new API, would acquire it on behalf > of the caller. > > As a rule, if a device relies on the BQL, it must use the old APIs. If > a device uses the new APIs, it must not acquire the BQL. This makes sense. > >> Note that fine-grained locking timers will also require reference >> counting: you want to call the timer expiration callback after releasing >> the timer subsystem lock, so you need to make sure the callback does not >> go away. > > glib simply uses a single main loop lock to deal with all of this. I > think that's absolutely the right model. That depends on what is under the lock. Also, relying on locking of external libraries is a no-go for realtime as they usually do not care about priorities and inversion avoidance. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux