通常，当使用“普通”互斥锁时，可以像在from PIL import ImageQt
qimagein = ImageQt.ImageQt(im)
中那样使用它。
但是，现在使用remove1()和shared_lock，是否应该先使用共享锁，而仅在必要时使用唯一锁？请注意，当模型不存在时，unique_lock可能不需要remove()。
unique_lock答案 0 :(得分：2)
sharedLock.unlock(); std::unique_lock<std::shared_mutex> uniqueLock(mutex_);
仅因为两个操作分别是原子操作，并不意味着一个操作后跟另一个操作代表一个原子序列。放弃锁后，您放弃。如果该互斥锁可以保护对容器的访问，则没有什么可以防止您拥有的迭代器失效。
您要尝试的是让内部unique_lock在独占模式下原子升级外部shared_lock。在C ++ 17中根本无法做到这一点。
当然，您永远不会在离开shared_lock块之前重新锁定if，因此在擦除一个元素之后，您会遇到麻烦。
这忽略了一个事实，只要您在任一循环中erase一个元素，都将跳过下一个。 erase返回的迭代器指向下一个元素，循环头中的++it将跳过它。这两个功能都是如此。
但是无论如何，shared_mutex的总体目的是允许多个读者，但只能有一个修饰符。您的整个操作实际上是修改操作。它可以有条件地进行修改，但是从原子上讲它是一个修改操作。您想要的是让所有人都看到操作之前的列表，或者让所有人都看到之后的列表，所有匹配的元素都将被删除。修改列表时，没人会看到该列表。
因此它应该使用互斥访问。