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被赋予上下文并从队列中接收一个项目：

队列的另一个极其常见的用例是让队列接受来自许多不同来源的输入。这对于像调试串口或日志文件这样的东西特别有用。许多不同的任务可以写入队列，由一个任务负责从队列中接收数据并将其推送到共享资源上。

参考资料

• 软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞，谢谢！
• 本文涉及的python测试开发库 谢谢点赞！ https://github.com/china-testing/python_cn_resouce
• python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md

实时操作系统的信号

Semaphores是另一种非常直接的，但却很强大的结构。semaphore这个词起源于希腊语--近似的英语翻译是sign-bearer，这是一种非常直观的思考方式。信号灯被用来表示某些事情已经发生；它们是事件的信号。一些信号灯的使用案例包括以下内容：

• ISR完成了对外围设备的服务。它可以给出信号，为任务提供信号，表明数据已经准备好进一步处理。
• 任务到达了关口，它需要等待系统中的其他任务跟上，然后再继续前进。在这种情况下，可以用semaphore来同步任务。
  限制受限资源的同时使用者的数量。
• 使用RTOS的方便之处在于信号灯的预先存在。它们被包含在每RTOS的实现中，因为它们的功能是如此的基本（和关键）。有两种不同类型的信号灯可供选择：计数信号灯和二进制信号灯。

计数信号

Counting semaphores最常被用来管理对同时使用的用户数量有限制的共享资源。在创建时，它们可以被配置为持有最大值，称为上限。通常给出的计算semaphores的例子是数据库中的读者...