Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-08-27 21:17, Anthony Liguori wrote:
> Avi Kivity <avi@redhat.com> 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