/******************
* linux內核的時間管理
******************/
(1)內核中的時間概念
時間管理在linux內核中占有非常重要的作用。
相對于事件驅動而言，內核中有大量函數是基于時間驅動的。
有些函數是周期執行的，比如每10毫秒刷新一次屏幕；
有些函數是推后一定時間執行的，比如內核在500毫秒后執行某項任務。
要區分：
- *絕對時間和相對時間
- *周期性產生的事件和推遲執行的事件
周期性事件是由系統系統定時器驅動的
(2)HZ值
內核必須在硬件定時器的幫助下才能計算和管理時間。
定時器產生中斷的頻率稱為節拍率(tick rate)。
在內核中指定了一個變量HZ，內核初始化的時候會根據這個值確定定時器的節拍率。
HZ定義在<asm/param.h>，在i386平臺上，目前采用的HZ值是1000。
也就是時鐘中斷每秒發生1000次，周期為1毫秒。即：
#define HZ 1000
注意！HZ不是個固定不變的值，它是可以更改的，可以在內核源代碼配置的時候輸入。
不同的體系結構其HZ值是不一樣的，比如arm就采用100。
如果在驅動中要使用系統的中斷頻率，直接使用HZ，而不要用100或1000
a.理想的HZ值
i386的HZ值一直采用100，直到2.5版后才改為1000。
提高節拍率意味著時鐘中斷產生的更加頻繁，中斷處理程序也會更頻繁地執行。
帶來的好處有：
- *內核定時器能夠以更高的頻率和更高的準確度運行
- *依賴定時器執行的系統調用，比如poll()和select()，運行的精度更高
- *提高進程搶占的準確度
(縮短了調度延時，如果進程還剩2ms時間片，在10ms的調度周期下，進程會多運行8ms。
由于耽誤了搶占，對于一些對時間要求嚴格的任務會產生影響)
壞處有：
*節拍率要高，系統負擔越重。
中斷處理程序將占用更多的處理器時間。
(3)jiffies
全局變量jiffies用于記錄系統啟動以來產生的節拍的總數。
啟動時，jiffies初始化為0，此后每次時鐘中斷處理程序都會增加該變量的值。
這樣，系統啟動后的運行時間就是jiffies/HZ秒
jiffies定義于<linux/jiffies.h>中：
extern unsigned long volatile jiffies;
jiffies變量總是為unsigned long型。
因此在32位體系結構上是32位，而在64位體系上是64位。對于32位的jiffies，如果HZ為1000，49.7天后會溢出。雖然溢出的情況不常見，但程序在檢測超時時仍然可能因為回繞而導致錯誤。linux提供了4個宏來比較節拍計數，它們能正確地處理節拍計數回繞。
#include <linux/jiffies.h>
#define time_after(unknown, known) // unknow > known
#define time_before(unknown, known) // unknow < known
#define time_after_eq(unknown, known) // unknow >= known
#define time_before_eq(unknown, known) // unknow <= known
unknown通常是指jiffies，known是需要對比的值(常常是一個jiffies加減后計算出的相對值)例：
unsigned long timeout = jiffies + HZ/2; /* 0.5秒后超時 */
...
if(time_before(jiffies, timeout)){
/* 沒有超時，很好 */
}else{
/* 超時了，發生錯誤 */
time_before可以理解為如果在超時(timeout)之前(before)完成
*系統中還聲明了一個64位的值jiffies_64，在64位系統中jiffies_64和jiffies是一個值。
可以通過get_jiffies_64()獲得這個值。
*使用
u64 j2;
j2 = get_jiffies_64();
(4)獲得當前時間
驅動程序中一般不需要知道墻鐘時間(也就是年月日的時間)。但驅動可能需要處理絕對時間。
為此，內核提供了兩個結構體，都定義在<linux/time.h>：
struct timeval {
time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* microseconds */
};
//較老，但很流行。采用秒和毫秒值，保存了1970年1月1日0點以來的秒數
struct timespec {
time_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
//較新，采用秒和納秒值保存時間。
do_gettimeofday()該函數用通常的秒或微秒來填充一個指向struct timeval的指針變量，原型如下：
#include <linux/time.h>
void do_gettimeofday(struct timeval *tv);
current_kernel_time()該函數可用于獲得timespec
#include <linux/time.h>
struct timespec current_kernel_time(void);
/********************
*確定時間的延遲執行
*******************/
設備驅動程序經常需要將某些特定代碼延遲一段時間后執行，通常是為了讓硬件能完成某些任務。
長于定時器周期(也稱為時鐘嘀嗒)的延遲可以通過使用系統時鐘完成，而非常短的延時則通過軟件循環的方式完成
(1)短延時
對于那些最多幾十個毫秒的延遲，無法借助系統定時器。
系統通過軟件循環提供了下面的延遲函數：
#include <linux/delay.h>
/* 實際在<asm/delay.h> */
void ndelay(unsigned long nsecs); /*延遲納秒 */
void udelay(unsigned long usecs); /*延遲微秒 */
void mdelay(unsigned long msecs); /*延遲毫秒 */
這三個延遲函數均是忙等待函數，在延遲過程中無法運行其他任務。
實際上，當前所有平臺都無法達到納秒精度。
(2)長延時
a.在延遲到期前讓出處理器
while(time_before(jiffies, j1))
schedule();
在等待期間可以讓出處理器，但系統無法進入空閑模式(因為這個進程始終在進行調度)，不利于省電。
b.超時函數
#include <linux/sched.h>
signed long schedule_timeout(signed long timeout);
使用方式：
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(2*HZ); /* 睡2秒 */
進程經過2秒后會被喚醒。如果不希望被用戶空間打斷，可以將進程狀態設置為TASK_UNINTERRUPTIBLE。
(3)等待隊列
使用等待隊列也可以實現長延遲。
在延遲期間，當前進程在等待隊列中睡眠。
進程在睡眠時，需要根據所等待的事件鏈接到某一個等待隊列。
a.聲明等待隊列
等待隊列實際上就是一個進程鏈表，鏈表中包含了等待某個特定事件的所有進程。
#include <linux/wait.h>
struct __wait_queue_head {
spinlock_t lock;
struct list_head task_list;
};
typedef struct __wait_queue_head wait_queue_head_t;
要想把進程加入等待隊列，驅動首先要在模塊中聲明一個等待隊列頭，并將它初始化。
靜態初始化
DECLARE_WAIT_QUEUE_HEAD(name);
動態初始化
wait_queue_head_t my_queue;
init_waitqueue_head(&my_queue);
b.等待函數
進程通過調用下面函數可以在某個等待隊列中休眠固定的時間：
#include <linux/wait.h>
long wait_event_timeout(wait_queue_head_t q,condition, long timeout);
long wait_event_interruptible_timeout(wait_queue_head_t q, condition, long timeout);
調用這兩個函數后，進程會在給定的等待隊列q上休眠，但會在超時(timeout)到期時返回。
如果超時到期，則返回0，如果進程被其他事件喚醒，則返回剩余的時間數。
如果沒有等待條件，則將condition設為0
使用方式：
wait_queue_head_t wait;
init_waitqueue_head(&wait);
wait_event_interruptible_timeout(wait, 0, 2*HZ);
/*當前進程在等待隊列wait中睡2秒 */
(4)內核定時器
還有一種將任務延遲執行的方法是采用內核定時器。與前面幾種延遲方法不同，內核定時器并不會阻塞當前進程，啟動一個內核定時器只是聲明了要在未來的某個時刻執行一項任務，當前進程仍然繼續執行。不要用定時器完成硬實時任務
定時器由結構timer_list表示，定義在<linux/timer.h>
struct timer_list{
struct list_head entry; /* 定時器鏈表 */
unsigned long expires; /* 以jiffies為單位的定時值 */
spinlock_t lock;
void(*function)(unsigned long); /* 定時器處理函數 */
unsigned long data; /* 傳給定時器處理函數的參數 */
}
內核在<linux/timer.h>中提供了一系列管理定時器的接口。
a.創建定時器
struct timer_list my_timer;
b.初始化定時器
init_timer(&my_timer);
/* 填充數據結構 */
my_timer.expires = jiffies + delay;
my_timer.data = 0;
my_timer.function = my_function; /*定時器到期時調用的函數*/
c.定時器的執行函數
超時處理函數的原型如下：
void my_timer_function(unsigned long data);
可以利用data參數用一個處理函數處理多個定時器?？梢詫ata設為0
d.激活定時器
add_timer(&my_timer);
定時器一旦激活就開始運行。
e.更改已激活的定時器的超時時間
mod_timer(&my_timer,
jiffies+ney_delay);
可以用于那些已經初始化但還沒激活的定時器，如果調用時定時器未被激活則返回0，否則返回1。一旦mod_timer返回，定時器將被激活。
f.刪除定時器
del_timer(&my_timer);
被激活或未被激活的定時器都可以使用，如果調用時定時器未被激活則返回0，否則返回1。不需要為已經超時的定時器調用，它們被自動刪除
g.同步刪除
del_time_sync(&my_timer);
在smp系統中，確保返回時，所有的定時器處理函數都退出。不能在中斷上下文使用。
/********************
*不確定時間的延遲執行
*******************/
(1)什么是不確定時間的延遲
前面介紹的是確定時間的延遲執行，但在寫驅動的過程中經常遇到這種情況：用戶空間程序調用read函數從設備讀數據，但設備中當前沒有產生數據。此時，驅動的read函數默認的操作是進入休眠，一直等待到設備中有了數據為止。
這種等待就是不定時的延遲，通常采用休眠機制來實現。
(2)休眠
休眠是基于等待隊列實現的，前面我們已經介紹過wait_event系列函數，但現在我們將不會有確定的休眠時間。
當進程被置入休眠時，會被標記為特殊狀態并從調度器的運行隊列中移走。
直到某些事件發生后，如設備接收到數據，則將進程重新設為運行態并進入運行隊列進行調度。
休眠函數的頭文件是<linux/wait.h>，具體的實現函數在kernel/wait.c中。
a.休眠的規則
- *永遠不要在原子上下文中休眠
- *當被喚醒時，我們無法知道睡眠了多少時間，也不知道醒來后是否獲得了我們需要的資源
- *除非知道有其他進程會在其他地方喚醒我們，否則進程不能休眠
b.等待隊列的初始化
見前文
c.休眠函數
linux最簡單的睡眠方式為wait_event宏。該宏在實現休眠的同時，檢查進程等待的條件。
1. void wait_event(
wait_queue_head_t q,
int condition);
2. int wait_event_interruptible(
wait_queue_head_t q,
int condition);
- q: 是等待隊列頭，注意是采用值傳遞。
- condition: 任意一個布爾表達式，在條件為真之前，進程會保持休眠。
- 注意！進程需要通過喚醒函數才可能被喚醒，此時需要檢測條件。
- 如果條件滿足，則被喚醒的進程真正醒來；
- 如果條件不滿足，則進程繼續睡眠。
d.喚醒函數
當我們的進程睡眠后，需要由其他的某個執行線程(可能是另一個進程或中斷處理例程)喚醒。喚醒函數：
#include <linux/wait.h>
1. void wake_up(
wait_queue_head_t *queue);
2. void wake_up_interruptible(
wait_queue_head_t *queue);
wake_up會喚醒等待在給定queue上的所有進程。而wake_up_interruptible喚醒那些執行可中斷休眠的進程。實踐中，約定做法是在使用wait_event時使用wake_up，而使用wait_event_interruptible時使用wake_up_interruptible。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。如果你想了解更多相關內容請查看下面相關鏈接
