On Thu, Sep 20, 2012 at 5:07 PM, Avi Kivity <a...@redhat.com> wrote:
> On 09/20/2012 10:51 AM, liu ping fan wrote:
>> On Wed, Sep 19, 2012 at 5:23 PM, Avi Kivity <a...@redhat.com> wrote:
>>> On 09/19/2012 12:19 PM, liu ping fan wrote:
>>>> On Wed, Sep 19, 2012 at 5:14 PM, Paolo Bonzini <pbonz...@redhat.com> wrote:
>>>>> Il 19/09/2012 11:11, liu ping fan ha scritto:
>>>>>>> > Why not? devA will drop its local lock, devX will retake the big lock
>>>>>>> > recursively, devB will take its local lock. In the end, we have
>>>>>>> > biglock
>>>>>>> > -> devB.
>>>>>>> >
>>>>>> But when adopting local lock, we assume take local lock, then biglock.
>>>>>
>>>>> No, because the local lock will be dropped before taking the biglock.
>>>>> The order must always be coarse->fine.
>>>>>
>>>> But if we takes coarse firstly, then the mmio-dispatcher will still
>>>> contend for the big lock against each other.
>>>
>>> Can you detail the sequence?
>>>
>> LOCK(local lock)
>> .......................
>> LOCK(big lock)
>> Access timer/block/network subsystem
>> UNLOCK(big lock)
>> .....................
>> UNLOCK(local lock)
>
> This is an invalid sequence. Either the subsystem has to be fine-grain
> locked, or the lock order has to be reversed.
>
Oh! And from this thread, my understanding of the reason for the rule
of lock sequence: coarse->fine is that biglock means higher
possibility of conflict, so we try it first, then try the fine-lock.
In this way, we have a smaller window for holding fine-lock which
means the other thread can get this lock more smoothly. Right?
NOT want to open an argument, just a question, is there any reason for
the sequence
devlock->timelock?
Regards,
pingfan
> Before we finish subsystem conversion, an mmio dispatcher may look like:
>
> dev_write(...)
> {
> lock(s->lock)
> switch (addr) {
> case REGA:
> ...
> case REGB:
> ...
> case REGC:
> unlock(s->lock)
> lock(big lock)
> lock(s->lock)
> qemu_mod_timer()
> unlock(bit lock)
> break;
> ...
> }
> unlock(s->lock)
> }
>
>
>
> --
> error compiling committee.c: too many arguments to function
