我目前正在开发一个音频录制应用程序，它可以从网络中获取多达 8 个音频流并将数据保存到磁盘（简化 ;)）。 现在，每个流都由一个线程处理 -> 同一个线程也在磁盘上进行保存工作。
这意味着我有 8 个不同的线程在同一个磁盘上执行写入操作，每个线程写入不同的文件。
如果所有写入工作都由一个公共线程完成（随后将数据写入特定文件），您认为磁盘 i/o 性能会提高吗？
OS 是嵌入式 Linux，“磁盘”是 CF 卡，应用程序是用 C 编写的。
感谢您的想法 尼克
【问题讨论】：
标签： multithreading file-io embedded-linux
如果是嵌入式 linux，我猜你的机器只有一个处理器/内核。在这种情况下，线程根本不会提高 I/O 性能。当然 linux 块子系统在并发环境中运行良好，但在您的情况下（如果我对内核数量的猜测是正确的）不会出现多个线程同时执行某些操作的情况。
如果我的猜测是错误的并且您有超过 1 个内核，那么我建议您对磁盘 I/O 进行基准测试。编写一个从不同线程写入大量数据的程序，以及另一个仅从一个线程执行相同操作的程序。结果将向您展示您想知道的一切。
【讨论】：
简短的回答：鉴于您正在写入闪存盘，我不认为线程数会以某种方式产生太大影响。但如果它确实有所作为，我希望多线程比单线程更快，而不是更慢。
更长的答案：
我写了一个与您在 6 年前描述的程序类似的程序——它在嵌入式 PowerPC Linux 卡上运行，并从 SCSI 硬盘驱动器读取/写入多个同步音频文件。我最初使用单线程执行 I/O 编写它，因为我认为这样可以提供最佳吞吐量，但事实证明并非如此。
特别是，当多个线程同时读/写时，SCSI 层知道来自所有不同线程的所有未决请求，并且能够重新排序 I/O 请求，以便寻找驱动器头最小化。另一方面，在单线程 IO 场景中，SCSI 层只知道单个“下一个”未完成的 I/O 请求，因此无法进行优化。在许多情况下，这意味着驱动头需要额外的行程，因此会降低吞吐量。
当然，您的应用程序没有使用 SCSI 或带有需要寻找磁头的旋转驱动器，因此这对您来说可能不是问题 - 但文件系统/硬件层可能会进行其他优化，如果它是知道多个同时的 I/O 请求。找出答案的唯一真正方法是尝试各种模型并测量结果。
我的建议是通过将磁盘 I/O 移动到线程池中来将磁盘 I/O 与网络 I/O 分离。然后，您可以将 I/O 线程池的最大大小从 1 更改为 N，并针对每个大小测量系统的性能。这样您就可以清楚地了解什么在您的特定硬件上最有效，而无需您多次重写代码。
【讨论】：
我认为在您的情况下，多线程和单线程解决方案之间没有太大区别，但是在多线程的情况下，您可以在接收线程之间同步，并且在某些系统调用阻塞的情况下，没有一个线程可以影响其他线程。
我在嵌入式系统上做了同样的事情，问题是当内核将许多缓存的脏页放到 CF 时 CPU 使用率很高，pdflush 内核进程在那一刻占用所有 cpu 时间，如果你通过 udp 接收流，那么它可以被跳过因为 udp 流来的时候 cpu 很忙，所以我每次接收到一些不大的数据时都会通过fdatasync() 调用来解决这个问题。
【讨论】：