Discussion :

[contremaitre]

Bonjour

Pour faire court : si j'ai un objet B qui hérite de l'objet A, est ce que c'est possible que l'objet B soit détruit alors que le destructeur de l'objet A n'est pas encore finit ?

Mon cas en détail :

J'ai une classe CThread générique, dont le destructeur fait un pthread_join.
Et une classe MonThread qui hérite de CThread dont le destructeur ne fait rien.
Mon problème c'est que lorsque mon programme se termine, J'ai l'impression que l'objet MonThread est détruit avant que le destructeur de CThread ne se termine (donc que le pthread_join soit finit)

En effet, à ce moment là une instruction du thread MonThread essaye de faire une opération sur une liste et ça plante car la liste a du etre détruite par le destructeur de MonThread.
Pourtant j'ai mis un affichage avant et après le pthread_join du destructeur de CThread et il n'a pas encore retourné.
Donc comment est ce possible que mon objet MonThread soit détruit alors que le destructeur de CThread ne soit pas finit.

[mister3957]

T'aurai un bout de code ?


En tout cas c'est toujours la classe mère qui est construite avant la classe fille, et inversement pour la destruction, la classe fille sera détruite avant la classe mère.

[contremaitre]

pour la destruction, la classe fille sera détruite avant la classe mère.

Ha mon problème doit venir de là alors.
Je pensais que mettre le pthread_join dans la classe mère empecherais la classe fille de se détruire avant la fin du thread.

Donc je suis obligé de mettre le pthread_join dans toutes mes classe filles, y'a pas un moyen pour éviter ça ? (vu que mon but est d'avoir une classe thread générique en ayant le moins de boulot possible dans les classes filles)

[Obsidian]

En effet, à ce moment là une instruction du thread MonThread essaye de faire une opération sur une liste et ça plante car la liste a du etre détruite par le destructeur de MonThread.

C'est le problème quand on considère un thread comme un objet ordinaire, malheureusement. Ça fait complètement abstraction de la notion de processus dans le sens littéraire du terme.

En poussant le raisonnement un peu plus loin, le problème se pose avec n'importe quel autre objet qui soit en mémoire partagée. Un fil peut très bien le détruire pendant qu'un autre le référence encore, et le problème sera rigoureusement le même : absence de synchro. On utilise un système de sémaphores et de mutex pour faire des accès atomiques à des ressources partagées, et ton objet devrait y être soumis lui-aussi. D'autre part, on doit aussi faire face à un problème peu courant : le thread, en se terminant, peut s'auto-détruire. Ce serait gênant s'il avait été déclaré dans la pile par un autre fil. On aurait alors un objet zombie.

On s'aperçoit comme çà que l'objet Thread en lui-même n'est censé qu'être un handler sur le thread en question, à la manière d'un descripteur de fichier, et que ce handler doit donc être local à chaque processus ou thread qui le manipule. D'où : TLS. Chaque fil peut détruire sa liste locale comme il en a envie, sans compromettre le bon déroulement de l'autre.

[contremaitre]

Merci pour les explications.

Sinon j'ai trouvé une autre solution :
Déplacer l'attente de la fin du thread dans la fonction stop. Du coup les destructeurs ne peuvent plus être apellées tant que le thread n'est pas fini.
Seul petit inconvenient, il faut apeller la fonction stop pour chaque thread créé alors qu'avant cette fonction était apellée automatiquement dans le destructeur.

Mais ce n'est pas illogique de devoir apeller un stop sur un objet ou on fait un start.

[Obsidian]

Sinon j'ai trouvé une autre solution :
Déplacer l'attente de la fin du thread dans la fonction stop. Du coup les destructeurs ne peuvent plus être apellées tant que le thread n'est pas fini.
Seul petit inconvenient, il faut apeller la fonction stop pour chaque thread créé alors qu'avant cette fonction était apellée automatiquement dans le destructeur.

Mais ce n'est pas illogique de devoir apeller un stop sur un objet ou on fait un start.

C'est effectivement cela que je voulais te conseiller, pour les mêmes raisons. Cependant, ça ne règle pas ton problème : si quelqu'un détruit ton objet avant d'avoir appelé stop(), tu te retrouves dans la même situation ...

[contremaitre]

Oui, effectivement.
Mais conceptuellement, ça peut facilement s'accepter de devoir apeller un stop sur un objet ou on a fait un start.
Ce n'est pas plus compliqué à gérer que de faire un delete pour chaque new.

[SoniX]

Une autre façon d'envisager le problème est de dissocier la classe représentant le thread et un autre objet utilisé pour contrôler les threads.

Ex :

Code :

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
 
// Classe de base pour les thread utilisateur
class Thread
{
	virtual ~Thread() {}
 
	// le thread runner est notre ami, lui seul peut executer la thread
	friend class ThreadRunner;
 
	// methode de demarrage de la thread
	protected : virtual void run() = 0;
};
 
 
// La class qui permet le contrôle des threads
class ThreadRunner
{
	// l'objet thread sous contrôle
	Thread	&m_thread;
public :
 
	ThreadRunner(Thread &t)
		:	m_thread(t)
	{}
 
	void start();
	void stop();
	void join();
 
	~ThreadRunner()
	{
		stop();
	}
 
};
 
// un thread utilisateur
class MaThread : public Thread
{
	// on implémente juste run()
	void run()
	{
		...
	}
};
 
void main()
{
	// création de ma thread et du runner
	ThreadRuner tr(MaThread);
	// démarrage de la thread	
	tr.start();
	// fin du context, ceci détruit l'objet runner, 
	// ce qui provoque l'appel à stop puis la destruction de la thread.
}

Il reste les finesses de contrôles de thread à adresser dans les méthodes start(), stop() et join() du runner et run() de la thread, notamment l'arrêt 'propre' de la thread lorsque stop() est appelé.