freebsder

mysterywolf 发表于 2022-4-26 10:23 freebsder 发表于 2022-4-26 10:19 mysterywolf 发表于 2022-4-26 09:15 线程挂起的操作在实时系统中是非 ...

rtthread我研究不深，多谢指出具体位置。建议rtthread加上挂起别人的支持，作为一个基础平台和支撑平台，你不能帮用户做选择，从而把功能阉割掉。有这种风险，应该把问题告诉客户，客户通过自己控制休眠唤醒时序来协助rtos解决问题。

bigbat

aozima 发表于 2022-4-26 10:57 挂起别人是有用的，考虑下面的场景： 有一设备，键盘8个脚和SPI存储是共用的，平时状态是键盘不停的扫 ...

如果高优先级的线程在操作key，这时adc就要等待锁的释放，这样ADC很可能就耽误了下次的采集。对于key这样的操作优先级很低，随时可以中断而adc不行。这个问题如何解决

aozima

bigbat 发表于 2022-4-26 12:06 如果高优先级的线程在操作key，这时adc就要等待锁的释放，这样ADC很可能就耽误了下次的采集。对于key这样 ...

>高优先级的线程在操作key...key这样的操作优先级很低

 

此时是否应该分析，本来就不应该让这种情况发生呢？

低的能抢高的，那高的不就白高了，反正可以乱抢。
反过来看，既然高的在操作key，那此时key就是高的；本身就不应该让相对低的adc抢走。

 

mysterywolf

bigbat 发表于 2022-4-26 12:06 如果高优先级的线程在操作key，这时adc就要等待锁的释放，这样ADC很可能就耽误了下次的采集。对于key这样 ...

人机交互任务（线程）的优先级设置的过高是没有意义的，人机交互任务和其他任务一个重要的不同是人机交互任务会把人的反应时间也纳入进去。人的反应时间大概在100ms或者小于100ms左右，你把键盘的优先级设置那么高没有意义的。

 

所以，多任务设计是很重要的，要合理地安排任务的优先级。

yc_2503

bigbat 发表于 2022-4-26 09:51 挂起别人是有用的，考虑下面的场景： 有一设备，键盘8个脚和SPI存储是共用的，平时状态是键盘不停的扫 ...

还是具体情况具体分析，如果只是一个简单的系统，功能逻辑非常清晰稳定，确实是可以的。

但是考虑一下，如果键盘线程增加了更高优先级的功能呢？比如急停？比如持有了SPI需要的独占资源？

我一直坚持的一个原则就是，取消线程或者挂起其他线程都是用通知，通知之后，自己去评估处理剩余的逻辑及释放资源。

最后还是，具体情况具体分析，小项目干就完了，大项目还是得好好规划规划，坚持原则，边界清晰之后好维护。

 

bigbat

aozima 发表于 2022-4-26 12:26 bigbat 发表于 2022-4-26 12:06 如果高优先级的线程在操作key，这时adc就要等待锁的释放，这样ADC很可能 ...

我的例程可能不合适，在举一个详细的例子，还是key，但是key是通过一芯片连接的，麻烦的是这颗芯片是通过模拟方式(GPIO)操作的，在读取芯片数据时，你的逻辑是不是不能中断，如果中断破坏时序,是不是就不能读取了。是不是你就地上锁，上锁就可能影响优先级，所以实际况且很复杂。但是在实际中key能不能读出来是无所谓的，所以就需要随时给它停掉。

wangerxian

是啊，RTThread 挂起函数只能挂起自己，之前我们挂起别的任务用了信号量。接收到信号量，然后把自己挂起，是有点麻烦。

数码小叶

额。。。没在一个线程挂起过其它线程，所以还真没考虑过这个，但是rt-thread的优先级继承提升反转肯定有啊

aozima

bigbat 发表于 2022-4-26 13:23 我的例程可能不合适，在举一个详细的例子，还是key，但是key是通过一芯片连接的，麻烦的是这颗芯片是通过 ...

你这个需求案例很好，实际项目中也有类似需求。

结合上面的内容，我的设计思路大概如下：

1. 争停按键 不会设计在我们上面讨论的"key"上面，他必须是独立的不可屏蔽的。

2.  如前面所说，“key设计时本身就会考虑他的最大耗时，肯定是能满足ADC的。

2.1 如果实在不能满足，或ADC要求等间隔采样，我会把key设计成可中途取消的，这样只要保证取消时间能满足ADC的要求即可。这样KEY这边提前中止让出时，是在我的设计范围内，我可以做妥善的取消操作，而不是直接被人挂起，这样KEY的状态是未知的，可能有害。

 

所以设计上不建议直接挂起别人，因为这有点像插队，如果只有你1个人插队，那你是很爽的，但所有人都这么干，就完全乱套的了。

 

当然，主动挂起这操作非要用也可以，需要知道他的风险，并承担相关风险。

mysterywolf

freebsder 发表于 2022-4-26 11:30 rtthread我研究不深，多谢指出具体位置。建议rtthread加上挂起别人的支持，作为一个基础平台和支撑平台， ...

大概率不会的，我特意在文档中仔细写出了rt_thread_suspend不允许挂起其他线程的原因，结果被楼主当做了《balabla》。挂起函数是从通用操作系统中传下来的，对于实时性有硬性要求的操作系统，这种操作非常的危险，不会因为其他RTOS有，RT-Thread就会盲目的去跟风。相反，其他的RTOS例如FreeRTOS并未在文档中提及这种操作的危险性，却被追崇。。。

 

另外，微软的相关软件中也是对suspend函数/方法有严格的限制，

https://devblogs.microsoft.com/oldnewthing/20031209-00/?p=41573

https://github.com/dotnet/csharplang/issues/2421#issuecomment-482799918

 

RTEMS操作系统论坛中对挂起任务/线程的危险性也有提及，但是我没有具体查验他的手册中是否提及：

https://rtems-users.rtems.narkive.com/VMOyyUJE/problem-when-suspending-a-task

 

> rtthread我研究不深

其实并不是你对rt-thread了解不深，而是对RTOS了解不深。你的定位一直把优先级继承协议和线程挂起绑定在一起是让我很困惑的。任何一款RTOS，优先级继承的概念是互斥量的一个下属分支，而线程挂起这个概念是个更大范围的，可以挂起任何线程，无论这个线程是否使用互斥量与否。楼主大概率是对这块的概念比较混淆。

jameszxj

mysterywolf 发表于 2022-4-27 08:30 freebsder 发表于 2022-4-26 11:30 rtthread我研究不深，多谢指出具体位置。建议rtthread加上挂起别人的 ...

支持一下，楼主把线程操作和互斥、同步这些操作揉在一起了，感觉有些混淆了概念。现在的实时系统很多，不管国内还是国外的，这些基本功能大多都是能够满足的。

吾妻思萌

发展还需要时间啊，线程挂起这块底层蛮复杂的。