[原创] 免费版rt-thread的内核实在差太多。。。

收费版不知道，没看到过，就说免费版。

最近在mcu上实现一个功能，需要使用rtos的一些特性，包括挂起，恢复，还有阻塞唤醒。。。之前没仔细用过rtthread，我以为作为一个rtos，应该有这些支持吧。

然后我看了 threadx，freertos和rtthread task/thread相关代码和文档，结果rtthread的支持最垃圾：

挂起只能挂起自己？！？！唤醒可以唤醒别人。。。这是什么操作。。。

还专门做个note告诉你不要挂起别人balabala的，卧槽，这种解释太扯淡了，明明是rtthread自己没有优先级继承、反转机制，可是话一说出来就让人觉得自己成了受害者如果不是看见这个note，我也不会发帖让大家擦亮眼睛

另外，rtthread也没有阻塞唤醒，类似 freertos xTaskAbortDelay这种功能。

整体上说rtthread内核实在是太入门级了。

rtthread简单用用还行，要做深度功能还是差了火候。

又看了下ucos 和 nuttx，都没有这个说法，也都有阻塞唤醒这种功能。

rtthread那段错误的note太容易误导初学者了。

感觉还行，研究完再分析分析

rtthread简单用用还行，能满足80%的场景。就目前流行的物联网终端也就是收收数据，传传mqtt数据这种还是比较好用的。

rtthread真的没有用过，但是你说唤醒可以唤醒其它进程，这个没有什么不对的呀。例如一个通知进程，接到通知后可以唤醒其它的工作进程，这不是很正常吗？

>>>挂起只能挂起自己？！？！唤醒可以唤醒别人

还有前半句。

挂起和唤醒是一对逻辑互补的操作。所以一个完备的RTOS里面就没有”只能挂起自己但是可以唤醒别人“这么骚的说法。要么你就只挂起自己只唤醒自己，要么就挂起别人也唤醒别人。很显然，除了rtthread我翻了一下帖子里面提到的一些rtos，大家都是“挂起别人也唤醒别人”。

线程挂起的操作在实时系统中是非常危险的操作，可能之前楼主在其他实时操作系统中用这个功能挺多的，但是要提醒你，不要这么去用。

一般，实时操作系统RTOS是采用基于优先级的抢占式调度方法，辅以同优先级下时间片轮转调度方法，来确保每个线程（任务）的实时性得到保证。大家都遵守一套规则，也就是谁优先级大，谁执行。

但是挂起解挂是一个逆天的存在，这个两个API如果使用上不受限制，会导致其他线程（任务）的饥饿，严重影响系统的实时性。举一个例子：

假设线程A（优先级10）和线程B（优先级20）在共享一块资源，通过互斥量保护。这时，如果线程C（优先级30）突然挂起了线程B，而线程B正在占用这块资源，互斥量迟迟得不到释放，就会导致线程A，也就是这个例子中最高优先级线程迟迟得不到运行，也就是所说的饥饿。

那么为什么优先级继承在这种情况下不起作用呢，因为优先级继承法是针对于基于优先级的抢占式调度方法的下的一种防范措施，而通过挂起解挂函数，已经超出了基于优先级的抢占式调度法的范围。因此优先级继承法是无法处理这种方式的。RT-Thread只不过是把这种有高实时性风险的操作给禁掉了。当然，楼主如果发现某款其他RTOS具备在挂起其他线程的同时，不会出现上述的饥饿情况，欢迎指正。

rt_thread_suspend函数内部里专门对用户给定的参数进行了检查，如果用户企图在其他线程中，直接挂起另一个线程会提示用户。

是我错了没有把前一句连起来，大多数的情况都是挂起自己别人唤醒。你说的自己唤醒自己只是在系统进程或其它高优先级进程做个钩子，也可以低优先级进程通知高优先级进程，再由高优先级进程唤醒目标进程。

挂起自己肯定是自己在等资源，别人把资源就绪了，去唤醒自己并没有什么问题。对于挂起别人，这个只能是发个信号给别的线程，请求挂起，别的线程自己评估当前环境决定是否挂起。这个逻辑并没有什么问题。

建议楼主不要搞些标题党

看着是楼主没太理解全面rt-thread的内核设计，就你说的那些功能全都支持的啊。

另外国外的操作系统的设计一定都合理嘛，每个rtos都有自己的特色嘛，没必要遇到自己不熟悉的和过去自己熟悉的不一样就吐槽啊

不喜勿喷哈

挂起别人是有用的，考虑下面的场景：

有一设备，键盘8个脚和SPI存储是共用的，平时状态是键盘不停的扫描，SPI存储不工作。当高优先级的进程ADC进程发现需要保存数据时，就可以直接休眠掉key，唤醒SPI

“另外国外的操作系统的设计一定都合理嘛，每个rtos都有自己的特色嘛，没必要遇到自己不熟悉的和过去自己熟悉的不一样就吐槽啊”

大家不要情绪化，这个问题谈不到国外的操作系统是不是合理的问题。流行的国外操作系统多数都是经过实践的，合不合理很多都经过检验了。rt-thread我没用过，如果你用过就把证据摆出来，不要一句话就说：“看着是楼主没太理解全面rt-thread的内核设计，就你说的那些功能全都支持的啊。”了事。

平静的讨论问题才能和谐进步

啊，坐看大家论道。

来，你来给我科普一下rt 哪里实现的优先级继承和反转。国外的东西再不合理，国内也是抄的。

不支持这个东西，自然不能挂起别人。rt文档note里说的那些不是“挂起”本身导致的问题，而是rt自己不完善的问题，所以我说那个错误的note误导初学者。

接受楼主的建议。

关于 优先级继承，可以看下互斥量这块说明都有写到的：互斥量可以解决优先级翻转问题，实现的是优先级继承协议 (Sha, 1990)。

https://github.com/RT-Thread/rt-thread/blob/master/src/ipc.c#L997 在这里，RT-Thread互斥量支持优先级继承协议。不过，挂起和优先级继承这两个问题是独立的，没有交集。

rt文档note里说的那些不是“挂起”本身导致的问题，而是rt自己不完善（也就是没有优先级继承和反转）的问题，所以我说那个错误的note误导初学者。

挂起之后如果有死锁，把这个任务提升后唤醒把临界区跑过去再降下来挂起。。。优先级继承和反转本来就是用来解决你所说的所谓“死锁”问题的。

其实suspend挂起操作和阻塞在某个semaphore上被动挂起有实质区别吗？没有的。。。

>>>已经超出了基于优先级的抢占式调度法的范围

如果不能详细展开说，那只能当废话听了。

当然优先级继承和反转解决不了所有死锁问题，但是，问题的重点是：挂起别人是一个十分有用的操作，作为一个基础平台和支撑平台，你不能帮用户做选择，从而把功能阉割掉。有这种风险，应该把问题告诉客户，客户通过自己控制休眠唤醒时序来协助rtos解决问题。

freertos就在手册里明确说suspend/resume是 advanced 功能。

https://github.com/RT-Thread/rt-thread/blob/master/src/ipc.c#L997 在这里，RT-Thread互斥量支持优先级继承协议。

是否支持挂起和互斥量的优先级继承协议是两个独立的问题，不知道为何你会把这两个问题交织在一起。

上述的线程A、B、C的场景同样适用于消息队列、信号量等其他内核对象。也会导致饥饿的问题。

> freertos就在手册里明确说suspend/resume是 advanced 功能。

所以，freertos的suspend是可以解决饥饿问题的？