我正在使用音频输出单元来捕获麦克风数据。我收到通知我已使用kAudioOutputUnit_SetInputCallback属性设置的回调读取数据，并在回调中通过调用AudioUnitRender（）读取数据。
最终，我将根据通过分析此数据提取的一些信息更新我的应用程序的用户界面。因此，我需要在某个阶段对主队列执行dispatch_async。分析耗费时间，并且比我从AudioUnitRender（）得到的块大得多，因此负载是突发性的。
我的问题是：在输入回调本身的实现中哪些操作被认为是可接受的？我发现有很多来源说明严格限制渲染回调（没有内存分配，没有i / o，没有与其他线程同步等），但是根本没有关于输入的信息< / em>回调。
如果我遵循与渲染回调相同的规则，我会遇到一些挑战。 dispatch_async（）本身是不合需要的，因为它分配内存，无论如何负载是突发的（在某些转弯上可能很容易长于一个渲染周期，而在其他转弯上几乎为零）。因此，似乎有必要将我的数据发送到工作线程进行处理，并进行dispatch_async（）调用。但是，我仍然需要管理将数据传递给此工作线程。最简单的方法（在C ++中）将使用循环缓冲区，加上互斥和条件变量以在数据可用时发出信号。但是，这需要输入回调来锁定互斥锁，这对渲染回调的指导明确禁止。
避免使用这个互斥锁将带我进入无锁循环缓冲区，信号量（POSIX或GCD），自旋锁等等，我想知道是否因为只是听麦克风而过度杀伤。对于这些东西，有一个令人震惊的缺乏文档，我不知道幕后真的发生了什么。我是否真的需要担心在输入回调实现中等待互斥（只是短暂地，很少被另一个线程锁定）？
答案 0 :(得分：2)
我使用来自https://github.com/michaeltyson/TPCircularBuffer
的循环缓冲区说明中指出：
只要将多线程访问限制为仅限一个生产者，并且只限制一个使用者，此实用程序应该是线程安全的。
所以你可以安全地从循环缓冲区渲染（生成）和处理（消耗）而不用担心锁定。
<强>更新：
我是否真的需要担心在输入回调实现中等待互斥（只是短暂地，很少被另一个线程锁定）？
对此我说是的。 ＆＃34;很少被锁定＆＃34;就是输入回调失败所需的一切。并且＆＃34;简要地说＆＃34;已经太久了我输入的回调只是因为NSLogging而失败了。