在linux下做的時鐘同步的工作終于暫時告一段落了。

前面簡單的做了客戶端和服務器端的同步，在基于時間同步的機制上，將系統(tǒng)的1s的時間劃分多個時槽。由于此時間同步應用在分布式系統(tǒng)中，涉及到多個客戶端和服務器通信的問題，因此劃分時槽是為了避免不同的客戶端的消息沖突，保證每個客戶端在自己的時槽里進行消息的發(fā)送。

整體思想是在時間同步以后，就開始判斷是否進入自己的時槽，是就喚醒一個線程進行消息發(fā)送接收處理。

起初考慮在時鐘中斷里面做，假設系統(tǒng)每秒產生1000次時鐘中斷，則周期為1ms，將1s的時間劃分為100個時槽，每個客戶端將在1秒的時間內獲得兩個時槽。

喚醒的機制最早考慮的是用信號量semaphore，我在核心定義了一個互斥信號量并初始化為加鎖的狀態(tài)，init_MUTEX_LOCKED，并將信號量導出供將要喚醒的線程使用。一進入線程主函數(shù)就使用down操作使線程阻塞等待信號量，而up操作則放在時鐘中斷中，判斷屬于自己的時槽再釋放信號量。

另一種方法就是使用wait_queue，一進入線程主函數(shù)就將線程設為不可中斷睡眠狀態(tài)，然后將線程掛到wait上，調用schedule函數(shù)進行切換，在核心要做的就是判斷屬于自己的時槽并且線程不是運行狀態(tài)時，就調用wake_up喚醒線程，如此循環(huán)。

但是上述兩種方法都遇到了一個問題，由于在內核喚醒線程，我們期望線程一經喚醒就能迅速的得到執(zhí)行，所以將線程的優(yōu)先級設置為實時優(yōu)先級，調度方式采用FIFO，一插入包含線程的模塊就會出現(xiàn)死機的情況。但如果不是實時優(yōu)先級就沒有問題。這個一直困擾著我，找不到原因所在。

再就是系統(tǒng)原有的時鐘中斷頻率太小，不能滿足我們高精度的需求，因此需要改變到1000hz。用的開發(fā)板是real6410，經過查閱內核代碼，發(fā)現(xiàn)這個板子與s3c2410一樣，都是由timer4來觸發(fā)中斷。timer4外接的時鐘可以直接選擇外部晶振的頻率，也可采用pclk。在中斷設置的函數(shù)中，首先給timer4設置一個計數(shù)初值，這個計數(shù)初值就是由timer4的頻率與系統(tǒng)中的HZ值即每秒鐘的時鐘中斷次數(shù)的比值，當timer4的計數(shù)值減為0時就觸發(fā)中斷，因此要改變時鐘中斷頻率就改變HZ到想要的值即可。

另外，還遇到的問題就是HZ雖然配置為200或者1000，但是用cat /proc/interrupts 顯示出的1秒的中斷次數(shù)僅為20多或者50多，遠遠沒有達到我們想要的值，后來發(fā)現(xiàn)在config文件里面有一個config_no_hz，經過查閱，發(fā)現(xiàn)在2.6.21內核以后引入了無滴答內核，使處理器保持低功耗狀態(tài)，我們需要多次時鐘中斷，則將config_no_hz配置為n即可。

轉載于:https://www.cnblogs.com/dearyy929/archive/2012/08/02/2620440.html

總結

以上是生活随笔為你收集整理的时钟同步及其应用（接上一篇）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。