SingletonPattern

UserPreferences

1. 개요
2. C++/싱글 스레드 버전
3. C++/다중 스레드 버전
4. 링크

1 개요

• 객체가 프로그램 내에 단 하나만 존재하는 것을 보장하기 위한 패턴
  
• 가장 널리 사용되는 패턴?
  
• 결국은 전역변수와 다를 것이 없으므로, 싱글톤의 과용은 잘못된 프로그램 디자인의 징후라고 볼 수 있다.
  
  
  

2 C++/싱글 스레드 버전

...생략...

//////////////////////////////////////////////////////////////////////////////
/// \class Singleton
/// \brief 싱글 스레드용 싱글톤 패턴 템플릿 클래스.
///
/// 어떤 클래스의 인스턴스가 하나뿐인 것을 보장하고, 그 오브젝트에 대한 
/// 전역적인 접근을 가능하게 하기 위한 Singleton 패턴을 클래스로 만들어놓았다.
/// 어떤 객체를 하나만 생성하고자 한다면, 이 클래스를 아래와 같은 방식으로
/// 상속받기 바란다.
///
/// <pre>
/// class TheOne : public Singleton<TheOne>
/// {
/// friend class Singleton; // friend 선언이 필요하다.
/// private: // 생성자 및 소멸자는 private으로 선언해야한다.
///     TheOne();
///     ~TheOne();
/// };
/// </pre>
//////////////////////////////////////////////////////////////////////////////

template <typename T>
class __declspec(noinline) Singleton
{
protected:
    Singleton() {}
    virtual ~Singleton() {}

public:
    static T* instance()
    {
        static T s_instance;
        return &s_instance;
    }

private:
    Singleton(const Singleton&) {}
    const Singleton& operator = (const Singleton&) { return *this; }
};
...생략...

3 C++/다중 스레드 버전

...생략...

//////////////////////////////////////////////////////////////////////////////
/// \class Singleton
/// \brief 싱글톤 패턴 템플릿 클래스.
///
/// 어떤 클래스의 인스턴스가 하나뿐인 것을 보장하고, 그 오브젝트에 대한 
/// 전역적인 접근을 가능하게 하기 위한 Singleton 패턴을 클래스로 만들어놓았다.
/// 어떤 객체를 하나만 생성하고자 한다면, 이 클래스를 아래와 같은 방식으로
/// 상속받기 바란다.
///
/// <pre>
/// class TheOne : public Singleton<TheOne>
/// {
/// friend class Singleton; // friend 선언이 필요하다.
/// private: // 생성자 및 소멸자는 private으로 선언해야한다.
///     TheOne();
///     ~TheOne();
/// };
/// </pre>
//////////////////////////////////////////////////////////////////////////////

template <typename TYPE> 
class Singleton
{
protected:
    /// 단 하나의 객체 포인터
    static TYPE* volatile s_pInstance;

    /// 다중 스레드 상황에서의 메모리 누수를 방지하기 위한 락
    static BasicCriticalSection s_InstanceSection; 


protected:
    /// \brief 기본 생성자는 외부 생성을 막기 위해 protected로 선언한다.
    Singleton() { atexit(clear); }

    /// \brief 소멸자도 마찬가지.
    virtual ~Singleton() {}


public:
    /// \brief 하나뿐인 객체의 포인터를 반환한다.
    /// \return TYPE* 하나뿐인 객체의 포인터
    static TYPE* instance(void)
    {
        // 이 부분에서 락을 쓰지 않게 되면, 멀티 스레드 환경에서 두 스레드가
        // 동시에 접근하게 되면 객체를 두 개 생성하게 되며 이 중 하나는
        // 버려지게 된다.
        // 이 문제를 해결하기 위해 Double-checked lock이라고 부르는 패턴을 
        // 썼는데, 이는 매번 락을 체크하는 부담을 줄이면서, 안전하게 객체를 
        // 생성할 수 있는 패턴이다.
        // 즉 s_pInstance == 0을 두 번 실행함으로서 안전한 객체의 생성이
        // 보장되는 것이다.
        //
        // *** CAUTION ***
        // 아래의 코드는 포인터 대입 연산이 Atomic Operation이라는 것을 
        // 가정하고 만든 코드다. 예를 들어 16비트 윈도우에서 32비트 포인터를
        // 다루는 것은 두 사이클에 걸쳐서 일어나기 때문에 이는 Atomic 
        // Operation이 아니다. 이런 경우 아래의 코드는 문제를 일으킬 수가 
        // 있다. 이런 경우를 피해가기 위해서는 CPU 벤더마다 다른 
        // 메모리 배리어 연산을 포인터 연산 위 아래로 집어넣어야 한다.
        if (s_pInstance == 0)
        {
            s_InstanceSection.enter();

            if (s_pInstance == 0)
            {
                s_pInstance = new TYPE;
            }

            s_InstanceSection.leave();
        }

        return s_pInstance;
    }

    /// \brief 하나뿐인 객체를 삭제한다.
    static void clear(void)
    {
        // 마찬가지로 Double-checked lock을 사용했다.
        if (s_pInstance != 0)
        {
            s_InstanceSection.enter();

            if (s_pInstance != 0)
            {
                delete s_pInstance;
                s_pInstance = 0;
            }

            s_InstanceSection.leave();
        }
    }


private:
    /// \brief 복사 생성자는 외부 생성을 막기 위해 private으로 선언한다.
    Singleton(const Singleton<TYPE>&) {}

    /// \brief 대입 연산자는 외부 생성을 막기 위해 private으로 선언한다.
    const Singleton<TYPE>& operator = (const Singleton<TYPE>&) { return *this; }
};

template <typename TYPE>
TYPE* volatile Singleton<TYPE>::s_pInstance = 0;

template <typename TYPE>
BasicCriticalSection Singleton<TYPE>::s_InstanceSection;

...생략...

class BasicCriticalSection
{
private:
    CRITICAL_SECTION m_Win32CS;

public:
    BasicCriticalSection() { ::InitializeCriticalSection(&m_Win32CS); }
    virtual ~BasicCriticalSection() { ::DeleteCriticalSection(&m_Win32CS); }

    void enter() { ::EnterCriticalSection(&m_Win32CS); }
    void leave() { ::LeaveCriticalSection(&m_Win32CS); }
    
private:
    BasicCriticalSection(const BasicCriticalSection&) {}
    const BasicCriticalSection& operator = (const BasicCriticalSection&) { return *this; }
};
...생략...

보다시피 인스턴스 자신의 삭제를 위해 atexit 함수를 이용하는데, atexit 함수를 통해 등록된 함수들은 main 함수가 반환된 다음 실행된다. 그래서 메모리 누수를 잡아주는 프로그램들에서 인스턴스에서 사용 중인 메모리를 누수된 것이라고 판단하는 경우가 많다. (사실 메모리 누수가 맞다. main 함수가 리턴되었는데도 정리되지 않은 메모리니까.)

이 문제를 해결하기 위해서는 main 함수가 반환되기 전에 atexit 함수들을 명시적으로 실행해줘야 한다. VisualCpp 2005 기준으로는 이 역할을 하는 함수가 _cexit 함수다. atexit 함수가 표준 함수니, 다른 컴파일러에도 _cexit 함수와 같은 역할을 하는 함수가 있으리라.

다만 클래스 타입의 전역 변수가 있는 경우, 소멸자가 두번 호출될 수 있다. VisualCpp 컴파일러는 이런 전역 클래스 변수 소멸자들을 atexit 함수를 통해 실행하기 때문이다. atexit 핸들러 리스트를 비워버리는 함수가 있을 법도 한데, 못 찾겠다. 어쩔 수 없이 atexit 비슷한 역할을 해주는 함수를 만들어야 한다.


// 종료 함수 타입 정의
typedef void (__cdecl *EXIT_FUNCTION)(void);

// 종료 함수 컬렉션
std::vector<EXIT_FUNCTION> g_ExitFunctions;

// 종료 함수 추가를 위한 락 (아무 락이나 사용)
cLock g_ExitFunctionLock;

// cSingleton 생성자에서 atexit 대신에 이 함수를 호출해준다.
void AddExitFunction(EXIT_FUNCTION func)
{
    g_ExitFunctionLock.Lock();
    g_ExitFunctions.push_back(func);
    g_ExitFunctionLock.Unlock();
}

// 그리고 메인 프로그램이 끝날 때쯤 아래와 같은 코드를 호출한다.
...
g_ExitFunctionLock.Lock();
for (size_t i=0; i<g_ExitFunctions.size(); ++i)
    (g_ExitFunctions[i])();
g_ExitFunctionLock.Unlock();
...

4 링크

• An Automatic Singleton Utility
  
• Double-checked locking and the Singleton pattern
  
A comprehensive look at this broken programming idiom

• see also DesignPattern
  

• CategoryDesign