避免优先级倒置

本文介绍了 Android 的音频系统如何尝试避免优先级倒置，还重点介绍了您可以使用的技术。

对于高性能音频应用的开发者、原始设备制造商 (OEM) 和要实现音频 HAL 的 SoC 提供商而言，这些技术可能很有用。请注意，实现这些技术不能保证一定不会出现错误或其他故障，尤其在音频环境之外使用时。使用不同的技术，获得的结果可能也会不同，您需要自己进行评估和测试。

背景

Android AudioFlinger 音频服务器和 AudioTrack/AudioRecord 客户端实现正在进行架构调整，以缩短延迟时间。这项工作从 Android 4.1 开始，在 4.2、4.3、4.4 和 5.0 中得到了进一步改进。

为了缩短延迟时间，需要对整个系统进行大量更改。其中一项重要更改是采用预测性更高的调度策略将 CPU 资源分配给对时间要求严格的线程。可靠的调度可减小音频缓冲区的大小和数目，同时仍可避免欠载和溢出。

优先级倒置

优先级倒置是实时系统的一种经典故障模式，是指优先级较高的任务因等待优先级较低的任务释放资源（如受互斥保护的共享状态）而无限长时间地受阻。

在音频系统中，优先级倒置通常表现为音频错误（咔嗒声、爆裂声、音频丢失）、音频重复（使用环形缓冲区时），或对命令的响应出现延迟。

优先级倒置的常见解决方法是增加音频缓冲区大小。不过，这种方法会增加延迟时间，仅仅将问题隐藏，而非解决问题。最好的方法是了解并防止优先级倒置，如下所示。

在 Android 音频实现中，优先级倒置最有可能发生在以下位置。因此，您应该重点关注这些位置：

  • AudioFlinger 中的常规混合器线程和快速混合器线程之间
  • 快速 AudioTrack 的应用回调线程和快速混合器线程之间（它们的优先级都较高，但略有不同）
  • 快速 AudioRecord 的应用回调线程和快速捕获线程之间（与上一种情况类似）
  • 在音频硬件抽象层 (HAL) 实现（例如用于电话或回声消除的实现）中
  • 在内核的音频驱动程序中
  • AudioTrack 或 AudioRecord 回调线程和其他应用线程（这不在我们的控制范围内）之间

常用解决方法

一般采用的解决方法包括：

  • 停用中断
  • 优先级继承互斥

停用中断在 Linux 用户空间中不可行，且不适用于对称多处理器 (SMP)。

优先级继承 Futex（快速用户区互斥）在音频系统中未被使用，因为它们属于相对重量级的应用，并且它们依赖于可信客户端。

Android 使用的技术

实验从“尝试锁定”和超时锁定开始。它们是互斥锁定操作的非阻塞和有界阻塞变体。尝试锁定和超时锁定的效果相当不错，但容易受到几个罕见故障模式的影响：如果客户端繁忙，将不能保证服务器一定能够获取共享状态；如果有一个较长序列的不相关锁定都已超时，累积的超时时间可能会过长。

我们还使用原子操作，例如：

  • 增加
  • 按位“或”
  • 按位“和”

所有这些操作均返回之前的值，并包含必要的 SMP 屏障。缺点在于它们可能需要无限次重试。在实践中，我们发现重试并不是问题。

注意：原子操作及其与内存屏障的互动遭到非常严重的误解和误用。我们在此处提供这些方法，是为了提供完整的信息；不过，建议您同时阅读 SMP Primer for Android 这篇文章，以了解更多信息。

我们仍然保有和使用上述大多数工具，并在最近添加了以下技术：

  • 针对数据使用非阻塞单读取器单写入器 FIFO 队列。
  • 尝试在高优先级模块和低优先级模块之间复制状态，而非共享状态。
  • 如果确实需要共享状态，请将状态的大小限定为在不重试的情况下，可以在单总线操作中通过原子方式获取的字的最大大小。
  • 对于复杂的多字状态，请使用状态队列。状态队列基本上只是用于状态（而非数据）的非阻塞单读取器单写入器 FIFO 队列，写入器将相邻推送合为单个推送的情况除外。
  • 注意内存屏障，以保证 SMP 的准确性。
  • 信任，但要验证。在进程之间共享“状态”时，请勿假定状态的格式正确无误。例如，检查索引是否在范围内。在同一个进程中的线程之间，以及在相互信任的进程（通常具有相同的 UID）之间，不需要进行验证。此外，也无需验证共享的“数据”，例如出现非继发性损坏的 PCM 音频。

非阻塞算法

非阻塞算法是我们最近一直在研究的一项内容。不过，除了单读取器单写入器 FIFO 队列之外，我们发现此类算法既复杂，又容易出错。

从 Android 4.2 开始，您可以在以下位置找到我们的非阻塞单读取器/写入器类：

  • frameworks/av/include/media/nbaio/
  • frameworks/av/media/libnbaio/
  • frameworks/av/services/audioflinger/StateQueue*

它们是专为 AudioFlinger 设计的，并不通用。非阻塞算法因其难以调试而臭名昭著。您可以将此代码视为一种模型。不过请注意，其中可能有 bug，并且我们不能保证这些类一定适用于其他用途。

对于开发者来说，应该更新部分示例 OpenSL ES 应用代码，以使用非阻塞算法或参照非 Android 开放源代码库。

我们发布了一个示例非阻塞 FIFO 实现，该实现专为应用代码设计。请查看位于平台源目录 frameworks/av/audio_utils 中的以下文件：

工具

据我们所知，目前没有用于找出优先级倒置（尤其是事先找出优先级倒置）的自动工具。一些研究型静态代码分析工具如果能够访问整个代码库，就能找出优先级倒置。当然，如果涉及到任意用户代码（这里指应用）或用户代码是一个大型代码库（如 Linux 内核和设备驱动程序），进行静态分析可能会不切实际。最重要的是，请务必认真阅读代码，并充分理解整个系统和各种交互操作。systrace 和 ps -t -p 等工具有助于在优先级倒置发生后及时发现，但并不会提前告知您。

总结

经过上述讨论后，请不要害怕互斥。一般情况下，互斥会是您的得力助手，例如，在时间不紧急的一般使用情形中正确使用和实现互斥时。但在高优先级任务和低优先级任务之间以及在时间敏感型系统中，互斥更有可能会导致出现问题。