Thread Scheduling

[Nicolai Haehnle]

On Tue, Dec 14, 2010 at 3:59 PM, Milian Wolff <mail at milianw.de> wrote:
> Interesting, this is pretty much the opposite of what Qt teaches in its
> trainings. There is an example shipped with Qt that basically creates
> thumbnails for images. According to the training, it will be slower to create
> lots of threads that all thrash the IO instead of having only a few.
>
> The reasoning is this: With fewer concurrent accesses to the HDD it will spin
> less and read more. When two threads read from the same HDD but at different
> places, the kernel will deliver those requests and the HDD will read a few
> bytes here, spin, read a few bytes there, spin back and repeat...
>
> Is this not correct, or did I misunderstand something? I find it very logical.

It is very logical, but so is David's example.

At least from a CS theory point of view, the problem is that KDevelop
simply is not in a position to know what the ideal behaviour is, nor
should it have to worry about it. It highly depends on the
characteristics of the storage medium (flash vs. mechanical drive vs.
network mount). Ideally, KDevelop would simply explain to the kernel
via its APIs that it is going to read a certain list of files in their
entirety in the near future, and leave it up to the kernel to decide
how to schedule the I/O.

Unfortunately, I'm more of a theory person in that regard and am not
familiar with the APIs that are exposed on Linux in that regard.

cu,
Nicolai