Discussion :

[contremaitre]

Bonjour,

Si je crée une instance d'une classe et que je passe un pointeur vers cette classe à plusieurs thread est ce qu'il faut que je protège l'accès simultanée aux fonctions de A par des mutex ou ca dépends de ce que font ces fonctions ?

Dans le cas ou il faut protéger par mutex, est ce qu'il vaut mieux que ce soit la classe qui gère ses propres mutex (lock en début de fonction et unlock en fin) ou est ce qu'il vaut mieux que ce soit l'appelant qui fasse le lock ?

merci

[wiztricks]

Et plus précisément des variables qu'elles modifient.
Il faut en général "sérialiser" les séquences { lecture, modification, écriture } de ces variables (par exemple via un "mutex").
Comme le code appelant n'a pas à s'occuper de l'implantation du code appelé, cette sérialisation doit être faite dans les méthodes de l'objet.
- W

[Spout]

A priori, je dirais que des fonctions qui ne font que renvoyer des données (copies ou non) sans en modifier le contenu (= fonctions const) n'ont pas besoin d'être protégées.
MAIS si un thread modifie une variable membre de ta classe pendant qu'un autre la lit, tu risques d'avoir des problèmes .

Conclusion : protège toutes tes fonctions par des sections critiques.

Dans le cas ou il faut protéger par mutex, est ce qu'il vaut mieux que ce soit la classe qui gère ses propres mutex (lock en début de fonction et unlock en fin) ou est ce qu'il vaut mieux que ce soit l'appelant qui fasse le lock ?

C'est la zone qui risque d'être appelée plusieurs fois qui doit être protégée, pas les appels. Le appels venant de threads différents à des endroits différents, un appel à ta classe A d'un même thread n'arrivera qu'une fois. (euh c'est clair ça ?)

[contremaitre]

merci pour vos réponse

Mais

C'est la zone qui risque d'être appelée plusieurs fois qui doit être protégée, pas les appels. Le appels venant de threads différents à des endroits différents, un appel à ta classe A d'un même thread n'arrivera qu'une fois. (euh c'est clair ça ?)

Pas trop

Oui un appel à A d'un même thread n'arrive qu'un fois, mais ça n'empeche pas d'avoir un mutex partagé entre tous les thread qui bloque l'appel à A, si c'est ce dont tu parlais ?

[Spout]

Oui un appel à A d'un même thread n'arrive qu'un fois, mais ça n'empeche pas d'avoir un mutex partagé entre tous les thread qui bloque l'appel à A, si c'est ce dont tu parlais ?

Non, mais je rejoins wiztricks à ce propos:

Comme le code appelant n'a pas à s'occuper de l'implantation du code appelé, cette sérialisation doit être faite dans les méthodes de l'objet.

De plus, ce mutex ne fait que rajouter un niveau entre ta classe A et tes threads. L'avantage de la section critique à l'intérieur des fonctions de ta classe A, c'est que si jamais un autre thread doit utiliser ta classe, tu n'auras pas à rajouter la gestion du mutex pour ce nouveau thread. Tout sera déjà fait dans la classe A !

[contremaitre]

oui j'avais bien compris ça, mais c'est ta phrase que j'avais pas bien comprise.