Fwd: Unusual behaviour of taglib using threads.

[Yogesh M]

On 01/05/07, Sergey Vlasov <vsu at altlinux.ru> wrote:
> On Tue, May 01, 2007 at 09:51:44PM +0530, Yogesh M wrote:
> > If TagLib is not threadsafe, then my application is going to have
> > *complete* design change (means hardwork of more than 1 yr becomes
> > zero).
>
> Unfortunately, TagLib does not seem to be threadsafe.  The worst
> offender is the RefCounter class, which is used as a base for other
> classes (e.g., ByteVector::ByteVectorPrivate):
>
>   class RefCounter
>   {
>   public:
>     RefCounter() : refCount(1) {}
>     void ref() { refCount++; }
>     bool deref() { return ! --refCount ; }
>     int count() { return refCount; }
>   private:
>     uint refCount;
>   };
>
> Such implementation of ref() and deref() methods may give bogus result
> if these methods are used concurrently by several threads - and this
> will happen at least with ByteVector::null.  One of your crashes is in
> ByteVector methods, another is in TagLib::String, which also uses
> RefCounter - so probably this is the real problem.
>
> There are other fishy places, but they seem to be mostly in the init
> code (however, ID3v1::genreList() and ID3v1::genreMap() try to perform
> initialization at the first call, which is not safe).  In general, any
> global or static variable may give troubles unless the access to it is
> appropriately protected.
>
>
>

I think things like RefCounter should not be of any problem because
I'm not sharing same taglib object(s) in two threads. In that sense
usage of String and ByteVector should be ok, right? What matters is
the use of static/global storage type and there seems to be a lot of
that (static stuff). (Please point out if I am wrong in understanding
working of thread, and in that case, also suggest a good book on the
topic.)

Using global mutex for wrapping access to taglib should work and will
save my app's design but that can severely impact its performance.

Is anyone able to reproduce the error?

I'm still trying hard to pin-point the code responsible for this.

Thanks
-- 
Yogesh M
Chandigarh, India
http://mr-yogi.blogspot.com/