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.
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