建议2： 数据说话，直觉不一定可靠。获取数据并不容易：搭建软硬件环境。软件环境中需要有强大的系统动态性能分析工具。
建议3： 仔细权衡对大锁的处理。将全局锁改造成per-cpu lock, lock哈希表，单结构体锁貌似很酷，但有时通过减短持有大锁的时间更为明智。建议4： 读写锁的陷阱。当出现读多写少的锁时，直观上倾向于改造成读写锁，当锁持有时间不是很长时间，这样做是否能改进并发性（扩展性）值得商榷，仔细评估。
建议5： 采用per-cpu锁。两个建议：考虑到实现上会增加复杂度，采用per-cpu锁也需要热点分析数据的支持；保持以同样的顺序获取锁，避免死锁。
建议6：权衡合适用广播、何时用signal原文地址：http://blog.csdn.net/xie1xiao1jun/article/details/41546893
