Для меня лучший способ реализовать синглтон с помощью C++ 11 является:
class Singleton
{
public:
static Singleton & Instance()
{
// Since it's a static variable, if the class has already been created,
// It won't be created again.
// And it **is** thread-safe in C++11.
static Singleton myInstance;
// Return a reference to our instance.
return myInstance;
}
// delete copy and move constructors and assign operators
Singleton(Singleton const&) = delete; // Copy construct
Singleton(Singleton&&) = delete; // Move construct
Singleton& operator=(Singleton const&) = delete; // Copy assign
Singleton& operator=(Singleton &&) = delete; // Move assign
// Any other public methods
protected:
Singleton()
{
// Constructor code goes here.
}
~Singleton()
{
// Destructor code goes here.
}
// And any other protected methods.
}
Это C++ 11 функции, но с этим, как вы можете создать потокобезопасные Singleton. Согласно новому стандарту, больше не нужно заботиться об этой проблеме. Инициализация объекта будет выполняться только одним потоком, другие потоки будут ждать завершения. Или вы можете использовать std :: call_once.
Если вы хотите сделать эксклюзивный доступ к ресурсам синглтона, вам необходимо использовать блокировку для этих функций.
Различный тип замков:
Использование atomic_flg_lck:
class SLock
{
public:
void lock()
{
while (lck.test_and_set(std::memory_order_acquire));
}
void unlock()
{
lck.clear(std::memory_order_release);
}
SLock(){
//lck = ATOMIC_FLAG_INIT;
lck.clear();
}
private:
std::atomic_flag lck;// = ATOMIC_FLAG_INIT;
};
Использование атомарным
class SLock
{
public:
void lock()
{
while (lck.exchange(true));
}
void unlock()
{
lck = true;
}
SLock(){
//lck = ATOMIC_FLAG_INIT;
lck = false;
}
private:
std::atomic<bool> lck;
};
Использование семафор:
class SLock
{
public:
void lock()
{
lck.lock();
}
void unlock()
{
lck.unlock();
}
private:
std::mutex lck;
};
Только для Окно:
class SLock
{
public:
void lock()
{
EnterCriticalSection(&g_crit_sec);
}
void unlock()
{
LeaveCriticalSection(&g_crit_sec);
}
SLock(){
InitializeCriticalSectionAndSpinCount(&g_crit_sec, 0x80000400);
}
private:
CRITICAL_SECTION g_crit_sec;
};
атомного и и atomic_flg_lck держать нить в счете спины. Mutex просто спит нить. Если время ожидания слишком длинное, возможно, лучше спать поток.Последний «CRITICAL_SECTION» удерживает поток в расчете количества спинов до тех пор, пока не будет потреблено время, затем нить переходит в режим сна.
Как использовать эти критические разделы?
unique_ptr<SLock> raiilock(new SLock());
class Smartlock{
public:
Smartlock(){ raiilock->lock(); }
~Smartlock(){ raiilock->unlock(); }
};
Использование идиомы raii. Конструктор блокирует критический раздел и деструктор, чтобы разблокировать его.
Пример
class Singleton {
void syncronithedFunction(){
Smartlock lock;
//.....
}
}
Этой реализация является безопасной нитью и исключения безопасна, так как переменная блокировки сохраняется в стеке так, когда область видимости функции закончилась (конец функции или исключения) деструктор будет называться.
Я надеюсь, что вы найдете это полезным.
Спасибо!
Я не видел ничего, чтобы предположить, что одноэлементный шаблон выпал из употребления у практических практиков. (Конечно, он никогда не использовался широко среди них. Только тогда, когда это необходимо, что не так часто.) –
Я видел много «Синглтона», но ни один из них не нужен. Просто сделайте это и передайте его. –
Грубо говоря: «Singleton» - это, как правило, ошибка дизайна. Хотя ... Я согласен, что это удобно для схем регистрации (гораздо больше, чем передача объекта Logger в каждой отдельной функции). –