qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [big lock] Discussion about the convention of device's


From: Avi Kivity
Subject: Re: [Qemu-devel] [big lock] Discussion about the convention of device's DMA each other after breaking down biglock
Date: Wed, 19 Sep 2012 13:06:52 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0

On 09/19/2012 12:51 PM, Paolo Bonzini wrote:
> Il 19/09/2012 11:21, Avi Kivity ha scritto:
>>> > I don't know if the front-end (device) lock should come before or after
>>> > the back-end (e.g. netdev) lock in the hierarchy, but that's another 
>>> > story.

>> I would say device -> backend.  It's natural if the backend is the timer
>> subsystem, so extend it from there to the block and network layers.  Of
>> course callbacks want it to be the other way round.
> 
> Yes, that's what I wasn't sure about.  In many cases I believe callbacks
> can just release the backend lock.  It works for timers, for example:
> 
>     for(;;) {
>         ts = clock->active_timers;
>         if (!qemu_timer_expired_ns(ts, current_time)) {
>             break;
>         }
>         /* remove timer from the list before calling the callback */
>         clock->active_timers = ts->next;
>         ts->next = NULL;
> 
>         /* run the callback (the timer list can be modified) */
> -       ts->cb(ts->opaque);
> +       cb = ts->cb;
> +       opaque = ts->opaque;
> +       unlock();
> +       cb(opaque);
> +       lock();
>     }
> 
> (The hunch is that ts could be deleted exactly at the moment the
> callback is unlocked.  This can be solved with ref/unref on the opaque
> value, as you mention below).

Are you saying that this works as is or not?  It does seem broken wrt
deletion; after qemu_del_timer() completes the caller expects the
callback not to be called.

This isn't trivial to guarantee, we need something like

   dispatch_timer():
      pending += 1
      timer.ref()
      drop lock
      timer.cb()
      take lock
      timer.unref()
      pending -= 1
      notify

   del_timer():
      take lock
      timer.unlink()
      while pending:
          wait for notification
      drop lock

but, if del_timer is called with the device lock held, we deadlock. ugh.

-- 
error compiling committee.c: too many arguments to function



reply via email to

[Prev in Thread] Current Thread [Next in Thread]