C 嵌入式系统设计模式 20：队列模式

本书的原著为：《Design Patterns for Embedded Systems in C ——An Embedded Software Engineering Toolkit 》，讲解的是嵌入式系统设计模式，是一本不可多得的好书。

本系列描述我对书中内容的理解。本文章描述嵌入式并发和资源管理模式之六：队列模式。

队列模式 (Queuing Pattern) 是一种 任务协作模式。在软件设计中，任务协作模式是用于协调不同任务之间通讯和同步的策略。它旨在确保任务能够高效、有序地执行，并处理任务之间的依赖关系、优先级冲突和资源共享等问题。

队列模式是任务间 异步通信 的最常见实现方式。它提供了一种简单的通信手段，适用于在时间上不耦合的任务之间的交互。队列模式通过将消息存储在队列（通常遵循先入先出原则的数据结构）中来实现这种通信。发送者将消息存入队列，并在稍后的某个时间点，接收者从队列中提取消息。由于队列的先入先出（FIFO）特性，任务可以按照消息发送的顺序来处理它们，这有助于维护系统的顺序和一致性。

此外，队列模式还提供了一种简单的 序列化访问 共享资源的方法。访问消息被排队并在稍后的时间处理，这避免了共享资源时常见的互斥问题。通过将请求排入队列，系统可以有序地处理这些请求，从而避免资源冲突和竞争条件。

时间上不耦合的任务 指的是那些在执行时间上没有严格依赖或关联性的任务。这种任务可以独立地安排和执行，它们的完成时间不需要与其他任务同步或对齐。时间上的不耦合意味着任务之间不需要等待或协调彼此的执行进度。

摘要

消息队列模式用于异步通信，通过将消息 入队 ，实现任务间的同步和信息共享。这种方法简单，并且没有互斥问题，因为使用资源的任务与资源没有直接关系。线程之间共享的任何信息都是通过队列传递的。发送方将信息复制到队列，接收方完成拥有它接收到的信息，因此可以自由的修改它们，而不用担心以下情况的共享数据损坏：

多个写入者
一个写入者和多个读取者

队列模式的一个缺点是，信息不会在发送者发布后立即处理；进程会等待，直到接收任务运行，并能够处理等待的信息。

问题

在多线程系统中，任务必须与其他任务 同步 以及 共享信息，在这个过程中，必须要做到：

任务必须同步：在多线程环境中，多个线程可能同时访问和修改共享资源，如果不同线程对共享资源的访问和修改没有得到适当的同步，就可能导致数据不一致或其他未定义的行为。同步机制 可以确保在任何时候只有一个任务可以访问共享资源，或者至少确保访问是以一种可预测和可控的顺序进行的。因此，任务必须有同步机制，才能安全的共享资源。
资源的共享方式必须确保不会出现数据损坏或竞态条件：为了避免竞态条件和数据损坏，信息的共享方式需要经过精心设计。例如，可以使用原子操作来确保对共享数据的读取和修改是不可分割的 ( 临界区模式 )；可以使用读写锁来允许多个任务同时读取共享数据，但只允许一个任务写入 ( 保护调用模式 )；

而本文讲述的 队列模式 ，是解决此类任务 同步 以及 共享信息 的又一种策略。

竞态条件 是指两个或多个线程在时间上以一种不可预测的方式访问共享数据，导致程序的行为取决于线程的相对执行顺序。

模式结构

模式结构如下图所示：
在这里插入图片描述

其中，队列数量 决定了队列可以保留的最大元素数量。在实际应用中，需要特别注意确保这个大小足够大，以处理系统使用中的最坏情况，同时又不能太大以至于浪费内存。

模式详情

消息

消息类 是使用消息队列的多个 抢占式任务 之间相关消息的一种抽象。可以是简单的数据值，也可以是 TCP/IP 消息传递中使用的复杂数据报结构。

消息队列

消息队列 是一种存储结构，用于抢占式任务之间交换信息。消息队列能够存储消息数量是有限的。为了实现消息存储，消息队列通常提供以下方法：

int getNextIndex(MessageQueue* me, int index) ：私有函数，使用模运算来计算下一个有效索引。
unsigned char isFull(MessageQueue* me)：私有函数，消息队列 满 则返回 1 ，否则返回 0 。
unsigned char isEmpty(MessageQueue* me)：私有函数，消息队列 空 则返回 1 ，否则返回 0 。
int insert(MessageQueue* me, Message m)：公有函数，如果消息队列未满，调用该函数会向队列 head 指向的位置插入一个消息并更新 head 索引。如果插入消息成功，则返回 0 ，消息队列满则返回 1 。
Message* remove(MessageQueue* me)：公有函数，如果消息队列非空，调用该函数先申请一个新的内存保存最老的消息，然后再把这个消息从队列中移除，之后更新 tail 索引，返回新申请内存的指针。如果函数执行失败返回 NULL 。

互斥量

互斥量 用于对 消息队列 的访问进行 序列化。当一个任务调用消息队列的受保护函数时，受保护函数内部会调用互斥锁的 lock() 函数，并在服务完成后调用 release() 函数。当互斥锁锁定时，如果有其他任务试图调用服务，这些任务将被阻塞，直到互斥锁解锁。互斥量通常由实时操作系统（RTOS）提供。

抢占式任务

抢占式任务 使用消息队列，它调用消息队列提供的 insert() 或 remove() 函数来访问存储在其中的数据。这些操作分别用于向消息队列中添加数据或从中移除数据。通过这种方式，抢占式任务能够与消息队列进行交互，实现数据的共享和通信。

效果

队列模式 为任务间的数据传递提供了一种有效的访问序列化机制。通过互斥锁的使用，消息队列能够安全地应对多个任务的并发访问，确保数据的完整性和一致性。由于队列模式实现了异步通信，因此，与 保护调用模式 相比，可能存在一定的延迟。然而，这种延迟是为了实现更好的任务解耦和资源利用率，允许数据发送者和接收者以独立的速率运行，从而提高了系统的整体性能和灵活性。

队列的容量可以设计得相当庞大，这种设计在处理突发性数据生成时显得尤为有用。它允许数据的消费者在生成高峰过后，按自己的节奏进行处理。然而，队列大小的设置需要谨慎考虑：过小的队列可能无法容纳突发的数据流量，从而导致宝贵的数据丢失；而过大的队列则可能占用过多的内存资源，造成不必要的浪费。另一方面，对于简单的异步数据交换场景，一个非常小的队列（例如只能容纳一两个元素）可能就足够了，因为在这种情境下通常不会出现数据丢失的问题。因此，根据具体的应用场景和需求来合理设置队列大小是至关重要的。

实现策略

最近的实现策略是使用数组，但这种方式没有链表灵活。

队列的实现相当简单，但却有着多种变体以适应不同的需求。在某些情况下，一些消息因其紧急性或重要性需要优先处理，这就要求队列能够支持优先级排序。为了实现这一点，可以通过增加多个缓冲区，每个对应不同的优先级，或者根据消息的优先级在队列中动态地插入元素。这样的设计修改使得高优先级的消息能够在低优先级消息之前得到处理。然而，这也可能带来一定的性能开销，如增加元素插入和删除的时间。因此，在实现优先级队列时，消息应当携带一个优先级属性，以便队列能够依据这一属性进行正确的排序和操作。这样的设计确保了系统既能够处理常规的消息流，又能够迅速响应紧急或重要的消息。

在复杂系统中，由于各种不确定性和动态性，最佳队列大小可能难以预测。为了解决这个问题，可以实现一种可扩展队列。当消息队列满时，这种队列能够动态地分配更多内存以容纳新消息。链表实现方式由于其灵活性，特别适合用于可扩展队列。然而，确定何时缩小队列并释放未使用的内存是一个挑战。一种可能的策略是监控队列的使用情况，当队列长时间处于低使用率状态时，考虑缩小其大小。但需要注意的是，频繁地调整队列大小可能会引入额外的开销和复杂性。

当潜在的元素数量超出内存容量时，缓存队列成为了一种有效的解决方案。这种队列结构主要包括三个存储组件：本地内存中的最新数据缓冲区、最旧数据缓冲区，以及用于存储中间数据的文件(比如存储到硬盘中)。当新数据缓冲区填满时，数据会被转移至文件系统进行存储。一旦旧数据缓冲区为空，系统会从文件系统中读取数据填充进去，并随后从磁盘中删除这些已经读取的数据（或者，在文件为空的情况下，从新数据缓冲区中复制数据）。这样的设计使得存储大量数据成为可能，但需要注意的是，缓存数据的操作可能会相当耗时 (因为可能要读写磁盘，而读写磁盘操作相比读写内存来说要慢的多)，因此在设计系统时需要权衡存储需求和性能要求。