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 _______________________________________________ Bug-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnustep
