使用多线程处理硬盘驱动器上的文件是否有用?

Bas*_*mme 7 multithreading

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

我认为主要是我的硬盘速度决定了我的治疗速度.

Jer*_*ner 8

多线程可以帮助,至少有时候.原因是,如果您正在写一个"普通"硬盘驱动器(例如不是固态驱动器),那么最让您放慢速度的事情就是硬盘驱动器的寻道时间(也就是说,它需要的时间)硬盘驱动器将其读/写磁头从磁盘半径的一个距离重新定位到另一个距离.与系统的其他部分相比,这种运动非常缓慢,并且头部寻找所需的时间与其必须行进的距离成比例.因此,例如,最糟糕的情况是,如果磁头必须在每次操作后从磁盘边缘移动到磁盘中心.

当然,理想的解决方案是让磁头永远不会寻找,或者很少寻找,如果你可以安排它,这样你的程序只需要按顺序读/写一个文件,这将是最快的.或者更好的是,切换到没有磁头的SSD,寻道时间实际上为零.:)

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

当然,OS的I/O子系统只有在事先知道I/O请求待处理的情况下才能实现此优化...如果您只有一个线程启动I/O请求,那么I/O子系统将只了解当前的要求.(即它不能"窥视"你的线程的用户空间请求队列,以查看你的线程接下来想要什么).当然,您的用户态线程不知道磁盘布局的细节,因此在用户空间中实现Elevator算法很困难(不可能?).

但是如果你的程序有N个线程一次读/写磁盘,那么操作系统的I/O子系统将立即意识到最多NI/O请求,并且可以根据需要重新排序这些请求以最大化磁盘性能.