27.06.2017 18:31, Vladimir Sementsov-Ogievskiy wrote:
27.06.2017 17:26, Paolo Bonzini wrote:
On 27/06/2017 16:20, Vladimir Sementsov-Ogievskiy wrote:
I'm likely not right, but for me introducing this mutex looks like
dirty
bitmaps may be accessed from concurrent threads. So for me it looks
strange that only accessors are protected by the mutex and not the
whole
transactions.
There must be something else protecting the whole transaction.
One example I've wrote above, other examples from code: are
qmp_block_dirty_bitmap** functions:
bdrv_create_dirty_bitmap() {
bdrv_find_dirty_bitmap()
....
bdrv_dirty_bitmaps_lock(bs);
QLIST_INSERT_HEAD(&bs->dirty_bitmaps, bitmap, list);
bdrv_dirty_bitmaps_unlock(bs);
}
- we protect inserting into list from other threads, but what prevent
creating bitmap with the same name from other thread after
bdrv_find_dirty_bitmap() and before bdrv_dirty_bitmaps_lock() ?
It's like a read-write lock.
Ok, finally I understand (not all, but the main idea=), sorry for
annoying.
Is there any example of accessing dirty bitmaps for read not under BQL
but only under dirty bitmap lock?
The write side is invoked under the 'big QEMU lock' so there cannot be
two concurrent writes.
A bitmap can be written to after bdrv_find_dirty_bitmap returns, but
only if _you_ tell another thread about the bitmap you've just created.
If that doesn't happen, the bitmap cannot change. And it can also
disappear because _your_ thread is the one with the big QEMU lock.
Paolo
--
Best regards,
Vladimir
