鸿蒙内核源码分析 (双向链表篇) | 谁是内核最重要结构体

双向链表是什么？

谁是鸿蒙内核最重要的结构体？一定是: LOS_DL_LIST(双向链表)，它长这样。

typedef struct LOS_DL_LIST {struct LOS_DL_LIST *pstPrev; /**< Current node's pointer to the previous node | 前驱节点(左手)*/struct LOS_DL_LIST *pstNext; /**< Current node's pointer to the next node | 后继节点(右手)*/
} LOS_DL_LIST;

在 linux 中是 list_head，很简单，只有两个指向自己的指针，但因为太简单，所以不简单。站长更愿意将它比喻成人的左右手，其意义是通过寄生在宿主结构体上来体现，可想象成在宿主结构体装上一对对勤劳的双手，它真的很会来事，超级活跃分子，为宿主到处拉朋友，建圈子。

基本概念：双向链表是指含有往前和往后两个方向的链表，即每个结点中除存放下一个节点指针外，还增加一个指向前一个节点的指针，从双向链表中的任意一个结点开始，都可以很方便地访问它的前驱结点和后继结点，这种数据结构形式使得双向链表在查找时更加方便，特别是大量数据的遍历。由于双向链表具有对称性，能方便地完成各种插入、删除等操作。
使用场景：在内核的各个模块都能看到双向链表的身影，下图是初始化双向链表的操作，因为太多了，只截取了部分:

可以豪不夸张的说理解 LOS_DL_LIST 及相关函数是读懂鸿蒙内核的关键。前后指针 (左右触手) 灵活的指挥着系统精准的运行，越是深挖内核代码越是能体会到它在内核举足轻重的地位，笔者仿佛看到了无数双手前后相连，拉起了一个个双向循环链表，把指针的高效能运用到了极致，这也许就是编程的艺术吧！

怎么实现？

鸿蒙系统中的双向链表模块为用户提供下面几个接口。

其插入 | 删除 | 遍历操作是它最常用的社交三大件，若不理解透彻在分析源码过程中很容易卡壳。虽在网上能找到很多它的图，但怎么看都不是自己想要的，干脆重画了它的主要操作。

//将指定节点初始化为双向链表节点
LITE_OS_SEC_ALW_INLINE STATIC INLINE VOID LOS_ListInit(LOS_DL_LIST *list)
{list->pstNext = list;list->pstPrev = list;
}//将指定节点挂到双向链表头部
LITE_OS_SEC_ALW_INLINE STATIC INLINE VOID LOS_ListAdd(LOS_DL_LIST *list, LOS_DL_LIST *node)
{node->pstNext = list->pstNext;node->pstPrev = list;list->pstNext->pstPrev = node;list->pstNext = node;
}
//将指定节点从链表中删除，自己把自己摘掉
LITE_OS_SEC_ALW_INLINE STATIC INLINE VOID LOS_ListDelete(LOS_DL_LIST *node)
{node->pstNext->pstPrev = node->pstPrev;node->pstPrev->pstNext = node->pstNext;node->pstNext = NULL;node->pstPrev = NULL;
}
//将指定节点从链表中删除，并使用该节点初始化链表
LITE_OS_SEC_ALW_INLINE STATIC INLINE VOID LOS_ListDelInit(LOS_DL_LIST *list)
{list->pstNext->pstPrev = list->pstPrev;list->pstPrev->pstNext = list->pstNext;LOS_ListInit(list);
}

数据在哪？

有好几个同学问数据在哪？确实 LOS_DL_LIST 这个结构看起来怪怪的，它竟没有数据域！所以看到这个结构的人第一反应就是我们怎么访问数据？其实 LOS_DL_LIST 不是拿来单独用的，它是寄生在内容结构体上的，谁用它谁就是它的数据。看图就明白了。

强大的宏

除了内联函数，对双向链表的初始化，偏移定位，遍历等等操作提供了更强大的宏支持。使内核以极其简洁高效的代码实现复杂逻辑的处理。

//定义一个节点并初始化为双向链表节点
#define LOS_DL_LIST_HEAD(list) LOS_DL_LIST list = { &(list), &(list) }//获取指定结构体内的成员相对于结构体起始地址的偏移量
#define LOS_OFF_SET_OF(type, member) ((UINTPTR)&((type *)0)->member)//获取包含链表的结构体地址，接口的第一个入参表示的是链表中的某个节点，第二个入参是要获取的结构体名称，第三个入参是链表在该结构体中的名称
#define LOS_DL_LIST_ENTRY(item, type, member) \((type *)(VOID *)((CHAR *)(item) - LOS_OFF_SET_OF(type, member)))//遍历双向链表
#define LOS_DL_LIST_FOR_EACH(item, list) \for (item = (list)->pstNext;         \(item) != (list);               \item = (item)->pstNext)//遍历指定双向链表，获取包含该链表节点的结构体地址，并存储包含当前节点的后继节点的结构体地址
#define LOS_DL_LIST_FOR_EACH_ENTRY_SAFE(item, next, list, type, member)               \for (item = LOS_DL_LIST_ENTRY((list)->pstNext, type, member)，                     \next = LOS_DL_LIST_ENTRY((item)->member.pstNext, type, member);              \&(item)->member != (list);                                                   \item = next, next = LOS_DL_LIST_ENTRY((item)->member.pstNext, type, member))//遍历指定双向链表，获取包含该链表节点的结构体地址
#define LOS_DL_LIST_FOR_EACH_ENTRY(item, list, type, member)             \for (item = LOS_DL_LIST_ENTRY((list)->pstNext, type, member);        \&(item)->member != (list);                                      \item = LOS_DL_LIST_ENTRY((item)->member.pstNext, type, member))

LOS_OFF_SET_OF 和 LOS_DL_LIST_ENTRY

这里要重点说下 LOS_OFF_SET_OF 和 LOS_DL_LIST_ENTRY 两个宏，个人认为它们是链表操作中最关键，最重要的宏。在读内核源码的过程会发现 LOS_DL_LIST_ENTRY 高频的出现，它们解决了通过结构体的任意一个成员变量来找到结构体的入口地址。这个意义重大，因为在运行过程中，往往只能提供成员变量的地址，那它是如何做到通过个人找到组织的呢？

LOS_OFF_SET_OF 找到成员变量在结构体中的相对偏移位置。在系列篇用栈方式篇中已说过鸿蒙采用的是递减满栈的方式。以 ProcessCB 结构体举例

typedef struct ProcessCB {LOS_DL_LIST          pendList;                     /**< Block list to which the process belongs | 进程所在的阻塞列表,进程因阻塞挂入相应的链表.*/LOS_DL_LIST          childrenList;                 /**< Children process list | 孩子进程都挂到这里,形成双循环链表*/LOS_DL_LIST          exitChildList;                /**< Exit children process list | 要退出的孩子进程链表，白发人要送黑发人.*/LOS_DL_LIST          siblingList;                  /**< Linkage in parent's children list | 兄弟进程链表, 56个民族是一家,来自同一个父进程.*/LOS_DL_LIST          subordinateGroupList;         /**< Linkage in group list | 进程组员链表*/LOS_DL_LIST          threadSiblingList;            /**< List of threads under this process | 进程的线程(任务)列表 */LOS_DL_LIST          waitList;     /**< The process holds the waitLits to support wait/waitpid | 父进程通过进程等待的方式，回收子进程资源，获取子进程退出信息*/
} LosProcessCB;

waitList 因为在结构体的后面，所以它内存地址会比在前面的 pendList 高，有了顺序方向就很容易得到 ProcessCB 的第一个变量的地址。LOS_OFF_SET_OF 就是干这个的，含义就是相对第一个变量地址，你 waitList 偏移了多少。

如此，当外面只提供 waitList 的地址再减去偏移地址就可以得到 ProcessCB 的起始地址。

#define LOS_DL_LIST_ENTRY(item， type， member) \((type *)(VOID *)((CHAR *)(item) - LOS_OFF_SET_OF(type， member)))

当然如果提供 pendList 或 exitChildList 的地址道理一样。LOS_DL_LIST_ENTRY 实现了通过任意成员变量来获取 ProcessCB 的起始地址。

OsGetTopTask

有了以上对链表操作的宏，可以使得代码变得简洁易懂，例如在调度算法中获取当前最高优先级的任务时，就需要遍历整个进程和其任务的就绪列表。LOS_DL_LIST_FOR_EACH_ENTRY 高效的解决了层层循环的问题。

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();
#endifLosProcessCB *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)) {
#endifnewTask->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;
}

结构体的最爱

LOS_DL_LIST 是复杂结构体的最爱，再以 ProcessCB(进程控制块) 举例，它是描述一个进程的所有信息，其中用到了 7 个双向链表，这简直比章鱼还牛逼，章鱼也才四双触手，但进程有 7 双 (14 只) 触手。

typedef struct ProcessCB {LOS_DL_LIST          pendList;                     /**< Block list to which the process belongs | 进程所在的阻塞列表,进程因阻塞挂入相应的链表.*/LOS_DL_LIST          childrenList;                 /**< Children process list | 孩子进程都挂到这里,形成双循环链表*/LOS_DL_LIST          exitChildList;                /**< Exit children process list | 要退出的孩子进程链表，白发人要送黑发人.*/LOS_DL_LIST          siblingList;                  /**< Linkage in parent's children list | 兄弟进程链表, 56个民族是一家,来自同一个父进程.*/LOS_DL_LIST          subordinateGroupList;         /**< Linkage in group list | 进程组员链表*/LOS_DL_LIST          threadSiblingList;            /**< List of threads under this process | 进程的线程(任务)列表 */LOS_DL_LIST          waitList;     /**< The process holds the waitLits to support wait/waitpid | 父进程通过进程等待的方式，回收子进程资源，获取子进程退出信息*/
} LosProcessCB;

解读

pendList 个人认为它是鸿蒙内核功能最多的一个链表，它远不止字面意思阻塞链表这么简单，只有深入解读源码后才能体会它真的是太会来事了，一般把它理解为阻塞链表就行。上面挂的是处于阻塞状态的进程。
childrenList 孩子链表，所有由它 fork 出来的进程都挂到这个链表上。上面的孩子进程在死亡前会将自己从上面摘出去，转而挂到 exitChildList 链表上。
exitChildList 退出孩子链表，进入死亡程序的进程要挂到这个链表上，一个进程的死亡是件挺麻烦的事，进程池的数量有限，需要及时回收进程资源，但家族管理关系复杂，要去很多地方消除痕迹。尤其还有其他进程在看你笑话，等你死亡 (wait/waitpid) 了通知它们一声。
siblingList 兄弟链表，和你同一个父亲的进程都挂到了这个链表上。
subordinateGroupList 朋友圈链表，里面是因为兴趣爱好 (进程组) 而挂在一起的进程，它们可以不是一个父亲，不是一个祖父，但一定是同一个老祖宗 (用户态和内核态根进程)。
threadSiblingList 线程链表，上面挂的是进程 ID 都是这个进程的线程 (任务)，进程和线程的关系是 1:N 的关系，一个线程只能属于一个进程。这里要注意任务在其生命周期中是不能改所属进程的。
waitList 是等待子进程消亡的任务链表，注意上面挂的是任务。任务是通过系统调用
```
pid_t wait(int *status);
pid_t waitpid(pid_t pid, int *status, int options);
```