首页 > 代码库 > Real-World Concurrency阅读笔记

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: 时时保持一颗红心两种准备。很难知道当前解决的并发性问题是否是最后一个。

Real-World Concurrency阅读笔记