基于 Qt 的 CD 抓取工具的线程构建块 (TBB)？
我正在用 C++ 和 Qt 构建 CD 抓取应用程序。 我想并行化应用程序，以便可以同时编码多个轨道。 因此，我以这样一种方式构建应用程序，即对轨道进行编码是一项“任务”，并且我正在研究一种同时运行一些此类任务的机制。 当然，我可以使用线程并编写自己的任务队列或工作管理器来完成此任务，但我认为英特尔的线程构建块（TBB）可能是完成这项工作的更好工具。 不过，我有几个问题。
- 将 WAV 文件编码为 FLAC、Ogg Vorbis 或 Mp3 文件是否可以作为 tbb::task 很好地工作？ 教程文档指出“如果线程频繁阻塞，则使用任务调度程序时会出现性能损失”。 我不认为我的编码任务会频繁地阻塞互斥体，但需要相对频繁地访问磁盘，因为它们必须从磁盘读取 WAV 数据才能进行编码。 从本教程描述的意义上来说，这种级别的磁盘活动是否有问题？
- TBB 与 Qt 配合得很好吗？ 使用Qt线程时，您可以跨线程透明地使用Qt的信号/槽机制。 如果我使用 tbb::tasks 而不是 Qt 线程，情况也会如此吗？ 还会有其他“陷阱”吗？
感谢您提供的任何见解。
I am building a CD ripper application in C++ and Qt. I would like to parallelize the application such that multiple tracks can be encoded concurrently. Therefore, I have structured the application in such a way that encoding a track is a "Task", and I'm working on a mechanism to run some number of these Tasks concurrently. I could, of course, accomplish this using threads and write my own Task queue or work manager, but I thought Intel's Threading Building Blocks (TBB) might be a better tool for the job. I have a couple of questions, however.
- Is encoding a WAV file into a FLAC, Ogg Vorbis, or Mp3 file something that would work well as a tbb::task? The tutorial document states that "if threads block frequently, there is a performance loss when using the task scheduler". I don't think my encoding tasks would block for mutexes frequently, but the will need to access disk relatively frequently, since they must read the WAV data from disk in order to encode. Is this level of disk activity problematic in the sense described by the tutorial?
- Does TBB work well with Qt? When using Qt threads, you can use Qt's signals/slots mechanism transparently across threads. Would the same be true if I were using tbb::tasks instead of Qt threads? Would there be any other "gotchas"?
Thanks for any insights you can provide.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么不使用 Qt Concurrent ？
Why not using Qt Concurrent ?
TBB 应该与其他线程机制一起工作得很好，甚至是透明的，所以理论上应该没有什么可以阻止您在同一程序中使用 QT 的线程类。 如果有一些东西可以更自然地与 QT 线程一起工作，例如 GUI，请使用它们并尽可能或想要地隔离 TBB 内容。
我认为您没有充分利用 TBB，因为您目前概述了您的设计。 您可以在最粗略的层面上并行化文件。 正如您所怀疑的，由于 CD 是一种速度相当慢的设备，因此您可能会花费更多的时间从多个文件中来回查找数据，而不是实际保存的时间。
TBB 真正的划算之处应该包括利用转换过程中存在的任何数据和/或任务并行性。 例如，您可以从流中提取任何字节块并独立于流之前或之后的任何部分对其应用任何转换吗？ 是否有多个可以并行的转换步骤？
TBB is suppose to work well, even transparently, with other threading mechanisms so theoretically there should be nothing preventing you from using QT's thread classes in the same program. If there is something that works more naturally with QT threads, like the GUI, use them and keep the TBB stuff segregated as best you can or want.
I don't see that you are making the best use of TBB as you currently outlined your design. You parallelize at the grossest level, the file. As you suspect, since the CD is a pretty slow device, you may spend more time seeking back and forth for data from multiple files than you actually save.
The real bang for the buck with TBB should involve exploiting whatever data and/or task parallelism there is in the transformation process. Can you, for instance, pull any block of bytes out of the stream and apply whatever transform to it independently of any part of the stream before or after? Are there multiple steps to the transform that can be parallelized?