今天的兩個收獲--linux的特性和海森堡式錯誤

今天我看了一個守護程序的man手冊，加深了我對linux的了解，這個守護程序就是netplugd，它主要就是檢測網絡接口的狀态，一旦一個網卡接口接通了，那麼就會調用ifup，相反down掉了就會調用ifdown，這裡涉及兩個問題，第一，使用者守護程序netplugd怎麼檢測到網絡接口的狀态；第二，使用者程序netplug怎麼知道檢測到接口變化以後要怎麼做。對于第一個問題，答案就是netlink套接字，核心肯定知道網絡接口的實時狀态，一旦知道了狀态就會用netlink通知使用者空間的netplugd守護程序，核心隻管通知，而根本不管使用者守護程序會怎麼做，進而我們知道核心提供機制，而使用者守護程序提供政策，對于第二個問題，答案就是配置檔案，當守護程序netplugd接收到netlink的資訊後，自己隻管接收到而不管具體怎麼做，它隻是核心機制和真正政策的二傳手，真正的政策需要配置檔案來定義，它實際上調用了/etc/netplug.d/netplug腳本來執行政策，這裡我們知道netplugd守護程序提供機制，而腳本配置檔案提供政策。進而我總結出，在linux中，一般的核心機制都會存在一個使用者程序，而一個使用者程序一般都會有一個配置檔案，分層次地展現機制和政策的思想，使用者程序作為核心機制的政策和使用者配置的機制相當于一個二傳手存在。

接下來的第二個收獲就是海森堡式錯誤，這是在核心郵件清單中的一個朋友的回複中學到的，有位朋友問wake_up和printk有什麼關系？為什麼他調用printk就可以正常執行，而不調用printk核心線程就會鎖在那裡，我感覺他肯定是在寫代碼時造成了終端的競争，因為printk可能要用到終端列印，但是我還是感覺這二者不應該有什麼實質性的關系的，後來另一位朋友發言了，這個論點十分精辟，他的回答如下：“海森堡形bug, 來自海森堡測不準原理 當你測試的時候就沒有發生相應的bug。因為測試的代碼帶來一些時間的消耗, 記憶體/cache的副作用...等待 導緻結果正确。50%是跟臆斷代碼執行的先後關系有關. printk() 僅僅是消耗了一些時間,

使得異步執行的語句的順序跟你原來編碼時臆想的一樣, 結果就正确了.”有了這個回答的原文，我就不多說什麼了，呵呵，很有趣的。

 本文轉自 dog250 51CTO部落格，原文連結:http://blog.51cto.com/dog250/1273952