[MT] thread et variable globale

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:

---

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.

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, ...) ?

Citation:

---

Envoyé par 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*.

---

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

Citation:

---

Envoyé par Laurent Gomila

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ô... :triste:

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

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

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

Code:

---

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:

---

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

---

Maintenant, si je l'initialise ainsi:

Code:

---

CLogger* CLogger::m_pInstance = NULL;

---

je n'ai plus de problème.

Citation:

---

Envoyé par r0d

Ha d'accord :oops:
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.