#48 RefImplementation is NOT thread-safe!
Hi,
I've discovered a really serious multithreading bug. This bug can lead to a crash - and quite often on certain systems (either OS or processor dependent, I don't know).
The class RefImplementation (in audiere.h) which is used for reference counting is not thread safe! The operations in ref and unref (++m_ref_count and --m_ref_count) are NOT atomic operations. Therefor the code sequence in unref():
if (--m_ref_count == 0)
delete this;
can lead to a crash because it can happen that delete is called twice. Example: --m_ref_count (e.g. initially at 2) first decrements the value (to 1) and then returns the current value. Between these two steps another thread could have called unref(), decremented the value to 0 and deleted the object. Then the other thread proceeds and also wants to delete the object because the current value of the ref count is now 0 -> crash.
Solution:
m_ref_count must be an atomic counter instead of a plain int. You can implement the atomic counter (new class) either with help of InterlockedIncrement/InterlockedDecrement (Win32) or a mutex. e.g.
int AtomicCounter::inc() {
int counter;
m_mutex.lock();
m_counter++;
counter = m_counter;
m_mutex.unlock();
return counter;
}
or
int AtomicCounter::inc() {
return InterlockedIncrement(counter);
}
I'm leaving out the other details of AtomicCounter right now (this is quite simple anyway).
If someone is interested and would give me cvs/svn access I could also commit the bugfix. Or leave a comment if you need help.
Alex
Logged In: YES
user_id=7212
Originator: NO
I think this is fixed in the latest code in Subversion.
Logged In: YES
user_id=1807898
Originator: NO
Hi!
Just a question. I have 2 PCs, one of then has a mono processor, and audiere works fine in that computer.
However, in my other PC, a quad core, sometimes audiere crash (no more info).
Is my problem due to this bug?
Thank you very much for your help.