鸿蒙内核源码分析(进程管理篇) | 进程是内核的资源管理单元 | 中文注解HarmonyOS源码 | v2.07

百万汉字注解 >> 精读鸿蒙源码,中文注解分析, 深挖地基工程,大脑永久记忆,四大码仓每日同步更新< gitee | github | csdn | coding >

百篇博客分析 >> 故事说内核,问答式导读,生活式比喻,表格化说明,图形化展示,主流站点定期更新中< osc | 51cto | csdn | harmony >

官方基本概念

• 从系统的角度看，进程是资源管理单元。进程可以使用或等待CPU、使用内存空间等系统资源，并独立于其它进程运行。

• OpenHarmony内核的进程模块可以给用户提供多个进程，实现了进程之间的切换和通信，帮助用户管理业务程序流程。这样用户可以将更多的精力投入到业务功能的实现中。

• OpenHarmony内核中的进程采用抢占式调度机制，支持时间片轮转调度方式和FIFO调度机制。

• OpenHarmony内核的进程一共有32个优先级(0-31)，用户进程可配置的优先级有22个(10-31)，最高优先级为10，最低优先级为31。

• 高优先级的进程可抢占低优先级进程，低优先级进程必须在高优先级进程阻塞或结束后才能得到调度。

• 每一个用户态进程均拥有自己独立的进程空间，相互之间不可见，实现进程间隔离。

• 用户态根进程init由内核态创建，其它用户态进程均由init进程fork而来。

进程状态说明：

• 初始化（Init）：该进程正在被创建。

• 就绪（Ready）：该进程在就绪列表中，等待CPU调度。

• 运行（Running）：该进程正在运行。

• 阻塞（Pend）：该进程被阻塞挂起。本进程内所有的线程均被阻塞时，进程被阻塞挂起。

• 僵尸态（Zombies）：该进程运行结束，等待父进程回收其控制块资源。

• Init→Ready：

  进程创建或fork时，拿到该进程控制块后进入Init状态，处于进程初始化阶段，当进程初始化完成将进程插入调度队列，此时进程进入就绪状态。

• Ready→Running：

  进程创建后进入就绪态，发生进程切换时，就绪列表中最高优先级的进程被执行，从而进入运行态。若此时该进程中已无其它线程处于就绪态，则该进程从就绪列表删除，只处于运行态；若此时该进程中还有其它线程处于就绪态，则该进程依旧在就绪队列，此时进程的就绪态和运行态共存。

• Running→Pend：

  进程内所有的线程均处于阻塞态时，进程在最后一个线程转为阻塞态时，同步进入阻塞态，然后发生进程切换。

• Pend→Ready / Pend→Running：

  阻塞进程内的任意线程恢复就绪态时，进程被加入到就绪队列，同步转为就绪态，若此时发生进程切换，则进程状态由就绪态转为运行态。

• Ready→Pend：

  进程内的最后一个就绪态线程处于阻塞态时，进程从就绪列表中删除，进程由就绪态转为阻塞态。

• Running→Ready：

  进程由运行态转为就绪态的情况有以下两种：

  1. 有更高优先级的进程创建或者恢复后，会发生进程调度，此刻就绪列表中最高优先级进程变为运行态，那么原先运行的进程由运行态变为就绪态。
  2. 若进程的调度策略为SCHED_RR，且存在同一优先级的另一个进程处于就绪态，则该进程的时间片消耗光之后，该进程由运行态转为就绪态，另一个同优先级的进程由就绪态转为运行态。

• Running→Zombies：

  当进程的主线程或所有线程运行结束后，进程由运行态转为僵尸态，等待父进程回收资源。

使用场景

进程创建后，用户只能操作自己进程空间的资源，无法操作其它进程的资源（共享资源除外）。 用户态允许进程挂起，恢复，延时等操作，同时也可以设置用户态进程调度优先级和调度策略，获取进程调度优先级和调度策略。进程结束的时候，进程会主动释放持有的进程资源，但持有的进程pid资源需要父进程通过wait/waitpid或父进程退出时回收。

开始正式分析

对应张大爷的故事，进程就是那些在场馆外32个队列里排队的，那些队列就是进程的就绪队列。

请注意 进程是资源管理单元 ，而非最终调度单元，调度单元是谁？是 Task ，看下官方对应状态定义

#define OS_PROCESS_STATUS_INIT           0x0010U    //进程初始状态
#define OS_PROCESS_STATUS_READY          0x0020U    //进程就绪状态
#define OS_PROCESS_STATUS_RUNNING        0x0040U    //进程运行状态
#define OS_PROCESS_STATUS_PEND           0x0080U    //进程阻塞状态
#define OS_PROCESS_STATUS_ZOMBIES        0x100U     //进程僵死状态

一个进程从创建到消亡过程，在内核肯定是极其复杂的。为了方便理解进程，整个系列文章笔者会用张大爷的故事打比方，从生活中的例子来将神秘的系统内核外化解剖出来给大家看。一件这么复杂的事情肯定会有个复杂的结构体来承载，它就是LosProcessCB(进程控制块)，代码很长但必须全部拿出来.

LITE_OS_SEC_BSS LosProcessCB *g_runProcess[LOSCFG_KERNEL_CORE_NUM]; //用一个指针数组记录进程运行，LOSCFG_KERNEL_CORE_NUM 为 CPU的核数
LITE_OS_SEC_BSS LosProcessCB *g_processCBArray = NULL;//进程池，最大进程数为 64个 
LITE_OS_SEC_DATA_INIT STATIC LOS_DL_LIST g_freeProcess;//记录空闲的进程链表
LITE_OS_SEC_DATA_INIT STATIC LOS_DL_LIST g_processRecyleList;//记录回收的进程列表

typedef struct ProcessCB {
    CHAR                 processName[OS_PCB_NAME_LEN]; /**< Process name */ //进程名称
    UINT32               processID;                    /**< process ID = leader thread ID */ //进程ID,由进程池分配,范围[0,64]
    UINT16               processStatus;                /**< [15:4] process Status; [3:0] The number of threads currently
                                                            running in the process *///这里设计很巧妙.用一个16表示了两层逻辑 数量和状态,点赞!
    UINT16               priority;                     /**< process priority */ //进程优先级
    UINT16               policy;                       /**< process policy */ //进程的调度方式,默认抢占式
    UINT16               timeSlice;                    /**< Remaining time slice *///进程时间片,默认2个tick
    UINT16               consoleID;                    /**< The console id of task belongs  *///任务的控制台id归属
    UINT16               processMode;                  /**< Kernel Mode:0; User Mode:1; */ //模式指定为内核还是用户进程
    UINT32               parentProcessID;              /**< Parent process ID */ //父进程ID
    UINT32               exitCode;                     /**< process exit status */ //进程退出状态码
    LOS_DL_LIST          pendList;                     /**< Block list to which the process belongs */ //进程所属的阻塞列表,如果因拿锁失败,就由此节点挂到等锁链表上
    LOS_DL_LIST          childrenList;                 /**< my children process list */ //孩子进程都挂到这里,形成双循环链表
    LOS_DL_LIST          exitChildList;                /**< my exit children process list */ //那些要退出孩子进程挂到这里，白发人送黑发人。
    LOS_DL_LIST          siblingList;                  /**< linkage in my parent's children list */ //兄弟进程链表, 56个民族是一家,来自同一个父进程.
    ProcessGroup         *group;                       /**< Process group to which a process belongs */ //所属进程组
    LOS_DL_LIST          subordinateGroupList;         /**< linkage in my group list */ //进程是组长时,有哪些组员进程
    UINT32               threadGroupID;                /**< Which thread group , is the main thread ID of the process */ //哪个线程组是进程的主线程ID
    UINT32               threadScheduleMap;            /**< The scheduling bitmap table for the thread group of the
                                                            process */ //进程的各线程调度位图
    LOS_DL_LIST          threadSiblingList;            /**< List of threads under this process *///进程的线程(任务)列表
    LOS_DL_LIST          threadPriQueueList[OS_PRIORITY_QUEUE_NUM]; /**< The process's thread group schedules the
                                                                         priority hash table */ //进程的线程组调度优先级哈希表
    volatile UINT32      threadNumber; /**< Number of threads alive under this process */ //此进程下的活动线程数
    UINT32               threadCount;  /**< Total number of threads created under this process */ //在此进程下创建的线程总数
    LOS_DL_LIST          waitList;     /**< The process holds the waitLits to support wait/waitpid *///进程持有等待链表以支持wait/waitpid
#if (LOSCFG_KERNEL_SMP == YES)
    UINT32               timerCpu;     /**< CPU core number of this task is delayed or pended *///统计各线程被延期或阻塞的时间
#endif
    UINTPTR              sigHandler;   /**< signal handler */ //信号处理函数,处理如 SIGSYS 等信号 
    sigset_t             sigShare;     /**< signal share bit */ //信号共享位
#if (LOSCFG_KERNEL_LITEIPC == YES)
    ProcIpcInfo         ipcInfo;       /**< memory pool for lite ipc */ //用于进程间通讯的虚拟设备文件系统,设备装载点为 /dev/lite_ipc
#endif
    LosVmSpace          *vmSpace;       /**< VMM space for processes */ //虚拟空间,描述进程虚拟内存的数据结构，linux称为内存描述符
#ifdef LOSCFG_FS_VFS
    struct files_struct *files;        /**< Files held by the process */ //进程所持有的所有文件，注者称之为进程的文件管理器
#endif //每个进程都有属于自己的文件管理器,记录对文件的操作. 注意:一个文件可以被多个进程操作
    timer_t             timerID;       /**< iTimer */

#ifdef LOSCFG_SECURITY_CAPABILITY //安全能力
    User                *user;  //进程的拥有者
    UINT32              capability; //安全能力范围 对应 CAP_SETGID
#endif
#ifdef LOSCFG_SECURITY_VID
    TimerIdMap          timerIdMap;
#endif
#ifdef LOSCFG_DRIVERS_TZDRIVER
    struct file         *execFile;     /**< Exec bin of the process */
#endif
    mode_t umask;
} LosProcessCB;

进程的模式有两种，内核态和用户态，能想到main函数中肯定会创建一个内核态的最高优先级进程，他就是 KProcess

通过task命令查看任务运行状态，可以看到 KProcess 进程 ,看名字就知道是一个内核进程，在系统启动时创建，图中可以看到 KProcess 的task运行情况，从表里可以看到KProcess内有 10几个task

​

进程模块是如何初始化的

KProcess 在张大爷的故事里相当于场馆的工作人员，他们也要接受张大爷的调度排队进场，但他们的优先级是最高的0级，他们进场后需完成场馆的准备工作，再开门做生意。如果需要多个工作人员怎么办，就是通过fork,简单说就是复制一个，复制的前提是需要有一个，鸿蒙里就是KProcess，其他工作人员都是通过它fork的。
那用户怎么来的呢？就是真正要排队的人也是一样，先创建一个用户祖先，其他用户皆由祖先fork来的。
注意用户进程和内核进程的祖先是不一样的,有各自的祖先根.分别是g_userInitProcess(1号) 和 g_kernelInitProcess(2号)

/******************************************************************************
 并发（Concurrent）:多个线程在单个核心运行，同一时间一个线程运行，系统不停切换线程，
   看起来像同时运行，实际上是线程不停切换
 并行（Parallel）每个线程分配给独立的CPU核心，线程同时运行
 单核CPU多个进程或多个线程内能实现并发（微观上的串行，宏观上的并行）
 多核CPU线程间可以实现宏观和微观上的并行
 LITE_OS_SEC_BSS 和 LITE_OS_SEC_DATA_INIT 是告诉编译器这些全局变量放在哪个数据段
******************************************************************************/
LITE_OS_SEC_BSS LosProcessCB *g_runProcess[LOSCFG_KERNEL_CORE_NUM];// CPU内核个数,超过一个就实现了并行
LITE_OS_SEC_BSS LosProcessCB *g_processCBArray = NULL; // 进程池数组
LITE_OS_SEC_DATA_INIT STATIC LOS_DL_LIST g_freeProcess;// 空闲状态下的进程链表, .个人觉得应该取名为 g_freeProcessList  @note_thinking
LITE_OS_SEC_DATA_INIT STATIC LOS_DL_LIST g_processRecyleList;// 需要回收的进程列表
LITE_OS_SEC_BSS UINT32 g_userInitProcess = OS_INVALID_VALUE;// 用户态的初始init进程,用户态下其他进程由它 fork
LITE_OS_SEC_BSS UINT32 g_kernelInitProcess = OS_INVALID_VALUE;// 内核态初始Kprocess进程,内核态下其他进程由它 fork
LITE_OS_SEC_BSS UINT32 g_kernelIdleProcess = OS_INVALID_VALUE;// 内核态idle进程,由Kprocess fork
LITE_OS_SEC_BSS UINT32 g_processMaxNum;// 进程最大数量,默认64个
LITE_OS_SEC_BSS ProcessGroup *g_processGroup = NULL;// 全局进程组,负责管理所有进程组

//进程模块初始化,被编译放在代码段 .init 中
LITE_OS_SEC_TEXT_INIT UINT32 OsProcessInit(VOID)
{
    UINT32 index;
    UINT32 size;

    g_processMaxNum = LOSCFG_BASE_CORE_PROCESS_LIMIT;//默认支持64个进程
    size = g_processMaxNum * sizeof(LosProcessCB);//算出总大小

    g_processCBArray = (LosProcessCB *)LOS_MemAlloc(m_aucSysMem1, size);// 进程池，占用内核堆,内存池分配 
    if (g_processCBArray == NULL) {
        return LOS_NOK;
    }
    (VOID)memset_s(g_processCBArray, size, 0, size);//安全方式重置清0

    LOS_ListInit(&g_freeProcess);//进程空闲链表初始化，创建一个进程时从g_freeProcess中申请一个进程描述符使用
    LOS_ListInit(&g_processRecyleList);//进程回收链表初始化,回收完成后进入g_freeProcess等待再次被申请使用

    for (index = 0; index < g_processMaxNum; index++) {//进程池循环创建
        g_processCBArray[index].processID = index;//进程ID[0-g_processMaxNum]赋值
        g_processCBArray[index].processStatus = OS_PROCESS_FLAG_UNUSED;// 默认都是白纸一张,贴上未使用标签
        LOS_ListTailInsert(&g_freeProcess, &g_processCBArray[index].pendList);//注意g_freeProcess挂的是pendList节点,所以使用要通过OS_PCB_FROM_PENDLIST找到进程实体.
    }

    g_userInitProcess = 1; /* 1: The root process ID of the user-mode process is fixed at 1 *///用户模式的根进程
    LOS_ListDelete(&g_processCBArray[g_userInitProcess].pendList);// 清空g_userInitProcess pend链表

    g_kernelInitProcess = 2; /* 2: The root process ID of the kernel-mode process is fixed at 2 *///内核模式的根进程
    LOS_ListDelete(&g_processCBArray[g_kernelInitProcess].pendList);// 清空g_kernelInitProcess pend链表

    return LOS_OK;
}

代码已经很清楚，创建了一个进程池，默认64个进程，也就是不改宏LOSCFG_BASE_CORE_PROCESS_LIMIT的情况下 系统最多是64个进程，但有两个进程先被占用，用户态和内核态各一个，他们是后续创建进程的根，所以最多留给外面的只有 62个进程可创建，代码的最后两个根进程的task阻塞链表被清空了,因为没有阻塞任务当然要清空.

内核态根进程创建过程

创建"Kprocess"进程，也就是线程池中的2号进程g_kernelInitProcess，设为最高优先级 0

//初始化 2号进程,即内核根进程
LITE_OS_SEC_TEXT_INIT UINT32 OsKernelInitProcess(VOID)
{
    LosProcessCB *processCB = NULL;
    UINT32 ret;

    ret = OsProcessInit();// 初始化进程模块全部变量,创建各循环双向链表
    if (ret != LOS_OK) {
        return ret;
    }

    processCB = OS_PCB_FROM_PID(g_kernelInitProcess);// 以PID方式得到一个进程
    ret = OsProcessCreateInit(processCB, OS_KERNEL_MODE, "KProcess", 0);// 初始化进程,最高优先级0,鸿蒙进程一共有32个优先级(0-31) 其中0-9级为内核进程,用户进程可配置的优先级有22个(10-31)
    if (ret != LOS_OK) {
        return ret;
    }

    processCB->processStatus &= ~OS_PROCESS_STATUS_INIT;// 进程初始化位 置1
    g_processGroup = processCB->group;//全局进程组指向了KProcess所在的进程组
    LOS_ListInit(&g_processGroup->groupList);// 进程组链表初始化
    OsCurrProcessSet(processCB);// 设置为当前进程

    return OsCreateIdleProcess();// 创建一个空闲状态的进程
}

//创建一个名叫"KIdle"的进程,给CPU空闲的时候使用
STATIC UINT32 OsCreateIdleProcess(VOID)
{
    UINT32 ret;
    CHAR *idleName = "Idle";
    LosProcessCB *idleProcess = NULL;
    Percpu *perCpu = OsPercpuGet();
    UINT32 *idleTaskID = &perCpu->idleTaskID;//得到CPU的idle task

    ret = OsCreateResourceFreeTask();// 创建一个资源回收任务,优先级为5 用于回收进程退出时的各种资源
    if (ret != LOS_OK) {
        return ret;
    }
 //创建一个名叫"KIdle"的进程,并创建一个idle task,CPU空闲的时候就待在 idle task中等待被唤醒
    ret = LOS_Fork(CLONE_FILES, "KIdle", (TSK_ENTRY_FUNC)OsIdleTask, LOSCFG_BASE_CORE_TSK_IDLE_STACK_SIZE);
    if (ret < 0) {
        return LOS_NOK;
    }
    g_kernelIdleProcess = (UINT32)ret;//返回进程ID

    idleProcess = OS_PCB_FROM_PID(g_kernelIdleProcess);//通过ID拿到进程实体
    *idleTaskID = idleProcess->threadGroupID;//绑定CPU的IdleTask,或者说改变CPU现有的idle任务
    OS_TCB_FROM_TID(*idleTaskID)->taskStatus |= OS_TASK_FLAG_SYSTEM_TASK;//设定Idle task 为一个系统任务
#if (LOSCFG_KERNEL_SMP == YES)
    OS_TCB_FROM_TID(*idleTaskID)->cpuAffiMask = CPUID_TO_AFFI_MASK(ArchCurrCpuid());//多核CPU的任务指定,防止乱串了,注意多核才会有并行处理
#endif
    (VOID)memset_s(OS_TCB_FROM_TID(*idleTaskID)->taskName, OS_TCB_NAME_LEN, 0, OS_TCB_NAME_LEN);//task 名字先清0
    (VOID)memcpy_s(OS_TCB_FROM_TID(*idleTaskID)->taskName, OS_TCB_NAME_LEN, idleName, strlen(idleName));//task 名字叫 idle
    return LOS_OK;
}

用户态根进程创建过程

创建Init进程，也就是线程池中的1号进程g_userInitProcess，优先级为 28,好低啊

/**
 * @ingroup los_process
 * User state root process default priority
 */
#define OS_PROCESS_USERINIT_PRIORITY     28

//所有的用户进程都是使用同一个用户代码段描述符和用户数据段描述符，它们是__USER_CS和__USER_DS，也就是每个进程处于用户态时，它们的CS寄存器和DS寄存器中的值是相同的。当任何进程或者中断异常进入内核后，都是使用相同的内核代码段描述符和内核数据段描述符，它们是__KERNEL_CS和__KERNEL_DS。这里要明确记得，内核数据段实际上就是内核态堆栈段。
LITE_OS_SEC_TEXT_INIT UINT32 OsUserInitProcess(VOID)
{
    INT32 ret;
    UINT32 size;
    TSK_INIT_PARAM_S param = { 0 };
    VOID *stack = NULL;
    VOID *userText = NULL;
    CHAR *userInitTextStart = (CHAR *)&__user_init_entry;//代码区开始位置 ,所有进程
    CHAR *userInitBssStart = (CHAR *)&__user_init_bss;// 未初始化数据区（BSS）。在运行时改变其值
    CHAR *userInitEnd = (CHAR *)&__user_init_end;// 结束地址
    UINT32 initBssSize = userInitEnd - userInitBssStart;
    UINT32 initSize = userInitEnd - userInitTextStart;

    LosProcessCB *processCB = OS_PCB_FROM_PID(g_userInitProcess);
    ret = OsProcessCreateInit(processCB, OS_USER_MODE, "Init", OS_PROCESS_USERINIT_PRIORITY);// 初始化用户进程,它将是所有应用程序的父进程
    if (ret != LOS_OK) {
        return ret;
    }

    userText = LOS_PhysPagesAllocContiguous(initSize >> PAGE_SHIFT);// 分配连续的物理页
    if (userText == NULL) {
        ret = LOS_NOK;
        goto ERROR;
    }

    (VOID)memcpy_s(userText, initSize, (VOID *)&__user_init_load_addr, initSize);// 安全copy 经加载器load的结果 __user_init_load_addr -> userText
    ret = LOS_VaddrToPaddrMmap(processCB->vmSpace, (VADDR_T)(UINTPTR)userInitTextStart, LOS_PaddrQuery(userText),
                               initSize, VM_MAP_REGION_FLAG_PERM_READ | VM_MAP_REGION_FLAG_PERM_WRITE |
                               VM_MAP_REGION_FLAG_PERM_EXECUTE | VM_MAP_REGION_FLAG_PERM_USER);// 虚拟地址与物理地址的映射
    if (ret < 0) {
        goto ERROR;
    }

    (VOID)memset_s((VOID *)((UINTPTR)userText + userInitBssStart - userInitTextStart), initBssSize, 0, initBssSize);// 除了代码段，其余都清0

    stack = OsUserInitStackAlloc(g_userInitProcess, &size);// 初始化堆栈区
    if (stack == NULL) {
        PRINTK("user init process malloc user stack failed!\n");
        ret = LOS_NOK;
        goto ERROR;
    }

    param.pfnTaskEntry = (TSK_ENTRY_FUNC)userInitTextStart;// 从代码区开始执行，也就是应用程序main 函数的位置
    param.userParam.userSP = (UINTPTR)stack + size;// 指向栈顶
    param.userParam.userMapBase = (UINTPTR)stack;// 栈底
    param.userParam.userMapSize = size;// 栈大小
    param.uwResved = OS_TASK_FLAG_PTHREAD_JOIN;// 可结合的（joinable）能够被其他线程收回其资源和杀死
    ret = OsUserInitProcessStart(g_userInitProcess, ¶m);// 创建一个任务，来运行main函数
    if (ret != LOS_OK) {
        (VOID)OsUnMMap(processCB->vmSpace, param.userParam.userMapBase, param.userParam.userMapSize);
        goto ERROR;
    }

    return LOS_OK;

ERROR:
    (VOID)LOS_PhysPagesFreeContiguous(userText, initSize >> PAGE_SHIFT);//释放物理内存块
    OsDeInitPCB(processCB);//删除PCB块
    return ret;
}

鸿蒙源码百篇博客 往期回顾

在给 鸿蒙内核源码加中文注释 过程中,整理出以下文章.内容立足源码,常以生活场景打比方尽可能多的将内核知识点置入某种场景,具有画面感.百篇博客绝不是百度教条式的在说一堆诘屈聱牙的概念,那没什么意思.更希望让内核变得栩栩如生,倍感亲切.确实有难度,自不量力,但已经出发,回头已是不可能的了.

写文章比写代码累多了,越深入研究,越觉得没写好,所以文章和注解会反复修正, .xx代表修改的次数, 将持续完善源码注解和文档内容，精雕细琢，言简意赅, 尽全力打磨精品内容.

• v50.xx (编译环境篇) | 编译鸿蒙看这篇或许真的够了 < csdn | 51cto | osc >

• v49.xx (信号消费篇) | 用户栈到内核栈的两次切换 < csdn | 51cto | osc >

• v48.xx (信号生产篇) | 如何安装和发送信号? < csdn | 51cto | osc >

• v47.xx (进程回收篇) | 进程在临终前如何向老祖宗托孤 < csdn | 51cto | osc >

• v46.xx (特殊进程篇) | 龙生龙,凤生凤,老鼠生儿会打洞 < csdn | 51cto | osc >

• v45.xx (fork篇) | fork是如何做到调用一次,返回两次的 ? < csdn | 51cto | osc >

• v44.xx (中断管理篇) | 硬中断的实现<>观察者模式 < csdn | 51cto | osc >

• v43.xx (中断概念篇) | 外人眼中权势滔天的当红海公公 < csdn | 51cto | osc >

• v42.xx (中断切换篇) | 中断切换到底在切换什么? < csdn | 51cto | osc >

• v41.xx (任务切换篇) | 汇编告诉任务到底在切换什么 < csdn | 51cto | osc >

• v40.xx (汇编汇总篇) | 所有的汇编代码都在这里 < csdn | 51cto | osc >

• v39.xx (异常接管篇) | 社会很单纯,复杂的是人 < csdn | 51cto | osc >

• v38.xx (寄存器篇) | arm所有寄存器一网打尽,不再神秘 < csdn | 51cto | osc >

• v37.xx (系统调用篇) | 系统调用到底经历了什么 < csdn | 51cto | osc >

• v36.xx (工作模式篇) | cpu是韦小宝,有哪七个老婆? < csdn | 51cto | osc >

• v35.xx (时间管理篇) | tick是操作系统的基本时间单位 < csdn | 51cto | osc >

• v34.xx (原子操作篇) | 是谁在为原子操作保驾护航? < csdn | 51cto | osc >

• v33.xx (消息队列篇) | 进程间如何异步解耦传递大数据 ? < csdn | 51cto | osc >

• v32.xx (cpu篇) | 整个内核就是一个死循环 < csdn | 51cto | osc >

• v31.xx (定时器篇) | 内核最高优先级任务是谁? < csdn | 51cto | osc >

• v30.xx (事件控制篇) | 任务间多对多的同步方案 < csdn | 51cto | osc >

• v29.xx (信号量篇) | 信号量解决任务同步问题 < csdn | 51cto | osc >

• v28.xx (进程通讯篇) | 九种进程间通讯方式速揽 < csdn | 51cto | osc >

• v27.xx (互斥锁篇) | 比自旋锁丰满许多的互斥锁 < csdn | 51cto | osc >

• v26.xx (自旋锁篇) | 自旋锁当立贞节牌坊! < csdn | 51cto | osc >

• v25.xx (并发并行篇) | 怎么记住并发并行的区别? < csdn | 51cto | osc >

• v24.xx (进程概念篇) | 进程在管理哪些资源? < csdn | 51cto | osc >

• v23.xx (汇编传参篇) | 汇编如何传递复杂的参数? < csdn | 51cto | osc >

• v22.xx (汇编基础篇) | cpu在哪里打卡上班? < csdn | 51cto | osc >

• v21.xx (线程概念篇) | 是谁在不断的折腾cpu? < csdn | 51cto | osc >

• v20.xx (用栈方式篇) | 栈是构建底层运行的基础 < csdn | 51cto | osc >

• v19.xx (位图管理篇) | 为何进程和线程优先级都是32个? < csdn | 51cto | osc >

• v18.xx (源码结构篇) | 梳理内核源文件的作用和含义 < csdn | 51cto | osc >

• v17.xx (物理内存篇) | 这样记伙伴算法永远不会忘 < csdn | 51cto | osc >

• v16.xx (内存规则篇) | 内存管理到底在管什么? < csdn | 51cto | osc >

• v15.xx (内存映射篇) | 什么是内存最重要的实现基础 ? < csdn | 51cto | osc >

• v14.xx (内存汇编篇) | 什么是虚拟内存的实现基础? < csdn | 51cto | osc >

• v13.xx (源码注释篇) | 鸿蒙必须成功,也必然成功 < csdn | 51cto | osc >

• v12.xx (内存管理篇) | 虚拟内存全景图是怎样的? < csdn | 51cto | osc >

• v11.xx (内存分配篇) | 内存有哪些分配方式? < csdn | 51cto | osc >

• v10.xx (内存主奴篇) | 紫禁城的主子和奴才如何相处? < csdn | 51cto | osc >

• v09.xx (调度故事篇) | 用故事说内核调度过程 < csdn | 51cto | osc >

• v08.xx (总目录) | 百万汉字注解 百篇博客分析 < csdn | 51cto | osc >

• v07.xx (调度机制篇) | 任务是如何被调度执行的? < csdn | 51cto | osc >

• v06.xx (调度队列篇) | 内核有多少个调度队列? < csdn | 51cto | osc >

• v05.xx (任务管理篇) | 任务池是如何管理的? < csdn | 51cto | osc >

• v04.xx (任务调度篇) | 任务是内核调度的单元 < csdn | 51cto | osc >

• v03.xx (时钟任务篇) | 调度最大的源动力来自哪里? < csdn | 51cto | osc >

• v02.xx (进程管理篇) | 进程是内核资源管理单元 < csdn | 51cto | osc >

• v01.xx (双向链表篇) | 谁是内核最重要结构体? < csdn | 51cto | osc >

进入 >> osc | csdn | 51cto | 掘金 | 公众号 | 头条号 | gitee | github

各大站点搜 "鸿蒙内核源码分析" .原创不易,欢迎转载,但请注明出处.

热爱是所有的理由和答案 - turing