linux编程的108种奇易做图巧计-7(再答gangban_lau)

再答gangban_lau:http://blog.csdn.net/gangban_lau/archive/2010/11/10/6000977.aspx

博客确实不是很好的讨论平台。

对于是否原子性这个问题，我们在水木体系结构版曾讨论过这个话题，参见yifanw的发言，“在所有mordern archiecture上，对齐的machine word读写肯定是atomic的，这点无须质疑”，当然体系架构变化后这个假设变化了，整个都要发生变化，正确性就不被保证了。但是这个体系架构变化的可能性太小了，未来很长一段时间不太可能，即便变了也会考虑兼容性， __sig_atomic_在linux里定义为一个ordinary int : typedef int __sig_atomic_t;当然如果写__sig_atomic_t会更好，当前没什么价值，但为了将来的移植性好，这是对的，大家都遵守__sig_atomic_t语义，将来肯定是有好处的，这是毫无疑问的。严谨的角度看的确应该如此写。

你说的“也许有个实现碰巧出现 size_t 需要两次 bus access才能取到完整的值。”，因为都是在栈上定义的，所以肯定都是对齐的，所以真的不会出现碰巧需要两次bus access的可能性，如果这一点我说的不能让你信服，你可以查查资料，这个都是公知的。我这个人也比较较真，但我要看到实践，你说月球上可能碰巧有水，我不能证明月球上无水，因为不可能遍历地球每一片土地，但要说月球有水需要拿出证据才好。因为目前没有一个人能拿出月球上有水的证据，而大部分证据证明月球上无水，所以现在公认月球上无水，应该是合理的。

对spin lock来说，我是比较经验主义的，相信第一手的实践的东西，但是实践的环境总是有限的，不免陷入局限，以后体系结构变了不兼容现在了这种情况也是有可能的。超高并发，或者多核心的情况慢可能会存在，我想也一定会存在，应该具体问题具体分析，spin lock是有应用场合的，比如一次慢速的磁盘访问还spin lock显然就不合适了。就应该把自己放到阻塞态去。

关于你说的题外话，http://blog.csdn.net/pennyliang/archive/2010/10/28/5971059.aspx上提到了-O3的优化编译，还贴了代码，来证明需要手工优化，因为加了-OX的优化后，汇编代码就很难看懂了，这是我不用-O的原因，如果需要，以后我都加上。

再比如，结构体建议是2的幂（第二篇），以及false shareing问题都是经典的优化问题，这个应该不存在什么疑问吧，即便在-O3，-O2也是避免不了的，不信的话可以实验看看，呵呵。

很多时候，我们做的东西在一个平台上好用了，移植到另一个平台可能就出问题了，优化在一个平台上有效，换了另一个平台可能出问题，甚至会有机器性能提升了，反而程序性能下降了，但遗憾的是，真的没有办法去照顾到所有可能的平台，一些general的东西应该写入教材，而不是写在博客中，博客中是难免局限的。好在我的博客中有申明：“不代表学术立场，只是非正式交流”呵呵。

到目前为止机器的很多问题，我还没有能力完全解释，相信有这个能力完全解释的人且愿意分享的人也会很多，因为操作系统太复杂，涉及的问题太多，我们的研究只能固定住其他的点，只对一个点进行研究讨论，但实践环节中，比如搜索引擎，影响性能的原因太多了，要找到全部的原因，进行深入的定量的分析和解释，需要对操作系统，指令集等等一系列深入理解，我有一个心愿，在有限的将来可以写一本《计算原理》这本书，能够把问题讲明白，遗憾的是我现在还在努力学习中，不断探索，只是我有时候停止脚步，趴下来，把肩膀露出来，垫更多的人从我的肩膀上去，去看到曾让我着迷的东西，和我一起去探索背后的原理。

最后，欢迎大家都来进行实验和质疑，实践和质疑才是进步的前提，感谢gangban_lau提出的质疑。

补充：综合编程 , 其他综合 ,