RT-Thread
[ipc][condvar] 修正 'timeout' 符号问题
拉取/合并请求描述：(PR description)
[
为什么提交这份PR (why to submit this PR)
rt_tick_t 是无符号数据类型，而 'timeout' 有时用到负值或与负值比较。 #8758
你的解决方案是什么 (what is your solution)
参考： rt_err_t rt_mutex_take(rt_mutex_t mutex, rt_int32_t timeout); rt_err_t rt_sem_take(rt_sem_t sem, rt_int32_t timeout); 等函数的定义，所以应该将 ‘ rt_tick_t timeout’ 改为 ‘rt_int32_t timeout’。
请提供验证的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
- [ ] 已经使用formatting 等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification
rt_tick_t 的意义不就是用来做 timeout 吗... 一个 int 我个人感觉理解不到单位是什么，因而用起来很麻烦。
补充一下，所谓 rt_tick_t 有时负值个人觉得也不成立。这个 timeout 的元素集合应该是 [0 ~ RT_TICK_MAX) 以及 RT_WAITING_FOREVER.
rt_tick_t 的意义不就是用来做 timeout 吗...一个 int 我个人感觉理解不到单位是什么，因而用起来很麻烦。
补充一下，所谓 rt_tick_t 有时负值个人觉得也不成立。这个 timeout 的元素集合应该是 [0 ~ RT_TICK_MAX） 以及 RT_WAITING_FOREVER.
RT_WAITING_FOREVER 就是负值，核心代码中 timeout 的类型也是使用的 rt_int32_t 。从类型名 rt_int32_t 看来确实有不能直观分辨数值单位的问题，但对于 rt_tick_t 无符号类型的风险更要重视！不知道 rt_tick_t 改为有符号的是否更好？
rt_tick_t 的意义不就是用来做 timeout 吗...一个 int 我个人感觉理解不到单位是什么，因而用起来很麻烦。 补充一下，所谓 rt_tick_t 有时负值个人觉得也不成立。这个 timeout 的元素集合应该是 [0 ~ RT_TICK_MAX） 以及 RT_WAITING_FOREVER.
RT_WAITING_FOREVER 就是负值，核心代码中 timeout 的类型也是使用的 rt_int32_t 。从类型名 rt_int32_t 看来确实有不能直观分辨数值单位的问题，但对于 rt_tick_t 无符号类型的风险更要重视！不知道 rt_tick_t 改为有符号的是否更好？
首先从这个 API 的设计层面上 RT_WAITING_FOREVER 是什么值不重要。重要的是这个值存在且区分于其它 tick 可取值。常量表达式 -1 只能说是一个实现。我也可以实现为 ((rt_tick_t)-1)。
其次，我主要想表达的是 timeout 最好是一个有语义的类型。至于是否是有符号类型，这是另一件事情了。这个与其改 rt_tick_t 不如加个新的 timeout 类型，因为 rt_tick_t 在 64 位平台本来有意义的范围就很小了。
sem_take那边都是有符号整数的，因为这部分也包括，tick_max是INT_MAX/2，这样防止值溢出。所以这里更改成rt_int32_t也可行的。不过对于64位系统是否依然是这样，需要结合timer那边的情况来考虑了。
sem_take那边都是有符号整数的，因为这部分也包括，tick_max是INT_MAX/2，这样防止值溢出。所以这里更改成rt_int32_t也可行的。不过对于64位系统是否依然是这样，需要结合timer那边的情况来考虑了。
所以是想搞个新的类似 rt_timeout_t 类型，专门用来做 tick，参考 https://github.com/RT-Thread/rt-thread/discussions/8789 。考虑兼容的话，可以定义为带符号的 rt_base_t 。
rt_timer内部都是用的rt_tick_t，所以这里用rt_tick_t是没问题的。即便是要统一也是从rt_timer开始，仅仅改这里没有意义。 可以先解决当前的编译告警问题，改为(rt_tick_t)RT_WAITING_FOREVER.
