Re: [Libreoffice] Helgrind results for LO

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