[Interest] [Semi OT] Concurrent (multi-threaded) read/write disk IO?

Till Oliver Knoll till.oliver.knoll at gmail.com
Thu Feb 5 14:44:43 CET 2015


> Am 05.02.2015 um 14:25 schrieb Till Oliver Knoll <till.oliver.knoll at gmail.com>:
> 
> ...
> 
> Does it make sense to guarantee/enforce "sequential (exclusive) access to the harddisk" on application level, or would I re-invent functionality already present in the underlying OS/disk driver (and maybe even sacrifice performance)?

I eventually found a link which seems to confirm that it would be best to only have sequential read/write access with physically spinning drives, that is, have some kind of "IO Manager" in the application:

http://www.tomshardware.co.uk/forum/251768-32-impact-concurrent-speed

Off course the tricky part then is that the Writer thread does not block the Reader thread for too long, such that the Work Queue would become empty (and the worker threads would be sitting there "idle").

Likewise the Writer thread must have enough chances to write, such that the Result Queue becomes not too large ("memory constraints"). Probably some kind of priorisation scheme taking Queue counts into consideration is the answer - but not part of my question; I am really just interested in whether concurrent read/write access should be avoided in the first place these days (or not).

For SSDs it still might be okay (or even better?) to use concurrent read/write access?

Any other thoughts on that?

Thanks,
  Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150205/76a4377e/attachment.html>


More information about the Interest mailing list