对实时操作系统多任务的一些理解

一、什么是优先级反转

优先级反转，是指在使用信号量时，可能会出现的这样一种不合理的现象，即：

优先级反转是指一个低优先级的任务持有一个被高优先级任务所需要的共享资源。高优先任务由于因资源缺乏而处于受阻状态，一直等到低优先级任务释放资源为止。而低优先级获得的CPU时间少，如果此时有优先级处于两者之间的任务，并且不需要那个共享资源，则该中优先级的任务反而超过这两个任务而获得CPU时间。如果高优先级等待资源时不是阻塞等待，而是忙循环，则可能永远无法获得资源，因为此时低优先级进程无法与高优先级进程争夺CPU时间，从而无法执行，进而无法释放资源，造成的后果就是高优先级任务无法获得资源而继续推进。

高优先级任务被低优先级任务阻塞，导致高优先级任务迟迟得不到调度。但其他中等优先级的任务却能抢到CPU资源。-- 从现象上来看，好像是中优先级的任务比高优先级任务具有更高的优先权。

具体来说：当高优先级任务正等待信号量（此信号量被一个低优先级任务拥有着）的时候，一个介于两个任务优先之间的中等优先级任务开始执行——这就会导致一个高优先级任务在等待一个低优先级任务，而低优先级任务却无法执行类似死锁的情形发生。

一个具体的例子：
假定一个进程中有三个线程Thread1(高）、Thread2（中）和Thread3（低），考虑下图的执行情况。

• T0时刻，Thread3运行，并获得同步资源SYNCH1；
• T1时刻，Thread2开始运行，由于优先级高于Thread3，Thread3被抢占（未释放同步资源SYNCH1），Thread2被调度执行；
• T2时刻，Thread1抢占Thread2；
• T3时刻，Thread1需要同步资源SYNCH1，但SYNCH1被更低优先级的Thread3所拥有，Thread1被挂起等待该资源
• 而此时线程Thread2和Thread3都处于可运行状态，Thread2的优先级大于Thread3的优先级，Thread2被调度执行。最终的结果是高优先级的Thread1迟迟无法得到调度，而中优先级的Thread2却能抢到CPU资源。

上述现象中，优先级最高的Thread1要得到调度，不仅需要等Thread3释放同步资源（这个很正常），而且还需要等待另外一个毫不相关的中优先级线程Thread2执行完成（这个就不合理了），会导致调度的实时性就很差了。

具体调度如下图所示

二、优先级反转的解决方法

1、优先级天花板

当Thread3使用资源S时，就把Thread3的优先级提升到能访问资源S的最高优先级，执行完成释放资源之后，把优先级再改回来；这样的方法，简单易行，解决了多个高优先级任务抢占资源S的问题。但是带来了一些缺点，就是不一定每次都有高优先级任务抢占资源S，每次都提升优先级是对CPU资源的一种浪费。

2、优先级继承

优先级继承就是为了解决优先级反转问题而提出的一种优化机制。其大致原理是让低优先级线程在获得同步资源的时候(如果有高优先级的线程也需要使用该同步资源时)，临时提升其优先级。以前其能更快的执行并释放同步资源。释放同步资源后再恢复其原来的优先级。

与上图相比，到了T3时刻，Thread1需要Thread3占用的同步资源SYNCH1，操作系统检测到这种情况后，就把 Thread3的优先级提高到Thread1的优先级。此时处于可运行状态的线程Thread2和Thread3中，Thread3的优先级大于Thread2的优先级，Thread3被调度执行。

Thread3执行到T4时刻，释放了同步资源SYNCH1，操作系统恢复了Thread3的优先级，Thread1获得了同步资源SYNCH1，重新进入可执行队列。处于可运行状态的线程Thread1和Thread2中，Thread1的优先级大于Thread2的优先级，所以Thread1被调度执行。

3、两者结合的方案

当Thread3使用资源S时，Thread1抢占执行权，申请资源S，比较资源1和资源3的优先级，假如Thread1优先级高，才提升Thread3，提升到能访问资源S的最高优先级，当Thread3释放资源后，将优先级再调整回来。

https://blog.csdn.net/pgs1004151212/article/details/90896433

优先级

三、死锁

1.什么是死锁？

所谓死锁，是指多个进程在运行过程中因争夺资源而造成的一种僵局，当进程处于这种僵持状态时，若无外力作用，它们都将无法再向前推进。 因此我们举个例子来描述，如果此时有一个线程A，按照先锁a再获得锁b的的顺序获得锁，而在此同时又有另外一个线程B，按照先锁b再锁a的顺序获得锁。如下图所示：

2.产生死锁的原因？

可归结为如下两点：

1. 竞争资源

• 系统中的资源可以分为两类：
  • 可剥夺资源，是指某进程在获得这类资源后，该资源可以再被其他进程或系统剥夺，CPU和主存均属于可剥夺性资源；
  • 另一类资源是不可剥夺资源，当系统把这类资源分配给某进程后，再不能强行收回，只能在进程用完后自行释放，如磁带机、打印机等。
• 产生死锁中的竞争资源之一指的是竞争不可剥夺资源（例如：系统中只有一台打印机，可供进程P1使用，假定P1已占用了打印机，若P2继续要求打印机打印将阻塞）
• 产生死锁中的竞争资源另外一种资源指的是竞争临时资源（临时资源包括硬件中断、信号、消息、缓冲区内的消息等），通常消息通信顺序进行不当，则会产生死锁

2. 进程间推进顺序非法

• 若P1保持了资源R1,P2保持了资源R2，系统处于不安全状态，因为这两个进程再向前推进，便可能发生死锁
• 例如，当P1运行到P1：Request（R2）时，将因R2已被P2占用而阻塞；当P2运行到P2：Request（R1）时，也将因R1已被P1占用而阻塞，于是发生进程死锁

3.死锁产生的4个必要条件？

产生死锁的必要条件：

• 互斥条件：进程要求对所分配的资源进行排它性控制，即在一段时间内某资源仅为一进程所占用。
• 请求和保持条件：当进程因请求资源而阻塞时，对已获得的资源保持不放。
• 不剥夺条件：进程已获得的资源在未使用完之前，不能剥夺，只能在使用完时由自己释放。
• 环路等待条件：在发生死锁时，必然存在一个进程–资源的环形链。

4.解决死锁的基本方法

预防死锁：

• 资源一次性分配：一次性分配所有资源，这样就不会再有请求了：（破坏请求条件）
• 只要有一个资源得不到分配，也不给这个进程分配其他的资源：（破坏请保持条件）
• 可剥夺资源：即当某进程获得了部分资源，但得不到其它资源，则释放已占有的资源（破坏不可剥夺条件）
• 资源有序分配法：系统给每类资源赋予一个编号，每一个进程按编号递增的顺序请求资源，释放则相反（破坏环路等待条件）

1、以确定的顺序获得锁

如果必须获取多个锁，那么在设计的时候需要充分考虑不同线程之前获得锁的顺序。按照上面的例子，两个线程获得锁的时序图如下：

如果此时把获得锁的时序改成：

那么死锁就永远不会发生。 针对两个特定的锁，开发者可以尝试按照锁对象的hashCode值大小的顺序，分别获得两个锁，这样锁总是会以特定的顺序获得锁，那么死锁也不会发生。问题变得更加复杂一些，如果此时有多个线程，都在竞争不同的锁，简单按照锁对象的hashCode进行排序（单纯按照hashCode顺序排序会出现“环路等待”），可能就无法满足要求了，这个时候开发者可以使用银行家算法，所有的锁都按照特定的顺序获取，同样可以防止死锁的发生，该算法在这里就不再赘述了，有兴趣的可以自行了解一下。

2、超时放弃

当使用synchronized关键词提供的内置锁时，只要线程没有获得锁，那么就会永远等待下去，然而Lock接口提供了boolean tryLock(long time, TimeUnit unit) throws InterruptedException方法，该方法可以按照固定时长等待锁，因此线程可以在获取锁超时以后，主动释放之前已经获得的所有的锁。通过这种方式，也可以很有效地避免死锁。 还是按照之前的例子，时序图如下：

避免死锁:

• 预防死锁的几种策略，会严重地损害系统性能。因此在避免死锁时，要施加较弱的限制，从而获得 较满意的系统性能。由于在避免死锁的策略中，允许进程动态地申请资源。因而，系统在进行资源分配之前预先计算资源分配的安全性。若此次分配不会导致系统进入不安全的状态，则将资源分配给进程；否则，进程等待。其中最具有代表性的避免死锁算法是银行家算法。
• 银行家算法：首先需要定义状态和安全状态的概念。系统的状态是当前给进程分配的资源情况。因此，状态包含两个向量Resource（系统中每种资源的总量）和Available（未分配给进程的每种资源的总量）及两个矩阵Claim（表示进程对资源的需求）和Allocation（表示当前分配给进程的资源）。安全状态是指至少有一个资源分配序列不会导致死锁。当进程请求一组资源时，假设同意该请求，从而改变了系统的状态，然后确定其结果是否还处于安全状态。如果是，同意这个请求；如果不是，阻塞该进程知道同意该请求后系统状态仍然是安全的。

5.检测死锁

1. 首先为每个进程和每个资源指定一个唯一的号码；
2. 然后建立资源分配表和进程等待表。

6.解除死锁

当发现有进程死锁后，便应立即把它从死锁状态中解脱出来，常采用的方法有：

• 剥夺资源：从其它进程剥夺足够数量的资源给死锁进程，以解除死锁状态；
• 撤消进程：可以直接撤消死锁进程或撤消代价最小的进程，直至有足够的资源可用，死锁状态.消除为止；所谓代价是指优先级、运行代价、进程的重要性和价值等。

7.死锁检测

1、Jstack命令

jstack是java虚拟机自带的一种堆栈跟踪工具。jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息。 Jstack工具可以用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。 线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。

2、JConsole工具

Jconsole是JDK自带的监控工具，在JDK/bin目录下可以找到。它用于连接正在运行的本地或者远程的JVM，对运行在Java应用程序的资源消耗和性能进行监控，并画出大量的图表，提供强大的可视化界面。而且本身占用的服务器内存很小，甚至可以说几乎不消耗。

参考博文：https://blog.csdn.net/jonnyhsu_0913/article/details/79633656

四、延时和抖动

延时和抖动是相互关联的两个东西，但是它们并不相同。延时是网络中的一个重要指标，它由四个关键部分组成：处理延时（processing delay），排队延时（queueing delay），传输延时（transmission delay）和传播延时（propagation delay）。它会影响用户体验，并可能因多种因素而发生变化。抖动是基于延时产生的—具体而言，就是前后延时的值不一致。抖动是两个数据包延时值之间的差异。它通常会导致丢包和网络拥塞。虽然延时和抖动有很多共同点和关联，但是它们并不相同。

1.什么是延时（delay）？

延时是网络中的一项重要指标，可衡量数据从一个端点移动到另一个端点所需的时间。网络延时通常在几秒钟的时间范围内，并且可以更具许多因素进行更改，包括端点的位置，数据包的大小以及流量大小。

延时（delay）与延迟（latency）有何不同

延迟和延时相互联系紧密，并且很多时候可以混用。但是，他们并不总是相同的。延时是数据从一个端点传输到另一个端点所花费的时间。然而，延迟可以表示两个量。

延迟有时被认为是数据包从一个端点传输到另一个端点所用的时间，这与单向延时是一样的。

但更多的情况，延迟表示的是往返时间。往返时间包括发送数据包所需的时间加上它返回所需的时间。这不包括在目的地处理数据包所需的时间。

网络监控工具可以确定给定网络上的精确往返时间。可以从发送处计算往返时间，因为它跟踪数据包发送的时间，并在确认返回时计算差值。但是，两个端点之间的延时可能难以确定，因为发送端没有到达接收端的时间信息。

2.延时的组成

延时可以理解为四个关键延时部分的组合：处理延时，排队延时，传输延时和传播延时。

1. 处理延时：处理延时是系统分析数据包报头并确定数据包必须发送到何处的时间。这很大程度上取决于路由表中的条目，系统中数据结构的执行以及硬件实现。

2. 排队延时：排队延时是数据包排队和发送之间的时间。这取决于数据流量的大小，流量类型以及实现哪些路由器队列算法。不同的算法可以调整系统偏好的延时，或者对所有流量要求相同的延时。

3. 传输延时：传输延时是将数据包的数据推入线路所需的时间。这会根据数据包的不同大小和带宽大小而不同。这并不取决于传输线的距离，因为它仅仅是将包中数据推入传输线的时间，而不是沿着传输线到达接收端的时间。

4. 传播延时：传播延时是与从发送端传输到接收端的数据包的第一个比特相关的时间。这通常被称为距离延时，并且因此数据比特受到传播距离和传播速度的影响。

这些延时组合在一起构成网络中的总延时。往返时间由这些延时和接收端到发送端之间的时间组成。

3.延时的影响

延时主要会影响用户体验。在严格的音频通话中，150毫秒的延时是非常明显的并且会影响用户。在严格的视频通话中，认为400毫秒是可辨识的。将这两种呼叫功能集中在一起后，联合的音频和视频呼叫应该保持同步，并且延时要少于150毫秒以不影响用户。但是，一般来说，延时尽可能低是非常重要的。无论如何，ITU建议将网络延时保持在100毫秒以下。

4.什么是抖动？

在网络上连续传输的数据包即便使用相同的路径，也会有不同的延时。这是由于分组交换网络固有的两个关键原因造成的。第一，数据包被单独路由。第二，网络设备接收队列中的数据包，因此无法保证延时调度不变。

每个数据包之间的这种延时不一致称为抖动。对于实时通信而言，这可能是一个相当大的问题，包括IP电话，视频会议和虚拟桌面基础架构。抖动可能由网络上的许多因素引起，并且每个网络都有延时时间变化。

5.抖动会导致什么后果？

1. 丢包：当数据包不是均匀的到达接收端时，接收端必须进行弥补并尝试更正。在某些情况下，接收端无法进行适当的更正，并丢失数据包。就最终用户体验而言，这可以有多种呈现出的形式。比如，如果用户正在观看视频并且画面变成像素化，这就是潜在抖动的指示。

2. 网络拥塞：网络设备无法发送相同数据的流量，因此他们的数据包缓冲区已满并开始丢弃数据包。如果端点上的网络没有干扰，则每个数据包都会到达。但是，如果端点缓冲区满了，会使数据包到达的越来越晚，导致抖动。这被称为初期拥塞（incipient congestion）。通过监视抖动，可以观察到初期拥塞。同样，如果出现初期网络拥塞，则说明抖动正在迅速变化。

当网络设备开始丢弃数据包，并且端点没有收到数据包时就会发生拥塞。终端可能会要求重发丢失的数据包，这会导致拥塞崩溃。

需要注意的是接收端不会直接导致拥塞，也不会丢弃数据包。请想象一条高速公路，其中有旅店A和旅店B。旅店B拥挤不是由于B没有足够的停车位而造成的。拥挤是由A引起的，所以它会不断地将公路上的骑车送到B旅店。

6.我该如何补偿抖动？

为了弥补抖动，在连接的接收端使用抖动缓冲区。抖动缓冲区收集并存储传入数据包，以便它可以确定如何以一致的间隔发送它们。

1. 静态抖动缓冲—其在系统的硬件中实现，并且通常由制造商配置。

2. 动态抖动缓冲—其在系统软件中实现，并由管理员进行配置。他们可对缓冲进行调整以适应网络变化。

7.播放延时

播放延时是数据包到达时和播放时间之间的延时。当抖动缓冲区存储传入数据包并等待以均匀间隔分配它们时，这会增加数据包到达时间与播放时间之间的时间，也被称为播放延时。这个延时是由抖动缓冲区引入的，因为它负责规定传入数据包何时分发。

8.总结

延时和抖动天生就紧密相连，但它们其实并不同。延时是数据从网络上的一个端点移动到另一个端点所花费的时间。这是一个受多种因素影响的复杂的值。另一方面，抖动是两个数据包之间的延时差异。同样，它也可能是由网络上的几个因素造成的。尽管抖动和延时有相似之处，但是抖动仅仅是基于延时产生的而已，但不等于它。

9.周期任务中的抖动

周期性执行的任务，随机发生的延迟时间叫做抖动。虽然轻微的抖动很难避免，但是抖动太严重就会导致性能变差，间歇性的数据丢失。例如，每隔5ms调整电机的控制参数，如果控制任务的抖动过大就会使得控制性能就变差。除了线程饥饿会导致抖动之外，RTOS系统配置也会有影响，例如系统节拍定时器节拍频率。理想情况下，两个节拍之间的时间应该比系统中最频繁任务的周期时间短得多。

即周期执行的任务两次执行间隔可能并不等于周期，这意味着如果我们需要非常准确的间隔相同的时间去执行某种操作，我们将其包装成一个周期函数，但是实际上两次任务执行间隔可能并不等于周期，这对一些情况可能是不利的。