在MySQL种,执行show engine innodb status \G 经常会看到里面有spin lock 及mutex的情况。我们有必要了解下这些知识。
自旋锁(spin lock)与互斥量(mutex)的比较 自旋锁是一种非阻塞锁,也就是说,如果某线程需要获取自旋锁,但该锁已经被其他线程占用时,该线程不会被挂起,而是在不断的消耗CPU的时间,不停的试图获取自旋锁。 互斥量是阻塞锁,当某线程无法获取互斥量时,该线程会被直接挂起,该线程不再消耗CPU时间,当其他线程释放互斥量后,操作系统会激活那个被挂起的线程,让其投入运行。 两种锁适用于不同场景: 如果是多核处理器,如果预计线程等待锁的时间很短,短到比线程两次上下文切换时间要少的情况下,使用自旋锁是划算的。 如果是多核处理器,如果预计线程等待锁的时间较长,至少比两次线程上下文切换的时间要长,建议使用互斥量。 如果是单核处理器,一般建议不要使用自旋锁。因为,在同一时间只有一个线程是处在运行状态,那如果运行线程发现无法获取锁,只能等待解锁,但因为自身不挂起,所以那个获取到锁的线程没有办法进入运行状态,只能等到运行线程把操作系统分给它的时间片用完,才能有机会被调度。这种情况下使用自旋锁的代价很高。 如果加锁的代码经常被调用,但竞争情况很少发生时,应该优先考虑使用自旋锁,自旋锁的开销比较小,互斥量的开销较大。 参考文献 《多核程序设计技术》 《Linux内核设计与实现》 from:http://blog.csdn.NET/swordmanwk/article/details/6819457 pthread与tbb中各种锁的对比测试 pthread中提供的锁有:pthread_mutex_t, pthread_spinlock_t, pthread_rwlock_t。 pthread_mutex_t是互斥锁,同一瞬间只能有一个线程能够获取锁,其他线程在等待获取锁的时候会进入休眠状态。因此pthread_mutex_t消耗的CPU资源很小,但是性能不高,因为会引起线程切换。 pthread_spinlock_t是自旋锁,同一瞬间也只能有一个线程能够获取锁,不同的是,其他线程在等待获取锁的过程中并不进入睡眠状态,而是在CPU上进入“自旋”等待。自旋锁的性能很高,但是只适合对很小的代码段加锁(或短期持有的锁),自旋锁对CPU的占用相对较高。 pthread_rwlock_t是读写锁,同时可以有多个线程获得读锁,同时只允许有一个线程获得写锁。其他线程在等待锁的时候同样会进入睡眠。读写锁在互斥锁的基础上,允许多个线程“读”,在某些场景下能提高性能。 诸如pthread中的pthread_cond_t, pthread_barrier_t, semaphone等,更像是一种同步原语,不属于单纯的锁。 TBB中提供的锁有: mutex 互斥锁,等同于pthread中的互斥锁(实际上就是对pthread_mutex_t进行封装) recurisive_mutex 可重入的互斥锁,在pthread_mutex_t的基础上加了一个可重入的属性 spin_metux 自旋锁,与pthread_spinlock_t类似,但是性能比pthread_spinlock_t低28% queuing_metux 公平的互斥锁,严格按照等待锁的先后顺序获得锁 spin_rw_mutex 读写自旋锁,功能与pthread_rwlock_t一致,但是性能比pthread_rwlock_t高很多 queuing_rw_mutex 公平的读写读写锁,也是严格按照等待锁的先后顺序获得锁 以下是我对一个拥有3667527个节点的HASH表进行读操作所花费的时间,可以说明各种锁的性能: (多线程的环境为:4CPU的电脑上使用四个线程进行同样的度操作,然后取四个线程读取的平均时间) ·单线程不加锁:0.818845s ·多线程使用pthread_mutex_t:120.978713s (很离谱吧…………我也吓了一跳) ·多线程使用pthread_rwlock_t:10.592172s (多个线程加读锁) ·多线程使用pthread_spinlock_t:4.766012s ·多个线程使用tbb::spin_mutex:6.638609s (从这里可以看出pthread的自旋锁比TBB的自旋锁性能高出28%) ·多个线程使用tbb::spin_rw_mutex:3.471757s (并行读的环境下,这是所有锁中性能最高的) OK,有了以上的测试结果,何种环境该使用何种锁,不辨自明。 from:http://hi.baidu.com/ah__fu/item/5bb98aaaebf5c113a9cfb758 #include <tbb/spin_rw_mutex.h> tbb::spin_rw_mutex g_rwMutex; tbb::spin_rw_mutex::scoped_lock lock(g_rwMutex); #include <boost/thread/mutex.hpp> boost::mutex io_mutex; boost::mutex::scoped_lock lock(io_mutex);