On Wed, Oct 26, 2016 at 2:57 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > In Windows it is not possible to have a static initialized mutex as of > now, but that seems to be painful for the upcoming refactoring of the > attribute subsystem, as we have no good place to put the initialization > of the attr global lock. > > The trick is to get a named mutex as CreateMutex[1] will return the > existing named mutex if it exists in a thread safe way, or return > a newly created mutex with that name. > > Inside the critical section of the single named mutex, we need to double > check if the mutex was already initialized because the outer check is > not sufficient. > (e.g. 2 threads enter the first condition `(!a)` at the same time, but > only one of them will acquire the named mutex first and proceeds to > initialize the given mutex a. The second thread shall not re-initialize > the given mutex `a`, which is why we have the inner condition on `(!a)`. > > Due to the use of memory barriers inside the critical section the mutex > `a` gets updated to other threads, such that any further invocation > will skip the initialization check code altogether on the first condition. > > [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682411(v=vs.85).aspx > > Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx> > --- > > Flying blind here, i.e. not compiled, not tested. For a system I do not > have deep knowledge of. The only help was the online documentation. This is of course a Double Check Locking Pattern, that Johannes warned about a couple of days ago. However according to https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html we can make it work by adding enough memory barriers, (See section "Making it work with explicit memory barriers").