Calling my singleton causes eternal loop in _Init_thread_header

Getting Started
1

Hi there,

I’m experiencing issues with one of my singletons, which I assume is related to threads somehow (pardon my modest knowledge of C++ and multithreading).

This is what my function looks like:

SettingsManager& SettingsManager::getInstance()
{
	static SettingsManager instance;
	return instance;
}

So basically a regular singleton. Some googling says that this code since C++11 is thread-safe.

But when it is called (unlike my other singletons!) app hangs without any assertion or exception. Basic debuging shows that function _Init_thread_header located in thread_safe_statistics.cpp is looping forever waiting initialization status to change, which doesn’t happen.

This is the looping fuction:

// Control access to the initialization expression.  Only one thread may leave
// this function before the variable has completed initialization, this thread
// will perform initialization.  All other threads are blocked until the
// initialization completes or fails due to an exception.
extern "C" void __cdecl _Init_thread_header(int* const pOnce) noexcept
{
    _Init_thread_lock();

    if (*pOnce == uninitialized)
    {
        *pOnce = being_initialized;
    }
    else
    {
        while (*pOnce == being_initialized)
        {
            // Timeout can be replaced with an infinite wait when XP support is
            // removed or the XP-based condition variable is sophisticated enough
            // to guarantee all waiting threads will be woken when the variable is
            // signalled.
            _Init_thread_wait(xp_timeout);

            if (*pOnce == uninitialized)
            {
                *pOnce = being_initialized;
                _Init_thread_unlock();
                return;
            }
        }
        _Init_thread_epoch = _Init_global_epoch;
    }

    _Init_thread_unlock();
}

Any suggestions on how to overcome this? Really need my class to be a singleton and I don’t need any multithreading…

Thanks.

2

And what is the SettingsManager itself? Does it inherit or use some Juce thing that is itself or contains a singleton, or makes assumptions about something already running? (For example a common thing in the Juce classes is that the MessageManager is supposed to be already created/running.)

3

The only class it inherits from is ActionListener. It doesn’t assume anything running but does contain references to my 2 other singletons (and initializes them). And they in turn both don’t assume anything running but JUCE String, File, var and basic primitives. These 2 singletons can be called without any issues.

4

Not directly an answer, but a different approach:
a)
Have a look at the JUCE_DECLARE_SINGLETON macro.

You can declare a singleton quite simple and rely on their tested code.

or b)
Adding your settings manager as member to your Application and create a static access method:

1 Like
5

any advice is much appreciated, thanks

6

Ok, looks like I have indirectly asked for instance of this singleton in the constructor of the singleton itself.

Thanks for your advices, using JUCE_DECLARE_SINGLETON macro helped me to get a meaningful assertion.