提示：本文基于開源鴻蒙內核分析，官方原始碼【kernel_liteos_a】官方檔案【docs】參考檔案【Huawei LiteOS】
本文作者：鴻蒙內核發燒友，將持續研究鴻蒙內核，更新博文，敬請關注，內容僅代表個人觀點，錯誤之處，歡迎大家指正完善，本系列全部文章進入 查看 鴻蒙系統原始碼分析(總目錄)
本文分析任務調度機制原始碼 詳見:../kernel/base/sched/sched_sq/los_sched.c
目錄
建議先閱讀
為什么學一個東西要學那么多的概念？
行程和執行緒的狀態遷移圖
誰來觸發調度作業？
原始碼告訴你調度程序是怎樣的？
請讀懂內核最美函式 OsGetTopTask()
建議先閱讀
閱讀之前建議先讀本系列其他文章，進入鴻蒙系統原始碼分析(總目錄)
以便對本文任務調度機制的理解，
為什么學一個東西要學那么多的概念？
鴻蒙的內核中 Task 和 執行緒 在廣義上可以理解為是一個東西，但狹義上肯定會有區別，區別在于管理體系的不同，Task是調度層面的概念，執行緒是行程層面概念，比如 main() 函式中首個函式 OsSetMainTask(); 就是設定啟動任務，但此時啥都還沒開始呢，Kprocess 行程都沒創建，怎么會有大家一般意義上所理解的執行緒呢，狹義上的后續有 鴻蒙內核原始碼分析(啟動程序篇) 來說明，不知道大家有沒有這種體會，學一個東西的程序中要接觸很多新概念，尤其像 Java/android 的生態，概念賊多，很多同學都被繞在概念中出不來，痛苦不堪，那問題是為什么需要這么多的概念呢？
舉個例子就明白了：
假如您去深圳參加一個面試老板問你哪里人？你會說是 江西人，湖南人... 而不會說是張家村二組的張全蛋，這樣還誰敢要你，但如果你參加同鄉會別人問你同樣問題，你不會說是來自東北那旮沓的，卻反而要說張家村二組的張全蛋，明白了嗎？張全蛋還是那個張全蛋，但因為場景變了，您的說法就得必須跟著變，否則沒法愉快的聊天，
那程式設計就是源于生活，歸于生活，大家對程式的理解就是要用生活中的場景去打比方，更好的理解概念，你說呢？
那在內核的調度層面，咱們就說task, task是內核調度的單元，調度就是圍著它轉，
行程和執行緒的狀態遷移圖
先看看task從哪些渠道產生：
渠道很多，可能是shell 的一個命令，也可能由內核創建，更多的是大家撰寫應用程式new出來的一個執行緒，
調度的內容已經有了，那他們如何有序的被調度？答案：是32個行程和執行緒就緒佇列，各32個哈，為什么是32個，鴻蒙系統原始碼分析(總目錄)文章里有詳細說明，自己去翻，
這張行程狀態遷移示意圖一定要看明白，執行緒的狀態遷移大家去官方檔案看，不一一列出來，太多了占地方，
注意行程和執行緒都只有就緒狀態的佇列(阻塞執行緒pendlist是鏈表，內核并沒有用佇列去描述它)但有 因為就緒就意味著作業都準備好了就等著CPU來執行了，有三種情況會加入就緒佇列
-
Init→Ready：
行程創建或fork時，拿到該行程控制塊后進入Init狀態，處于行程初始化階段，當行程初始化完成將行程插入調度佇列，此時行程進入就緒狀態，
-
Pend→Ready / Pend→Running：
阻塞行程內的任意執行緒恢復就緒態時，行程被加入到就緒佇列，同步轉為就緒態，若此時發生行程切換，則行程狀態由就緒態轉為運行態，
-
Running→Ready：
行程由運行態轉為就緒態的情況有以下兩種：
- 有更高優先級的行程創建或者恢復后，會發生行程調度，此刻就緒串列中最高優先級行程變為運行態，那么原先運行的行程由運行態變為就緒態，
- 若行程的調度策略為SCHED_RR，且存在同一優先級的另一個行程處于就緒態，則該行程的時間片消耗光之后，該行程由運行態轉為就緒態，另一個同優先級的行程由就緒態轉為運行態，
誰來觸發調度作業？
就緒佇列讓task各就各位，在其生命周期內不停的進度狀態流轉，那是什么讓調度去作業的，它是如何被觸發的？
筆者能想到的觸發方式是以下四個：
- Tick(時鐘管理)，類似于JAVA的定時任務，時間到了就觸發，系統定時器是內核時間機制中最重要的一部分，它提供了一種周期性觸發中斷機制，即系統定時器以HZ（時鐘節拍率）為頻率自行觸發時鐘中斷，當時鐘中斷發生時，內核就通過時鐘中斷處理程式OsTickHandler對其進行處理，鴻蒙內核默認是10ms觸發一次，執行以下中斷函式：
/*
* Description : Tick interruption handler
*/
LITE_OS_SEC_TEXT VOID OsTickHandler(VOID)
{
UINT32 intSave;
TICK_LOCK(intSave);
g_tickCount[ArchCurrCpuid()]++;
TICK_UNLOCK(intSave);
#ifdef LOSCFG_KERNEL_VDSO
OsUpdateVdsoTimeval();
#endif
#ifdef LOSCFG_KERNEL_TICKLESS
OsTickIrqFlagSet(OsTicklessFlagGet());
#endif
#if (LOSCFG_BASE_CORE_TICK_HW_TIME == YES)
HalClockIrqClear(); /* diff from every platform */
#endif
OsTimesliceCheck();
OsTaskScan(); /* task timeout scan *///*kyf 任務掃描，發起調度
#if (LOSCFG_BASE_CORE_SWTMR == YES)
OsSwtmrScan();
#endif
}里面對任務進行了掃描，呼叫任務調度
- 第二個是各種軟硬中斷，如何USB插拔，鍵盤，滑鼠這些外設引起的中斷，
- 第三個是程式主動中斷，比如運行程序中需要申請其他資源，而主動讓出控制權
- 最后一個是創建一個新任務后主動發起的搶占式調度
- 哪些地方會申請調度？看一張圖，
這里提下圖中的 OsCopyProcess(), 這是fork行程的主體函式，可以看出fork之后立即申請了一次調度，
LITE_OS_SEC_TEXT INT32 LOS_Fork(UINT32 flags, const CHAR *name, const TSK_ENTRY_FUNC entry, UINT32 stackSize)
{
UINT32 cloneFlag = CLONE_PARENT | CLONE_THREAD | CLONE_VFORK | CLONE_FILES;
if (flags & (~cloneFlag)) {
PRINT_WARN("Clone dont support some flags!\n");
}
flags |= CLONE_FILES;
return OsCopyProcess(cloneFlag & flags, name, (UINTPTR)entry, stackSize);
}
STATIC INT32 OsCopyProcess(UINT32 flags, const CHAR *name, UINTPTR sp, UINT32 size)
{
UINT32 intSave, ret, processID;
LosProcessCB *run = OsCurrProcessGet();
LosProcessCB *child = OsGetFreePCB();
if (child == NULL) {
return -LOS_EAGAIN;
}
processID = child->processID;
ret = OsForkInitPCB(flags, child, name, sp, size);
if (ret != LOS_OK) {
goto ERROR_INIT;
}
ret = OsCopyProcessResources(flags, child, run);
if (ret != LOS_OK) {
goto ERROR_TASK;
}
ret = OsChildSetProcessGroupAndSched(child, run);
if (ret != LOS_OK) {
goto ERROR_TASK;
}
LOS_MpSchedule(OS_MP_CPU_ALL);
if (OS_SCHEDULER_ACTIVE) {
LOS_Schedule();//*kyf 申請調度
}
return processID;
ERROR_TASK:
SCHEDULER_LOCK(intSave);
(VOID)OsTaskDeleteUnsafe(OS_TCB_FROM_TID(child->threadGroupID), OS_PRO_EXIT_OK, intSave);
ERROR_INIT:
OsDeInitPCB(child);
return -ret;
}原來創建一個行程這么簡單，真的就是在COPY！
原始碼告訴你調度程序是怎樣的？
以上是需要提前了解的資訊，接下來直接上原始碼看調度程序吧，檔案就三個函式，主要就是這個了：
VOID OsSchedResched(VOID)
{
LOS_ASSERT(LOS_SpinHeld(&g_taskSpin));//*kyf 調度程序要上鎖
newTask = OsGetTopTask(); //*kyf 獲取最高優先級任務
OsSchedSwitchProcess(runProcess, newProcess);//*kyf 切換運行的行程
(VOID)OsTaskSwitchCheck(runTask, newTask);
OsCurrTaskSet((VOID*)newTask);//*kyf 設定當前任務
if (OsProcessIsUserMode(newProcess)) {
OsCurrUserTaskSet(newTask->userArea);//*kyf 運行空間
}
/* do the task context switch */
OsTaskSchedule(newTask, runTask); //*kyf 切換任務背景關系
}函式有點長，筆者留了最重要的幾行，看這幾行就夠了，流程如下:
- 調度程序要自旋鎖，不允許任何中斷發生，沒錯，說的是任何事是不能去打斷它，否則后果太嚴重了，這可是內核在切換行程和執行緒的操作啊，
- 在就緒佇列里找個最高優先級的task
- 切換行程，就是task/執行緒 歸屬的那個行程為當前行程
- 設定它為當前任務
- 用戶模式需要設定運行空間，因為每個行程的空間是不一樣的
- 是最重要的，切換任務背景關系，引數是新老兩個任務，一個要保存現場，一個要恢復現場，
什么是任務背景關系？看鴻蒙系統原始碼分析(總目錄)其他文章，有專門的介紹，這里要說明的是 在CPU的層面，它只認任務背景關系！這里看不到任何代碼了，因為這是跟CPU相關的，不同的CPU需要去適配不同的匯編代碼，所以這些匯編代碼不會出現在一個通用工程中，請留意后續 鴻蒙內核原始碼分析(匯編指令篇)，
請讀懂內核最美函式 OsGetTopTask()
最后留個作業，讀懂這個筆者認為的內核最美函式，就明白了就緒佇列是怎么回事了，
LITE_OS_SEC_TEXT_MINOR LosTaskCB *OsGetTopTask(VOID)
{
UINT32 priority, processPriority;
UINT32 bitmap;
UINT32 processBitmap;
LosTaskCB *newTask = NULL;
#if (LOSCFG_KERNEL_SMP == YES)
UINT32 cpuid = ArchCurrCpuid();
#endif
LosProcessCB *processCB = NULL;
processBitmap = g_priQueueBitmap;
while (processBitmap) {
processPriority = CLZ(processBitmap);
LOS_DL_LIST_FOR_EACH_ENTRY(processCB, &g_priQueueList[processPriority], LosProcessCB, pendList) {
bitmap = processCB->threadScheduleMap;
while (bitmap) {
priority = CLZ(bitmap);
LOS_DL_LIST_FOR_EACH_ENTRY(newTask, &processCB->threadPriQueueList[priority], LosTaskCB, pendList) {
#if (LOSCFG_KERNEL_SMP == YES)
if (newTask->cpuAffiMask & (1U << cpuid)) {
#endif
newTask->taskStatus &= ~OS_TASK_STATUS_READY;
OsPriQueueDequeue(processCB->threadPriQueueList,
&processCB->threadScheduleMap,
&newTask->pendList);
OsDequeEmptySchedMap(processCB);
goto OUT;
#if (LOSCFG_KERNEL_SMP == YES)
}
#endif
}
bitmap &= ~(1U << (OS_PRIORITY_QUEUE_NUM - priority - 1));
}
}
processBitmap &= ~(1U << (OS_PRIORITY_QUEUE_NUM - processPriority - 1));
}
OUT:
return newTask;
}
#ifdef __cplusplus
#if __cplusplus
}本篇就先寫這么多吧，鴻蒙內核原始碼雖然檔案不多，但關系及其復雜，拆解原始碼是件辛苦也是快樂的事，撰寫成文分享給大家更是件痛并快樂著的事，喜歡的就點個贊吧，謝謝支持！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/114950.html
標籤：其他
上一篇：Android微信登錄開發集成