[kernel]在smart模式也启用"回收线程"
lwp的某些资源回收放到了后台,其中会引起线程挂起,而idle不应该被挂起
拉取/合并请求描述:(PR description)
[
为什么提交这份PR (why to submit this PR)
用户态程序退出后在idle中回收资源会触发assert(mutex->owner == current-thread)
你的解决方案是什么 (what is your solution)
单核smart模式也启用回收线程
请提供验证的bsp和config (provide the config and bsp)
#9181 milkv
]
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
- [ ] 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
- [ ] 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo
代码质量 Code Quality:
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
- [ ] 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
- [ ] 代码风格正确,包括缩进空格,命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
- [ ] 没有垃圾代码,代码尽量精简,不包含
#if 0代码,不包含已经被注释了的代码 All redundant code is removed and cleaned up - [ ] 所有变更均有原因及合理的,并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
- [ ] 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
- [ ] 代码是高质量的 Code in this PR is of high quality
- [ ] 已经使用formatting 等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification
@polarvid 可以考虑帮忙给出分离成不同的idle.c版本建议出来,也可以直接对idle.c进行重构。
@polarvid 可以考虑帮忙给出分离成不同的idle.c版本建议出来,也可以直接对idle.c进行重构。
把defunct单独放不好吗
@polarvid 可以考虑帮忙给出分离成不同的idle.c版本建议出来,也可以直接对idle.c进行重构。
把defunct单独放不好吗
我觉得有个独立的 defunct 对应到原本的 SMP defunct 倒是没什么。只是说可以再讨论一下原本那个 idle 线程兼任空闲任务有没有必要保留。
@polarvid 可以考虑帮忙给出分离成不同的idle.c版本建议出来,也可以直接对idle.c进行重构。
把defunct单独放不好吗
我觉得有个独立的 defunct 对应到原本的 SMP defunct 倒是没什么。只是说可以再讨论一下原本那个 idle 线程兼任空闲任务有没有必要保留。
我倾向于idle就让它做个单纯的空闲任务,只处理一些pm相关事情就好了,defunct事务就交给专门的线程处理,即使在简单的RTOS模式也保留defunct线程
如果需要保持两种 idle 的实现,在这个 PR 基础上补充一个 Kconfig 并且保留 idle 线程调用 defunct 例程的能力应该就可以了。
我倾向于idle就让它做个单纯的空闲任务,只处理一些pm相关事情就好了,defunct事务就交给专门的线程处理,即使在简单的RTOS模式也保留defunct线程
个人建议是保留原来复用 idle 实现一些简单回收的功能。因为 RTT 支持的平台很多,并不是每个都需要完成极其复杂的回收任务。特别是资源受限的平台上,本来它们的任务就简单,还要占用有限的资源多创建一个线程完成这项工作并不合理。
因此可以基于这份 PR,增加一个 Kconfig 配置是否创建 defunct 线程。默认 64 bits 架构下或者使能 Smart 时为 Y,否则为 N。
我倾向于idle就让它做个单纯的空闲任务,只处理一些pm相关事情就好了,defunct事务就交给专门的线程处理,即使在简单的RTOS模式也保留defunct线程
个人建议是保留原来复用 idle 实现一些简单回收的功能。因为 RTT 支持的平台很多,并不是每个都需要完成极其复杂的回收任务。特别是资源受限的平台上,本来它们的任务就简单,还要占用有限的资源多创建一个线程完成这项工作并不合理。
因此可以基于这份 PR,增加一个 Kconfig 配置是否创建 defunct 线程。默认 64 bits 架构下或者使能 Smart 时为 Y,否则为 N。
以前的方式还是保留了的,这个pr里只是分离了部分代码并在smart模式也用了回收线程,配置就先不加了,因为当前根据已有配置自动判断足够用了,等以后需要加配置的时候再由其他人来修吧