避免优先级倒置

本文介绍了 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 内核和设备驱动程序),进行静态分析可能会不切实际。最重要的是,请务必认真阅读代码,并充分理解整个系统和各种交互操作。systraceps -t -p 等工具有助于在优先级倒置发生后及时发现,但并不会提前告知您。

总结

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