Para responder sua pergunta sobre por que não é seguro para threads, não é porque a primeira chamada para instance()deve chamar o construtor Singleton s. Para ser seguro para threads, isso teria que ocorrer em uma seção crítica, mas não há exigência no padrão de que uma seção crítica seja realizada (o padrão até o momento é completamente silencioso em threads). Os compiladores geralmente implementam isso usando uma verificação e incremento simples de um boolean estático - mas não em uma seção crítica. Algo como o seguinte pseudocódigo:
static Singleton& instance()
{
static bool initialized = false;
static char s[sizeof( Singleton)];
if (!initialized) {
initialized = true;
new( &s) Singleton(); // call placement new on s to construct it
}
return (*(reinterpret_cast<Singleton*>( &s)));
}
Então, aqui está um simples Singleton seguro para threads (para Windows). Ele usa um invólucro de classe simples para o objeto CRITICAL_SECTION do Windows, para que possamos fazer com que o compilador inicialize automaticamente CRITICAL_SECTIONantes de main()ser chamado. Idealmente, seria usada uma verdadeira classe de seção crítica RAII que pode lidar com exceções que podem ocorrer quando a seção crítica é realizada, mas isso está além do escopo desta resposta.
A operação fundamental é que, quando uma instância de Singletoné solicitada, um bloqueio é realizado, o Singleton é criado, se necessário, o bloqueio é liberado e a referência do Singleton retornada.
#include <windows.h>
class CritSection : public CRITICAL_SECTION
{
public:
CritSection() {
InitializeCriticalSection( this);
}
~CritSection() {
DeleteCriticalSection( this);
}
private:
// disable copy and assignment of CritSection
CritSection( CritSection const&);
CritSection& operator=( CritSection const&);
};
class Singleton
{
public:
static Singleton& instance();
private:
// don't allow public construct/destruct
Singleton();
~Singleton();
// disable copy & assignment
Singleton( Singleton const&);
Singleton& operator=( Singleton const&);
static CritSection instance_lock;
};
CritSection Singleton::instance_lock; // definition for Singleton's lock
// it's initialized before main() is called
Singleton::Singleton()
{
}
Singleton& Singleton::instance()
{
// check to see if we need to create the Singleton
EnterCriticalSection( &instance_lock);
static Singleton s;
LeaveCriticalSection( &instance_lock);
return s;
}
Cara - isso é muita porcaria para "fazer uma melhor global".
As principais desvantagens dessa implementação (se eu não deixei passar alguns bugs) são:
- se
new Singleton()jogar, a trava não será liberada. Isso pode ser corrigido usando um objeto de bloqueio RAII verdadeiro, em vez do simples que tenho aqui. Isso também pode ajudar a tornar as coisas portáteis se você usar algo como o Boost para fornecer um invólucro independente da plataforma para o bloqueio.
- isso garante a segurança do encadeamento quando a instância Singleton é solicitada após a
main()chamada - se você a chamar antes (como na inicialização de um objeto estático), as coisas podem não funcionar porque CRITICAL_SECTIONpodem não ser inicializadas.
- um bloqueio deve ser executado toda vez que uma instância é solicitada. Como eu disse, esta é uma implementação segura de thread simples. Se você precisar de uma melhor (ou quiser saber por que coisas como a técnica de trava de verificação dupla são falhas), consulte os papéis vinculados na resposta do Groo .