[Libreoffice] Helgrind results for LO

[Julian Seward]

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