因此，我有一个std :: map对象，该对象被多个线程同时访问，因此我决定使用unique_lock使地图操作安全。
在线程的一种实现中，某些函数正在使用map对象（这些函数通常从map对象添加/删除项），因此我想知道是否可以确保在父函数顶部定义unique_lock可以确保安全 ？还是我需要将其添加到所有这些功能中？
void Thread1() {
std::unique_lock<std::mutex> ul(mutex);
func1(); // map object is getting changed here
func2(); // map object is getting changed here
}
我在这里看到的内容无法真正起作用。如果每个线程在操作开始时都尝试获取互斥锁，则可能是死锁或顺序线程（只能运行一个线程），或者您有多个不同的互斥锁。后者是不正确的，但是前者放弃了多线程的一些好处。
如果对必须锁定的功能使用了更明确的作用域，则可以使用锁而不将其直接添加到使用中的功能。
void Thread1() {
funcA();
{// Explicit scoping
std::unique_lock<std::mutex> ul(mutex);
func1(); // map object is getting changed here
func2(); // map object is getting changed here
}
funcB();
}
我们希望在尽可能短的时间内使用锁。因此，您必须判断更改映射对象的函数是否足够小以证明在整个时间内进行锁定都是合理的。
,使用互斥量的全部目的是防止线程B，C，D等由于线程A所做的更改而看到处于不一致状态的共享数据。
您提出了以下建议：
void Thread1() {
std::unique_lock<std::mutex> ul(mutex);
func1(); // map object is getting changed here
func2(); // map object is getting changed here
}
func1()是否将映射（以及其他共享变量）保持在其他线程不应该看到的状态？ func2()是否再次使其他线程可以看到共享数据？如果是这样，那么您的榜样可能是您所希望的最好的例子。但是，如果这两个函数调用中的每一个都使共享数据处于“安全”状态，那么您可以考虑让它们各自分别锁定和解锁mutex。
如果可以设计线程以使它们通常不需要访问共享数据，并且当他们需要访问共享数据时，通常会更好。他们会尽快进出（即锁定和解锁）。
另请参见 readers writer locking （在C ++中为std::shared_lock），以防碰巧有助于解决您的特定问题。