关于RT-Thread 0.3.1内核运行机制的几个疑问

zhiyunli

******** 关于编程指南43页画出的内核状态迁移图 ********

1，线程是否只有在挂起状态才能被delete/detach？一个处于就绪状态或初始状态的线程因为某种原因需要被delete/detach的话，是否需要先把它切换到挂起状态才能被delete/detach？

2，能否将动态创建的线程终止而不彻底删除（终止线程指线程的完整实体存在于OS中，但是不参与线程调度也不挂在任何内核队列上，删除线程指回收TCB、线程栈等存储资源并将线程从内核所有队列中删除），以便后续需要的时候重新启动线程？

3，如果某个线程因为等待某个资源（Semphore、Mutex、Message、Event、Time）而被置于挂起状态，此时另外的在运行线程能否再将线程强行Suspend？（即不管被挂起的线程之前等待的资源是否满足，都不让此线程恢复到就绪状态，从而强行禁止此线程执行。总体上看，RTOS中线程/任务等待的东西可概括成三类，一是实体资源如Semphore、Mutex、Message、Event，二是time，三是人为Suspend后的Resume，这三类等待可施加于同一线程而并行不悖，每一类等待也可单独施加于某一线程/任务，前两类等待同时施加于同一线程任务就变成了带时间限制的资源等待）；

******** 关于编程指南47页的Note：线程运行完成，自动结束时，系统会自动删除线程，不需要再调用rt_thread_delete接口。这个接口*不应由*线程本身来调用以删除自身，一般由其他线程调用或在定时器超时函数中调用。********

4，线程什么时候能运行完成？一般的理解：线程是个无限循环，如果不调用特定的OS内核system call的话，是无法通知OS内核自己运行完成了的，反过来说，内核怎么能知道某个线程是否运行完成了？

ffxz

1. 不限制于挂起状态才能被delete/detach。但是线程自身不应该自己delete/detach自己。
2. 不能；如果需要这样，请使用静态线程模式。
3. 不能；
4. 线程从线程入口函数返回就会被认为是线程运行结束。

zhiyunli

回复【1楼】ffxz
1. 不限制于挂起状态才能被delete/detach。但是线程自身不应该自己delete/detach自己。
>> 这样看来是编程指南43页的状态迁移图误导了。另外，线程为什么不能自己delete/detach自己？？一个临时性的线程完成任务后自行了断岂不省了其他线程的麻烦？

2. 不能；如果需要这样，请使用静态线程模式。
3. 不能；
>> 从上面的2、3点看，RT-Thread内核状态机的状态划分粒度相对粗些，无法实现对线程的一些精细化控制。在复杂的嵌入式系统里面，对于某些复杂的应用逻辑可能会难以实现。

4. 线程从线程入口函数返回就会被认为是线程运行结束。
>> 从维持线程结构的一致性以及其他RTOS的通常做法看，提供一个类似thread_exit()的终止在运行线程自身的system call可能会更方便些。

综上，个人觉得在内核状态机设计方面，RT-Thread也许可以做得更精细些，当然目前这种设计满足一些常规的嵌入式应用可能也是足够的。在内核状态机设计方面，iTRON标准定义的内核状态机（包括一些System Call）对于实现各种嵌入式应用应该会更方便些。
-----------------------------------------------------------------------

mbbill

回复【2楼】zhiyunli  
-----------------------------------------------------------------------

1  bernard说的是“不应该”，不是不能。想要delete/detach自己，其实直接return就可以了。
2  你提的需求其实就是“静态线程”完成的事情。动态线程不能够也不应该去多此一举，这并不是限制而是设计就是这样。
3  能举个例子么？
4  你觉得调用 thread_exit()比直接return更“方便”些吗？

ffxz

如果你确实有这些方面的需求，建议你读读RT-thread的POSIX线程实现。

POSIX thread这部分在0.4.0 beta2发布后，我会专门写系列文章进行介绍

ftest01

回复【1楼】ffxz
1. 不限制于挂起状态才能被delete/detach。但是线程自身不应该自己delete/detach自己。
2. 不能；如果需要这样，请使用静态线程模式。
3. 不能；
4. 线程从线程入口函数返回就会被认为是线程运行结束。
-----------------------------------------------------------------------

我觉得第4点可以算rtt设计得极为精妙的地方之一。对比ucos，其实ucos中的线程是绝对不能返回的，一旦某个线程返回了，系统就崩溃了，因为ucos并没有设定该线程返回到什么地方去。而RTT就考虑到了此问题，我没仔细看代码，但我猜想，一定是线程开始调度时，就用汇编代码设定好了线程的返回地址和返回参数，一旦线程执行结束，就返回到了那个精心设定好的地址——就是处理线程返回的那个函数，然后该函数通过返回参数，就可以唯一确定是哪个线程返回了，于是就着手处理其“后事”。
上面都是我猜的，还希望各位高手多多指点。