多线程：Swift中有损线程通知的最佳方法？

我有一个高优先级的音频线程，定期运行，应该做最小的同步

有时，在发送下一批参数之前，主线程需要确保至少已通过一个音频周期，并且已拾取某些参数。例如，当禁用音频节点时，主线程需要等待下一个周期，当禁用命令被拾取并且节点自身关闭时

有时，主线程等待命令完全执行很重要，但有时并不重要，因此可能没有人在侦听同步事件。因此出现了“有损”的情况

那么，以最小的开销和可能的“有损”方式通知其他线程事件的最佳方式是什么呢

无法想出为此任务使用信号量的方法。有什么标准的方法可以实现这一点吗？看起来Java的

notifyAll（）

就是这样工作的，如果是这样，那么

notifyAll（）后面使用的同步机制是什么

编辑：我一直在想，有没有“在队列中给我发送一个信号量，我会给它发信号”这样的事情？看起来有点太复杂了，但理论上它可以完成这项工作。对于同一个任务，有没有更简单的工具？
一般来说，您永远不希望阻塞主线程（或者，至少，阻塞时间超过几毫秒）。如果响应可能需要更长的时间，而不是实际等待，我们将采用异步模式，让主线程继续。当然，如果您需要阻止用户交互，我们会这样做，但我们不会阻止主线程

关键问题是，如果某个应用程序长时间阻止主线程，您的用户体验（UX）不好（应用程序似乎冻结），您的应用程序可能会被看门狗进程杀死。因此，我不建议使用信号量（或任何其他类似机制）让主线程等待来自音频引擎控制器的内容

例如，假设主线程希望告诉音频引擎暂停播放，但您希望UI“等待”它被确认和处理。与实际等待不同，我们将设置一些异步模式，其中主线程通知音频引擎它希望暂停，然后音频控制器将在通过某种回调机制（例如，通过委托协议模式、完成处理程序关闭等）处理该请求时通知主线程。如果您恰好需要在中间时间阻止用户交互，那么您应该禁用控制器并使用一些
UIActivityIndicatorView
（即微调器）或类似的东西，这些东西在调用完成处理程序时会被删除

现在，您使用了术语“有损”，但这通常表示您不介意请求丢失。但我认为事实并非如此。我假设您并不真的希望请求丢失，而只是主线程不关心响应，相信音频控制器会在可能的时候找到它。在这种情况下，您可能仍然会给音频控制器一个回调机制，但主线程不会利用它

现在，如果您希望音频引擎按顺序处理一系列命令，那么音频控制器可能有一个用于这些请求的专用内部队列，您可以将其配置为在前一个请求完成之前不启动后续请求。主线程不应该担心所需的音频周期是否已处理。它应该只发送任何适当的请求，音频控制器应该按照所需的顺序/时间处理这些请求。
这里有一个想法，可能是不成熟的：如果后台操作放在串行操作队列中，则主操作可以放在同一个操作队列中，这样就保证了它在队列被清除之前无法启动。@马特，很抱歉，在你的术语中，我不知道哪一个是音频线程？背景还是主要？目标是让音频线程在每个周期开始时通知其他线程（如果当前有任何线程正在等待事件）。如果没有，音频线程应该以绝对最小的开销进行。等待、信号量、指向主队列等都是我们建议不要使用的技术。我建议我们从“notifyAll

的等价物是什么”或“我将如何使用信号量”这样的问题退后一步，也许你可以给我们一些真实世界的例子，比如你想对你的音频控制器提出的一些请求，其中1个或2个是你想“等待”的请求还有一两个你不介意的“有损”。毫无疑问，有更好的模式，但如果没有真实的例子来说明您正在尝试做什么，就很难具体说明。了解您的目标平台和使用的音频框架也可能很有用。感谢您深思熟虑的回复，您提出了一些好的观点。这个想法的灵感来自CoreAudio自己的单元启动/停止机制，据说该机制实际上要等到最后一个音频周期完成。但无论如何，另一种选择可能是，例如，我想发送一个信号来禁用音频节点，并在它收到信号并实际禁用自身时获得回调。类似于非阻塞（Swift）

setEnabled（false，completion:{…}）

。所有这些调用都将按顺序排队和执行。委托可以工作，但仅限于一个侦听器。