On Thursday, March 31, 2011, Caolán McNamara wrote: > The first one at least seems to be the common enough pattern we have > where we grab our global mutex when initializing singletons on first > use/creation e.g. > > const Class& foo() > { > static Class aFoo; > if (aFoo.uninit) //need to init this > { > //grab mutex > MutexGuard guard(Mutex::getGlobalMutex()); > //make sure some other thread didn't already do it > //while waiting to get mutex > if (aFoo.uninit) > aFoo.init; > } > return aFoo; > } > > so we have loads of warnings along the lines of "the last time you > accessed that singleton you took a mutex, but this time you didn't!"
/me slightly confused: IIUC you're referring to the fact that accesses to aFoo.uninit aren't consistently protected by a lock. But it's not complaining about that -- it's complaining about a bunch of lock acquisition ordering inconsistencies. (In parentheses, the above fragment is the double-checked locking idiom, which is considered unfixably broken, especially on non-x86 multiprocessors. But that's another story: www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) > I guess we might need to sprinkle that > VALGRIND_HELGRIND_DISABLE_CHECKING(&pInstance, sizeof pInstance); That stops it complaining about races, but not about lock order problems. J _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice