微控制器实时操作系统实践3任务信令和通信机制
3任务信令和通信机制
在本章中，将简要介绍任务信号和任务间通信的核心机制。这些基元是事件驱动的并行编程的基础，它是基于RTOS的应用程序良好实现的基础。
与其直接进入FreeRTOS的API，不如将每个基元与一些图形例子和一些关于每个机制可被使用的建议一起介绍。不要担心：在后面的章节中，我们将进入使用API的细枝末节。现在，让我们把注意力集中在基本原理上。
实时操作系统队列
队列的概念相当简单，但它们也非常强大和灵活，特别是如果你传统上用C语言在裸机上编程的话。 在其核心，队列只是一个循环缓冲区。然而，这个缓冲区包含一些非常特殊的属性，比如原生的多线程安全，每个队列可以灵活地容纳任何类型的数据，以及唤醒正在等待队列中出现的项目的其他任务。默认情况下，数据存储在队列中使用先进先出（FIFO）排序--第一个被放入队列的项目就是第一个被从队列中移除的项目。
我们将首先看看当队列处于不同状态和以不同方式使用时的一些简单行为（发送与接收），然后继续讨论如何用队列在任务之间传递信息。
简单的队列发送
第一个队列例子是简单地将一个项目添加（也被称为发送）到有空位的队列中：
当项目被添加到有可用空间的队列中时，添加立即发生。因为队列中的空间是可用的，所以将项目发送到队列的任务继续运行，除非有另优先级更高的任务在等待队列中出现的项目。
尽管与队列的交互通常发生在任务内部，但这并不总是这样的。在一些特殊情况下，队列也可以从ISR中访问（但这种行为有不同的规则）。在本章的例子中，我们将假设任务从队列中发送和接收项目。
简单的队列接收
在下图中，任务被显从队列中接收一个项目：
当任务准备从队列中接收项目时，默认情况下，它将获得最老的项目。在这个例子中，由于队列中至少有一个项目，所以接收被立即处理，任务继续运行。
满队列发送
当队列已满时，没有信息被丢弃。相反，试图将项目发送到队列的任务将等待队列中的可用空间，最长时间为预先确定的数量：
当队列已满时，试图向队列发送项目的任务将等待，直到队列中的空间变得可用，但只到指定的超时值。
在这个例子中，如果任务试图向满的队列发送，并且它的超时值是10毫秒--它将只等待10毫秒的队列中的空间变得可用。超时结束后，调用将返回并通知调用代码发送失败。如何处理这个失败是由设置调用代码的程序员决定的，并将根据使用情况而变化。极大的超时值可以用于真正的非关键性功能。只是要注意，这将导致发送任务有效地永远等待队列中的空位（这显然不再是实时的了）
你的代码通常会被结构化，以便尝试向队列中发送不会超时。作为程序员，你应该根据具体情况来决定什么是可接受的时间量。你也有责任确定超时的严重性和纠正措施，如果真的发生超时。潜在的纠正措施可以从什么都不做（想想视频通话中的丢帧）到紧急关机。
接收空队列
访问队列可能导致任务阻塞的另一种情况是接收空队列：
与等待空间的发送类似，从队列中接收的任务也有可能被延迟。在空队列的情况下，试图从队列中接收的任务将被阻塞，直到队列中出现项目。如果在超时之前没有项目出现，调用代码将被通知失败。同样，要采取的确切行动方案也是不同的。
有时，会使用无限期的等待。你经常会遇到一些队列的等待时间非常长，这些队列正在接收来自外部接口的输入，如串行端口，它们可能不会不断地发送数据。如果串口另一端的人类用户在很长一段时间内没有发送数据，那就完全没有问题。
另一方面，接收超时也可以用来确保你有一个最低可接受的数据量来处理。让我们使用一个旨在以10赫兹（每秒10个读数）提供新读数的传感器。如果你正在实现一个依赖于这个传感器的新鲜读数的算法，一个略大于100毫秒的超时可以用来触发一个错误。这个超时将保证该算法总是在新鲜的传感器读数上行动。在这种情况下，击中超时可用于触发某种类型的纠正措施或通知，说明传感器没有按照预期执行。
任务间通信的队列
既然已经介绍了队列的简单行为，我们就来看看如何利用它们在任务之间移动数据。队列的非常常见的用例是让一个任务填充队列，而另一个任务则从同一队列中读取数据。这通常是直截了当的，但可能有一些细微的差别，这取决于系统是如何设置的：
在前面的例子中，任务1和任务2都在与同一个队列进行交互。任务1将向队列发送一个项目。只要任务2的优先级比任务1高，它就会立即收到该项目。
让我们考虑另一个实例，在实践中，当多个任务与队列进行交互时，经常会出现这种情况。由于抢占式调度器总是运行具有最高优先级的任务，如果该任务总是有数据要写入队列，那么在另一个任务有机会从队列中读取数据之前，队列就会充满。下面是一个例子，说明这可能会发生的情况：
下面的数字与时间轴上的索引相对应：
- 任务2试图从空队列中接收一个项目。没有项目可用，所以任务2阻塞。
- 任务1向队列添加项目。由于它是系统中优先级最高的任务，任务1向队列中添加项目，直到它没有更多的项目可以添加，或者直到队列已满。
- 队列被填满了，所以任务1被阻塞了。
- 任务2被调度器赋予上下文，因为它现在是可能运行的最高优先级任务。
- 一旦有项目从队列中移出，任务1就会再次被赋予上下文（这是系统中优先级最高的任务，它现在可以运行了，因为它在等待队列中的空间时被阻塞了）。在添加一个项目后，队列已经满了，任务1被阻塞了。
- 任务2被赋予上下文并从队列中接收一个项目：
队列的另一个极其常见的用例是让队列接受来自许多不同来源的输入。这对于像调试串口或日志文件这样的东西特别有用。许多不同的任务可以写入队列，由一个任务负责从队列中接收数据并将其推送到共享资源上。
实时操作系统的信号
Semaphores是另一种非常直接的，但却很强大的结构。semaphore这个词起源于希腊语--近似的英语翻译是sign-bearer，这是一种非常直观的思考方式。信号灯被用来表示某些事情已经发生；它们是事件的信号。一些信号灯的使用案例包括以下内容：
- ISR完成了对外围设备的服务。它可以给出信号，为任务提供信号，表明数据已经准备好进一步处理。
- 任务到达了关口，它需要等待系统中的其他任务跟上，然后再继续前进。在这种情况下，可以用semaphore来同步任务。
限制受限资源的同时使用者的数量。 - 使用RTOS的方便之处在于信号灯的预先存在。它们被包含在每RTOS的实现中，因为它们的功能是如此的基本（和关键）。有两种不同类型的信号灯可供选择：计数信号灯和二进制信号灯。
计数信号
Counting semaphores最常被用来管理对同时使用的用户数量有限制的共享资源。在创建时，它们可以被配置为持有最大值，称为上限。通常给出的计算semaphores的例子是数据库中的读者...... 好吧，我们在这里谈论的是基于MCU的嵌入式系统，所以让我们保持我们的例子的相关性。如果你对数据库感兴趣，你可能最好用通用的操作系统! 对于我们的例子，假设你正在实现基于套接字的通信驱动，而你的系统只有足够的内存来满足有限数量的同时套接字连接。
在下图中，我们有一个共享网络资源，可以容纳两个同时进行的套接字连接。然而，有三个任务需要访问。计数信号被用来限制同时进行的套接字连接的数量。每当任务使用完共享资源（即它的套接字关闭），它必须交出它的信号，以便另一任务能够获得对网络的访问。如果任务碰巧给了已经达到最大计数的信号灯，这个计数将保持不变：
前面的图演绎了一个共享资源只能同时为两个任务服务的例子（尽管系统中有三个任务需要使用该资源）。如果任务要使用套接字，而这个套接字受到计数信号的保护，它必须首先从池中获取一个信号。如果没有semaphore，那么该任务必须等待，直到有semaphore可用：
- 最初，semaphore被创建，最大（上限）为2，初始计数为0。
- 当任务A和任务B试图获取semaphore时，他们立即成功。这时，他们可以各自打开套接字，通过网络进行通信。
- TaskC稍后，所以它需要等待，直到semaphores的计数小于2，这时网络套接字就可以自由使用了。
- 在TaskB完成了通过其套接字的通信后，它将返回semaphore。
- 现在有了semaphore，TaskC完成了它的取舍，并被允许访问网络。
- 在TaskC获得访问权后不久，TaskB有另一条消息要发送，所以它试图获取信号灯，但需要等待可用的信号灯，所以它被置于睡眠状态。
- 当TaskC在网络上进行通信时，TaskA完成并返回它的semaphore。
- 任务B被唤醒并完成了它的任务，这使得它能够开始通过网络进行通信。
- 在TaskB得到它的信号后，TaskC完成了它的事务并归还了它的信号。
等待信号是RTOS与其他大多数信号实现不同的地方--任务在等待信号时可以超时。如果任务未能及时获得信号，它就不能访问共享资源。相反，它必须采取另一种行动。这个替代行动可以是任何数量的行动，从严重到触发紧急关机程序的故障，到仅仅在日志文件中提及或推送到调试串口供以后分析的良性事件。作为一个程序员，应该由你来决定什么是适当的行动方案，这有时会促使你与其他学科进行一些困难的讨论。
二进制信号
二进制信号灯实际上就是最大计数为1的计数信号灯，它们最常用于同步。当任务需要在事件上进行同步时，它将尝试使用信号链，阻塞直到信号链变得可用或直到指定的超时时间结束。系统的另异步部分（无论是任务还是ISR）将给出信号灯。二进制semaphores可以被多次给出，那段代码没有必要返回它们。在下面的例子中，任务A只给出信号，而任务B只接受信号：
任务B被设置为在继续履行其职责之前等待信号（信号）：
- 最初，TaskB试图接受信号，但它并不存在，所以TaskB进入了睡眠状态。
- 过了一段时间，任务A发出了信号。
- 任务B被唤醒（由调度器唤醒；这发生在后台），现在有了信号灯。它将进行它所需要的工作，直到完成。然而，请注意，任务B不需要归还二进制信号。相反，它只是再次等待它。
- 任务B再次被阻塞，因为信号灯不可用（就像第一次一样），所以它进入睡眠状态，直到有信号灯可用。
周而复始。
如果任务B "交还 "二进制信号，它将立即再次运行，而不会收到来自任务A的指令。其结果只是全速运行的循环，而不是在任务A发出信号的条件下被提示。
实时操作系统的互斥
术语mutex是相互排斥的简写。在共享资源和任务的上下文中，互斥意味着，如果一个任务正在使用共享资源，那么该任务是唯一被允许使用该资源的任务--所有其他任务都需要等待。
如果这一切听起来很像二进制信号灯，那是因为它就是。然而，它还有一个额外的功能，我们很快就会介绍。首先，让我们来看看使用二进制信号灯来提供相互排斥的问题。
优先级倒置
让我们来看看在试图使用二进制信号提供互斥功能时发生的常见问题。
考虑三个任务，A、B和C，其中A的优先级最高，B的优先级居中，而C的优先级最低。任务A和C依靠信号灯来访问它们之间共享的资源。由于任务A是系统中优先级最高的任务，它应该总是在其他任务之前运行。然而，由于任务A和任务C都依赖于它们之间共享的资源（由二进制信号灯守护），这里有意外的依赖关系：
让我们一步一步地通过这个例子来看看这种情况是如何发生的：
- 任务C（系统中优先级最低的任务）获得了二进制信号，开始做一些工作。
- 在任务C完成工作之前，任务A（最高优先级的任务）中断并试图获得相同的信号，但由于任务C已经获得了信号而被迫等待。
- 任务B也抢占了任务C，因为任务B的优先级比任务C高。
- 任务C用共享资源完成了剩余的工作，这时它把信号灯还给了任务C。
- 任务A终于可以运行了。
任务A最终能够运行，但要等到两个低优先级的任务都运行完了才行。任务C用共享资源完成它的工作是不可避免的（除非在设计上做出改变，以防止它与任务A访问相同的共享资源）。然而，任务B也有机会运行到完成，尽管任务A在旁边等待，并且有更高的优先级！这就是优先级倒置--更高的优先级是指任务A在完成工作时，他的任务也在完成！这就是优先级倒置--系统中优先级较高的任务正在等待运行，但它被迫等待，而另一个优先级较低的任务正在运行--在这种情况下，这两个任务的优先级实际上是倒置的。
互斥器使优先级倒置最小化
早些时候，我们曾说过，在FreeRTOS中，突变体是二进制信号，有一个重要的附加功能。这个重要的特性就是优先级继承--互斥器有能力暂时改变一个任务的优先级，以避免在系统中造成重大延误。当调度员发现一个高优先级的任务试图获取一个已经被低优先级的任务所持有的突变时，就会出现这种情况。在这种特定情况下，调度器将暂时提高低级任务的优先级，直到它释放突变。在这一点上，低级任务的优先级将被设置回它在优先级继承之前的状态。让我们来看看上图中使用互斥（而不是二进制信号）实现的完全相同的例子：
让我们一步一步地通过这个例子来看看这种情况是如何发生的：
- 任务A仍然在等待任务C返回互斥。
- 任务C的优先级被提高到与更高优先级的任务A相同。任务C运行到完成，因为它持有mutex，是一个高优先级的任务。
- 任务C返回突变，它的优先级被降到了它持有突变之前的水平，因为突变耽误了高优先级任务。
- 任务A拿着mutex并完成了它的工作。
- 任务B被允许运行。
根据任务C在共享资源上花费的时间，以及任务A的时间敏感性，这可能是一个主要的问题，也可能不是什么大问题。可以进行时间分析，以确保任务A仍然符合最后期限，但跟踪所有可能的优先级倒置和其他高优先级异步事件的原因可能被证明是具有挑战性的。至少，用户应该利用为获取突变提供的内置超时，并在突变未能及时获取的情况下执行适当的替代行动。关于如何实现这一目标的更多细节可以在第9章 "任务间通信 "中找到。
Mutexes和semaphores是任务间信号传递的相当标准的机制。它们在不同的RTOS之间是非常标准的，并且提供了很好的灵活性。