使用多线程处理硬盘驱动器上的文件是否有用? [英] Is it useful to use multithreading to handle files on a hard drive?

问题描述

就性能和执行速度而言，使用多线程处理硬盘驱动器上的文件是否有用? (将文件从磁盘移动到另一个磁盘或检查文件的完整性)

In terms of performance and speed of execution it is useful to use multithreading to handle files on a hard drive? (to move files from a disk to another or to check integrity of files)

我认为主要取决于硬盘驱动器的速度.

I think it is mainly the speed of my HDD that will determine the speed of my treatment.

推荐答案

多线程处理至少在某些时候可以提供帮助.原因是，如果您正在写入普通"硬盘(例如非固态硬盘)，那么最让您慢下来的是硬盘的寻道时间(即所需的时间).硬盘驱动器将其读/写磁头从沿着磁盘半径的一个距离重新定位到另一个距离).与系统的其余部分相比，该运动在冰河上缓慢，并且头部寻找所需的时间与其必须行进的距离成正比.因此，例如，最坏的情况是在每次操作后磁头必须从磁盘边缘移动到磁盘中心.

Multithreading can help, at least sometimes. The reason is that if you are writing to a "normal" hard drive (e.g. not a solid state drive) then the thing that is going to slow you down the most is the hard drive's seek time (that is, the time it takes for the hard drive to reposition its read/write head from one distance along the the disk's radius to another). That movement is glacially slow compared to the rest of the system, and the time it takes for the head to seek is proportional to the distance it must travel. So for example, the worst case scenario would be if the head had to move from the edge of the disk to center of the disk after each operation.

当然，理想的解决方案是让磁盘磁头永远不寻觅，或者寻极寻觅，并且如果可以安排它，以便程序只需要顺序读取/写入单个文件，那将是最快的.或更妙的是，切换到没有磁盘头的SSD，查找时间实际上为零. :)

Of course the ideal solution is to have the disk head never seek, or seek only very rarely, and if you can arrange it so that your program only needs to read/write a single file sequentially, that will be fastest. Or better yet, switch to an SSD, where there is no disk head, and the seek time is effectively zero. :)

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

But sometimes you need your drive to be able to read/write multiple files in parallel, in which case the drive head will (of necessity) be seeking back and forth a lot. So how can multithreading help in this scenario? The answer is this: with a sufficiently smart disk I/O subsystem (e.g. SCSI, I'm not sure if IDE can do this), the I/O logic will maintain a queue of all currently outstanding read/write requests, and it will dynamically re-order that queue so that the requests are fulfilled in the order that minimizes the amount of travel by the read/write head. This is known as the Elevator Algorithm, because it is similar to the logic used by an elevator to maximize the number of people it can transport in a given period of time.

当然，如果操作系统的I/O子系统事先知道哪些I/O请求正在等待中，并且只有一个线程发起I/O请求，则该I/O才可以实现此优化.子系统只会知道当前请求. (即，它无法窥视"线程的userland请求队列，以查看线程接下来想要什么).当然，您的userland线程不知道磁盘布局的详细信息，因此很难(不可能?)在用户空间中实现Elevator Algorithm.

Of course, the OS's I/O subsystem can only implement this optimization if it knows in advance what I/O requests are pending... and if you have only one thread initiating I/O requests, then the I/O subsystem will only know about the current request. (i.e. it can't "peek" into your thread's userland request queue to see what your thread will want next). And of course your userland thread doesn't know the details of the disk layout, so it's difficult (impossible?) to implement the Elevator Algorithm in user space.

但是，如果您的程序有N个线程一次读取/写入磁盘，则OS的I/O子系统将立即知道多达NI/O个请求，并可以根据需要重新排序这些请求.最大化磁盘性能.

But if your program has N threads reading/writing the disk at once, then the OS's I/O subsystem will be aware of up to N I/O requests at once, and can re-order those requests as it sees fit to maximize disk performance.

这篇关于使用多线程处理硬盘驱动器上的文件是否有用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！