Discussion :

[stardeath]

bonsoir, petite question qui me taraude l'esprit, est ce qu'on ne pourrait pas résoudre le problème du double check de (http://come-david.developpez.com/tut...page=Singleton) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
template <class T>  T* Singleton<T>::Get()
{
    if(m_i==0) //Premier check
    {
        Lock lock
        if(m_i==0) //Second
        {
            m_i=new T();
        }
    }
    return m_i;
}

avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
template <class T>  T* Singleton<T>::Get()
{
    if(m_i==0) //Premier check
    {
        Lock lock
        if(m_i==0) //Second
        {
            InterlockedExchangePointer(&m_i, new T());
        }
    }
    return m_i;
}

bien sur uniquement sous windows, mais bon je me pose la question.

[jabbounet]

dans un contexte d'application multithreadé.

Oui en revanant au cas du simple check, mais tu pose un lock pour te protéger des accès concurents à chaque fois que tu souhaite récuperer ton singleton .

La solution du double check t'évite de poser un lock une fois que tu es certain que ton singleton est crée (m_i != 0).

Verifier que m_i != 0 est beacoup moins couteux que de poser un lock systématiquement.

[Flob90]

@jabbounet: Je crois pas qu'il parle de remplacer le DCLP, mais de corriger son problème. (cf article de David)

Je ne sais pas exactement ce que fait cette méthode spécifique, mais si elle fait un echange de pointeur en situation MT alors non ce n'est pas suffisant, il me semble que le compilateur pourra toujours intervertir les opérations et donc on retrouve le problème de base.

Alexandrescu et Meyers ont écrit un article sur le sujet (il faut voir sur le site de Meyers ou Dr Dobbs), la conclusion qu'ils font est qu'il n'existe pas de solution réel au problème. Ce qui a le plus de chance de marcher est d'utiliser des objet déclaré virtual, mais ca peut toujours échouer. Et une autre solution non portable qu'il évoque et l'utilisation de Barrière Mémoire, mais il ne donne pas plus d'info là-dessus. (si la fonction que tu utilises est de ce type alors oui ca marche)

[stardeath]

oui dans un contexte multithread, c'est un oublie de ma part, et oui "corriger" le problème, enfin c'est vite dit mais bon.

alors InterlockedExchangePointer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
PVOID __cdecl InterlockedExchangePointer(
  __inout  PVOID volatile *Target,
  __in     PVOID Value
);

stocke de manière atomique le second argument dans le premier.

et puis je me suis rappelé que justement comme le reprécise Flob90, le compilateur peut changer l'ordre des instructions, voilà d'où vient cette idée.

[white_tentacle]

Le problème c'est qu'InterlockedExchangedPointer est dépendante de ton modèle mémoire, et que je ne suis pas sûr qu'elle existe partout.

Le double-checked singleton pattern marche sur certaines architectures, pas d'autres. Sur celles-ci, pas vraiment d'autre choix que de locker pour de vrai à chaque fois. Et peu de cas où ce sera vraiment un problème (si ça l'est, la fonction d'initialisation appelée au début du programme est probablement la solution à envisager).

[Flob90]

Le double-checked singleton pattern marche sur certaines architectures, pas d'autres.

De mémoire le problème incombe au compilateur pas à l'architecture en elle même, et comme le compilateur est libre de faire ce qu'il veut le problème est réel.

Sur celles-ci, pas vraiment d'autre choix que de locker pour de vrai à chaque fois.

Mieux vaut créer le singleton dans un portion mono-thread (qaund on est sur qu'il n'y aura pas d'acces simultané) du programme alors :p

Et peu de cas où ce sera vraiment un problème

En réalité ca pose problème une seul fois : lors de la création du singleton, mais ca reste un problème. (Le résultat du problème est quand même un pointeur non initialisé, ce n'est pas anodin)