指令是穩(wěn)定的,但指令序列是變化的,只有這樣計算機才能夠?qū)崿F(xiàn)用計算來解決一切問題這個目標。計算是穩(wěn)定的,但計算的數(shù)據(jù)是多變的,多態(tài)的,地址是數(shù)據(jù),控制信號也是數(shù)據(jù)。指令集本身也是數(shù)據(jù)(固定的數(shù)據(jù))。只有這樣才能夠讓計算機不必修改基礎架構卻可以適應不斷發(fā)展變化的技術革命。
cpu是負責執(zhí)行指令的,誰能給它指令?是線程(也叫任務), 任務是內(nèi)核的調(diào)度單元,調(diào)度到哪個任務CPU就去執(zhí)行哪個任務的指令。 要執(zhí)行指令就要有個取指令的開始地址。 開始地址就是大家所熟知的main函數(shù)。一個程序被加載解析后內(nèi)核會在ELF中找到main函數(shù)的位置,并自動創(chuàng)建一個線程,指定線程的入口地址為main函數(shù)的地址,由此開始了取指,譯指,執(zhí)指之路。
多線程內(nèi)核是怎么處理的? 一樣的, 以JAVA舉例,對內(nèi)核來說 new thread中的run() 函數(shù) 和 main() 并沒有區(qū)別。 都是一個線程(任務)的執(zhí)行入口。 注意在系列篇中反復的說任務就是線程,線程就是任務,它們是一個東西在不同層面上的描述。對應用層說線程,對內(nèi)核層說任務。 有多少個線程就會有多少個入口,它們統(tǒng)一接受調(diào)度算法的調(diào)度, 調(diào)度算法只認優(yōu)先級的高低,不會管你是main() 還是 run() 而區(qū)別對待。
定時器的實現(xiàn)也是通過任務實現(xiàn)的,只不過是個系統(tǒng)任務OsSwtmrTaskCreate,優(yōu)先級最高,和入口地址OsSwtmrTask由系統(tǒng)指定。
所以理解CPU就要先理解任務,任務是理解內(nèi)核的主線,把它搞明白了分析內(nèi)核就輕輕松松,事半功倍了??此聘呱畹腃PU只不過是摟草打兔子。不相信?那就看看內(nèi)核對CPU是怎么描述的吧。本篇就圍繞這個結構體展開說。
Percpu
percpu變量,顧名思義,就是對于同一個變量,每個cpu都有自己的一份,它可以被用來存放一些cpu獨有的數(shù)據(jù),比如cpu的id,cpu上正在運行的任務等等。
Percpu g_percpu[LOSCFG_KERNEL_CORE_NUM];//CPU核描述符,描述每個CPU的信息。
typedef struct {//內(nèi)核對cpu的描述
SortLinkAttribute taskSortLink; /* task sort link */ //掛等待和延時的任務
SortLinkAttribute swtmrSortLink; /* swtmr sort link */ //掛定時器
UINT32 idleTaskID; /* idle task id */ //空閑任務ID 見于 OsIdleTaskCreate
UINT32 taskLockCnt; /* task lock flag */ //任務鎖的數(shù)量,當 》 0 的時候,需要重新調(diào)度了
UINT32 swtmrHandlerQueue; /* software timer timeout queue id */ //軟時鐘超時隊列句柄
UINT32 swtmrTaskID; /* software timer task id */ //軟時鐘任務ID
UINT32 schedFlag; /* pending scheduler flag */ //調(diào)度標識 INT_NO_RESCH INT_PEND_RESCH
#if (LOSCFG_KERNEL_SMP == YES)
UINT32 excFlag; /* cpu halt or exc flag */ //CPU處于停止或運行的標識
#endif
} Percpu;
至于 g_percpu的值怎么來的,因和編譯過程相關,將在后續(xù)編譯篇中說明。 Percpu結構體不復雜,但很重要,一個一個掰開了說。
taskSortLink是干什么用的? 一個任務在運行過程中,經(jīng)常會主動或被動停止,而進入等待狀態(tài)。
主動停止情況, 例如:主動delay300毫秒,這是應用層很常見的操作。
被動停止情況, 例如:申請互斥鎖失敗,等待某個事件發(fā)生。 發(fā)生這些情況時任務將被掛到taskSortLink上。這些任務可能來自不同的進程,但都是因為在被這個CPU執(zhí)行時停下來了,等著再次被它執(zhí)行。下圖很清晰的看出在哪種情況下會被記錄在案。

UINT32 OsTaskWait(LOS_DL_LIST *list, UINT32 timeout, BOOL needSched)
{
LosTaskCB *runTask = NULL;
LOS_DL_LIST *pendObj = NULL;
runTask = OsCurrTaskGet();//獲取當前任務
OS_TASK_SCHED_QUEUE_DEQUEUE(runTask, OS_PROCESS_STATUS_PEND);//將任務從就緒隊列摘除,并變成阻塞狀態(tài)
pendObj = &runTask-》pendList;
runTask-》taskStatus |= OS_TASK_STATUS_PEND;//給任務貼上阻塞任務標簽
LOS_ListTailInsert(list, pendObj);//將阻塞任務掛到list上,,這步很關鍵,很重要!
if (timeout != LOS_WAIT_FOREVER) {//非永遠等待的時候
runTask-》taskStatus |= OS_TASK_STATUS_PEND_TIME;//阻塞任務再貼上在一段時間內(nèi)阻塞的標簽
OsAdd2TimerList(runTask, timeout);//把任務加到定時器鏈表中
}
if (needSched == TRUE) {//是否需要調(diào)度
OsSchedResched();//申請調(diào)度,里面直接切換了任務上下文,至此任務不再往下執(zhí)行了。
if (runTask-》taskStatus & OS_TASK_STATUS_TIMEOUT) {//這條語句是被調(diào)度再次選中時執(zhí)行的,和上面的語句可能隔了很長時間,所以很可能已經(jīng)超時了
runTask-》taskStatus &= ~OS_TASK_STATUS_TIMEOUT;//如果任務有timeout的標簽,那么就去掉那個標簽
return LOS_ERRNO_TSK_TIMEOUT;
}
}
return LOS_OK;
}
LITE_OS_SEC_TEXT STATIC INLINE VOID OsAdd2TimerList(LosTaskCB *taskCB, UINT32 timeOut)
{
SET_SORTLIST_VALUE(&taskCB-》sortList, timeOut);//設置idxRollNum的值為timeOut
OsAdd2SortLink(&OsPercpuGet()-》taskSortLink, &taskCB-》sortList);//將任務掛到定時器排序鏈表上
#if (LOSCFG_KERNEL_SMP == YES)//注意:這里的排序不是傳統(tǒng)意義上12345的排序,而是根據(jù)timeOut的值來決定放到CPU core哪個taskSortLink[0:7]鏈表上
taskCB-》timerCpu = ArchCurrCpuid();
#endif
}
OsAdd2SortLink,將任務掛到排序鏈表上,因等待時間不一樣,所以內(nèi)核會對這些任務按時間長短排序。
定時器相關三個變量,在系列篇定時器機制篇中已有對定時器的詳細描述,可前往以下查看。 v31.xx (定時器篇) | 內(nèi)核最高優(yōu)先級任務是誰? 看完后就不難理解以下三個的作用了。
SortLinkAttribute swtmrSortLink;//CPU要處理的定時器鏈表
UINT32 swtmrHandlerQueue; //隊列中放各個定時器的響應函數(shù)
UINT32 swtmrTaskID; // 其實就是 OsSwtmrTaskCreate
搞明白定時器的機制只需搞明白: 定時器(SWTMR_CTRL_S),定時任務(swtmrTaskID),定時器響應函數(shù)(SwtmrHandlerItem),定時器處理隊列swtmrHandlerQueue 四者的關系就可以了。 一句話概括:定時任務swtmrTaskID是個系統(tǒng)任務,優(yōu)先級最高,它循環(huán)讀取隊列swtmrHandlerQueue中的已到時間的定時器(SWTMR_CTRL_S),并執(zhí)行定時器對應的響應函數(shù)SwtmrHandlerItem.
idleTaskID空閑任務,注意這又是個任務,每個cpu核都有屬于自己的空閑任務,cpu沒事干的時候就待在里面??臻e任務長什么樣? Look!
//創(chuàng)建一個空閑任務
LITE_OS_SEC_TEXT_INIT UINT32 OsIdleTaskCreate(VOID)
{
UINT32 ret;
TSK_INIT_PARAM_S taskInitParam;
Percpu *perCpu = OsPercpuGet();//獲取CPU信息
UINT32 *idleTaskID = &perCpu-》idleTaskID;//每個CPU都有一個空閑任務
(VOID)memset_s((VOID *)(&taskInitParam), sizeof(TSK_INIT_PARAM_S), 0, sizeof(TSK_INIT_PARAM_S));//任務初始參數(shù)清0
taskInitParam.pfnTaskEntry = (TSK_ENTRY_FUNC)OsIdleTask;//入口函數(shù)
taskInitParam.uwStackSize = LOSCFG_BASE_CORE_TSK_IDLE_STACK_SIZE;//任務棧大小 2K
taskInitParam.pcName = “Idle”;//任務名稱 叫pcName有點怪怪的,不能換個撒
taskInitParam.usTaskPrio = OS_TASK_PRIORITY_LOWEST;//默認最低優(yōu)先級 31
taskInitParam.uwResved = OS_TASK_FLAG_IDLEFLAG;//默認idle flag
#if (LOSCFG_KERNEL_SMP == YES)//CPU多核情況
taskInitParam.usCpuAffiMask = CPUID_TO_AFFI_MASK(ArchCurrCpuid());//每個idle任務只在單獨的cpu上運行
#endif
ret = LOS_TaskCreate(idleTaskID, &taskInitParam);//創(chuàng)建task并申請調(diào)度,
OS_TCB_FROM_TID(*idleTaskID)-》taskStatus |= OS_TASK_FLAG_SYSTEM_TASK;//設置task狀態(tài)為系統(tǒng)任務,系統(tǒng)任務運行在內(nèi)核態(tài)。
//這里說下系統(tǒng)任務有哪些?比如: idle,swtmr(軟時鐘),資源回收等等
return ret;
}
LITE_OS_SEC_TEXT WEAK VOID OsIdleTask(VOID)
{
while (1) {//只有一個死循環(huán)
#ifdef LOSCFG_KERNEL_TICKLESS //低功耗模式開關, idle task 中關閉tick
if (OsTickIrqFlagGet()) {
OsTickIrqFlagSet(0);
OsTicklessStart();
}
#endif
Wfi();//WFI指令:arm core 立即進入low-power standby state,等待中斷,進入休眠模式。
}
}
OsIdleTask是一個死循環(huán),只有一條匯編指令Wfi. 啥意思? WFI(Wait for interrupt):等待中斷到來指令。 WFI一般用于cpuidle,WFI 指令是在處理器發(fā)生中斷或類似異常之前不需要做任何事情。具體在鴻蒙內(nèi)核源碼分析(總目錄)自旋鎖篇中有詳細描述,可前往查看。 說到死循環(huán),這里多說一句,從宏觀尺度上來理解,整個內(nèi)核就是一個死循環(huán)。因為有 軟硬中斷/異常 使得內(nèi)核能活躍起來,能跳到不同的地方去執(zhí)行,執(zhí)行完了又會沉寂下去,等待新的觸發(fā)到來。 這句話能理解嗎 ?
taskLockCnt 這個簡單,記錄等鎖的任務數(shù)量。任務在運行過程中優(yōu)先級是會不斷地變化的, 例如 高優(yōu)先級的A任務在等某鎖,但持有鎖的一方B任務優(yōu)先級低,這時就會調(diào)高B的優(yōu)先級至少到A的等級,提高B被調(diào)度算法命中的概率,如此就能快速的釋放鎖交給A運行。 taskLockCnt記錄被CPU運行過的正在等鎖的任務數(shù)量。
schedFlag 調(diào)度的標簽。
typedef enum {
INT_NO_RESCH = 0, /* no needs to schedule *///不需要調(diào)度
INT_PEND_RESCH, /* pending schedule flag *///阻止調(diào)度
} SchedFlag;
調(diào)度并不是每次都能成功的,在某些情況下內(nèi)核會阻止調(diào)度進行。例如:OS_INT_ACTIVE硬中斷發(fā)生的時候。
STATIC INLINE VOID LOS_Schedule(VOID)
{
if (OS_INT_ACTIVE) {//發(fā)生硬件中斷,調(diào)度被阻塞
OsPercpuGet()-》schedFlag = INT_PEND_RESCH;//
return;
}
OsSchedPreempt();//搶占式調(diào)度
}
excFlag標識CPU的運行狀態(tài),只在多核CPU下可見。
#if (LOSCFG_KERNEL_SMP == YES)
typedef enum {
CPU_RUNNING = 0, /* cpu is running */ //CPU正在運行狀態(tài)
CPU_HALT, /* cpu in the halt */ //CPU處于暫停狀態(tài)
CPU_EXC /* cpu in the exc */ //CPU處于異常狀態(tài)
} ExcFlag;
#endif
以上為內(nèi)核對CPU描述的全貌,不是很復雜.
編輯:hfy
-
cpu
+關注
關注
68文章
11226瀏覽量
223189 -
定時器
+關注
關注
23文章
3361瀏覽量
121907 -
多線程
+關注
關注
0文章
279瀏覽量
20936 -
控制信號
+關注
關注
0文章
200瀏覽量
12623
發(fā)布評論請先 登錄
鴻蒙內(nèi)核源碼Task/線程技術分析
如何同時等待多個內(nèi)核對象的返回?
ucosIII同時等待多個內(nèi)核對象為什么內(nèi)核對象不回到0
每日推薦 | 鴻蒙IPC開發(fā)板免費試用,OpenHarmony內(nèi)核對象隊列算法詳解
RT_Thread文檔—內(nèi)核對象模型-靜態(tài)對象與動態(tài)對象存儲位置疑問求解
鴻蒙內(nèi)核源碼分析:task是內(nèi)核調(diào)度的單元
RT-Thread 內(nèi)核學習筆記 - 內(nèi)核對象鏈表結構深入理解
RT-Thread 內(nèi)核學習筆記 - 內(nèi)核對象初始化鏈表組織方式
RT-Thread 內(nèi)核學習筆記 - 內(nèi)核對象操作API
RT-Thread 內(nèi)核學習筆記 - 內(nèi)核對象rt_object

鴻蒙技術:內(nèi)核對CPU是怎么描述
評論