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提出的質疑。

       

本系列其他文章：http://blog.csdn.net/pennyliang/category/746545.aspx