Should be this:

...
private:
    // Critical section.
    static CriticalSection m_instanceCs;
...

with:

CriticalSection MyClass::m_instanceCs;

in a CPP file somewhere.

Jay

    // Nested class.
    class Locker
    {
     public:
        Locker(CriticalSection& cs) : m_cs(cs) { m_cs.Enter(); }
        ~Locker() { m_cs.Leave(); }
    private:
        CriticalSection& m_cs;
    };

private:
    CRITICAL_SECTION m_cs;

class MyClass
{
public:
    MyClass& GetInstance()
    {
        // Serialize access to the object.
        CriticalSection::Locker locker(m_instanceCs);

        // The singleton object.
        static MyClass myClass;
        return myClass;
    }

private:
    // Private constructor.
    MyClass()
    {
    // ...
    }

private:
    // Critical section.
    CriticalSection m_instanceCs;

MyClass& myClass = MyClass::GetInstance();

HTH
Jay

Singleton& Singleton::Instance()
{
  if (!pInstance)
  {
     AcquireCriticalSectionOrMutex(....)
     if (!pInstance)
    {
      pInstance=new Singleton(....)
    }
    ReleaseCriticalSectionOrMutex(....)
  }
 return *pInstance;

Also, make the pInstance variable volatile.

Arnaud
MVP - VC

for Win32/x86, I don't think there's any problem with double-checked
locking since IA32 processors provide strong cache coherency and memory
ordering guarantees.

-cd

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken

The code I posted works just fine in a multi-threaded case *except* for the
aforementioned unpredicability of global objects.

But your objection raises an interesting problem: given that any
synchronization object needs to be constructed before it's used, and given
that it can't be constructed on first use (you basically move the
non-thread-safeness to the construction of *that* object), is there a
solution that works for the random global object case? Perhaps a global
integer coupled with some Interlocked* functions, etc.? (I haven't worked
this out myself because I haven't needed to; just wondering if anyone else
had.)

Jay

Not sure I agree with the emphasized assessment above.

Global objects (AFAIK) construct on the same thread, so there are no
threading issues if this is, indeed, "the whole point". (Any threads started
by those global objects are another matter entirely.)

The cases I've run into where threading is an issue are precisely those
where the singleton is *not* constructed before main(). For example, a
common resource accessed by multiple threads that only needs to be
constructed if the threads happen to come into existence and need it.
Threads fired up all hit the resource at once.

I guess all my threads are normally created *after* I get into main/WinMain,
so I never thought about *thread-safety* issues as being a global object
issue.

Jay

class Singleton
{
private:
    static Singleton instance;
public:
    static Signleton& getInstance() {return instance;}

class Singleton
{
public:
    static Signleton& getInstance()
    {static Signleton instance; return instance;}

I know two ways around this. One is the technique used to ensure that
std::cout is available to all global objects. You put the following into
the same .h file that defines the Singleton class:

namespace
{
    struct SingletonInit
    {
        SingletonInit() {Singleton::getInstance();}
    } initSingleton;

Another way is using OS-specific atomic integer operations, just as you
noted. Luckily, a global variable of a fundamental type gets its intial
value assigned before any code whatsoever is executed, so you can rely
on it being, say, 0 when the object is not initialized. You can then use
a manually implemented spinlock for synchronization.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken