[mutex] 跨线程 rt_thread_delete 被删线程持有的mutex也一并释放

[meng-plus]

Clarified mutex release conditions and added exception handling for closed owner threads.

拉取/合并请求描述：(PR description)

[

为什么提交这份PR (why to submit this PR)

#11619

你的解决方案是什么 (what is your solution)

结合_thread_detach 清理流程可以看到先执行的 error = rt_thread_close(thread); 将 线程标记为RT_THREAD_CLOSE状态
再进入_thread_detach_from_mutex 清理所有mutex, 同时看到 mutex->hold = 1; 可知此处意图也是释放mutex

        /* recursively take */
        mutex->hold = 1;
        rt_mutex_release(mutex);

但是rt_mutex_release 处只进行了所有者的判定，未覆盖更多场景，如线程被外部杀死，线程锁死无法恢复等情况，
因此在释放处保留所有着判定外，额外增加 线程关闭也允许释放，以满足上述需求

对比工单11619 可看到解决效果

请提供验证的bsp和config (provide the config and bsp)

• BSP:

• .config:

• action:

]

当前拉取/合并请求的状态 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
• 已经使用clang-format 源码格式化工具确保格式符合RT-Thread代码规范 This PR has been formatted with clang-format and complies with RT-Thread code specification
• 如果是新增bsp, 已经添加ci检查到.github/ALL_BSP_COMPILE.json 详细请参考链接BSP自查

[github-actions]

👋 感谢您对 RT-Thread 的贡献！Thank you for your contribution to RT-Thread!

为确保代码符合 RT-Thread 的编码规范，请在你的仓库中执行以下步骤运行代码格式化工作流（如果格式化CI运行失败）。
To ensure your code complies with RT-Thread's coding style, please run the code formatting workflow by following the steps below (If the formatting of CI fails to run).

---

🛠 操作步骤 | Steps

1. 前往 Actions 页面 | Go to the Actions page
   点击进入工作流 → | Click to open workflow →

2. 点击 Run workflow | Click Run workflow

• 设置需排除的文件/目录（目录请以"/"结尾）
  Set files/directories to exclude (directories should end with "/")
• 将目标分支设置为 \ Set the target branch to：patch-1
• 设置PR number为 \ Set the PR number to：11620

3. 等待工作流完成 | Wait for the workflow to complete
   格式化后的代码将自动推送至你的分支。
   The formatted code will be automatically pushed to your branch.

完成后，提交将自动更新至 patch-1 分支，关联的 Pull Request 也会同步更新。
Once completed, commits will be pushed to the patch-1 branch automatically, and the related Pull Request will be updated.

如有问题欢迎联系我们，再次感谢您的贡献！💐
If you have any questions, feel free to reach out. Thanks again for your contribution!

[github-actions]

📌 Code Review Assignment

🏷️ Tag: kernel

Reviewers: @GorrayLi @ReviewSun @hamburger-os @lianux-mm @wdfk-prog @xu18838022837

Changed Files (Click to expand)

• src/ipc.c
• src/utest/mutex_tc.c

---

📊 Current Review Status (Last Updated: 2026-07-15 12:43 CST)

• ⌛ @GorrayLi Pending Review
• ⌛ @ReviewSun Pending Review
• ⌛ @hamburger-os Pending Review
• ⌛ @lianux-mm Pending Review
• ⌛ @wdfk-prog Pending Review
• ⌛ @xu18838022837 Pending Review

---

📝 Review Instructions

1. 维护者可以通过单击此处来刷新审查状态: 🔄 刷新状态
   Maintainers can refresh the review status by clicking here: 🔄 Refresh Status

2. 确认审核通过后评论 LGTM/lgtm
   Comment LGTM/lgtm after confirming approval

3. PR合并前需至少一位维护者确认
   PR must be confirmed by at least one maintainer before merging

ℹ️ 刷新CI状态操作需要具备仓库写入权限。
ℹ️ Refresh CI status operation requires repository Write permission.

[github-actions]

MemBrowse Memory Report

at32f415-start

• ROM: .text +24 B (+0.0%, 65,288 B / 262,144 B, total: 25% used)

gd32105r-start

• CODE: .text +24 B (+0.0%, 52,672 B / 262,144 B, total: 20% used)

hc32f334

• FLASH: .text +24 B (+0.0%, 99,520 B / 131,072 B, total: 76% used)

hpmicro-hpm5301evklite

• ILM: .fast +32 B (+0.1%, 38,128 B / 131,072 B, total: 29% used)
• XPI0: .fast +32 B (+0.0%, 124,912 B / 1,048,576 B, total: 12% used)

infineon-psoc6

• flash: .text +24 B (+0.0%, 116,164 B / 262,144 B, total: 44% used)

loongson-ls1cdev

• Code: .text +48 B (+0.0%, 362,672 B)

nordic-nrf51822

• FLASH: .text +24 B (+0.0%, 51,932 B / 262,144 B, total: 20% used)

nuvoton-m487

• CODE: .text +16 B (+0.0%, 355,780 B / 524,288 B, total: 68% used)

raspberry-pico-rp2040

• FLASH: .text +24 B (+0.0%, 114,168 B / 2,097,152 B, total: 5% used)

renesas-ra2l1

• FLASH: .text +24 B (+0.0%, 98,220 B / 262,144 B, total: 37% used)

simulator

• Code: .rela.dyn +432 B, .rodata +64 B, .text +225 B (+0.0%, 2,633,556 B)
• Data: .data +512 B (+0.0%, 1,583,008 B)

stm32f407-rt-spark

• CODE: .text +24 B (+0.0%, 85,788 B / 1,048,576 B, total: 8% used)

stm32l475-atk-pandora-llvm

• ROM: .text +24 B (+0.0%, 83,472 B / 524,288 B, total: 16% used)

wch-ch32v208w-r0

• FLASH: .text +32 B (+0.0%, 159,456 B / 491,520 B, total: 32% used)

x86

• Code: .text +32 B (+0.0%, 198,317 B)

xuantie-e901plus

• ISRAM: .rodata +48 B, .text +16 B (+0.1%, 46,360 B / 131,072 B, total: 35% used)
  No memory changes detected for:
• esp32-c3
• k230
• nxp-lpc1114
• qemu-virt64-aarch64

[Rbb666]

@meng-plus 可以帮忙补充一份测试用例到utest里面？

[Rbb666]

调研了主流 RTOS 在“跨线程终止（线程 A 强杀线程 B）”场景下对互斥锁释放的处理机制。
发现无论是 Zephyr（参考文档）还是 FreeRTOS（参考讨论），其内核设计哲学都不支持自动回收被终止线程占用的应用层资源（如互斥锁、堆内存等），而是统一要求在用户业务层面进行手动释放或协同退出。

[meng-plus]

查了下 FreeRTOS 和 Zephyr 源码，vTaskDelete() 和 k_thread_abort() 都不会清理线程持有的 mutex。FreeRTOS 的 prvDeleteTCB() 直接 vPortFree(pxTCB)，mutex 中的 xMutexHolder 指针就变成野指针了。Zephyr 同理。
不过 Linux 的做法值得参考 —— futex 存的是 TID 不是指针，进程退出时内核标记 FUTEX_OWNER_DIED 并唤醒 waiter，让用户态决定恢复策略。这样不存在野指针问题，恢复逻辑也和内核解耦。
RT-Thread 这边 mutex->owner 是裸指针，线程 delete 后指针失效，后续 rt_mutex_release() 和优先级继承都会踩野指针。这不是"该不该释放"的问题，是内核数据结构的完整性问题。

当前这个 PR 并非独创的释放持有的锁，结合源码可知，之前的设计意图也是释放mutex，只是设计后未经验证，不符合其设计预期