全部学习汇总： GreyZhang/g_ChibiOS: I found a new RTOS called ChibiOS and it seems interesting! (github.com)

1. RTOS指的是实时性操作系统，但是并不是只有嵌入式领域使用RTOS。然而，嵌入式是RTOS的主要使用领域。

2. 一般的RTOS有一组共同的特点：首先，都是采用了多线程单应用的模型；其次，具有确定的优先级调度模式；第三，API的处理包括了ISR。

3. 可以认为ISR也是一种线程，只是它的优先级是高于一般的线程的。

4. 一般来说，RTOS也都有一个idle task，它的任务优先级是最低的。

5. 从任务的优先级方面看，优先级有静态以及可变两种模式。

1. 中断可以触发ISR，而ISR可以唤醒任务。由此，这种处理逻辑与FreeRTOS中通过事件激活任务的方式类似。

2. 关于中断是可以分为两类的，一种是不可以用OS接口的，另一种是可以用OS接口的。这样的分类，也类似于AUTOSAR OS中的一类中断自己二类中断的分类方式。

3. 堆栈也可能有两种模式，一种是OS负责给ISR分配堆栈，另一种是ISR有专用的堆栈区。

1. Task可以认为是虚拟的CPU，有自己的寄存器组以及堆栈。之前关于这个概念了解的还不算是很透彻，自从看了一部分MIT 6.828的课程之后，对这个理念算是有了一个比较深入的理解了。

2. 作者倾向于把具有Create、Exit、Join等功能的任务叫做线程。也就是说，可能线程的概念比任务还要复杂一点。而这里的Join，看解释的信息应该就是fork以及wait的组合。

3. 这一页给出来了一个任务状态机，这个在不同的OS中都大同小异。从这个文件来看，其实作者也说了，可能这个状态机是一个标准的描述。

这里给出来了几种OS任务的分类：周期性的、非周期性的、连续的。

1. 结合上一页的末尾以及这一页的开头，通过伪代码的形式来介绍了可能的共享数据问题。

2. 比较好的设计应该从OS的角度来考虑一些行为的原子化操作而不是依赖于架构以及工具。

3. 采用关键代码保护区的方式处理共享数据问题，这通常是通过开关中断来实现的。但是这种处理方法不是很细致，应该考虑更加完善的方式。

1. 针对前面的比较简单粗暴的保护区的处理机制，进行一个改进：关中断的时候不要把全部中断都关掉，只关闭一部分。这样，可以减少因此带来的抖动。

2. 上面的方案看似不错了，但是其实有一个弊端，那就是对于多核是无效的。针对此问题，可以采用硬件信号的机制来处理。

3. 做这方面的处理的时候，需要考虑编译器代码优化所带来的影响。

4. 针对关键区域的设计，最好要兼顾几个方面：轻巧且快速、能够实现任务以及ISR的互斥。

5. 关键区的设计可能的缺点：抖动可能更大，而且不能够使用OS的API。

1. 常见的互斥信号有：计数信号量、二值信号量、互斥信号量等。

2. 优先级提升、消息、关键区等解决方案各有利弊。

3. 接下来引入了一个优先级翻转的案例，这个在其他的OS资料中也接触过了，不再仔细看了。

针对优先级翻转问题的解决方案：1. 避免互斥，但是可能不是一直可行； 2. 重排优先级，让任务可以用相邻优先级的资源，这种方式也可能效果有限；3. 互斥信号产生的时候，禁止抢占； 4. 采用优先级的天花板机制，让信号具有高于任务的优先级，获得信号的任务具有与其对等的优先级。

         1. OSEK OS等众多的OS采用了优先级天花板机制。

         2. 除了优先级天花板机制之外，其实还有一种解决方案：优先级继承机制。这样的机制，可以让使用互斥资源的任务中的资源请求任务临时获得所有资源使用任务中最高优先级的同等优先级。

         说起来，这种处理机制类似于中断保护中对中断处理的改进，只是让处理更加细腻了。

         ChibiOS采用的优先级继承的方法来实现任务优先级翻转问题的处理。