[ipc][condvar] 修正 'timeout' 符号问题

[sp-cai]

拉取/合并请求描述：(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

[polarvid]

rt_tick_t 的意义不就是用来做 timeout 吗... 一个 int 我个人感觉理解不到单位是什么，因而用起来很麻烦。

补充一下，所谓 rt_tick_t 有时负值个人觉得也不成立。这个 timeout 的元素集合应该是 [0 ~ RT_TICK_MAX) 以及 RT_WAITING_FOREVER.

[sp-cai]

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 改为有符号的是否更好？

[polarvid]

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 位平台本来有意义的范围就很小了。

[sp-cai]

#8789

[BernardXiong]

sem_take那边都是有符号整数的，因为这部分也包括，tick_max是INT_MAX/2，这样防止值溢出。所以这里更改成rt_int32_t也可行的。不过对于64位系统是否依然是这样，需要结合timer那边的情况来考虑了。

[polarvid]

sem_take那边都是有符号整数的，因为这部分也包括，tick_max是INT_MAX/2，这样防止值溢出。所以这里更改成rt_int32_t也可行的。不过对于64位系统是否依然是这样，需要结合timer那边的情况来考虑了。

所以是想搞个新的类似 rt_timeout_t 类型，专门用来做 tick，参考 #8789 。考虑兼容的话，可以定义为带符号的 rt_base_t 。

[yangpengya]

rt_timer内部都是用的rt_tick_t，所以这里用rt_tick_t是没问题的。即便是要统一也是从rt_timer开始，仅仅改这里没有意义。
可以先解决当前的编译告警问题，改为(rt_tick_t)RT_WAITING_FOREVER.

[lygstate]

统一用 rt_tick_t
#deinfe RT_WAITING_FOREVER ((rt_tick_t)-1)

rt_tick_t 为无符号整数，可以是 32bit, 也可以是64bit