Re: Another multithreading bug (I think)

[David Ayers]

Richard Frith-Macdonald schrieb:

> Can you see any problems with this?
> I don't think -retain needs to lock the gate, and as long as we are 
> only locking in the -release method as above, I think we can avoid 
> using a recursive lock (as I don't think we call -release inside any 
> region where we already lock the gate), but I may have missed something.

This is just tangential, but I just want to make everyone aware of the
fact that stores may not be atomic.  I'm not certain how relevant that
is for pointers/integers on IA-32 SMP platforms but for AMD64/EMT64/IA64
SMP this may become a serious issue.

This little detail is what makes the usage of the double checked locking
idiom an issue for us also:

http://en.wikipedia.org/wiki/Double-checked_locking
(The issue is described in Java but is valid for plain C just as well.)

Note that the article implies that some C++ compilers make volatile
read/stores atomic operations, but I'm certain that's not the case for
GCC (at least not for current versions).  Effectively, I believe,
volatile only means that the memory won't be cached in registers.

http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Volatiles.html#Volatiles

I understand that sacrificing double checked locking could have a harsh
performance impact, but I don't have any numbers.  Personally I would
rather sacrifice performance for correctness but I could live with a
compile time option if numbers show that the cost is very high.

Since I currently don't have the time to deal with this, I can only
offer writing up a bug report.  It would be great if someone had the
time to investigate how others have implemented test cases for
multi-threaded issues and put a pointer on the wiki.

Cheers,
David