四. 就绪列表

最新推荐文章于 2025-04-24 16:54:41 发布
原创 最新推荐文章于 2025-04-24 16:54:41 发布 · 952 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#c语言 #uCOS III #嵌入式系统 #就绪列表

本文详细介绍了嵌入式系统中就绪列表的结构和作用，包括优先级的设定、就绪列表的组成以及如何将任务添加到就绪队列中，最后进行了总结。

准备运行的任务被放置于就绪列表中。就绪列表包括2 个部分：位映像组包含了优先级信息，一个表包含了所有指向就绪任务的指针。

一  优先级

显示了优先级的位映像组。它的宽度取决于CPU_DATA 的数据类型（见CPU.H），它可以是8 位、16 位、32 位。根据处理器相应地设定。
uC/OS-III 支持多达OS_CFG_PRIO_MAX 种不同的优先级（见OS_CFG.H）。在uC/OS-III 中，数值越小优先级越高。因此优先级0是优先级最高的。优先级OS_CFG_PRIO_MAX-1 的优先级最低。uC/OS-III 将最低优先级唯一地分配给空闲任务，其它任务不允许被设置为这个优先级。当任务准备好运行了，根据任务的优先级，位映像表中相应位就会被设置为1。如果处理器支持位清零指令CLZ，这个指令会加快位映像表的设置过程。


OS_PRIO.C 中包含了位映像表的设置、清除、查找的相关代码
最低0.47元/天 解锁文章
RTOS学习（9）--就绪列表
weixin_58670090的博客
02-03 536
介绍UCOS的就序列表，以及相关函数
FreeRTOS之实现就绪列表（或者说就绪列表的建立更容易理解）
weixin_41040351的博客
03-08 761
就绪列表顾名思义：一个个需要在操作系统里面运行的好多任务，我们需要给这些任务分配好，先运行那个，也就是事情的轻重缓急呗。 具体步骤很简单：先初始化一个链表，吧这个链表起个名字叫做就绪列表，那么初始化该链表也就是就绪列表的初始化， 参考代码如下： #define configMAX_PRIORITIES ( 5 ) List_t pxReadyTasksLists[ configMAX_PRIORITIES ]; /* 初始化任务相关的列表 */ void prvIniti
FreeRTOS就绪列表视图.vsdx
11-14
在FreeRTOS中，使用数字表示任务优先级，数字越小优先级越小（这点和uC/OS & RT-Thread正好相反） FreeRTOS中任务就绪列表视图如下图所示，可见如何将就绪列表状态映射到就绪位图中
实现就绪列表
m0_63702526的博客
08-01 239
8.1
uCOS-III 学习记录（7）——就绪列表
Mount256的博客
02-01 2215
喜气洋洋过虎年！预祝各位明年会有更大的进步！ 参考内容：《[野火]uCOS-III内核实现与应用开发实战指南——基于STM32》第 11 章。 文章目录1 就绪列表和任务控制块的定义（os.h）1.1 任务控制块链表 OS_TCB1.2 就绪列表 OS_RDY_LIST1.3 全局变量定义1.4 结构全图2 初始化就绪列表 OS_RdyListInit()（os_core.c）3 将 TCB 节点从链表头部移到链表尾部 OS_RdyListMoveHeadToTail()（os_core.c）3.1 链表头
RTOS学习之旅（四）（ucosIII 优先级表 就绪列表）
weixin_36101480的博客
05-03 1054
在 uC/OS-III 中，任务被创建后，任务的 TCB 会被放入就绪列表中，表示任务在就绪，随时可能被运行。就绪列表包含一个表示任务优先级的优先级表，一个存储任务 TCB 的 TCB 双向链表。 1.优先级表 1.1优先级表介绍 优先级表实质上是一个数组。在os_prio.c中定义。 CPU_DATA OSPrioTbl[OS_PRIO_TBL_SIZE]; 数组类型为 CPU_DATA...
14.Kubernetes 就绪性探针（Readiness Probe）详解
Anwen的博客
04-13 1976
就绪性探针（Readiness Probe）用于检测容器是否已准备好接收外部流量。其核心机制包括：流量控制：探针成功时，Pod IP 被加入 Service 的 Endpoints 列表，允许流量转发；失败时则从列表中移除，暂停流量分发至该 Pod。业务就绪保障：确保 Pod 完成初始化（如加载配置、预热程序）后才开放服务请求，避免未就绪实例处理请求导致失败。
以就绪列表为例。如果在32位的硬件中，会保存一个32位的变量，代表0-31的优先级。当某个位，置一时，代表所对应的优先级就绪列表有任务存在。如果有多个任务优先级相同，会连接在同一个就绪列表上：
03-15
好的，我需要回答用户关于FreeRTOS中就绪列表的问题，特别是如何在32位硬件中使用32位变量来管理不同优先级的任务。用户提到当某个位被置1时，表示对应优先级有任务就绪，并且相同优先级的任务会链接到同一个就绪...
uCos II 就绪列表
且行且珍惜
05-30 531
参考http://blog.sina.com.cn/s/blog_762cf5f80101ce8w.html
RT-Thread 读后感3 —— 实现就绪列表 （定义就绪列表，将线程插入到就绪列表）
qq_27762895的博客
10-25 468
1. 定义就绪列表 线程创建好后，需要将线程添加到就绪列表里面，表示线程已经就绪，系统随时可以调度。RT-Thread定义的就绪列表如下： /* 线程就绪列表如下 ** RT_THREAD_PRIORITY_MAX 在rtconfig.h中默认定义为32 决定最大线程优先级 */ rt_list_t rt_thread_priority_table[RT_THREAD_PRIORI...
FreeRTOS内核学习笔记记录（三）——任务就绪列表
weixin_41673690的博客
03-23 423
configMAX_PRIORITIES 宏决定 表示优先级。同样 宏越大占用的内存资源越多。但是它是List_t类型 即每个数组成员都是一个根节点数据结构。根节点数据结构，链表结点能够挂载在上面。任务就绪列表实际上是一个静态数组。第二个函数上一个章节已经提及。
任务管理和就绪列表
思泽之思
10-16 840
简单介绍一下uCOS-III中的任务管理(Task management)和就绪列表(The Ready List)
μC/OS-III_任务就绪表
aaronbin的博客
07-07 594
任务就绪表 在系统中，所有已经就绪等待运行的任务都被放入一个所谓“就绪表”(ready list)中，该表包括两部分 就绪优先级位映射表 就绪任务列表 1.1 就绪优先级位映射表 每一位代表一个优先级，当某一优先级由任务就绪时，在就绪优先级位映射表中该优先级对应的位被置1，之所以按照上图的顺序映射，是为了便于使用一条特殊的指令“计算前导零”，该指令可以显著提高最高优先级查找的速度。 优先级操作函数 函数 说明 OS_PrioGetHighest() 查找就绪的最高优先级 OS-Pr
任务与列表
YDXBJJH的博客
04-24 274
总结：高优先级任务优先执行，高优先级任务不结束低优先级任务无法执行，被抢占的任务会进入就绪状态。2.时间片调度：在优先级相同的时候进行时间式调度（一个时间片就等于systick周期）1.就绪列表：pxReadyTasksLists[x]，x代表优先级。1.抢占式调度：根据优先级进行分配任务（数值越大优先级越高）1.运行态：实际上同一时间只有一个任务处于运行态。（除了运行态，其他三种都有所对应的任务列表）3.阻塞态：因为延时等等因素在等待等待。2.就绪态：准备执行。移植Freertos。
uc/os-iii学习笔记-任务就绪表
JosephGodVim的博客
07-19 1095
就绪表就绪表由两部分组成：就绪优先级位映射表、就绪任务列表。
FreeRTOS 查找最高优先级的就绪任务源码分析
a只如初见的博客
08-24 1000
就绪列表是一个数组， 数组里面存的是就绪任务的 TCB（准确来说是 TCB 里面的 xStateListItem 节点） ，数组的下标对应任务的优先级，优先级越低对应的数组下标越小(即数字优先级越小，逻辑优先级也越小)。空闲任务的优先级最低，对应的是下标为 0 的链表。configMAX_PRIORITIES 该宏定义在FreeRTOSConfig.h中，代表支持的最大优先级。我们看到configMAX_PRIORITIES 即为就绪任务列表的数组元素个数。
FreeRTOSFreeRTOS列表和列表项
qq_44219883的博客
04-07 1001
列表就是FreeRTOS中的数据结构，它被用来跟踪FreeRTOS中的任务。就绪列表（Ready Lists）：对于每个优先级，FreeRTOS都维护一个就绪列表。当任务处于就绪状态，能够运行，但由于CPU正被其他任务使用而无法立即执行时，该任务会被放入相应优先级的就绪列表中。当CPU可用时，调度器会从最高优先级的就绪列表中选择任务来执行。阻塞列表（Blocked Lists）：当任务等待某个事件（如信号量、互斥量或定时器）时，它会被放入阻塞列表。阻塞列表用于跟踪哪些任务正在等待资源变得可用。
就绪任务的管理
Sugar的专栏
11-03 1538
uc/OS-II在RAM中设立了一个记录表，系统中的每个任务在表中占一个位置，并用这个位置的状态（0和1）来表示任务是否处于就绪状态。这个表叫做任务就绪状态表。 就绪任务表实际上是一个类型为INT8U的数组OSRdyTbl[]。其中每个字节的每个位表示一个任务，这样一个数组元素就可以表示8个任务的就绪状态。以任务优先级别高低为顺序，比如OSRdyTbl[0]的第1位表示任务优先级0，OSRdyT
FreeRTOS实现就绪列表
weixin_45589030的博客
02-22 602
就绪列表 就绪列表就是一个 List_t 类型的数组（List_t 就是链表头的数据类型），数组大小由 决定最大任务优先级的宏 configMAX_PRIORITIES 决定 目前在配置文件中默认定义为5。最大支持256个优先级，数组的下标就对应了任务的优先级，同一优先级的任务统一插入到就绪列表的同一条链表中 就绪列表定义： List_t pxReadyTasksLists[configMAX_PRIORITIES]; 就绪列表只有5个数 初始化任务相关的就绪列表 static void prvInit
epoll 双向链表（就绪事件列表）
最新发布
05-07
<think>好的，我需要帮助用户理解epoll中双向链表的实现及其在就绪事件列表中的作用。首先，用户已经提到了红黑树的结构，现在转向双向链表。我需要结合用户提供的引用内容，特别是引用[1]、[2]、[4]来构建回答。 首先，确定双向链表在epoll中的位置。根据引用[1]，就绪列表需要快速插入和删除，所以使用双向链表（rdllist）。每个epitem结构体（引用[2]）中的rdllink就是链表的节点。因此，双向链表的节点结构应该来自epitem的list_head rdllink。 接下来，双向链表的作用。根据引用[1]，当socket事件发生时，内核将其插入就绪列表，并且在删除时，如果该socket在列表中，也需要移除。这里需要解释链表如何高效处理插入和删除，可能涉及O(1)时间复杂度。同时，引用[4]提到LT模式下，事件处理完成后会重新放回链表，而ET模式不会，这说明链表在处理不同触发模式时的不同操作。 然后，源码实现部分。用户可能希望看到具体的链表操作函数，比如list_add_tail或list_del_init，这需要结合Linux内核代码中的实际函数，虽然用户没有直接给出这部分源码，但根据常见的链表操作，可以合理推断。例如，在事件触发时调用list_add_tail将epitem加入链表，处理时遍历链表并处理事件。 接着，性能优势。需要对比其他数据结构，比如数组或单向链表，说明双向链表在插入、删除和遍历上的效率。特别是删除操作时，双向链表可以直接通过节点指针删除，不需要遍历，这是O(1)的。 然后，LT和ET模式的处理差异。根据引用[4]，LT模式在事件未被处理完时会被重新放回链表，而ET模式不会。这里需要说明链表在这两种模式下的不同处理流程，可能导致LT的效率较低，因为需要多次回放。 最后，总结双向链表与红黑树的关系，红黑树管理所有监控的fd，而链表仅管理就绪的，两者协同工作。同时，回答用户的相关问题，确保覆盖可能的扩展点，比如LT和ET的性能差异、链表线程安全等。 需要确保回答结构清晰，分点说明，结合引用内容，同时保持技术准确性。可能需要检查引用内容是否准确支持每个观点，比如引用[1]提到删除红黑树节点会同时删除链表节点，但根据结构体定义，epitem同时包含红黑树节点和链表节点，因此在删除epitem时，确实会同时从两个数据结构中移除，但实际代码中是否自动处理需要确认。不过根据用户提供的引用，可以接受这种描述。 另外，用户可能希望了解链表的具体实现细节，比如内核中的list_head结构，如何链接前后节点，以及如何遍历链表。这部分可以简要说明，但不需要深入内核源码的细节，除非用户明确要求。 最后，确保使用中文，正确使用LaTeX格式，如时间复杂度O(1)，并生成相关问题。</think>### epoll中双向链表的实现及就绪事件列表的作用 #### 一、双向链表的实现 1. **节点结构** epoll使用Linux内核的通用双向链表结构`list_head`，其定义如下（见引用[2]）： ```c struct epitem { struct list_head rdllink; // 双向链表节点 // ...其他字段（红黑树节点、文件描述符等） }; ``` 每个`epitem`通过`rdllink`字段嵌入到双向链表中，链表的每个节点包含前驱（`prev`）和后继（`next`）指针，支持快速插入和删除操作[^1][^2]。 2. **链表操作函数** - **插入事件**：当内核检测到文件描述符（fd）就绪时，调用`list_add_tail`将对应的`epitem`添加到链表尾部，时间复杂度为$O(1)$。 - **删除事件**：从链表中移除节点时，使用`list_del_init`直接操作指针，无需遍历，时间复杂度为$O(1)$[^1]。 - **遍历链表**：通过`list_for_each_entry_safe`宏遍历链表，逐个处理就绪事件[^4]。 --- #### 二、就绪事件列表的核心作用 1. **高效事件通知** - **快速响应**：就绪链表（`rdllist`）仅存储已触发事件的`epitem`，`epoll_wait`直接从链表中拷贝就绪事件到用户空间，避免遍历所有监控的fd[^1][^4]。 - **低延迟**：链表的插入和删除操作均为$O(1)$，确保高并发场景下事件通知的实时性。 2. **与红黑树的协同** - **分工明确**：红黑树管理所有注册的fd（增删复杂度$O(\log n)$），链表仅缓存就绪事件（操作复杂度$O(1)$），两者结合实现高效的事件管理[^1][^2]。 - **数据一致性**：删除红黑树中的`epitem`时，若该节点已存在于链表，会同步移除链表节点（因`epitem`同时包含红黑树和链表节点）[^1]。 3. **支持LT与ET模式** - **LT（水平触发）**：处理事件后，若未完全消费事件（如socket缓冲区仍有数据），内核会重新将`epitem`插入链表，确保下次`epoll_wait`继续返回该事件[^4]。 - **ET（边缘触发）**：事件仅被加入链表一次，用户需一次性处理完所有数据，否则可能丢失后续事件。 --- #### 三、源码级实现细节（以LT模式为例） ```c // 内核源码逻辑（fs/eventpoll.c）[^4] static int ep_poll_callback(void *priv) { struct epitem *epi = priv; struct eventpoll *ep = epi->ep; // 将epitem加入就绪链表 list_add_tail(&epi->rdllink, &ep->rdllist); // 若为LT模式且事件未处理完，重新插入链表 if (!(epi->event.events & EPOLLET) && !list_empty(&epi->rdllink)) list_add_tail(&epi->rdllink, &ep->rdllist); // 唤醒等待进程 wake_up(&ep->wq); } ``` **关键逻辑**： 1. 事件触发时，回调函数将`epitem`加入`rdllist`。 2. LT模式下，若事件未被完全处理，重新插入链表以保证下次通知[^4]。 --- #### 四、性能优势对比 | 操作类型 | 双向链表（rdllist） | 数组 | 单向链表 | |----------------|--------------------|---------------|---------------| | **插入/删除** | $O(1)$ | $O(n)$* | $O(1)$ | | **遍历效率** | $O(n)$ | $O(n)$ | $O(n)$ | | **内存占用** | $O(n)$ | $O(n)$ | $O(n)$ | > *数组插入/删除需移动元素，时间复杂度为$O(n)$ **结论**：双向链表在动态事件管理场景下综合性能最优，完美适配epoll高吞吐量的需求[^1]。 --- #### 五、与其他组件的交互 1. **与红黑树的关系** - 红黑树负责长期管理所有fd，双向链表仅临时缓存活跃事件，两者通过`epitem`结构体关联[^1]。 - 删除红黑树节点时，若该节点在链表中，会同步移除（因`epitem`同时属于两种数据结构）。 2. **与等待队列（`wq`）的联动** - 当`rdllist`非空时，通过`wq`唤醒阻塞在`epoll_wait`的进程，触发用户态事件处理[^4]。 --- ### 相关问题 1. **为什么双向链表比单向链表更适合实现就绪队列？** 双向链表支持$O(1)$时间复杂度的尾部插入和任意节点删除（通过前后指针直接操作），而单向链表删除节点需遍历前驱节点，复杂度为$O(n)$[^1]。 2. **LT模式下频繁回放链表是否会导致性能下降？** 是的。LT模式下未处理完的事件会被重新插入链表，导致多次通知和遍历，增加CPU开销。ET模式通过一次性处理优化性能，但需要用户代码更严谨[^4]。 3. **就绪链表的线程安全性如何保障？** 内核通过自旋锁（`ep->lock`）保护`rdllist`的并发访问，确保多核环境下插入/删除操作的原子性[^4]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值