我目前正在编写一种批量处理算法，用于从磁盘流式传输音频中进行音高检测。我已经加强了我的算法，使其几乎实时地运行，用于串行流数据。
理想情况下，我希望系统的工作方式比实时更快，这样我就可以将实时数据传递给实时数据，并且在产生音高轨道数据后不会产生很大的延迟。
现在让我感到震惊的是，数据的串行处理是我可以提供大量加速的地方。我正在运行四核i7（具有8个硬件线程），所以我应该能够通过在多个块上扩展处理来显着提高速度。
目前我正在做以下事情：
现在让我感到震惊的是，一旦我有了一个窗口，我就可以轻松地将这些数据复制到给定的线程工作缓冲区中（以及提供一个将写入结果的内存位置）。通过这种方式，我可以有效地缓冲7个线程（保持线程8打开以抽取数据）线程池然后将处理的线程数据。
当我尝试提交第8个音频窗口时，我希望池可以阻塞，直到线程可用于处理数据等等。我的想法是，我将保持7个线程不断处理数据。根据以前的经验，我预计这样做会加速5倍。
过去我在C ++下编写了我自己的基于任务的系统，可以完美地完成这项工作，但这个应用程序是在C＃下开发的。为了在C ++下以低开销获得良好的并行性，我花了大量时间构建一个良好的无锁排队机制。
我非常希望，在C＃下，有人会为我这样做而痛苦。但是，我找不到任何似乎有用的东西。我查看了System.Threading.ThreadPool，它似乎无法检查当前有多少线程在运行。更不用说开销似乎过高了。然后出现了一个大问题，我不能重复使用现有的预分配结构（这在我的处理中很重要），迫使我每次提交工作项时都要重新创建它。这有一个巨大的缺点，我然后生成的工作比我处理它更快，所以我不仅浪费了大量时间来设置我真正不应该需要的结构和工作空间，而且我的内存使用情况失控。
然后我发现了System.Threading.Tasks但是它似乎也没有提供我所追求的功能。
我想我可以通过互操作使用我的C ++任务管理器，但我真的认为在这个时代，有人已经建立了类似的东西。我错过了什么吗？或者任何人都可以为我提供这种任务管理引擎的链接吗？
答案 0 :(得分：4)
Task Parallel Library是专为您要解决的任务而设计和实施的！您也可以管理此过程。
所以你必须确保：
答案 1 :(得分：3)
好吧，在这些情况下，我建议使用ZeroMQ。它可以让你很容易地控制消费者的数量。
至于你的便笺区域，首先，0.5GB并不是当今时代的大量内存。我认为我的手机有比这更多的RAM，更不用说我的桌面......如果你想真正轻松消耗内存，只需为每个线程创建一个暂存区域，将所有这些区域放入池中并让生产者获得排队任务前的暂存区域，附加任务的该区域。消费者完成后，将便笺簿区域返回池中。
答案 2 :(得分：1)
我会在这里使用Task Parallel数据流库。它旨在允许创建可以链接在一起的进程块，并明确控制并行度和阻塞语义。