RTOS临界区中（仅指关闭总中断的方法），用户是否可以任务切换的初步思考

Cos***

首先声明，关于这个问题我不是要给出具体答案，也不是要阐述自己的观点，只是给出一种我能想到的思考问题的方式，
希望能给各位读者以启迪，起一个抛砖引玉的作用。不足之处在所难免，望谅解。

1、一般意义上的临界区，是用来保护全局公共资源的，通常采用“加锁/解锁”（互斥锁/自旋锁）的方法来实现，
以实现对全局公共资源的互斥访问，是允许线程切换的。

2、一般意义上的原子操作，是用来保护程序过程的，对于单核CPU，通常采用“关闭/开启”（总中断）的方法来实现，
以实现程序过程（执行流）不会被打断，当然同时也可实现对全局公共资源的保护，是不允许线程切换的。

3、RTOS中的互斥量，等同于一般意义上的临界区，当成功获取互斥量以后（已处于保护中），也是允许线程切换的。

4、RTOS中的临界区（仅指通过关闭总中断的方法实现的临界区，通过其它方式实现的临界区不在本次分析范围内），
即可实现对全局公共资源的保护，又可实现对程序过程（执行流）的保护，所以称之为原子操作可能更为贴切。

那么，单从以上分析来看，在RTOS临界区中（仅指通过关闭总中断的方法实现的临界区），用户是否可以线程（任务）切换呢？
这个问题仅是针对用户而言的，不包括OS自身，OS自己想做什么都是合理的，只要能够实现功能、不出问题。
排除OS自身是非常重要的限定条件，否则就容易产生“悖论”。
如“刮胡子悖论”：”一个理发师只给不给自己刮胡子的人刮胡子”，那他能不能给自己刮胡子？
可见，如果不加限定条件就会产生悖论；
如果加上限定条件：“一个理发师只给除他自己之外的不给自己刮胡子的人刮胡子”，就不会产生悖论。

当然，关于这个问题，不能仅凭上述分析，还应从不同角度出发，多方面加以论述。

我发这个帖子的目的并非是要引起新一轮骂战，我对战争不感兴趣。只是很多朋友可能会对这个问题感兴趣，我只是提供一个思路而已。

仁者见仁、智者见智，每个人都可以有自己的观点，没必要争斗。

杨***

楼主想要讨论的问题是单片机RTOS中很重要和和基本的问题。但是建议楼主将讨论的题目修改为“在关闭总中断的情况下 在STC单片机上实现中断里和中断外任务切换的 技术方法探讨”。

建议的理由如下：

（1）首先题目不当。因为“是否应该允许”这种讨论的主体和客体都不明确，容易变成骂战。主体是谁？谁有权利来允许和不允许？客体又是谁？谁愿意或者必须服从谁的允许不允许。

比如“允不允许打狗”就是一个典型，如果不说明是什么样的人，在什么样的场合，打什么样的狗，就得不出有效的结论来。

（2）其次是论点涉及的对象不具体，“RTOS临界区”和“任务切换”的概念对于不同的领域有不同的语义，并且对于STC单片机RTOS而言，“任务切换”就分为中断里和中断外两种，而STC单片机上的“RTOS临界区”和“RTOS临界区保护方法”远不止一种。

（3）然后题目的 “深度思考”要求不明确。是楼主已经“深度思考”过了，准备分享自己“深度思考”的结果，还是楼主还没有“深度思考”，准备分享自己“深度思考”的过程？

又或者是楼主要求有兴趣的网友自己在家“深度思考”？

（4）最后是楼主本身就是一个单片机RTOS的研发者，楼主没有以身作则，有点老太太打电筒只照别人不照自己的味道。

楼主你自己的CosyOS允不允许在关闭中断的情况下进行中断里和中断外的任务切换？你没有说。你觉得应该不允许？也没有说？如果现在的版本不允许，是技术没有实现还是根本就不想允许？也没有说。你自己都不说，自己都不做例子，别人怎么跟帖？

（5）如果题目修改了，是技术类的讨论，我会参与。如果不修改，是思想类的讨论，也还是有价值的。只是我已经过了这个阶段了，就不参与了，大家讨论和争论就好，我吃瓜就行了。

所以不论怎么样都支持楼主开辟讨论帖。

Cos***

杨为民 发表于 2023-11-8 16:16
楼主想要讨论的问题是单片机RTOS中很重要和和基本的问题。但是建议楼主将讨论的题目修改为“在关闭总中断的 ...

感谢杨老师的建议，RTOS临界区确实不等于关闭总中断，所以我需要修改一下相关内容

Cos***

请大家不要跟帖讨论，这不是讨论贴，而是友情提示贴：“开酒不喝车，喝车不开酒”。
无论您的想法如何，都请自行分组讨论，本人仅是提供一个思路而已。

杨***

（1）楼主的标题已经改为“RTOS临界区中（仅指关闭总中断的方法），用户是否可以任务切换的初步思考”了，但是楼主仍然不肯表明自己的观点是“可以任务切换”你还是“不可以任务切换”？

（2）我打个比方，假如论文的题目是“在餐馆中（仅指中餐馆），顾客是否可以点麻婆豆腐的初步思考”，会不会很多余？这有什么要思考的？如果是在川菜馆，川菜馆肯定提供麻婆豆腐，顾客想吃就点，有什么允许不允许和可以不可以的？顾客想吃餐馆提供，还要思考什么？但是如果是在粤菜馆，人家不提供麻婆豆腐，顾客想吃也没有呀，允许不允许点有什么差别，再思考什么有什么用？
（3）我的STC单片机RTOS的技术水平已经达到了“在关闭总中断的时候允许用户自由地进行中断里和中断外两种任务切换”高度，我的RTOS用户在总中断关闭是爱选择不选择任务切换是他们自己编程的事，不存在谁允不允许的问题，也不存在可不可以的问题，我也不知道我或者他们需要思考什么。
（4）我的研究结果已经发在论坛《挑战者x51（5）：STC32G单片机uC/OS-II系统对用户程序打开/关闭总中断的响应》（https://www.stcaimcu.com/forum.php?mod=viewthread&tid=4643）的帖子中，对这个问题给出了测试方法，给出了测试说明，给出了测试效果，给出了测试范例程序供网友下载验证。同时我也对论坛上的STC单片机RTOS进行了测试，分别给出对它们的测试程序、测试结果和测试结论。
测试结论：目前在论坛上除了我移植的“挑战者x51移植版V3.30”外，包括楼主的CosyOS在内的其他STC单片机RTOS都不支持“在关闭总中断的情况下进行中断里和中断外的任务切换”，你们的RTOS系统不提供这种功能，思考有用吗？
（5）我在帖子和范例程序中指明了，我可以做到的原因是我的系统中断采用了STC单片机的专门为单片机RTOS设计的定时器0的模式3：“不可屏蔽中断模式”，这样即使用户关闭了总中断，系统中断不会停止，任务切换照样进行。技术原因就这么简单，再说一遍“系统中断采用STC专门为RTOS设计的不可屏蔽模式”！
（6）如果楼主想思考，就思考一下在技术上你的定时器0系统中断为什么不能使用“模式3不可屏蔽中断模式”（我猜测你一定是试过了,不行），而我的可以，是差在什么地方了。如果你做不到，不需要思考什么，大方地告诉你的用户CosyOS不提供这种功能就行了。世界因为多样性而精彩，就像粤菜馆不提供麻婆豆腐，有什么好纠结地呢？

Cos***

杨为民 发表于 2023-11-8 19:42
（1）楼主的标题已经改为“RTOS临界区中（仅指关闭总中断的方法），用户是否可以任务切换的初步思考”了， ...

是的，CosyOS的确不支持用户在关闭总中断时切换任务，这一点我没有特意隐瞒，只是没有专门的介绍给大家。
杨老师的 “在关闭总中断时仍然可以自由切换任务” 的创举，我也并不反对。
我只是在思考，这种功能是否有必要成为RTOS的标配、标准。
但有一点可以确定的是，杨老师所实现的这一创举绝对是一个创举、一个特色。如果用户有这方面的需求，用了杨老师的RTOS就有福音了。

杨***

CosyOS 发表于 2023-11-8 20:21
是的，CosyOS的确不支持用户在关闭总中断时切换任务，这一点我没有特意隐瞒，只是没有专门的介绍给大家。
...

“我只是在思考，这种功能是否有必要成为RTOS的标配、标准。”
（1）你说话经常不加定语，就会显得口气太大。什么RTOS的标配和标准？是全世界的RTOS？是全中国的RTOS？是所有单片机的RTOS？还只是STC单片机的RTOS？如果只是你的RTOS，你自己做主。
（2）声明：我做的不是什么创举和特色。我在1996年前使用的国内外不同计算机上的RTOS，自己研制的RTOS和指导研究生研制的RTOS均是关闭总中断也可以切换任务的。我在本世纪看到的单片机上主流的RTOS包括FreeRTOS都是关闭总中断也可以切换任务的，我移植的uC/OS是关闭总中断也可以切换任务的，说明uC/OS的内核也是支持关闭总中断也可以切换任务的。
（3）我猜想你的意思是思考“如果是标配和标准，那么你就去努力克服技术难题，如果不是就放弃”，如果这样就别听那些瞎叨叨，专注做好你自己的CosyOS，发挥好你的特色，为STC单片机用户提供更多的选择。川菜馆和粤菜馆用户都需要！

Cos***

杨为民 发表于 2023-11-8 20:57
“我只是在思考，这种功能是否有必要成为RTOS的标配、标准。”
（1）你说话经常不加定语，就会显得口气太 ...

杨老师的猜想是正确的！
感谢杨老师指点迷津，犹如拨云见日

tzz***

CosyOS 发表于 2023-11-8 21:10
杨老师的猜想是正确的！
感谢杨老师指点迷津，犹如拨云见日

谈谈互斥访问吧, 我觉得我这方面的理论比较欠缺, 虽然也知道一些用法, 但不系统, 总感觉还欠了点啥.
CosyOS大侠做做好事, 来给我和广大网友普及一下

Cos***

tzz1983 发表于 2023-11-8 22:01
谈谈互斥访问吧, 我觉得我这方面的理论比较欠缺, 虽然也知道一些用法, 但不系统, 总感觉还欠了点啥.
Cos ...

那我就简单谈一谈我所了解的“互斥访问”，有不足之处望大家谅解。

一、访问
访问包括“读访问”和“写访问”，对目标对象的“读操作”是读访问，对目标对象的“写操作”是写访问。
所以，当我们描述一个问题需要用到相关词汇的时候，还是要多考虑一下到底应该用哪一个词才更为准确，读？写？还是 访问？

二、互斥访问
互斥访问是指各访问者之间是互相排斥的，即每次只允许一个访问者访问目标对象，目标对象是不可重入的。
这个目标对象可称之为“互斥资源”、“临界资源”、“公共资源” 等，都是“不可重入资源”。
具体的，它可以是一个全局的变量、数组、结构体、函数、程序过程  等。

三、实现互斥访问的方法
一般的，实现互斥访问的方法包括 “信号量”、“互斥锁”、“自旋锁”、“原子操作”、“关闭任务调度” 等，但不仅限于此。
下面主要说一下互斥锁/自旋锁：
对于单核CPU，一般采用互斥锁（即互斥量）；对于多核CPU，还可考虑采用自旋锁。
它们的区别是：
互斥锁：如果不能立即成功获取就阻塞了，把CPU使用权转交给其它任务。
自旋锁：原地打转自旋，等待成功获取的那一刻，即在循环中不断的查询，特点是不会阻塞（不会切换任务）。
为何单核CPU不能用自旋锁呢？因为它永远也等不到那一天的到来，只会陷入无尽的黑暗！
为何多核CPU可以用自旋锁呢？因为那一天可能即将到来，希望就在眼前！

采用信号量、互斥锁/自旋锁实现的互斥访问，是允许线程切换的，也就是说程序过程（执行流）是可被打断的，但不会重入；
采用原子操作实现的互斥访问，一般是不允许线程切换的，也就是说程序过程（执行流）是不可被打断的；

四、单片机RTOS中的“互斥量”、“信号量”、“原子操作”与“关闭任务调度”
1、“互斥量”只能用于对“任务级公共资源”的保护，即互斥量只能应用于任务中，并且一般都适配有用于抑制“优先级反转”发生的“优先级继承”或“优先级天花板”机制。
2、“关闭任务调度”只能用于对“任务级公共资源”的保护。
3、“信号量”可用于对“全局公共资源”的保护，但程序过程（执行流）是可被打断的。信号量可能会获取失败，将导致访问失败。
     这里的信号量包括计数信号量和二值信号量。对于CosyOS来说，二值信号量的使用是没有限制的，但计数信号量在中断中是不能获取的，这点需要注意。
4、“原子操作”即可用于对“全局公共资源”的保护，也可用于对“程序过程（执行流）”的保护。

五、互斥访问方式的一般使用原则
（1）如果访问过程非常快速，可以用原子操作的方式，如全局变量的读、写、自运算等；
（2）如果访问过程非常耗时，在实时性要求不高的情况下，尽量用信号量、互斥量，必须用原子操作的也要尽量分成若干个临界段，再空函数或空操作隔离。
（3）如果必须对程序过程（执行流）加以保护，就只能用原子操作了，如一个高速通讯的通讯时序。
（4）在任务中，能用互斥量的就不要用信号量，因为互斥量有优先级继承机制，可有效减少高优先级任务不能立即成功获取时的阻塞时间。
（5）能用二值信号量的就不要用计数信号量，因为二值信号量的Take、Give操作效率一般会高于计数信号量。
（6）能用关闭任务调度的就不要用原子操作，因为关闭任务调度不会关闭总中断。

六、单片机RTOS - 互斥量应用示例
（已假定目标资源仅会在任务中访问，不会在中断中访问。）
1、读或写一个全局变量，而最终的读或写操作，一条汇编指令无法完成；      // 全局变量不可重入
2、全局变量自运算；                                                                                // 自运算过程不可重入
3、访问一个全局的数组或结构体；                                                             // 数组或结构体不可重入
4、调用一个不可重入函数；                                                                       // 函数不可重入
5、调用一个可重入函数，但这个函数所要访问的目标资源仍然是不可重入的。 // 目标资源不可重入
     尤其是这一点需要格外注意，如memcpy、strcpy、malloc 等，都是可重入函数，但不可以随便就用了，因为最终要访问的资源可能是不可重入的。
6、有多个任务都要用到IIC通讯，可在外层用互斥量，实现对整个IIC通讯过程的互斥访问，// 整个IIC通讯过程不可重入
     内层具体的通讯时序再考虑是否需要用原子操作。
当然，以上示例，也可考虑用信号量、原子操作、关闭任务调度等方式来实现。

上述“原子操作”，在单片机RTOS中有时等同于“临界区”。

其实，有些东西说多了容易引发不必要的争论，因为不同的RTOS也都有所不同，大家的认知可能也不同，本人的学识也有限，就点到为止吧。
如果以上所述个别内容，谁有不同见解，大可不必争论，各说各话就可以了。


-- END --