wrote:Jean-Marc Bourguet wrote:Laurent Deniau writes:Jean-Marc Bourguet wrote:Laurent Deniau writes:Si c'est ce que tu cherches, je ne vois pas l'interet du test avec NULL
La possibilite d'utiliser le singleton dans
l'initialisation de variables statiques (donc a un moment
ou ourInstance n'a potentiellement pas encore ete
initialisee).
Ok. On peut reformuler:
class Singleton
{
public:
static Singleton& instance() ;
private:
Singleton() {}
} ;
Singleton& Singleton::instance()
{
static Singleton& myInstance = *new Singleton;
return myInstance;
}
C'est ce que j'utilise (presque, je n'aime pas l'utilisation
de la reference, j'utilise donc un pointeur) J'utilise meme
Singleton& Singleton::instance()
{
static Singleton myInstance;
return myInstance;
}
quand je n'ai pas a choisir une classe derivee. Je ne sais pas
pourquoi James fait autre chose.
Deux raisons. La raison pour le new est simple : je peux aussi
utiliser le singleton dans des destructeurs des statiques, sans
risque qu'il soit déjà detruit. La raison pour l'initialisation
explicite en dehors de la fonction, c'est simplement pour
assurer que instance est appelé au moins une fois pendant les
initialisations static, avant le démarrage des threads. Et que
donc, il n'a pas besoin de lock. J'aurais pu utiliser n'importe
quelle variable statique, mais je le trouve assez succinct (mais
peut-être pas trop lisible) d'utiliser précisement le pointeur
d'instance du singleton.
Mais est-ce que:
class Singleton
{
public:
static Singleton& instance() ;
private:
Singleton() {}
static Singleton myInstance;
} ;
Singleton Singleton::myInstance;
Singleton& Singleton::instance() { return myInstance; }
ne rempli pas le cahier des charges?
kanze@gabi-soft.fr wrote:
Jean-Marc Bourguet wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Jean-Marc Bourguet wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Si c'est ce que tu cherches, je ne vois pas l'interet du test avec NULL
La possibilite d'utiliser le singleton dans
l'initialisation de variables statiques (donc a un moment
ou ourInstance n'a potentiellement pas encore ete
initialisee).
Ok. On peut reformuler:
class Singleton
{
public:
static Singleton& instance() ;
private:
Singleton() {}
} ;
Singleton& Singleton::instance()
{
static Singleton& myInstance = *new Singleton;
return myInstance;
}
C'est ce que j'utilise (presque, je n'aime pas l'utilisation
de la reference, j'utilise donc un pointeur) J'utilise meme
Singleton& Singleton::instance()
{
static Singleton myInstance;
return myInstance;
}
quand je n'ai pas a choisir une classe derivee. Je ne sais pas
pourquoi James fait autre chose.
Deux raisons. La raison pour le new est simple : je peux aussi
utiliser le singleton dans des destructeurs des statiques, sans
risque qu'il soit déjà detruit. La raison pour l'initialisation
explicite en dehors de la fonction, c'est simplement pour
assurer que instance est appelé au moins une fois pendant les
initialisations static, avant le démarrage des threads. Et que
donc, il n'a pas besoin de lock. J'aurais pu utiliser n'importe
quelle variable statique, mais je le trouve assez succinct (mais
peut-être pas trop lisible) d'utiliser précisement le pointeur
d'instance du singleton.
Mais est-ce que:
class Singleton
{
public:
static Singleton& instance() ;
private:
Singleton() {}
static Singleton myInstance;
} ;
Singleton Singleton::myInstance;
Singleton& Singleton::instance() { return myInstance; }
ne rempli pas le cahier des charges?
wrote:Jean-Marc Bourguet wrote:Laurent Deniau writes:Jean-Marc Bourguet wrote:Laurent Deniau writes:Si c'est ce que tu cherches, je ne vois pas l'interet du test avec NULL
La possibilite d'utiliser le singleton dans
l'initialisation de variables statiques (donc a un moment
ou ourInstance n'a potentiellement pas encore ete
initialisee).
Ok. On peut reformuler:
class Singleton
{
public:
static Singleton& instance() ;
private:
Singleton() {}
} ;
Singleton& Singleton::instance()
{
static Singleton& myInstance = *new Singleton;
return myInstance;
}
C'est ce que j'utilise (presque, je n'aime pas l'utilisation
de la reference, j'utilise donc un pointeur) J'utilise meme
Singleton& Singleton::instance()
{
static Singleton myInstance;
return myInstance;
}
quand je n'ai pas a choisir une classe derivee. Je ne sais pas
pourquoi James fait autre chose.
Deux raisons. La raison pour le new est simple : je peux aussi
utiliser le singleton dans des destructeurs des statiques, sans
risque qu'il soit déjà detruit. La raison pour l'initialisation
explicite en dehors de la fonction, c'est simplement pour
assurer que instance est appelé au moins une fois pendant les
initialisations static, avant le démarrage des threads. Et que
donc, il n'a pas besoin de lock. J'aurais pu utiliser n'importe
quelle variable statique, mais je le trouve assez succinct (mais
peut-être pas trop lisible) d'utiliser précisement le pointeur
d'instance du singleton.
Mais est-ce que:
class Singleton
{
public:
static Singleton& instance() ;
private:
Singleton() {}
static Singleton myInstance;
} ;
Singleton Singleton::myInstance;
Singleton& Singleton::instance() { return myInstance; }
ne rempli pas le cahier des charges?
Le DCLP ne marche à priori que sur des processeurs ayant une
cohérence forte de cache (X86...). Si tu veux être générique
et portable, utilises un lock pour chaque appel à
"GetInstance".
Le DCLP ne marche a priori pas. Un point, c'est tout. Tel qu'il
est implémenté dans ACE, il ne marche même pas sur le 80x86 le
plus primitif, avec un seul processeur. S'il donne l'air de
marcher, parfois, c'est parce que le compilateur n'optimise pas.
Le DCLP ne marche à priori que sur des processeurs ayant une
cohérence forte de cache (X86...). Si tu veux être générique
et portable, utilises un lock pour chaque appel à
"GetInstance".
Le DCLP ne marche a priori pas. Un point, c'est tout. Tel qu'il
est implémenté dans ACE, il ne marche même pas sur le 80x86 le
plus primitif, avec un seul processeur. S'il donne l'air de
marcher, parfois, c'est parce que le compilateur n'optimise pas.
Le DCLP ne marche à priori que sur des processeurs ayant une
cohérence forte de cache (X86...). Si tu veux être générique
et portable, utilises un lock pour chaque appel à
"GetInstance".
Le DCLP ne marche a priori pas. Un point, c'est tout. Tel qu'il
est implémenté dans ACE, il ne marche même pas sur le 80x86 le
plus primitif, avec un seul processeur. S'il donne l'air de
marcher, parfois, c'est parce que le compilateur n'optimise pas.
Ok, alors soyons plus précis : Si les processeurs ont une force cohérence de
cache et si je mets le code d'initialisation dans une autre unité de
translation que le code du singleton (l'initialisation se fait par un appel
de fonction - et je considère que le compilateur ne fait pas d'optimisation
globale, ou alors je l'interdis), est-e qu'il y a quelque chose qui te
chagrine avec le DCLP?
Ok, alors soyons plus précis : Si les processeurs ont une force cohérence de
cache et si je mets le code d'initialisation dans une autre unité de
translation que le code du singleton (l'initialisation se fait par un appel
de fonction - et je considère que le compilateur ne fait pas d'optimisation
globale, ou alors je l'interdis), est-e qu'il y a quelque chose qui te
chagrine avec le DCLP?
Ok, alors soyons plus précis : Si les processeurs ont une force cohérence de
cache et si je mets le code d'initialisation dans une autre unité de
translation que le code du singleton (l'initialisation se fait par un appel
de fonction - et je considère que le compilateur ne fait pas d'optimisation
globale, ou alors je l'interdis), est-e qu'il y a quelque chose qui te
chagrine avec le DCLP?
Arnaud Debaene wrote:Ok, alors soyons plus précis : Si les processeurs ont une force
cohérence de cache et si je mets le code d'initialisation dans une
autre unité de translation que le code du singleton
(l'initialisation se fait par un appel de fonction - et je considère
que le compilateur ne fait pas d'optimisation globale, ou alors je
l'interdis), est-e qu'il y a quelque chose qui te chagrine avec le
DCLP?
Par curiosité, qu'est-ce tu veux dire précisément par "les processeurs
ont une forte cohérence de cache" ?
Un système où, lorsqu'un processeur effectue une opération d'écriture, une
Tu as un exemple de ce genre
d'architecture dans la vie courante ?
Les 80X86 jusqu'à présent.
Arnaud Debaene wrote:
Ok, alors soyons plus précis : Si les processeurs ont une force
cohérence de cache et si je mets le code d'initialisation dans une
autre unité de translation que le code du singleton
(l'initialisation se fait par un appel de fonction - et je considère
que le compilateur ne fait pas d'optimisation globale, ou alors je
l'interdis), est-e qu'il y a quelque chose qui te chagrine avec le
DCLP?
Par curiosité, qu'est-ce tu veux dire précisément par "les processeurs
ont une forte cohérence de cache" ?
Un système où, lorsqu'un processeur effectue une opération d'écriture, une
Tu as un exemple de ce genre
d'architecture dans la vie courante ?
Les 80X86 jusqu'à présent.
Arnaud Debaene wrote:Ok, alors soyons plus précis : Si les processeurs ont une force
cohérence de cache et si je mets le code d'initialisation dans une
autre unité de translation que le code du singleton
(l'initialisation se fait par un appel de fonction - et je considère
que le compilateur ne fait pas d'optimisation globale, ou alors je
l'interdis), est-e qu'il y a quelque chose qui te chagrine avec le
DCLP?
Par curiosité, qu'est-ce tu veux dire précisément par "les processeurs
ont une forte cohérence de cache" ?
Un système où, lorsqu'un processeur effectue une opération d'écriture, une
Tu as un exemple de ce genre
d'architecture dans la vie courante ?
Les 80X86 jusqu'à présent.
Patrick Mézard wrote:Arnaud Debaene wrote:Ok, alors soyons plus précis : Si les processeurs ont une force
cohérence de cache et si je mets le code d'initialisation dans une
autre unité de translation que le code du singleton
(l'initialisation se fait par un appel de fonction - et je considère
que le compilateur ne fait pas d'optimisation globale, ou alors je
l'interdis), est-e qu'il y a quelque chose qui te chagrine avec le
DCLP?
Par curiosité, qu'est-ce tu veux dire précisément par "les processeurs
ont une forte cohérence de cache" ?
Un système où, lorsqu'un processeur effectue une opération d'écriture, une
interruption prioritaire interrompts immédiatement tous les autres
processeurs pour qu'ils marquent l'adresse correspondante comme "dirty" dans
leur cache local, et évitent donc de lire une version "ancienne" cachée
localement de la valeur.Un mécanisme similaire a lieu également lors de la
lecture d'une variable.
Ce système simplifie la programmation multi-tâches car il n'y a pas besoin
de "barrière" applicative pour mettre à jour les caches des processeurs,
mais elle est très mauvaise en terme de "scalability" (traduction
française????) car, avec beaucoup de processeurs, elle entraine une trafic
pas possible entre processeurs (souvent sur un bus dédié à ces mises-à-jour
de cache) et un taux très important d'interruptions. La tendance actuelle
est de laisser tomber ce système à cause de ces limitations.Tu as un exemple de ce genre
d'architecture dans la vie courante ?
Les 80X86 jusqu'à présent.
Patrick Mézard wrote:
Arnaud Debaene wrote:
Ok, alors soyons plus précis : Si les processeurs ont une force
cohérence de cache et si je mets le code d'initialisation dans une
autre unité de translation que le code du singleton
(l'initialisation se fait par un appel de fonction - et je considère
que le compilateur ne fait pas d'optimisation globale, ou alors je
l'interdis), est-e qu'il y a quelque chose qui te chagrine avec le
DCLP?
Par curiosité, qu'est-ce tu veux dire précisément par "les processeurs
ont une forte cohérence de cache" ?
Un système où, lorsqu'un processeur effectue une opération d'écriture, une
interruption prioritaire interrompts immédiatement tous les autres
processeurs pour qu'ils marquent l'adresse correspondante comme "dirty" dans
leur cache local, et évitent donc de lire une version "ancienne" cachée
localement de la valeur.Un mécanisme similaire a lieu également lors de la
lecture d'une variable.
Ce système simplifie la programmation multi-tâches car il n'y a pas besoin
de "barrière" applicative pour mettre à jour les caches des processeurs,
mais elle est très mauvaise en terme de "scalability" (traduction
française????) car, avec beaucoup de processeurs, elle entraine une trafic
pas possible entre processeurs (souvent sur un bus dédié à ces mises-à-jour
de cache) et un taux très important d'interruptions. La tendance actuelle
est de laisser tomber ce système à cause de ces limitations.
Tu as un exemple de ce genre
d'architecture dans la vie courante ?
Les 80X86 jusqu'à présent.
Patrick Mézard wrote:Arnaud Debaene wrote:Ok, alors soyons plus précis : Si les processeurs ont une force
cohérence de cache et si je mets le code d'initialisation dans une
autre unité de translation que le code du singleton
(l'initialisation se fait par un appel de fonction - et je considère
que le compilateur ne fait pas d'optimisation globale, ou alors je
l'interdis), est-e qu'il y a quelque chose qui te chagrine avec le
DCLP?
Par curiosité, qu'est-ce tu veux dire précisément par "les processeurs
ont une forte cohérence de cache" ?
Un système où, lorsqu'un processeur effectue une opération d'écriture, une
interruption prioritaire interrompts immédiatement tous les autres
processeurs pour qu'ils marquent l'adresse correspondante comme "dirty" dans
leur cache local, et évitent donc de lire une version "ancienne" cachée
localement de la valeur.Un mécanisme similaire a lieu également lors de la
lecture d'une variable.
Ce système simplifie la programmation multi-tâches car il n'y a pas besoin
de "barrière" applicative pour mettre à jour les caches des processeurs,
mais elle est très mauvaise en terme de "scalability" (traduction
française????) car, avec beaucoup de processeurs, elle entraine une trafic
pas possible entre processeurs (souvent sur un bus dédié à ces mises-à-jour
de cache) et un taux très important d'interruptions. La tendance actuelle
est de laisser tomber ce système à cause de ces limitations.Tu as un exemple de ce genre
d'architecture dans la vie courante ?
Les 80X86 jusqu'à présent.
wrote:Jean-Marc Bourguet wrote:C'est ce que j'utilise (presque, je n'aime pas l'utilisation
de la reference, j'utilise donc un pointeur) J'utilise meme
Singleton& Singleton::instance()
{
static Singleton myInstance;
return myInstance;
}
quand je n'ai pas a choisir une classe derivee. Je ne sais
pas pourquoi James fait autre chose.
Deux raisons. La raison pour le new est simple : je peux
aussi utiliser le singleton dans des destructeurs des
statiques, sans risque qu'il soit déjà detruit. La raison
pour l'initialisation explicite en dehors de la fonction,
c'est simplement pour assurer que instance est appelé au
moins une fois pendant les initialisations static, avant le
démarrage des threads. Et que donc, il n'a pas besoin de
lock. J'aurais pu utiliser n'importe quelle variable
statique, mais je le trouve assez succinct (mais peut-être
pas trop lisible) d'utiliser précisement le pointeur
d'instance du singleton.
Mais est-ce que:
class Singleton
{
public:
static Singleton& instance() ;
private:
Singleton() {}
static Singleton myInstance;
} ;
Singleton Singleton::myInstance;
Singleton& Singleton::instance() { return myInstance; }
ne rempli pas le cahier des charges?
kanze@gabi-soft.fr wrote:
Jean-Marc Bourguet wrote:
C'est ce que j'utilise (presque, je n'aime pas l'utilisation
de la reference, j'utilise donc un pointeur) J'utilise meme
Singleton& Singleton::instance()
{
static Singleton myInstance;
return myInstance;
}
quand je n'ai pas a choisir une classe derivee. Je ne sais
pas pourquoi James fait autre chose.
Deux raisons. La raison pour le new est simple : je peux
aussi utiliser le singleton dans des destructeurs des
statiques, sans risque qu'il soit déjà detruit. La raison
pour l'initialisation explicite en dehors de la fonction,
c'est simplement pour assurer que instance est appelé au
moins une fois pendant les initialisations static, avant le
démarrage des threads. Et que donc, il n'a pas besoin de
lock. J'aurais pu utiliser n'importe quelle variable
statique, mais je le trouve assez succinct (mais peut-être
pas trop lisible) d'utiliser précisement le pointeur
d'instance du singleton.
Mais est-ce que:
class Singleton
{
public:
static Singleton& instance() ;
private:
Singleton() {}
static Singleton myInstance;
} ;
Singleton Singleton::myInstance;
Singleton& Singleton::instance() { return myInstance; }
ne rempli pas le cahier des charges?
wrote:Jean-Marc Bourguet wrote:C'est ce que j'utilise (presque, je n'aime pas l'utilisation
de la reference, j'utilise donc un pointeur) J'utilise meme
Singleton& Singleton::instance()
{
static Singleton myInstance;
return myInstance;
}
quand je n'ai pas a choisir une classe derivee. Je ne sais
pas pourquoi James fait autre chose.
Deux raisons. La raison pour le new est simple : je peux
aussi utiliser le singleton dans des destructeurs des
statiques, sans risque qu'il soit déjà detruit. La raison
pour l'initialisation explicite en dehors de la fonction,
c'est simplement pour assurer que instance est appelé au
moins une fois pendant les initialisations static, avant le
démarrage des threads. Et que donc, il n'a pas besoin de
lock. J'aurais pu utiliser n'importe quelle variable
statique, mais je le trouve assez succinct (mais peut-être
pas trop lisible) d'utiliser précisement le pointeur
d'instance du singleton.
Mais est-ce que:
class Singleton
{
public:
static Singleton& instance() ;
private:
Singleton() {}
static Singleton myInstance;
} ;
Singleton Singleton::myInstance;
Singleton& Singleton::instance() { return myInstance; }
ne rempli pas le cahier des charges?
wrote:Le DCLP ne marche à priori que sur des processeurs ayant
une cohérence forte de cache (X86...). Si tu veux être
générique et portable, utilises un lock pour chaque appel à
"GetInstance".
Le DCLP ne marche a priori pas. Un point, c'est tout. Tel
qu'il est implémenté dans ACE, il ne marche même pas sur le
80x86 le plus primitif, avec un seul processeur. S'il donne
l'air de marcher, parfois, c'est parce que le compilateur
n'optimise pas.
Ok, alors soyons plus précis : Si les processeurs ont une
force cohérence de cache et si je mets le code
d'initialisation dans une autre unité de translation que le
code du singleton (l'initialisation se fait par un appel de
fonction - et je considère que le compilateur ne fait pas
d'optimisation globale, ou alors je l'interdis), est-e qu'il y
a quelque chose qui te chagrine avec le DCLP?
Et si tu peux nous donner un exemple (ou un lien) sur un
problème possible avec un *monoprocesseur* (quel qu'il soit),
je suis preneur parce que là je ne vois vraiement pas!
kanze@gabi-soft.fr wrote:
Le DCLP ne marche à priori que sur des processeurs ayant
une cohérence forte de cache (X86...). Si tu veux être
générique et portable, utilises un lock pour chaque appel à
"GetInstance".
Le DCLP ne marche a priori pas. Un point, c'est tout. Tel
qu'il est implémenté dans ACE, il ne marche même pas sur le
80x86 le plus primitif, avec un seul processeur. S'il donne
l'air de marcher, parfois, c'est parce que le compilateur
n'optimise pas.
Ok, alors soyons plus précis : Si les processeurs ont une
force cohérence de cache et si je mets le code
d'initialisation dans une autre unité de translation que le
code du singleton (l'initialisation se fait par un appel de
fonction - et je considère que le compilateur ne fait pas
d'optimisation globale, ou alors je l'interdis), est-e qu'il y
a quelque chose qui te chagrine avec le DCLP?
Et si tu peux nous donner un exemple (ou un lien) sur un
problème possible avec un *monoprocesseur* (quel qu'il soit),
je suis preneur parce que là je ne vois vraiement pas!
wrote:Le DCLP ne marche à priori que sur des processeurs ayant
une cohérence forte de cache (X86...). Si tu veux être
générique et portable, utilises un lock pour chaque appel à
"GetInstance".
Le DCLP ne marche a priori pas. Un point, c'est tout. Tel
qu'il est implémenté dans ACE, il ne marche même pas sur le
80x86 le plus primitif, avec un seul processeur. S'il donne
l'air de marcher, parfois, c'est parce que le compilateur
n'optimise pas.
Ok, alors soyons plus précis : Si les processeurs ont une
force cohérence de cache et si je mets le code
d'initialisation dans une autre unité de translation que le
code du singleton (l'initialisation se fait par un appel de
fonction - et je considère que le compilateur ne fait pas
d'optimisation globale, ou alors je l'interdis), est-e qu'il y
a quelque chose qui te chagrine avec le DCLP?
Et si tu peux nous donner un exemple (ou un lien) sur un
problème possible avec un *monoprocesseur* (quel qu'il soit),
je suis preneur parce que là je ne vois vraiement pas!
Patrick Mézard wrote:Arnaud Debaene wrote:Ok, alors soyons plus précis : Si les processeurs ont une
force cohérence de cache et si je mets le code
d'initialisation dans une autre unité de translation que le
code du singleton (l'initialisation se fait par un appel de
fonction - et je considère que le compilateur ne fait pas
d'optimisation globale, ou alors je l'interdis), est-e
qu'il y a quelque chose qui te chagrine avec le DCLP?
Par curiosité, qu'est-ce tu veux dire précisément par "les
processeurs ont une forte cohérence de cache" ?
Un système où, lorsqu'un processeur effectue une opération
d'écriture, une interruption prioritaire interrompts
immédiatement tous les autres processeurs pour qu'ils marquent
l'adresse correspondante comme "dirty" dans leur cache local,
et évitent donc de lire une version "ancienne" cachée
localement de la valeur.Un mécanisme similaire a lieu
également lors de la lecture d'une variable.
Ce système simplifie la programmation multi-tâches car il n'y
a pas besoin de "barrière" applicative pour mettre à jour les
caches des processeurs, mais elle est très mauvaise en terme
de "scalability" (traduction française????) car, avec beaucoup
de processeurs, elle entraine une trafic pas possible entre
processeurs (souvent sur un bus dédié à ces mises-à-jour de
cache) et un taux très important d'interruptions. La tendance
actuelle est de laisser tomber ce système à cause de ces
limitations.
Patrick Mézard wrote:
Arnaud Debaene wrote:
Ok, alors soyons plus précis : Si les processeurs ont une
force cohérence de cache et si je mets le code
d'initialisation dans une autre unité de translation que le
code du singleton (l'initialisation se fait par un appel de
fonction - et je considère que le compilateur ne fait pas
d'optimisation globale, ou alors je l'interdis), est-e
qu'il y a quelque chose qui te chagrine avec le DCLP?
Par curiosité, qu'est-ce tu veux dire précisément par "les
processeurs ont une forte cohérence de cache" ?
Un système où, lorsqu'un processeur effectue une opération
d'écriture, une interruption prioritaire interrompts
immédiatement tous les autres processeurs pour qu'ils marquent
l'adresse correspondante comme "dirty" dans leur cache local,
et évitent donc de lire une version "ancienne" cachée
localement de la valeur.Un mécanisme similaire a lieu
également lors de la lecture d'une variable.
Ce système simplifie la programmation multi-tâches car il n'y
a pas besoin de "barrière" applicative pour mettre à jour les
caches des processeurs, mais elle est très mauvaise en terme
de "scalability" (traduction française????) car, avec beaucoup
de processeurs, elle entraine une trafic pas possible entre
processeurs (souvent sur un bus dédié à ces mises-à-jour de
cache) et un taux très important d'interruptions. La tendance
actuelle est de laisser tomber ce système à cause de ces
limitations.
Patrick Mézard wrote:Arnaud Debaene wrote:Ok, alors soyons plus précis : Si les processeurs ont une
force cohérence de cache et si je mets le code
d'initialisation dans une autre unité de translation que le
code du singleton (l'initialisation se fait par un appel de
fonction - et je considère que le compilateur ne fait pas
d'optimisation globale, ou alors je l'interdis), est-e
qu'il y a quelque chose qui te chagrine avec le DCLP?
Par curiosité, qu'est-ce tu veux dire précisément par "les
processeurs ont une forte cohérence de cache" ?
Un système où, lorsqu'un processeur effectue une opération
d'écriture, une interruption prioritaire interrompts
immédiatement tous les autres processeurs pour qu'ils marquent
l'adresse correspondante comme "dirty" dans leur cache local,
et évitent donc de lire une version "ancienne" cachée
localement de la valeur.Un mécanisme similaire a lieu
également lors de la lecture d'une variable.
Ce système simplifie la programmation multi-tâches car il n'y
a pas besoin de "barrière" applicative pour mettre à jour les
caches des processeurs, mais elle est très mauvaise en terme
de "scalability" (traduction française????) car, avec beaucoup
de processeurs, elle entraine une trafic pas possible entre
processeurs (souvent sur un bus dédié à ces mises-à-jour de
cache) et un taux très important d'interruptions. La tendance
actuelle est de laisser tomber ce système à cause de ces
limitations.
Laurent Deniau wrote:wrote:Jean-Marc Bourguet wrote:C'est ce que j'utilise (presque, je n'aime pas l'utilisation
de la reference, j'utilise donc un pointeur) J'utilise memeSingleton& Singleton::instance()
{
static Singleton myInstance;
return myInstance;
}quand je n'ai pas a choisir une classe derivee. Je ne sais
pas pourquoi James fait autre chose.Deux raisons. La raison pour le new est simple : je peux
aussi utiliser le singleton dans des destructeurs des
statiques, sans risque qu'il soit déjà detruit. La raison
pour l'initialisation explicite en dehors de la fonction,
c'est simplement pour assurer que instance est appelé au
moins une fois pendant les initialisations static, avant le
démarrage des threads. Et que donc, il n'a pas besoin de
lock. J'aurais pu utiliser n'importe quelle variable
statique, mais je le trouve assez succinct (mais peut-être
pas trop lisible) d'utiliser précisement le pointeur
d'instance du singleton.Mais est-ce que:class Singleton
{
public:
static Singleton& instance() ;
private:
Singleton() {}
static Singleton myInstance;
} ;Singleton Singleton::myInstance;
Singleton& Singleton::instance() { return myInstance; }ne rempli pas le cahier des charges?
Pas du tout. Si on appelle Singleton::instance() du constructeur
d'un objet statique dans une autre unité de compilation, je
risque de me rétrouvait avec un objet non-encore construit. Et
si je l'utilise dans le destructeur d'un tel objet, je risque de
me rétrouvait avec un objet déjà detruit.
Laurent Deniau wrote:
kanze@gabi-soft.fr wrote:
Jean-Marc Bourguet wrote:
C'est ce que j'utilise (presque, je n'aime pas l'utilisation
de la reference, j'utilise donc un pointeur) J'utilise meme
Singleton& Singleton::instance()
{
static Singleton myInstance;
return myInstance;
}
quand je n'ai pas a choisir une classe derivee. Je ne sais
pas pourquoi James fait autre chose.
Deux raisons. La raison pour le new est simple : je peux
aussi utiliser le singleton dans des destructeurs des
statiques, sans risque qu'il soit déjà detruit. La raison
pour l'initialisation explicite en dehors de la fonction,
c'est simplement pour assurer que instance est appelé au
moins une fois pendant les initialisations static, avant le
démarrage des threads. Et que donc, il n'a pas besoin de
lock. J'aurais pu utiliser n'importe quelle variable
statique, mais je le trouve assez succinct (mais peut-être
pas trop lisible) d'utiliser précisement le pointeur
d'instance du singleton.
Mais est-ce que:
class Singleton
{
public:
static Singleton& instance() ;
private:
Singleton() {}
static Singleton myInstance;
} ;
Singleton Singleton::myInstance;
Singleton& Singleton::instance() { return myInstance; }
ne rempli pas le cahier des charges?
Pas du tout. Si on appelle Singleton::instance() du constructeur
d'un objet statique dans une autre unité de compilation, je
risque de me rétrouvait avec un objet non-encore construit. Et
si je l'utilise dans le destructeur d'un tel objet, je risque de
me rétrouvait avec un objet déjà detruit.
Laurent Deniau wrote:wrote:Jean-Marc Bourguet wrote:C'est ce que j'utilise (presque, je n'aime pas l'utilisation
de la reference, j'utilise donc un pointeur) J'utilise memeSingleton& Singleton::instance()
{
static Singleton myInstance;
return myInstance;
}quand je n'ai pas a choisir une classe derivee. Je ne sais
pas pourquoi James fait autre chose.Deux raisons. La raison pour le new est simple : je peux
aussi utiliser le singleton dans des destructeurs des
statiques, sans risque qu'il soit déjà detruit. La raison
pour l'initialisation explicite en dehors de la fonction,
c'est simplement pour assurer que instance est appelé au
moins une fois pendant les initialisations static, avant le
démarrage des threads. Et que donc, il n'a pas besoin de
lock. J'aurais pu utiliser n'importe quelle variable
statique, mais je le trouve assez succinct (mais peut-être
pas trop lisible) d'utiliser précisement le pointeur
d'instance du singleton.Mais est-ce que:class Singleton
{
public:
static Singleton& instance() ;
private:
Singleton() {}
static Singleton myInstance;
} ;Singleton Singleton::myInstance;
Singleton& Singleton::instance() { return myInstance; }ne rempli pas le cahier des charges?
Pas du tout. Si on appelle Singleton::instance() du constructeur
d'un objet statique dans une autre unité de compilation, je
risque de me rétrouvait avec un objet non-encore construit. Et
si je l'utilise dans le destructeur d'un tel objet, je risque de
me rétrouvait avec un objet déjà detruit.
Le problème ne concerne pas la cache, qui est, autant que je
sache, toujours plus ou moins synchronisé.
Le problème ne concerne pas la cache, qui est, autant que je
sache, toujours plus ou moins synchronisé.
Le problème ne concerne pas la cache, qui est, autant que je
sache, toujours plus ou moins synchronisé.
