Discussion :

[r0d]

Bonjour tout le monde,

j'ai un petit souci avec un thread et une variable globale.

Mon appli doit tourner exclusivement sous Windows (XP/Vista).
J'ai un bout de code "critique" qui peut être bloquant. J'ai donc décidé de le mettre dans un thread afin de pouvoir l'arêter au bout d'un certain temps s'il ne répond pas.

En gros, mon code ressemble à ça:

Code c++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// le thread
DWORD WINAPI MonThread( MonObjet* pMonObjet)
{
    // du code qui utilise pMonObjet
}
 
//quelque part ailleurs, dans une fonction membre de MonObjet:
DWORD dwThreadId = 0;
HANDLE handle = CreateThread( NULL, //security attributes
    0, //stack size
    (LPTHREAD_START_ROUTINE) MonThread, // start address
    (LPVOID) this,  // thread parameter
    0,  // creation flag
    &dwThreadId); // thread Id
 
DWORD dwWaitResult = WaitForSingleObject(handle, myThreadTimeOutMax);

Jusqu'ici tout va bien.
Maintenant, j'ai une variable globale (un objet) que je voudrais utiliser dans ce thread. Si j'ai bien compris, la mémoire du thread et celle de l'application sont distinctes, donc mon objet global n'est pas connu à l'intérieur du thread.

1/ Ais-je bien compris le problème?
2/ Quelles sont les solutions qui existent pour régler ce problème?

ps: j'ai cherché du côté des "security attributes" de CreateThread, mais je n'ai pas réussi à en sortir quelque chose.

[Laurent Gomila]

Remarque qui n'a rien à voir : transtyper le callback est très sale, tu devrais plutôt lui faire prendre un LPVOID en paramètre (comme demandé) et transtyper celui-ci en MonObjet*.

Ensuite, il n'y a aucun problème, les variables globales sont accessibles depuis les threads. C'est l'un des intérêts : tous les threads partagent la mémoire du processus père. Et puis si on ne pouvait pas partager de variables, à quoi serviraient les mécanismes de synchronisation (mutex, sémaphore, ...) ?

[r0d]

Remarque qui n'a rien à voir : transtyper le callback est très sale, tu devrais plutôt lui faire prendre un LPVOID en paramètre (comme demandé) et transtyper celui-ci en MonObjet*.

Ha d'accord
J'avais fais ça parce que je trouvais que sémantiquement c'était plus "parlant". Pourquoi c'est trés sale de faire ça?

Ensuite, il n'y a aucun problème, les variables globales sont accessibles depuis les threads. C'est l'un des intérêts : tous les threads partagent la mémoire du processus père. Et puis si on ne pouvait pas partager de variables, à quoi serviraient les mécanismes de synchronisation (mutex, sémaphore, ...) ?

Hum... je ne comprends pas alors.
En fait, cet objet global est mon logger, qui est un singleton. Ce logger est initialisé à la première ligne de mon application, et lors de cette initialisation, je lui fournis le chemin du fichier dans lequel il doit écrire.
Ce qu'il se passe, c'est que tout ce qui est loggé à l'intérieur de mon thread est écrit dans un autre fichier, celui qui est défini lorsque le constructeur par défaut du logger est appelé.
Comprend pô...

[bolhrak]

Possible de voir comment est initialisé ton Logger et comment tu le récupères dans ton thread ?

[r0d]

Ok, j'ai trouvé l'erreur... mais je n'ai pas encore compris ce comportement

En fait, l'instance unique de mon logger est déclarée ainsi:

Code :

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

1
2
3
4
5
6
7
8
9
class CLogger :	public std::ofstream
{
public:
// code
 
private:
	//! unique instance
	static CLogger* m_pInstance;	
};

Et je l'initialisais sinsi:

Code :

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

CLogger* CLogger::m_pInstance = new CLogger();

Maintenant, si je l'initialise ainsi:

Code :

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

CLogger* CLogger::m_pInstance = NULL;

je n'ai plus de problème.

[nicroman]

Ha d'accord
J'avais fais ça parce que je trouvais que sémantiquement c'était plus "parlant". Pourquoi c'est trés sale de faire ça?

Parceque le compilateur ne pourra jamais te prévenir si tu as fait une erreur dans ta callback, et ca plantera salement à l'execution.

De ton coté, un dynamic-cast permet de s'assurer "proprement" au runtime que l'objet passé est bien du bon type.