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)

[white_tentacle]

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)

Je parlais du problème de perf induit par le lock à chaque accès, qui n'en est que très rarement un . Le fait que le programme puisse planter, même si c'est rarissime, n'est pas un problème que je considère négligeable.

[Flob90]

Je parlais du problème de perf induit par le lock à chaque accès, qui n'en est que très rarement un

J'avais compris à l'envers

Je croyais que le lock systématique réduisait vraiment les perf, ce n'est pas le cas ? Tu as un bench sur les pref des mutexes ? J'était persuadé que c'était une opération couteuse

[jabbounet]

J'avais compris à l'envers

Je croyais que le lock systématique réduisait vraiment les perf, ce n'est pas le cas ? Tu as un bench sur les pref des mutexes ? J'était persuadé que c'était une opération couteuse

Tout dépend des accès que tu fait sur le lock et la section critique associé en fait.

En gros plus le lock est sollicité et plus la section critique est longue a s'executer plus les perf vont réduire (logique). si cela deviens problématique pour les perfs de ton application un redesign de cette partie peu etre à envisager.

Maintenant si ton lock/ta section critique est accédé un fois par heure par 4 threads et que le temps moyen d'execution de ta section critique est de 10 ms aucune chance que tu ai des problèmes de perf de ce coté là.

[Flob90]

Pour la longueur de la section critique qui réduit les perf ca me parait assez logique. C'est le lock (disons d'un mutexe classique) en lui même que je croyait non performant.

C'est d'ailleurs la raison invoqué (l'inneficasité des lock) par Alexandrescu dans MC++D pour ne pas utiliser un Lock simple mais le DCLP.

[Luc Hermitte]

L'autre jour, je suis tombé sur ces infos relativement aux singletons en situation MT.
J'avoue avoir été surpris par diverses choses (que je n'ai pas encore pris le temps de contrôler)

[Flob90]

Je suis pas certain d'avoir tout compris. Mais l'existence de fonction Compare en Swap atomique à l'air d'être vraiment une solution interresente à voir si il ne reste aucun autre problème.

[jabbounet]

Je suis pas certain d'avoir tout compris. Mais l'existence de fonction Compare en Swap atomique à l'air d'être vraiment une solution interresente à voir si il ne reste aucun autre problème.

oui CAS est interessant surtout pour les structure lockfree, mais je ne l'ai pas encore rencontré dans la pratique.