Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Fam Zheng (famz@redhat.com) wrote:
> On Tue, 08/22 10:56, Peter Xu wrote:
> > I haven't really encountered (c), but I think it's the migrate_cancel
> > command that matters, which should not need BQL as well.
> 
> There is bdrv_invalidate_cache_all() in migrate_cancel which clearly isn't safe.
> Is that if block unreachable in this case? If so we should assert, otherwise
> this command is not okay to run without BQL.

Hmm yes that's a fairly recent addition to migrate_cancel - it used to
be a simplish shutdown();  still I think it must be possible to get
back to a simple shutdown() which is run directly with the cache stuff
perhaps coming along later;  actually the tricky bit is that the fd for
the shutdown() isn't just a simple int, but is in an object which
we have to make sure doesn't get freed while we do it.

> Generically, what guarantee the thread-safety of a qmp command when you decide
> BQL is not needed? In other words, how do you prove commands are safe without
> BQL? I think almost every command accesses global state, but lock-free data
> structures are rare AFAICT.

I'm assuming there would initially be very few commands marked as
lock-free, that were mostly trivially small.

I was thinking that it might be possible to do a debug build with
some checking as well; something like making the code that takes
the bql check a per-thread flag, and assert if the flag is set.
The monitor-threads could set the flag, so that if we fell
down a path that tried to take the BQL we'd fail.

Dave

> Fam
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK