吴忠躺衫网络科技有限公司

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

鴻蒙內(nèi)核分析:線程中斷環(huán)境下的任務(wù)切換

鴻蒙系統(tǒng)HarmonyOS ? 來源:oschina ? 作者:oschina ? 2021-03-19 14:34 ? 次閱讀

關(guān)于中斷部分系列篇將用兩篇詳細(xì)說明整個(gè)過程.

中斷切換篇用自下而上的方式,從匯編開始處往上跟蹤.說清楚保存和恢復(fù)TaskIrqContext,以及調(diào)用HalIrqHandler的入口,此為中斷切換篇.

中斷管理篇用自上而下的方式,從C語言中斷注冊(cè)管理開始往下跟蹤,一直到匯編調(diào)用的4個(gè)HalIrqHandlerOsTaskProcSignalOsSchedPreemptOsSaveSignalContextIrqC函數(shù)為止.

中斷環(huán)境下的任務(wù)切換

鴻蒙的內(nèi)核線程就是任務(wù),系列篇中說的任務(wù)和線程當(dāng)一個(gè)東西去理解.

一般二種場(chǎng)景下需要切換任務(wù)上下文:

在中斷環(huán)境下,從當(dāng)前線程切換到目標(biāo)線程,這種方式也稱為硬切換.不由軟件控制的被動(dòng)式切換.哪些情況下會(huì)出現(xiàn)硬切換呢?

由硬件產(chǎn)生的中斷,比如 鼠標(biāo),鍵盤外部設(shè)備每次點(diǎn)擊和敲打,屏幕的觸摸,USB的插拔等等這些都是硬中斷.同樣的需要切換棧運(yùn)行,需要復(fù)用寄存器,但與軟切換不一樣的是,硬切換會(huì)切換工作模式(中斷模式).所以會(huì)更復(fù)雜點(diǎn),但道理還是一樣要保存和恢復(fù)切換現(xiàn)場(chǎng)寄存器的值, 而保存寄存器順序的結(jié)構(gòu)體叫:任務(wù)中斷上下文(TaskIrqContext).

在線程環(huán)境下,從當(dāng)前線程切換到目標(biāo)線程,這種方式也稱為軟切換,能由軟件控制的自主式切換.哪些情況下會(huì)出現(xiàn)軟切換呢?

運(yùn)行的線程申請(qǐng)某種資源(比如各種鎖,讀/寫消息隊(duì)列)失敗時(shí),需要主動(dòng)釋放CPU的控制權(quán),將自己掛入等待隊(duì)列,調(diào)度算法重新調(diào)度新任務(wù)運(yùn)行.

每隔10ms就執(zhí)行一次的OsTickHandler節(jié)拍處理函數(shù),檢測(cè)到任務(wù)的時(shí)間片用完了,就發(fā)起任務(wù)的重新調(diào)度,切換到新任務(wù)運(yùn)行.

不管是內(nèi)核態(tài)的任務(wù)還是用戶態(tài)的任務(wù),于切換而言是統(tǒng)一處理,一視同仁的,因?yàn)榍袚Q是需要換棧運(yùn)行,寄存器有限,需要頻繁的復(fù)用,這就需要將當(dāng)前寄存器值先保存到任務(wù)自己的棧中,以便別人用完了輪到自己再用時(shí)恢復(fù)寄存器當(dāng)時(shí)的值,確保老任務(wù)還能繼續(xù)跑下去. 而保存寄存器順序的結(jié)構(gòu)體叫:任務(wù)上下文(TaskContext).

本篇說清楚在中斷環(huán)境下切換(硬切換)的實(shí)現(xiàn)過程.線程切換(軟切換)實(shí)現(xiàn)過程已在鴻蒙內(nèi)核源碼分析(總目錄)任務(wù)切換篇中詳細(xì)說明.

ARM的七種工作模式中,有兩個(gè)是和中斷相關(guān).

普通中斷模式(irq):一般中斷模式也叫普通中斷模式,用于處理一般的中斷請(qǐng)求,通常在硬件產(chǎn)生中斷信號(hào)之后自動(dòng)進(jìn)入該模式,該模式可以自由訪問系統(tǒng)硬件資源。

快速中斷模式(fiq):快速中斷模式是相對(duì)一般中斷模式而言的,用來處理高優(yōu)先級(jí)中斷的模式,處理對(duì)時(shí)間要求比較緊急的中斷請(qǐng)求,主要用于高速數(shù)據(jù)傳輸及通道處理中。

此處分析普通中斷模式下的任務(wù)切換過程.

普通中斷模式相關(guān)寄存器

這張圖一定要刻在腦海里,系列篇會(huì)多次拿出來,目的是為了能牢記它.

pIYBAGBURP6AJ00tAAKBis0FJdQ741.png

普通中斷模式(圖中IRQ列)是一種異常模式,有自己獨(dú)立運(yùn)行的棧空間.一個(gè)(IRQ)中斷發(fā)生后,硬件會(huì)將CPSR寄存器工作模式位置為IRQ模式.并跳轉(zhuǎn)到入口地址OsIrqHandler執(zhí)行.

#define OS_EXC_IRQ_STACK_SIZE 64 //64個(gè)字節(jié), 16個(gè)棧空間

__irq_stack:
    .space OS_EXC_IRQ_STACK_SIZE * CORE_NUM
__irq_stack_top:

OsIrqHandler匯編代碼實(shí)現(xiàn)過程,就干了三件事:

1.保存任務(wù)中斷上下文TaskIrqContext

2.執(zhí)行中斷處理程序HalIrqHandler,這是個(gè)C函數(shù),由匯編調(diào)用.

3.恢復(fù)任務(wù)中斷上下文TaskIrqContext,返回被中斷的任務(wù)繼續(xù)執(zhí)行

TaskIrqContext 和 TaskContext

先看本篇結(jié)構(gòu)體TaskIrqContext

#define TASK_IRQ_CONTEXT \
        unsigned int R0;     \
        unsigned int R1;     \
        unsigned int R2;     \
        unsigned int R3;     \
        unsigned int R12;    \
        unsigned int USP;    \
        unsigned int ULR;    \
        unsigned int CPSR;   \
        unsigned int PC;

typedef struct {//任務(wù)中斷上下文
#if !defined(LOSCFG_ARCH_FPU_DISABLE)
    UINT64 D[FP_REGS_NUM]; /* D0-D31 */
    UINT32 regFPSCR;       /* FPSCR */
    UINT32 regFPEXC;       /* FPEXC */
#endif
    UINT32 resved;
    TASK_IRQ_CONTEXT
} TaskIrqContext;
typedef struct {//任務(wù)上下文,已在任務(wù)切換篇中詳細(xì)說明,放在此處是為了對(duì)比  
#if !defined(LOSCFG_ARCH_FPU_DISABLE)
    UINT64 D[FP_REGS_NUM]; /* D0-D31 */
    UINT32 regFPSCR;       /* FPSCR */
    UINT32 regFPEXC;       /* FPEXC */
#endif
    UINT32 resved;          /* It's stack 8 aligned */
    UINT32 regPSR;          
    UINT32 R[GEN_REGS_NUM]; /* R0-R12 */
    UINT32 SP;              /* R13 */
    UINT32 LR;              /* R14 */
    UINT32 PC;              /* R15 */
} TaskContext;

兩個(gè)結(jié)構(gòu)體很簡(jiǎn)單,目的更簡(jiǎn)單,就是用來保存寄存器現(xiàn)場(chǎng)的值的.TaskContext把17個(gè)寄存器全部保存了,TaskIrqContext保存的少些,在棧中沒有保存R4-R11寄存器的值,這說明在整個(gè)中斷處理過程中,都不會(huì)用到R4-R11寄存器.不會(huì)用到就不會(huì)改變,當(dāng)然就沒必要保存了.這也說明內(nèi)核開發(fā)者的嚴(yán)謹(jǐn)程度,不造成時(shí)間和空間上的一丁點(diǎn)浪費(fèi).效率的提升是從細(xì)節(jié)處入手的,每個(gè)小地方優(yōu)化那么一丟丟,整體性能就上來了.

TaskIrqContext中有兩個(gè)變量有點(diǎn)奇怪unsigned int USP;unsigned int ULR;指的是用戶模式下的SP和LR值, 這個(gè)要怎么理解? 因?yàn)閷?duì)一個(gè)運(yùn)行著的任務(wù)而言,中斷的到來是不顆不定時(shí)炸彈,無法預(yù)知,也無法準(zhǔn)備,中斷一來它立即被打斷,根本沒有時(shí)間去保存現(xiàn)場(chǎng)到自己的棧中,那只能是保存在IRQ棧或者SVC棧中.而IRQ棧非常的小,只有64個(gè)字節(jié),16個(gè)棧空間,指望不上了,就保存在SVC棧中,SVC模式棧可是有 8K空間的.

從接下來的OsIrqHandler代碼中可以看出,鴻蒙內(nèi)核整個(gè)中斷的工作其實(shí)都是在SVC模式下完成的,而irq的棧只是個(gè)過渡棧. 具體看匯編代碼一行一行分析.

普通中斷處理程序

OsIrqHandler:	@硬中斷處理,此時(shí)已切換到硬中斷棧
    SUB     LR, LR, #4	@記錄譯碼指令地址,以防切換過程丟失指令

    /* push r0-r3 to irq stack */ @irq棧只是個(gè)過渡棧
    STMFD   SP, {R0-R3}		@r0-r3寄存器入 irq 棧
    SUB     R0, SP, #(4 * 4)@r0 = sp - 16,目的是記錄{R0-R3}4個(gè)寄存器保存的開始位置,屆時(shí)從R3開始出棧
    MRS     R1, SPSR		@獲取程序狀態(tài)控制寄存器
    MOV     R2, LR			@r2=lr

    /* disable irq, switch to svc mode */@超級(jí)用戶模式(SVC 模式),主要用于 SWI(軟件中斷)和 OS(操作系統(tǒng))。
    CPSID   i, #0x13				@切換到SVC模式,此處一切換,后續(xù)指令將在SVC棧運(yùn)行
									@CPSID i為關(guān)中斷指令,對(duì)應(yīng)的是CPSIE
    @TaskIrqContext 開始保存中斷現(xiàn)場(chǎng) ......							
    /* push spsr and pc in svc stack */
    STMFD   SP!, {R1, R2} @實(shí)際是將 SPSR,和PC入棧對(duì)應(yīng)TaskIrqContext.PC,TaskIrqContext.CPSR,
    STMFD   SP, {LR}	  @LR再入棧,SP不自增,如果是用戶模式,LR值將被 282行:STMFD   SP, {R13, R14}^覆蓋  
						  @如果非用戶模式,將被 286行:SUB     SP, SP, #(2 * 4) 跳過.
    AND     R3, R1, #CPSR_MASK_MODE	@獲取CPU的運(yùn)行模式
    CMP     R3, #CPSR_USER_MODE		@中斷是否發(fā)生在用戶模式
    BNE     OsIrqFromKernel			@非用戶模式不用將USP,ULR保存在TaskIrqContext

    /* push user sp, lr in svc stack */
    STMFD   SP, {R13, R14}^ 		@將用戶模式的sp和LR入svc棧

OsIrqFromKernel:	@從內(nèi)核發(fā)起中斷
    /* from svc not need save sp and lr */@svc模式下發(fā)生的中斷不需要保存sp和lr寄存器值
    SUB     SP, SP, #(2 * 4)	@目的是為了留白給 TaskIrqContext.USP,TaskIrqContext.ULR
								@TaskIrqContext.ULR已經(jīng)在 276行保存了,276行用的是SP而不是SP!,所以此處要跳2個(gè)空間
    /* pop r0-r3 from irq stack*/
    LDMFD   R0, {R0-R3}		    @從R0位置依次出棧 

    /* push caller saved regs as trashed regs in svc stack */
    STMFD   SP!, {R0-R3, R12}	@寄存器入棧,對(duì)應(yīng) TaskIrqContext.R0~R3,R12

    /* 8 bytes stack align */
    SUB     SP, SP, #4			@棧對(duì)齊 對(duì)應(yīng)TaskIrqContext.resved

    /*
     * save fpu regs in case in case those been
     * altered in interrupt handlers.
     */
    PUSH_FPU_REGS   R0 @保存fpu regs,以防中斷處理程序中的fpu regs被修改。
    @TaskIrqContext 結(jié)束保存中斷現(xiàn)場(chǎng)......	
    @開始執(zhí)行真正的中斷處理函數(shù)了.
#ifdef LOSCFG_IRQ_USE_STANDALONE_STACK @是否使用了獨(dú)立的IRQ棧
    PUSH    {R4}	@R4先入棧保存,接下來要切換棧,需保存現(xiàn)場(chǎng)
    MOV     R4, SP	@R4=SP
    EXC_SP_SET __svc_stack_top, OS_EXC_SVC_STACK_SIZE, R1, R2 @切換到svc棧
#endif
	/*BLX 帶鏈接和狀態(tài)切換的跳轉(zhuǎn)*/
    BLX     HalIrqHandler /* 調(diào)用硬中斷處理程序,無參 ,說明HalIrqHandler在svc棧中執(zhí)行 */

#ifdef LOSCFG_IRQ_USE_STANDALONE_STACK @是否使用了獨(dú)立的IRQ棧
    MOV     SP, R4	@恢復(fù)現(xiàn)場(chǎng),sp = R4 
    POP     {R4}	@彈出R4
#endif

    /* process pending signals */ 	@處理掛起信號(hào)
    BL      OsTaskProcSignal 		@跳轉(zhuǎn)至C代碼 

    /* check if needs to schedule */@檢查是否需要調(diào)度
    CMP     R0, #0	@是否需要調(diào)度,R0為參數(shù)保存值
    BLNE    OsSchedPreempt @不相等,即R0非0,一般是 1

    MOV     R0,SP	@參數(shù)
    MOV     R1,R7	@參數(shù)
    BL      OsSaveSignalContextIrq @跳轉(zhuǎn)至C代碼 

    /* restore fpu regs */
    POP_FPU_REGS    R0 @恢復(fù)fpu寄存器值

    ADD     SP, SP, #4 @sp = sp + 4 

OsIrqContextRestore:	@恢復(fù)硬中斷環(huán)境
    LDR     R0, [SP, #(4 * 7)]	@R0 = sp + 7,目的是跳到恢復(fù)中斷現(xiàn)場(chǎng)TaskIrqContext.CPSR位置,剛好是TaskIrqContext倒數(shù)第7的位置.
    MSR     SPSR_cxsf, R0		@恢復(fù)spsr 即:spsr = TaskIrqContext.CPSR
    AND     R0, R0, #CPSR_MASK_MODE @掩碼找出當(dāng)前工作模式
    CMP     R0, #CPSR_USER_MODE	@是否為用戶模式?
    @TaskIrqContext 開始恢復(fù)中斷現(xiàn)場(chǎng) ......	
    LDMFD   SP!, {R0-R3, R12}	@從SP位置依次出棧 對(duì)應(yīng) TaskIrqContext.R0~R3,R12
								@此時(shí)已經(jīng)恢復(fù)了5個(gè)寄存器,接來下是TaskIrqContext.USP,TaskIrqContext.ULR
    BNE     OsIrqContextRestoreToKernel @看非用戶模式,怎么恢復(fù)中斷現(xiàn)場(chǎng).

    /* load user sp and lr, and jump cpsr */
    LDMFD   SP, {R13, R14}^ @出棧,恢復(fù)用戶模式sp和lr值 即:TaskIrqContext.USP,TaskIrqContext.ULR
    ADD     SP, SP, #(3 * 4) @跳3個(gè)位置,跳過 CPSR ,因?yàn)樯弦痪洳皇?SP!,所以跳3個(gè)位置,剛好到了保存TaskIrqContext.PC的位置

    /* return to user mode */
    LDMFD   SP!, {PC}^ @回到用戶模式,整個(gè)中斷過程完成
    @TaskIrqContext 結(jié)束恢復(fù)中斷現(xiàn)場(chǎng)(用戶模式下) ......	

OsIrqContextRestoreToKernel:@從內(nèi)核恢復(fù)中斷
    /* svc mode not load sp */
    ADD     SP, SP, #4 @其實(shí)是跳過TaskIrqContext.USP,因?yàn)樵趦?nèi)核模式下并沒有保存這個(gè)值,翻看 287行
    LDMFD   SP!, {LR} @彈出LR
    /* jump cpsr and return to svc mode */
    ADD     SP, SP, #4 @跳過cpsr
    LDMFD   SP!, {PC}^ @回到svc模式,整個(gè)中斷過程完成
    @TaskIrqContext 結(jié)束恢復(fù)中斷現(xiàn)場(chǎng)(內(nèi)核模式下) ......

逐句解讀

跳轉(zhuǎn)到OsIrqFromKernel硬件會(huì)自動(dòng)切換到__irq_stack執(zhí)行

1句:SUB LR, LR, #4在arm執(zhí)行過程中一般分為取指,譯碼,執(zhí)行階段,而PC是指向取指,正在執(zhí)行的指令為 PC-8 ,譯碼指令為PC-4.當(dāng)中斷發(fā)生時(shí)硬件自動(dòng)執(zhí)行 mov lr pc, 中間的PC-4譯碼指令因?yàn)闆]有寄存器去記錄它,就會(huì)被丟失掉.所以SUB LR, LR, #4的結(jié)果是lr = PC -4 ,定位到了被中斷時(shí)譯碼指令,將在棧中保存這個(gè)位置,確保回來后能繼續(xù)執(zhí)行.

2句:STMFD SP, {R0-R3}當(dāng)前4個(gè)寄存器入__irq_stack保存

3句:SUB R0, SP, #(4 * 4)因?yàn)镾P沒有自增,R0跳到保存R0內(nèi)容地址

4,5句:讀取SPSR,LR寄存器內(nèi)容,目的是為了后面在SVC棧中保存TaskIrqContext

6句:CPSID i, #0x13禁止中斷和切換SVC模式,執(zhí)行完這條指令后工作模式將切到 SVC模式

@TaskIrqContext 開始保存中斷現(xiàn)場(chǎng) ......

中間代碼需配合TaskIrqContext來看,不然100%懵逼.結(jié)合看就秒懂,代碼都已經(jīng)注釋,不再做解釋,注解中提到的 翻看276行 是指源碼的第276行,請(qǐng)對(duì)照注解源碼看理解會(huì)更透徹.進(jìn)入源碼注解地址查看

@TaskIrqContext 結(jié)束保存中斷現(xiàn)場(chǎng) ......

TaskIrqContext保存完現(xiàn)場(chǎng)后就真正的開始處理中斷了,

	/*BLX 帶鏈接和狀態(tài)切換的跳轉(zhuǎn)*/
    BLX     HalIrqHandler /* 調(diào)用硬中斷處理程序,無參 ,說明HalIrqHandler在svc棧中執(zhí)行 */
#ifdef LOSCFG_IRQ_USE_STANDALONE_STACK @是否使用了獨(dú)立的IRQ棧
    MOV     SP, R4	@恢復(fù)現(xiàn)場(chǎng),sp = R4 
    POP     {R4}	@彈出R4
#endif
    /* process pending signals */ 	@處理掛起信號(hào)
    BL      OsTaskProcSignal 		@跳轉(zhuǎn)至C代碼 
    /* check if needs to schedule */@檢查是否需要調(diào)度
    CMP     R0, #0	@是否需要調(diào)度,R0為參數(shù)保存值
    BLNE    OsSchedPreempt @不相等,即R0非0,一般是 1
    MOV     R0,SP	@參數(shù)
    MOV     R1,R7	@參數(shù)
    BL      OsSaveSignalContextIrq @跳轉(zhuǎn)至C代碼 
    /* restore fpu regs */
    POP_FPU_REGS    R0 @恢復(fù)fpu寄存器值
    ADD     SP, SP, #4 @sp = sp + 4 

這段代碼都是跳轉(zhuǎn)到C語言去執(zhí)行,分別是HalIrqHandlerOsTaskProcSignalOsSchedPreemptOsSaveSignalContextIrqC語言部分內(nèi)容很多,將在中斷管理篇中說明.

@TaskIrqContext 開始恢復(fù)中斷現(xiàn)場(chǎng) ......

同樣的中間代碼需配合TaskIrqContext來看,不然100%懵逼.結(jié)合看就秒懂,代碼都已經(jīng)注釋,不再做解釋,注解中提到的 翻看287行 是指源碼的第287行,請(qǐng)對(duì)照注解源碼看理解會(huì)更透徹.進(jìn)入源碼注解地址查看

@TaskIrqContext 結(jié)束恢復(fù)中斷現(xiàn)場(chǎng) ......

編輯:hfy

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • ARM
    ARM
    +關(guān)注

    關(guān)注

    134

    文章

    9165

    瀏覽量

    369170
  • 寄存器
    +關(guān)注

    關(guān)注

    31

    文章

    5363

    瀏覽量

    121155
  • SVC
    SVC
    +關(guān)注

    關(guān)注

    0

    文章

    33

    瀏覽量

    12179
  • 線程
    +關(guān)注

    關(guān)注

    0

    文章

    505

    瀏覽量

    19756
  • 鴻蒙系統(tǒng)
    +關(guān)注

    關(guān)注

    183

    文章

    2638

    瀏覽量

    66705
收藏 人收藏

    評(píng)論

    相關(guān)推薦

    鴻蒙內(nèi)核源碼Task/線程技術(shù)分析

    前言 在鴻蒙內(nèi)核中,廣義上可理解為一個(gè)Task就是一個(gè)線程 一、怎么理解Task 1. 官方文檔是怎么描述線程 基本概念 從系統(tǒng)的角度看,線程
    的頭像 發(fā)表于 10-18 10:42 ?2268次閱讀
    <b class='flag-5'>鴻蒙</b><b class='flag-5'>內(nèi)核</b>源碼Task/<b class='flag-5'>線程</b>技術(shù)<b class='flag-5'>分析</b>

    鴻蒙內(nèi)核源碼的中斷環(huán)境任務(wù)切換

    中斷環(huán)境任務(wù)切換鴻蒙內(nèi)核
    的頭像 發(fā)表于 04-30 16:41 ?2360次閱讀
    <b class='flag-5'>鴻蒙</b><b class='flag-5'>內(nèi)核</b>源碼的<b class='flag-5'>中斷</b><b class='flag-5'>環(huán)境</b><b class='flag-5'>下</b>的<b class='flag-5'>任務(wù)</b><b class='flag-5'>切換</b>

    用戶級(jí)線程內(nèi)核級(jí)線程

    線程:不需要內(nèi)核支持而在用戶程序中實(shí)現(xiàn)的線程,其不依賴于操作系統(tǒng)核心,應(yīng)用進(jìn)程利用線程庫提供創(chuàng)建、同步、調(diào)度和管理線程的函數(shù)來控制用戶
    發(fā)表于 01-10 15:01

    【HarmonyOS】鴻蒙內(nèi)核源碼分析(調(diào)度機(jī)制篇)

    任務(wù)上下文}函數(shù)有點(diǎn)長,筆者留了最重要的幾行,看這幾行就夠了,流程如下: 調(diào)度過程要自旋鎖,不允許任何中斷發(fā)生,沒錯(cuò),說的是任何事是不能去打斷它,否則后果太嚴(yán)重了,這可是內(nèi)核切換進(jìn)
    發(fā)表于 10-14 14:00

    鴻蒙內(nèi)核源碼分析(調(diào)度機(jī)制篇):Task是如何被調(diào)度執(zhí)行的

    (); 就是設(shè)置啟動(dòng)任務(wù),但此時(shí)啥都還沒開始呢,Kprocess 進(jìn)程都沒創(chuàng)建,怎么會(huì)有大家一般意義上所理解的線程呢。狹義上的后續(xù)有 鴻蒙內(nèi)核源碼
    發(fā)表于 11-23 10:53

    鴻蒙內(nèi)核源碼分析(Task管理篇):task是內(nèi)核調(diào)度的單元

    有狀態(tài),要運(yùn)行就需要內(nèi)存空間,就需要被內(nèi)核算法調(diào)度,被選中CPU就去執(zhí)行代碼段指令,CPU要執(zhí)行就需要告訴它從哪里開始執(zhí)行,因?yàn)槭嵌?b class='flag-5'>線程,但只有一個(gè)CPU就需要不斷的切換任務(wù),那執(zhí)行會(huì)
    發(fā)表于 11-23 14:01

    鴻蒙內(nèi)核源碼分析(Task管理篇):task是內(nèi)核調(diào)度的單元

    還原回去就能保證task的連續(xù)執(zhí)行,讓用戶毫無感知。鴻蒙內(nèi)核給一個(gè)任務(wù)執(zhí)行的時(shí)間是 20ms ,也就是說有多任務(wù)競(jìng)爭(zhēng)的情況,一秒鐘內(nèi)最多要
    發(fā)表于 11-24 10:24

    RTThread內(nèi)核線程是如何切換

    1、背景本文章主要說明 rtthread 內(nèi)核線程是如何切換的,初學(xué)者剛從裸機(jī)開發(fā)接觸 RTOS 時(shí)難免會(huì)有些不適應(yīng),明白這部分原理之后就會(huì)對(duì) RTOS 有更深的理解。在學(xué)習(xí)內(nèi)核
    發(fā)表于 10-10 16:50

    請(qǐng)問線程間的切換會(huì)不會(huì)影響外設(shè)的中斷響應(yīng)?

    例如,有一個(gè)編碼器使用io口中斷的方式讀取狀態(tài)然后在程序中有多個(gè)線程來回切換,那線程切換時(shí)會(huì)不會(huì)將編碼器觸發(fā)的io口
    發(fā)表于 03-23 11:38

    鴻蒙內(nèi)核源碼之線程環(huán)境任務(wù)切換

    中斷環(huán)境,從當(dāng)前線程切換到目標(biāo)線程,這種方式也稱為硬切換
    的頭像 發(fā)表于 04-25 16:48 ?1506次閱讀
    <b class='flag-5'>鴻蒙</b><b class='flag-5'>內(nèi)核</b>源碼之<b class='flag-5'>線程</b><b class='flag-5'>環(huán)境</b><b class='flag-5'>下</b>的<b class='flag-5'>任務(wù)</b><b class='flag-5'>切換</b>

    鴻蒙內(nèi)核源碼分析線程環(huán)境任務(wù)切換

    從代碼段哪個(gè)位置取指令? 也就是入口地址,main函數(shù)是應(yīng)用程序的入口地址, run()是new一個(gè)線程執(zhí)行的入口地址.高級(jí)語言是這么叫,但到了匯編層的叫法就是PC寄存器.給PC寄存器喂妹值,指令就從哪里取.
    的頭像 發(fā)表于 04-25 15:22 ?1496次閱讀
    <b class='flag-5'>鴻蒙</b><b class='flag-5'>內(nèi)核</b>源碼<b class='flag-5'>分析</b>之<b class='flag-5'>線程</b><b class='flag-5'>環(huán)境</b><b class='flag-5'>下</b>的<b class='flag-5'>任務(wù)</b><b class='flag-5'>切換</b>

    鴻蒙內(nèi)核源碼分析:引起中斷的事件或原因

    通過中斷機(jī)制,在外設(shè)不需要CPU介入時(shí),CPU可以執(zhí)行其它任務(wù),而當(dāng)外設(shè)需要CPU時(shí),將通過產(chǎn)生中斷信號(hào)使CPU立即中斷當(dāng)前任務(wù)來響應(yīng)
    的頭像 發(fā)表于 04-25 09:25 ?1922次閱讀
    <b class='flag-5'>鴻蒙</b><b class='flag-5'>內(nèi)核</b>源碼<b class='flag-5'>分析</b>:引起<b class='flag-5'>中斷</b>的事件或原因

    鴻蒙內(nèi)核源碼分析任務(wù)環(huán)境的事件控制塊

    一對(duì)多同步模型:一個(gè)任務(wù)等待多個(gè)事件的觸發(fā)。可以是任意一個(gè)事件發(fā)生時(shí)喚醒任務(wù)處理事件,也可以是幾個(gè)事件都發(fā)生后才喚醒任務(wù)處理事件。
    的頭像 發(fā)表于 04-26 14:29 ?1392次閱讀
    <b class='flag-5'>鴻蒙</b><b class='flag-5'>內(nèi)核</b>源碼<b class='flag-5'>分析</b>多<b class='flag-5'>任務(wù)</b><b class='flag-5'>環(huán)境</b><b class='flag-5'>下</b>的事件控制塊

    鴻蒙內(nèi)核源碼分析:task是內(nèi)核調(diào)度的單元

    從系統(tǒng)的角度看,線程是競(jìng)爭(zhēng)系統(tǒng)資源的最小運(yùn)行單元。線程可以使用或等待CPU、使用內(nèi)存空間等系統(tǒng)資源,并獨(dú)立于其它線程運(yùn)行。 鴻蒙內(nèi)核每個(gè)進(jìn)
    發(fā)表于 11-23 15:51 ?22次下載
    <b class='flag-5'>鴻蒙</b><b class='flag-5'>內(nèi)核</b>源碼<b class='flag-5'>分析</b>:task是<b class='flag-5'>內(nèi)核</b>調(diào)度的單元

    鴻蒙內(nèi)核源碼分析:進(jìn)程和Task的就緒隊(duì)列對(duì)調(diào)度的作用

    鴻蒙內(nèi)核代碼中有兩個(gè)源文件是關(guān)于隊(duì)列的,一個(gè)是用于調(diào)度的隊(duì)列,另一個(gè)是用于線程間通訊的IPC隊(duì)列。 鴻蒙內(nèi)核進(jìn)程和
    發(fā)表于 11-23 15:48 ?31次下載
    <b class='flag-5'>鴻蒙</b><b class='flag-5'>內(nèi)核</b>源碼<b class='flag-5'>分析</b>:進(jìn)程和Task的就緒隊(duì)列對(duì)調(diào)度的作用
    百家乐官网起步多少| 网上玩百家乐官网技巧| 威尼斯人娱乐网上百家乐的玩法技巧和规则 | 奇迹百家乐官网的玩法技巧和规则 | 澳门百家乐网上直赌| 赢家百家乐官网的玩法技巧和规则 | 至尊百家乐下载| 百乐坊百家乐官网娱乐城| 长海县| 大发888下载大发888娱乐城| 名仕百家乐的玩法技巧和规则| 罗盘24层| 百家乐官网做庄家必赢诀窍| 棋牌游戏平台排名| 百家乐辅助器| 圣安娜百家乐代理| 百家乐官网光纤冼牌机| 百家乐官网过滤软件| 南京百家乐官网电| 缅甸百家乐官网赌场| 百家乐官网隔一数打法| 大发888打不开| 全讯网3344666| 大发888出纳柜台| 大发888游戏官方下载| 百家乐鞋| 百家乐的珠盘| 百家乐平台凯发| 百家乐赢钱的技巧是什么| 华侨人百家乐的玩法技巧和规则 | 菲利宾太阳城娱乐网| 游戏机百家乐的玩法技巧和规则| 百家乐投注方法网| 百家乐官网款| 狮威百家乐官网的玩法技巧和规则| 百家乐官网平台哪个比较安全 | 百家乐官网获胜秘决百家乐官网获胜秘诀| 百家乐官网赌场凯时娱乐| 百家乐官网八卦投注法| 百家乐官网强对弱的对打法| 做生意住房买什么朝向|