标签：大小   频繁   状态   question   stack   个数   实现   不用   flow   

翻译自：https://stackoverflow.com/questions/3652056/how-efficient-is-locking-an-unlocked-mutex-what-is-the-cost-of-a-mutex

一个锁，锁很多数据；还是一个数据一个锁？

如果有很多线程频繁的访问这些数据，那么多个锁，可以增加并行性。不过锁太多不太好维护，损失了代码的可维护性。

锁操作会不会很耗性能? 或者说，一个锁操作有多少汇编指令？耗时多久？ (解锁操作呢)?

那点汇编指令对性能的影响微乎其微，性能影响的大头是内存/缓存的一致性保证(memory/cache coherency guarantees). 所以锁操作越少越好。

互斥量主要有两部分组成 (简化后):

• (1) 一个标记（标记锁处于什状态，锁了还是没锁）
• (2) 等待队列

标记状态的改变，就几条指令，一般不会有syscall.
如果试图获取一个已经锁住的锁，那么调用线程会被添加到等待队列里面，开始等待。这个操作需要通过系统调用来实现。
解锁时，如果等待队列为空，那么什么都不用干，不影响性能；如果队列不为空，那么需要唤醒一个等待的线程，这个操作也需要通过系统调用来实现。
系统调用，一般比较耗性能，不过有的平台可能有做优化，也会非常快。
锁住一个未锁的锁很cheap，打开一个锁时，如果等待队列为空，也很cheap。

互斥量会不会很耗资源? 太多的互斥量会不会引起问题? 或者说，互斥量像int一样，可以随便用?

可以像int一样使用，限制互斥量数量的是你的程序可以申请的内存大小。

总结

• 锁少，好调试，影响并行性（参考问题一）
• 锁多，难调试，并行性高。

所以要具体问题具体对待

std::mutex的一些性能疑问

标签：大小   频繁   状态   question   stack   个数   实现   不用   flow   

原文地址：https://www.cnblogs.com/ConfuciusPei/p/12359126.html