iterators+multithreading on win32

[Anton Sergunov]

Actualy reading form hdd performs muliple steps by thread:
1. Send read request
2. Actual reading
3. Send data back to caller

If you use sync reader (like read(), ReadFile(...) on windows) caller
thread wait for data.
HDD gets request for reading physical blocks. Optimise request queue.
Move heads to right place. Waits while platter turns on correct angle.

So thread just waits.

If you use multiple threads it can improve performance. Hdd driver has
longer queue and it can beter optimise it.

But every thread has speed penalty. So better way is to use async
reader. CreareFileEx on windows
Single thread place all requests to driver queue. And waits while one
finished. Then performs data processing

2011/3/6 James O. <houndeyex at gmail.com>:
> Correct me if I'm wrong, but since hard drives can't read from two places at
> once are speed increases actually realized from trying to multithread reads
> with TagLib?
>
> 2011/3/5 Lukáš Lalinský <lalinsky at gmail.com>
>>
>> On Sat, Mar 5, 2011 at 6:00 PM, Stephen F. Booth <me at sbooth.org> wrote:
>> > I've also run into crashes like this in the past, when I tried to
>> > realize
>> > speed increases by parsing several files simultaneously in separate
>> > threads.
>> >  It seems that if atomic increment/decrement were added to RefCounter,
>> > as
>> > long as a single file wasn't shared across threads then STL thread
>> > safety
>> > wouldn't be an issue.  I'm not sure which statics could affect this, as
>> > I
>> > haven't looked through the code in a while.  Is thread safety (or some
>> > level
>> > of it) something planned for a future release?
>>
>> I don't think thread-safe TagLib is a particularly good idea. It would
>> cause too many speed penalties for no good reason. I definitely want
>> to be able to call different instances of TagLib classes from
>> different threads though. I believe that fixing the RefCounter should
>> be the only thing that is needed. The other static instances are
>> read-only, as far as I remember.
>>
>> Lukas
>> _______________________________________________
>> taglib-devel mailing list
>> taglib-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/taglib-devel
>
>
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel
>
>