[prev in list] [next in list] [prev in thread] [next in thread]
List: taglib-devel
Subject: Re: iterators+multithreading on win32
From: "Stephen F. Booth" <me () sbooth ! org>
Date: 2011-03-05 18:40:10
Message-ID: AANLkTimh7KA8fTOrcs-+X8YYu0vSLcbdJ956iPxFZSzx () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
If a user's music is stored all on one drive, then you're probably right,
speed likely wouldn't change. But with the prevalence of NAS and RAID and
cheap storage in general I don't know if assuming everything is all on one
disk is a valid assumption. Personally, I have most of my music on an
external drive, some on NAS, and some on the machine's local disk. So in m=
y
case there would be a speedup.
Stephen
On Sat, Mar 5, 2011 at 10:21 AM, James O. <houndeyex@gmail.com> wrote:
> 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=C3=A1=C5=A1 Lalinsk=C3=BD <lalinsky@gmail.com>
>
>> On Sat, Mar 5, 2011 at 6:00 PM, Stephen F. Booth <me@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, a=
s
>> 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@kde.org
>> https://mail.kde.org/mailman/listinfo/taglib-devel
>>
>
>
> _______________________________________________
> taglib-devel mailing list
> taglib-devel@kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel
>
>
[Attachment #5 (text/html)]
If a user's music is stored all on one drive, then you're probably right, \
speed likely wouldn't change. But with the prevalence of NAS and RAID and cheap \
storage in general I don't know if assuming everything is all on one disk is a \
valid assumption. Personally, I have most of my music on an external drive, some on \
NAS, and some on the machine's local disk. So in my case there would be a \
speedup.<div> <br></div><div>Stephen<br><br><div class="gmail_quote">On Sat, Mar 5, \
2011 at 10:21 AM, James O. <span dir="ltr"><<a \
href="mailto:houndeyex@gmail.com">houndeyex@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> 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?<br><br><div class="gmail_quote"><div \
class="im"> 2011/3/5 Lukáš Lalinský <span dir="ltr"><<a \
href="mailto:lalinsky@gmail.com" \
target="_blank">lalinsky@gmail.com</a>></span><br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px \
solid rgb(204, 204, 204);padding-left:1ex"><div>On Sat, Mar 5, 2011 at 6:00 PM, \
Stephen F. Booth <<a href="mailto:me@sbooth.org" \
target="_blank">me@sbooth.org</a>> wrote:<div> <div></div><div class="h5"><br>
> I've also run into crashes like this in the past, when I tried to \
realize<br> > speed increases by parsing several files simultaneously in separate \
threads.<br> > It seems that if atomic increment/decrement were added to \
RefCounter, as<br> > long as a single file wasn't shared across threads then \
STL thread safety<br> > wouldn't be an issue. I'm not sure which statics \
could affect this, as I<br> > haven't looked through the code in a while. Is \
thread safety (or some level<br> > of it) something planned for a future \
release?<br> <br>
</div></div></div><div><div></div><div class="h5">I don't think thread-safe \
TagLib is a particularly good idea. It would<br> cause too many speed penalties for \
no good reason. I definitely want<br> to be able to call different instances of \
TagLib classes from<br> different threads though. I believe that fixing the \
RefCounter should<br> be the only thing that is needed. The other static instances \
are<br> read-only, as far as I remember.<br>
<div><div></div><div><br>
Lukas<br>
_______________________________________________<br>
taglib-devel mailing list<br>
<a href="mailto:taglib-devel@kde.org" target="_blank">taglib-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/taglib-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/taglib-devel</a><br> \
</div></div></div></div></blockquote></div><br> \
<br>_______________________________________________<br> taglib-devel mailing list<br>
<a href="mailto:taglib-devel@kde.org">taglib-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/taglib-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/taglib-devel</a><br> \
<br></blockquote></div><br></div>
_______________________________________________
taglib-devel mailing list
taglib-devel@kde.org
https://mail.kde.org/mailman/listinfo/taglib-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic