【发布时间】:2013-12-30 17:29:19
【问题描述】:
iOS 是否有任何不包括锁定的非常低级别的条件锁?
我正在寻找一种方法来从 Core Audio 渲染线程中发出等待线程的信号,而无需使用锁。我想知道是否可能存在像 Mach 系统调用这样的低级别的东西。
现在我有一个 Core Audio 线程,它使用非阻塞线程安全消息队列将消息发送到另一个线程。然后,另一个线程每 100 毫秒拉一次以查看队列中是否有消息。
但这是非常初级的,而且时机很糟糕。我可以使用条件锁,但这涉及到锁定,我希望将任何类型的锁定排除在渲染线程之外。
我正在寻找的是让消息队列线程等待,直到 Core Audio 渲染线程发出信号。就像 pthread 条件一样,但没有锁定并且没有立即的上下文切换?我希望 Core Audio 线程在消息队列线程被唤醒之前完成。
【问题讨论】:
-
您想在没有任何锁定和/或上下文切换的情况下进行线程间信号传输?如果您正在排队音频缓冲区指针,为什么锁定和/或上下文切换会成为任何类型的瓶颈?
-
这与音频渲染无关。这是关于核心音频线程发送正在发生的事情的消息:它将播放从一个音频缓冲区切换到另一个(轨道更改)或者它已经用完了音频帧来播放(缓冲区运行不足)等等。所以会发生什么,它将此消息放入一个结构中,然后将其写入非阻塞循环缓冲区。然后,另一个线程会不时(100 毫秒)检查缓冲区,作为回报,它会处理从渲染线程接收到的消息。所以我基本上只是在寻找一种方法来推送到另一个线程,而不是每 100 毫秒拉一次。
-
如果您使用条件变量 (
cnd_wait()),您的锁将非常短,即使对于音频渲染线程也是可以接受的。我将它用于 CoreMIDI readProc,但我也将它用于音频渲染线程。 -
@bio 我也这么认为,但事实证明,实时上下文中的任何锁定根本都是危险的。事件保证永不阻止对
pthread_trylock()的调用是不安全的,因为您锁定的任何东西都必须再次解锁,而解锁机制可能会导致系统调用,这反过来又会耗尽您的时间预算并导致音频捕捉。 (见:youtu.be/zrWYJ6FdOFQ?t=591)
标签: ios multithreading core-audio