STC 原生RTOS PK 移植RTOS

杨***

CosyOS 发表于 2023-5-18 14:14
首先，CosyOS当然不会存在这个问题。
其它的RTOS是否存在这样的问题我也不能确定，我没有时间仔细研究其它 ...

谢谢答复，我现在明白是什么问题了。

（1）这种多个任务访问同一个公共变量的问题从操作系统一诞生的时刻就有了。在操作系统（包括RTOS）中，这种变量（广义称为资源）就叫做“临界变量”（广义临界资源），对这种临界资源的保护问题被称为“临界区保护”问题，保护的方法被称为“临界区保护方法”。

（2）临界资源的保护对所有的多任务系统而言都十分重要，因此在所有的操作系统教科书中都要用专门的章节来介绍,最著名的例子是哲学家就餐问题：（百度百科）

哲学家就餐问题可以这样表述，假设有五位哲学家围坐在一张圆形餐桌旁，做以下两件事情之一：吃饭，或者思考。吃东西的时候，他们就停止思考，思考的时候也停止吃东西。餐桌中间有一大碗意大利面，每两个哲学家之间有一只餐叉。因为用一只餐叉很难吃到意大利面，所以假设哲学家必须用两只餐叉吃东西。他们只能使用自己左右手边的那两只餐叉。哲学家就餐问题有时也用米饭和筷子而不是意大利面和餐叉来描述，因为很明显，吃米饭必须用两根筷子。

哲学家从来不交谈，这就很危险，可能产生死锁，每个哲学家都拿着左手的餐叉，永远都在等右边的餐叉（或者相反）。即使没有死锁，也有可能发生资源耗尽。例如，假设规定当哲学家等待另一只餐叉超过五分钟后就放下自己手里的那一只餐叉，并且再等五分钟后进行下一次尝试。这个策略消除了死锁（系统总会进入到下一个状态），但仍然有可能发生“活锁”。如果五位哲学家在完全相同的时刻进入餐厅，并同时拿起左边的餐叉，那么这些哲学家就会等待五分钟，同时放下手中的餐叉，再等五分钟，又同时拿起这些餐叉。

在实际的计算机问题中，缺乏餐叉可以类比为缺乏共享资源。一种常用的计算机技术是资源加锁，用来保证在某个时刻，资源只能被一个程序或一段代码访问。当一个程序想要使用的资源已经被另一个程序锁定，它就等待资源解锁。当多个程序涉及到加锁的资源时，在某些情况下就有可能发生死锁。例如，某个程序需要访问两个文件，当两个这样的程序各锁了一个文件，那它们都在等待对方解锁另一个文件，而这永远不会发生

见下图：

https://blog.csdn.net/u012135009/article/details/95043461

在这个问题里，筷子就相当于公共变量（临界资源），哲学家就相当于任务。大家都要去拿，两个人一起抢他们中间的筷子。最尴尬的情况是每个人都只拿到了一支筷子，谁也无法就餐。

（3）对于像Linux和Windows这样的计算机操作系统，当然不能用关闭总中断来进行临界区保护，而是采用加锁解锁等各种方法，有兴趣的读者简单的可以搜“哲学家就餐问题”的解法。

（4）对于像单片机上的没有标准操作系统支持的RTOS，只能采用关闭总中断的方法来进行临界区保护，笔者在本论坛里有专门帖子介绍，有兴趣的读者可以前往观看。

（5）uC/OS-II对于临界区保护同时提供了两种方法：单片机的关闭总中断的方法和操作系统对任务调度（切换）程序加锁解锁的方法。后者是标准的操作系统临界区保护方法，根本不涉及任何中断，就可以对RTOS的系统过程进行临界区保护。

（6）这是笔者选uC/OS-II来进行移植的原因之一，以后随着对移植过程的逐步展开，会专门介绍在那些不允许关闭总中断的的单片机应用场合如何使用这种方法来进行临界区保护。

神***

巅峰对话

杨***

8051：只有单字节变量访问不会重入；
80251：data、edata直接寻址（1~4字节）不会重入，间接寻址（1~2字节）不会重入；
Arm32：所有（1~4字节）访问不会重入；



楼主上面提的这个原则也很重要，可以使我们更好地理解单片机指令和RTOS程序。不过有疏漏，所以这里代楼主解释一下：
（1）凡是单片机一条指令就可以完成的操作在操作系统理论的术语中被称为“原子操作”，对于单核的单片机或者CPU，原子操作不需要进行临界区保护，因为某个指令正在执行的时候，不会发生任务切换，其他任务的代码插不进来。
（2）8051是8位单片机，其每条指令最多读写一个字节。因此，对于位于DATA区域和SFR区域的单字节变量可以用“MOV  XXX,Dire8”一条指令完成，所以对这区域的单字节访问不会重入。但是对于XDATA区域和CODE的变量，至少需要两条指令“MOV DPTR, # XXXX”和“MOVX A, @DPRT”/“MOVC A, @DPTR”才能完成，所以在这两个区域内，即使对单个字节变量的访问也是会重入的。
（3）对于80251CPU，由于有单指令“MOV  XXX,Dire8”和“MOV  XXX,Dire16”，其中的XXX可以是8位、16位和32位的寄存器，所以对“data、edata直接寻址（1~4字节）不会重入”。
（4）但是80251CPU对于任何间接寻址，就像上面的8051，至少先要对指针进行赋值,然后才能进行内存存取，所以在80251上对任何间接寻址操作都可能会重入。
（5）根据笔者的认识，ARM32是32位指令集，一是每条指令被限制在32位长度了，二是其9种寻址方式中并不存在“直接寻址”这样一种方式（其立即数寻址是将立即数赋值给寄存器，不是访问内存），因此笔者认为，对于ARM32架构的CPU，对所有变量的访问都有可能重入，哪怕是单字节的变量。
（6）在C语言中，除了单个简单变量，还有“结构变量”（比如RTOS中的TCB任务控制块），还有“数组”，还有“指针”，这些变量在编译为机器码时无一例外地都要使用CPU的“间接寻址”，因此不论在任何单片机或者计算机中，对这些不简单C语言的公共变量，都存在重入问题。

Cos***

杨为民 发表于 2023-5-18 16:34
8051：只有单字节变量访问不会重入；
80251：data、edata直接寻址（1~4字节）不会重入，间接寻址（1~2字节 ...

是这样的杨老师，
按照我的理解，一个全局变量只要最终访问数据时能一条汇编完成访问，就不会重入，包括间接寻址。
原因是，全局变量的地址对于编译器来说是“常量”，间接寻址时，这个地址会存入 Ri、DPTR，或其它寄存器（Arm：Rx），然后@Ri、@DPTR、或[Rx]访问数据。如果在寻址过程中发生了任务切换或中断，Ri、DPTR、Rx等都会入栈保护的，当回来的时候又出栈恢复了，寄存器中的地址是不会改变的。
如下方示例（读1字节xdata中全局变量）：

MOV DPTR, #XXXX
MOVX A, @DPTR
MOV R0, A
在MOVX A, @DPTR之前，如果发生任务切换或中断，在其它任务或中断中又写了这个变量，当返回后，DPTR中的地址不会改变，读到的新值；
在MOVX A, @DPTR之后，如果发生任务切换或中断，在其它任务或中断中又写了这个变量，当返回后，由于已经读完，所以读到的历史；
可见，当间接寻址时，只要最终访问数据时能一条汇编完成访问，就不会重入，顶多是“历史”与“最新”的区别。

如果访问数据时需要多次寻址，就会重入了。如下方示例：
MOV DPTR, #XXXX
MOVX A, @DPTR
MOV R0, A
INC DPTR
MOVX A, @DPTR
MOV R1, A

某全局变量需要两次间接寻址才能读完，如果在两次MOVX A, @DPTR之间发生了任务切换或中断，在其它任务或中断中又写了这个变量，当返回后继续读，就会高字节是历史，低字节是最新的，完全读错了。

杨***

CosyOS 发表于 2023-5-18 17:14
是这样的杨老师，
按照我的理解，一个全局变量只要最终访问数据时能一条汇编完成访问，就不会重入，包括 ...

（1）我自以为是，以为楼主的“全局变量重入”这个说法是指“原子操作”这个概念，所以上面所说的一切都是以操作系统原理里的“原子操作”和“临界资源保护”为标准来议论的。现在看来不是一回事，当我多说了。

（2）楼主你的“全局变量重入”这个说法我之前从未听过，所以你怎么定义你说了算，我不再表态了。期望在你以后在对你作品的解读中加以说明，方便大家理解。

新***

巅峰对决

Cos***

杨为民 发表于 2023-5-18 21:46
（1）我自以为是，以为楼主的“全局变量重入”这个说法是指“原子操作”这个概念，所以上面所说的一切都 ...

是我对杨老师的所述解读有误，望谅解！！！
杨老师是站在了原子操作、临界区保护的层面来说的，站得高、看得远。而我则站在了微观角度，过于纠结细节。
这个说法确实是我自己定义的说法，以后不再谈论。
以后我会尽量少发表自己的说法，这样不专业。

大刀***

两位老师，谦逊恭谨,诚以待人！像两位学习，勤勉务实,励精笃行!
期待两位发表更多的精彩贴！
用学术思想的交流碰撞 ，点燃教学科研火花！

杨***

CosyOS 发表于 2023-5-18 13:27
“PK”这个词可能我用的不好，应该说是比较或对比，是原生RTOS与移植RTOS的对比。对比的目的也不是分个高 ...

这个“LED灯的测试程序”待我抽空看下怎么回事。。。

我看到了很多小板凳，不知道第2局的PK你准备的怎么样了？我的文章在这里
https://www.stcaimcu.com/forum.php?mod=viewthread&tid=2192

（1）文章里有uC/OS-II的程序说明和全部开源的程序，希望早日见到用CosyOS写的类似功能的程序。
（2）我的移植程序是在8051内核单片机写的，楼主的程序是在80251内核单片机写的，而且都是全部代码公开的。由于STC8H系列单片机与STC32G系列在结构设计上非常相似，如果楼主也贡献出与我的RTOS测试程序同样功能的程序范例，那么通过：STC的8位单片机 VS STC的32位单片机、Keil的 C51编译器 VS C251编译器、移植的RTOS VS 原生的RTOS、STC的最小开发板 打狗棒 VS 降龙棍 、移植者 VS 原创作者 等这些既相对又统一的对比和PK，相信广大的STC单片机和RTOS爱好者会从中学到很多东西的。

杨***

对于单片机上的RTOS有两个关键技术点，一个是临界区保护方法，另一个是有中断嵌套时不进行任务切换的保护方法。

（1）不知道CosyOS系统有没有采取什么措施来实现在有中断嵌套时不进行任务切换？
（2）uC/OS-II中有中断嵌套保护。我在你的帖子中都没有看到这方面的内容，无论CosyOS中有没有，你能介绍一下你的看法和决策的依据吗？