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