multithreading - 使用多线程处理硬盘驱动器上的文件有用吗？

Question

在性能和执行速度方面，使用多线程处理硬盘驱动器上的文件有用吗？ (将文件从一个磁盘移动到另一个磁盘或检查文件的完整性)

我认为主要是我硬盘的速度将决定我的治疗速度。

Answer 1

多线程可以提供帮助，至少有时是这样。原因是，如果您正在写入“普通”硬盘驱动器(例如，不是固态驱动器)，那么最会减慢您速度的是硬盘驱动器的寻道时间(即所需的时间)硬盘驱动器将其读/写磁头从沿磁盘半径的一个距离重新定位到另一个距离)。与系统的其他部分相比，这种运动是冰川般缓慢的，头部寻找所需的时间与其必须行进的距离成正比。例如，最坏的情况是磁头在每次操作后都必须从磁盘边缘移动到磁盘中心。

当然，理想的解决方案是让磁头从不寻道，或者很少寻道，如果您可以安排它以便您的程序只需要按顺序读/写单个文件，那将是最快的。或者更好的是，切换到没有磁头的 SSD，并且寻道时间实际上为零。 :)

但有时您需要您的驱动器能够并行读取/写入多个文件，在这种情况下，驱动器磁头将(必然)来回寻找很多。那么多线程如何在这种情况下提供帮助呢？答案是这样的:使用足够智能的磁盘 I/O 子系统(例如 SCSI，我不确定 IDE 是否可以做到这一点)，I/O 逻辑将维护所有当前未完成的读/写请求的队列，并且它将动态重新排序该队列，以便按最小化读/写头的旅行量的顺序满足请求。这被称为 Elevator Algorithm ，因为它类似于电梯在给定时间段内最大化其可以运送的人数的逻辑。

当然，OS 的 I/O 子系统只有在事先知道哪些 I/O 请求未决的情况下才能实现这种优化……而如果您只有一个线程发起 I/O 请求，那么 I/O 子系统只会了解当前的请求。 (即它无法“窥视”您线程的用户空间请求队列以查看您的线程接下来想要什么)。当然，您的用户线程不知道磁盘布局的详细信息，因此很难(不可能？)在用户空间中实现电梯算法。

但是，如果您的程序有 N 个线程同时读取/写入磁盘，那么操作系统的 I/O 子系统将同时识别最多 NI/O 请求，并且可以按照它认为合适的方式重新排列这些请求以最大化磁盘性能.