Real-World Concurrency阅读笔记

文章名称： Real-World Concurrency
链接： http://queue.acm.org/detail.cfm?id=1454462
由于文章是领域内高人多年经验的总结，有很多地方理解不够深刻，只能先写下自己的理解。
文章首先介绍了并发行的历史:提高系统并发性的唯一目标就是提高性能。并发性提高性能的三种方式：减少、隐藏延迟；提高吞吐量。
接下来是一系列的建议：
建议1： 辨别系统的热点和非热点路径，并区别对待。 对于非热点路径，不要花太多心思提高并发：效果不彰、容易出错。关于容易出错这一点，系统的非热点路径很多时候是很难实现并发和易出错的代码（如启动、初始化）

建议2： 数据说话，直觉不一定可靠。获取数据并不容易：搭建软硬件环境。软件环境中需要有强大的系统动态性能分析工具。

建议3： 仔细权衡对大锁的处理。将全局锁改造成per-cpu lock, lock哈希表，单结构体锁貌似很酷，但有时通过减短持有大锁的时间更为明智。

建议4： 读写锁的陷阱。当出现读多写少的锁时，直观上倾向于改造成读写锁，当锁持有时间不是很长时间，这样做是否能改进并发性（扩展性）值得商榷，仔细评估。

建议5： 采用per-cpu锁。两个建议：考虑到实现上会增加复杂度，采用per-cpu锁也需要热点分析数据的支持；保持以同样的顺序获取锁，避免死锁。

建议6：权衡合适用广播、何时用signal
建议7：学会事后分析。如利用coredump查找问题。
建议8：将系统设计成组件化（模块化）的。模块化和锁/条件变量是可以共存的，实现的方式有两种：将锁/条件变量限制在子系统内部；无锁化。
建议9：当mutex满足要求时，不要使用semaphore。
建议10：采用memory retiring来实现per-chain哈希表锁。当需要并行化对hash表的访问时，可以采用per-chain的锁。
建议12：避免false sharing。
建议13：采用同步非阻塞函数监控竞态条件。
建议14：如非必须，不用waitfree和lockfree技巧。
建议15： 时时保持一颗红心两种准备。很难知道当前解决的并发性问题是否是最后一个。