百万汉字注解 >> 精读内核源码,中文注解分析, 深挖地基工程,大脑永久记忆,四大码仓每日同步更新< gitee | github | csdn | coding >
百篇博客分析 >> 故事说内核,问答式导读,生活式比喻,表格化说明,图形化展示,主流站点定期更新中< oschina | csdn | weharmony >
![在这里插入图片描述]()
本篇说清楚任务切换是怎么实现的?
任务(也叫线程)是被调度算法调度,切换上下文运行的.这是一句概括性的总结.追问下以下几个问题:
- 怎么切换的? 代码的实现细节是怎样的?
- 如何保证切换不会发生错误,指令不会丢失?
在 鸿蒙内核源码分析(总目录) 系列篇中已经说清楚了调度机制,线程概念,寄存器,CPU,工作模式,这些是读懂本篇的基础,建议先前往翻看,不然理解本篇会费劲.本篇代码量较多,涉及C和汇编代码,代码都添加了注释,试图把任务的整个切换过程逐行逐行说清楚.
前置条件
一个任务要跑起来,需要两个必不可少的硬性条件:
-
1.从代码段哪个位置取指令? 也就是入口地址,main函数是应用程序的入口地址, run()是new一个线程执行的入口地址.高级语言是这么叫,但到了汇编层的叫法就是PC寄存器.给PC寄存器喂妹值,指令就从哪里取.
-
2.运行的场地(栈空间)在哪里? ARM有7种工作模式,到了进程层面只需要考虑内核模式和用户模式两种,对应到任务会有内核态栈空间和用户态栈空间.内核模式的任务只有内核态的栈空间,用户模式任务二者都有.栈空间是在初始化一个任务时就分配指定好的.以下是两种栈空间的初始化过程.为了精练省去了部分代码,留下了核心部分.
//任务控制块中对两个栈空间的描述
typedef struct {
VOID *stackPointer; /**< Task stack pointer */ //内核态栈指针,SP位置,切换任务时先保存上下文并指向TaskContext位置.
UINT32 stackSize; /**< Task stack size */ //内核态栈大小
UINTPTR topOfStack; /**< Task stack top */ //内核态栈顶 bottom = top + size
// ....
UINTPTR userArea; //使用区域,由运行时划定,根据运行态不同而不同
UINTPTR userMapBase; //用户态下的栈底位置
UINT32 userMapSize; /**< user thread stack size ,real size : userMapSize + USER_STACK_MIN_SIZE */
} LosTaskCB;
//内核态运行栈初始化
LITE_OS_SEC_TEXT_INIT VOID *OsTaskStackInit(UINT32 taskID, UINT32 stackSize, VOID *topStack, BOOL initFlag)
{
UINT32 index = 1;
TaskContext *taskContext = NULL;
taskContext = (TaskContext *)(((UINTPTR)topStack + stackSize) - sizeof(TaskContext));//上下文存放在栈的底部
/* initialize the task context */ //初始化任务上下文
taskContext->PC = (UINTPTR)OsTaskEntry;//程序计数器,CPU首次执行task时跑的第一条指令位置
taskContext->LR = (UINTPTR)OsTaskExit; /* LR should be kept, to distinguish it's THUMB or ARM instruction */
taskContext->resved = 0x0;
taskContext->R[0] = taskID; /* R0 */
taskContext->R[index++] = 0x01010101; /* R1, 0x01010101 : reg initialed magic word */ //0x55
for (; index < GEN_REGS_NUM; index++) {//R2 - R12的初始化很有意思
taskContext->R[index] = taskContext->R[index - 1] + taskContext->R[1]; /* R2 - R12 */
}
taskContext->regPSR = PSR_MODE_SVC_ARM; /* CPSR (Enable IRQ and FIQ interrupts, ARM-mode) */
return (VOID *)taskContext;
}
//用户态运行栈初始化
LITE_OS_SEC_TEXT_INIT VOID OsUserTaskStackInit(TaskContext *context, TSK_ENTRY_FUNC taskEntry, UINTPTR stack)
{
context->regPSR = PSR_MODE_USR_ARM;//工作模式:用户模式 + 工作状态:arm
context->R[0] = stack;//栈指针给r0寄存器
context->SP = TRUNCATE(stack, LOSCFG_STACK_POINT_ALIGN_SIZE);//给SP寄存器值使用
context->LR = 0;//保存子程序返回地址 例如 a call b ,在b中保存 a地址
context->PC = (UINTPTR)taskEntry;//入口函数
}
您一定注意到了TaskContext,说的全是它,这就是任务上下文结构体,理解它是理解任务切换的钥匙.它不仅在C语言层面出现,而且还在汇编层出现,TaskContext是连接或者说打通 C->汇编->C 实现任务切换的最关键概念.本篇全是围绕着它来展开.先看看它张啥样,LOOK!
TaskContext 任务上下文
typedef struct {
#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;
-
结构很简单,目的更简单,就是用来保存寄存器现场的值的. 鸿蒙内核源码分析(总目录) 系列寄存器篇中已经说过了,到了汇编层就是寄存器在玩,当CPU工作在用户和系统模式下时寄存器是复用的,玩的是17个寄存器和内存地址,访问内存地址也是通过寄存器来玩.
-
哪17个? R0~R15和CPSR. 当调度(主动式)或者中断(被动式)发生时.将这17个寄存器压入任务的内核栈的过程叫保护案发现场.从任务栈中弹出依次填入寄存器的过程叫恢复案发现场.
-
从栈空间的具体哪个位置开始恢复呢? 答案是:stackPointer,任务控制块(LosTaskCB)的首个变量.对应到汇编层的就是SP寄存器.
-
而TaskContext(任务上下文)就是一定的顺序来保存和恢复这17个寄存器的.任务上下文在任务还没有开始执行的时候就已经保存在内核栈中了,只不过是一些默认的值,OsTaskStackInit干的就是这个默认的事. 而OsUserTaskStackInit是对用户栈的初始化,改变的是(CPSR)工作模式和SP寄存器.
-
新任务的运行栈指针(stackPointer)给SP寄存器意味着切换了运行栈,这是本篇最重要的一句话.
以下通过汇编代码逐行分析如何保存和恢复TaskContext(任务上下文)
OsSchedResched 调度算法
//调度算法的实现
VOID OsSchedResched(VOID)
{
// ...此处省去 ...
/* do the task context switch */
OsTaskSchedule(newTask, runTask);//切换任务上下文,注意OsTaskSchedule是一个汇编函数 见于 los_dispatch.s
}
- 在鸿蒙内核源码分析(总目录)之调度机制篇中,留了一个问题,
OsTaskSchedule不是一个C函数,而是个汇编函数,就没有往下分析了,本篇要完成整个分析过程.OsTaskSchedule实现了任务的上下文切换,汇编代码见于los_dispatch.S中
OsTaskSchedule的参数指向的是新老两个任务,这两个参数分别保存在R0,R1寄存器中.
OsTaskSchedule 汇编实现
读这段汇编代码一定要对照上面的TaskContext,不然很难看懂,容易懵圈,但对照着看就秒懂.
/*
* R0: new task
* R1: run task
*/
OsTaskSchedule: /*任务调度,OsTaskSchedule的目的是将寄存器值按TaskContext的格式保存起来*/
MRS R2, CPSR /*MRS 指令用于将特殊寄存器(如 CPSR 和 SPSR)中的数据传递给通用寄存器，要读取特殊寄存器的数据只能使用 MRS 指令*/
STMFD SP!, {LR} /*返回地址入栈,LR = PC-4 ,对应TaskContext->PC(R15寄存器)*/
STMFD SP!, {LR} /*再次入栈对应,对应TaskContext->LR(R14寄存器)*/
/* jump sp */
SUB SP, SP, #4 /* 跳的目的是为了,对应TaskContext->SP(R13寄存器)*/
/* push r0-r12*/
STMFD SP!, {R0-R12} @对应TaskContext->R[GEN_REGS_NUM](R0~R12寄存器)。
STMFD SP!, {R2} /*R2 入栈 对应TaskContext->regPSR*/
/* 8 bytes stack align */
SUB SP, SP, #4 @栈对齐,对应TaskContext->resved
/* save fpu registers */
PUSH_FPU_REGS R2 /*保存fpu寄存器*/
/* store sp on running task */
STR SP, [R1] @在运行的任务栈中保存SP,即runTask->stackPointer = sp
OsTaskContextLoad: @加载上下文
/* clear the flag of ldrex */ @LDREX 可从内存加载数据,如果物理地址有共享TLB属性，则LDREX会将该物理地址标记为由当前处理器独占访问，并且会清除该处理器对其他任何物理地址的任何独占访问标记。
CLREX @清除ldrex指令的标记
/* switch to new task's sp */
LDR SP, [R0] @ 即:sp = task->stackPointer
/* restore fpu registers */
POP_FPU_REGS R2 @恢复fpu寄存器,这里用了汇编宏R2是宏的参数
/* 8 bytes stack align */
ADD SP, SP, #4 @栈对齐
LDMFD SP!, {R0} @此时SP!位置保存的是CPSR的内容,弹出到R0
MOV R4, R0 @R4=R0,将CPSR保存在r4, 将在OsKernelTaskLoad中保存到SPSR
AND R0, R0, #CPSR_MASK_MODE @R0 =R0&CPSR_MASK_MODE ,目的是清除高16位
CMP R0, #CPSR_USER_MODE @R0 和 用户模式比较
BNE OsKernelTaskLoad @非用户模式则跳转到OsKernelTaskLoad执行,跳出
/*此处省去 LOSCFG_KERNEL_SMP 部分*/
MVN R3, #CPSR_INT_DISABLE @按位取反 R3 = 0x3F
AND R4, R4, R3 @使能中断
MSR SPSR_cxsf, R4 @修改spsr值
/* restore r0-r12, lr */
LDMFD SP!, {R0-R12} @恢复寄存器值
LDMFD SP, {R13, R14}^ @恢复SP和LR的值,注意此时SP值已经变了,CPU换地方上班了.
ADD SP, SP, #(2 * 4)@sp = sp + 8
LDMFD SP!, {PC}^ @恢复PC寄存器值,如此一来 SP和PC都有了新值,完成了上下文切换.完美!
OsKernelTaskLoad: @内核任务的加载
MSR SPSR_cxsf, R4 @将R4整个写入到程序状态保存寄存器
/* restore r0-r12, lr */
LDMFD SP!, {R0-R12} @出栈,依次保存到 R0-R12,其实就是恢复现场
ADD SP, SP, #4 @sp=SP+4
LDMFD SP!, {LR, PC}^ @返回地址赋给pc指针,直接跳出.
解读
-
汇编分成了三段 OsTaskSchedule, OsTaskContextLoad, OsKernelTaskLoad.
-
第一段OsTaskSchedule其实就是在保存现场.代码都有注释,对照着TaskContext来的,它就干了一件事把17个寄存器的值按TaskContext的格式入栈,因为鸿蒙用栈方式采用的是满栈递减的方式,所以存放顺序是从最后一个往前依次入栈.
-
连着来两句STMFD SP!, {LR}之前让笔者懵圈了很久, 看了TaskContext才恍然大悟,因为三级流水线的原因,LR和PC寄存器之间是差了一条指令的,LR指向了处于译码阶段指令,而PC指向了取指阶段的指令,所以此处做了两次LR入栈,其实是保存了未执行的译码指令地址,确保执行不会丢失一条指令.
-
R1是正在运行的任务栈, OsTaskSchedule总的理解是在任务R1的运行栈中插入一个TaskContext结构块.而STR SP, [R1],是改变了LosTaskCB->stackPointer的值,这个值只能在汇编层进行精准的改变,而在整个鸿蒙内核C代码层面都没有看到对它有任何修改的地方.这个改变意义极为重要.因为新的任务被调度后的第一件事情就是恢复现场!!!
-
在OsTaskSchedule执行完成后,因为PC寄存器并没有发生跳转,所以紧接着往下执行OsTaskContextLoad
-
OsTaskContextLoad的任务就是恢复现场,谁的现场?当然是R0: new task的,所以第一条指令就是CLREX,清除干净后立马执行LDR SP, [R0],所指向的就是LosTaskCB->stackPointer,这个位置存的是新任务的TaskContext结构块,是上一次R0任务被打断时保存下来当时这17个寄存器的值啊,依次出栈就是恢复这17个寄存器的值.
-
OsTaskContextLoad在开始之前会判断下工作模式,即判断下是内核栈还是用户栈,两种处理方式稍有不同.但都是在恢复现场.
-
BNE OsKernelTaskLoad是查询CPSR后判断此时为内核栈的现场恢复过程,代码很简单就是恢复17个寄存器. 如此一来,任务执行的两个条件,第一个SP的在LDR SP, [R0]时就有了.第二个条件:PC寄存器的值也在最后一条汇编LDMFD SP!, {LR, PC}^ 也已经有了.改变了PC和LR有了新值,下一条指令位置一样是上次任务被中断时还没被执行的处于译码阶段的指令地址.
-
如果是用户态区别是需要恢复中断.因为用户模式的优先级是最低的,必须允许响应中断,也是依次恢复各寄存器的值,最后一句LDMFD SP!, {PC}^结束本次旅行,下一条指令位置一样是上次任务被中断时还没被执行的处于译码阶段的指令地址.
-
如此,说清楚了任务上下文切换的整个过程,初看可能不太容易理解,建议多看几篇,用笔画下栈的运行过程,脑海中会很清晰的浮现出整个切换过程的运行图.
参与贡献
喜欢请大方 点赞+关注+收藏 吧
各大站点搜 "鸿蒙内核源码分析" .欢迎转载,请注明出处.
![公众号: 鸿蒙内核源码分析]()
进入 >> 百万汉字注解 百篇博客分析 精读鸿蒙源码 深挖地基工程 < gitee | csdn | oschina >
