Discussion :

[Xemame]

Bonjour,

je voudrais vérifier une information, mais je n'ai pas trouvé ce que je voulais sur le net (j'ai surtout trouvé du Java ).
Si vous pouviez me dire si ce que je dis ci-dessous est vrai ou non, ça me débloquerait!

L'information que je voudrais vérifier est

2 threads peuvent appeler la même méthode d'un même objet sans problème mais il il peut y avoir un problème si les méthodes font un accès concurent à un attribut de l'objet alors qu'il n'est pas protégé.

Par exemple, une méthode std::cout << "hello world"; ne posera pas de problème si 2 threads appellent simultanément cette méthode sur un même objet.

Par contre, le code suivant posera problème

Code :

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

1
2
3
int res = AttributNombreAppelMethode; // AttributNombreAppelMethode est un attribut de l'objet qui compte le nombre de fois où sa méthode a été appelée
    std::cout << "le nombre d'appel de cette méthode est " << res; 
    AttributNombreAppelMethode= res + 1;

Si 2 threads appellent cette méthode sur un même objet, on aura
1er thread ////////// 2ème thread
res = 0;
//////////////////////// res = 0;
AttributNombreAppelMethode = 1;
//////////////////////// AttributNombreAppelMethode = 1; // au lieu de 2

En plus des problèmes de cohérence des valeurs, il peut y avoir des problèmes si les threads écrivent en même temps dans attribut de grande taille, puisque l'attribut sera composé à la fin d'un mélange de ce que les 2 threads ont mis.

Une méthode qui peut être appelée simultanément sur le même objet sans poser de problèmes:

Code :

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

1
2
3
4
5
LockMutex(); // prend le mutex
    int res = AttributNombreAppelMethode; 
    AttributNombreAppelMethode++;
    UnlockMutex(); // rend le mutex
    std::cout << "le nombre d'appel de cette méthode est " << res;

Je ne suis pas sûr du tout de ce que je viens de dire.
Est ce que quelqu'un pourrait me dire ce qu'il en pense, svp?
Merci d'avance!

[3DArchi]

Salut,
Le problème pourra se produire dès que les fonctions utiliseront une variable commune non protégée dont au - un thread en écriture, que la variable soit membre de la classe, paramètre de la fonction ou variable globale.
En l'occurrence std::cout<<"coucou" ne sera pas thread safe car l'état interne de std::ostream est affecté.

[Xemame]

En l'occurrence std::cout<<"coucou" ne sera pas thread safe car l'état interne de std::ostream est affecté.

Ok, je ne savais pas. merci!!!

A part std::cout, est ce qu'il y a des fautes dans ce que j'ai dit? Est ce qu'il est bien possible d'appeler simultanément la même méthode d'un même objet sans poser de problèmes?

Le problème pourra se produire dès que les fonctions utiliseront une variable commune non protégée dont au - un thread en écriture

En parlant de thread en écriture, on est d'accord que plusieurs threads peuvent lire une même donnée sans que cela pose de problème, du moment qu'aucun d'entre eux n'écrivent?

[3DArchi]

A part std::cout, est ce qu'il y a des fautes dans ce que j'ai dit?

Si tu veux dire qu'il faut protéger par un mutex lorsque plusieurs threads accèdent à une même variable et qu'au - l'un d'entre eux la modifie, alors oui.
Si tu parles du déroulement problématique en cas de 2 threads sans mutex :

Si 2 threads appellent cette méthode sur un même objet, on aura
1er thread ////////// 2ème thread
res = 0;
//////////////////////// res = 0;
AttributNombreAppelMethode = 1;
//////////////////////// AttributNombreAppelMethode = 1; // au lieu de 2

Le problème est que, sur un système multi-thread préemptif, c'est non prévisible. Le premier thread peut se dérouler en entier avant le second, ou le contraire, ou le changement peut avoir lieu avant ou après les instructions problématiques ... ou pas. C'est bien le problème, c'est qu'on ne peut pas prévoir quel sera le comportement. Tu en décris un, mais ça peut être différent (et passer inaperçu en phase de test et planter lamentablement en démo chez le client )

Est ce qu'il est bien possible d'appeler simultanément la même méthode d'un même objet sans poser de problèmes?

Oui et non. Si la fonction ne modifie rien et n'utilise rien qui puisse être modifié par un autre thread, alors oui. Dès que qu'une variable partagée est modifiée directement ou indirectement, alors l'appel sera problématique s'il l'objet du changement n'est pas protégé sur les problèmes de concurrence.

En parlant de thread en écriture, on est d'accord que plusieurs threads peuvent lire une même donnée sans que cela pose de problème, du moment qu'aucun d'entre eux n'écrivent?

Oui. Le problème est qu'il peut y avoir des modifications alors que tu penses que non. Exemples :
-> std::cout<<"coucou" tu pensais ne rien modifier, et en fait si. D'une façon plus globale, si tu ne sais pas comment est implémenté un objet ou une fonction ou que la doc ne donne aucune information à ce sujet, il te sera difficile de savoir si ton thread est un vrai thread 'lecteur'.
-> le fait qu'une fonction soit const n'est d'aucune utilité pour savoir si la-dite fonction est thread safe ou pas (un des paramètres peut être partagé et non constant, peut modifier un membre mutable, peut utiliser une classe tierce non constant, compteur de référence d'un smart ptr non thread safe, etc.).
-> dans la même veine, le fait que les paramètres soient constants ne garantie pas que la méthode est thread safe (pour à peu près les mêmes raisons)
-> appeler une même fonction sur 2 instances différentes ne garantie toujours pas le thread-safe (variables statiques membres, variables globales/singletons, etc.).
Tu peux chercher les patterns lecteur/écrivain (reader/writer), fournisseur/consommateur (consumer/producer). Ca parle des threads en lecture uniquement.

[Xemame]

D'accord, merci! J'ai tout ce que je voulais savoir!!!

[Jackyzgood]

Bonjour

Je me permet de déterrer ce post pour avoir quelques précisions.

Si 2 threads appelent une même fonctions mais avec des paramètres différents, est ce qu'un thread devra attendre que l'autre en ait fini avec cette fonction ou est ce que cette fonction pourra être exécuté simultanément par les 2 threads ?

Par exemple dans mon cas, j'ai fais un programme qui recherche des nombres premiers, avec plusieurs threads. S'il y en a 2 ils cherchent chacun un nombre sur 4, s'il y en a 3 ils chercheront chacun un nombre sur 6 etc ....

Malgrés que chaque threads cherchent sur des nombres différents, j'ai remarqué qu'ils ne tournaient pas simultanément ... Chaque thread affiche ce qu'il trouve dans la console et j'obtiens un truc du genre :

thread 0 :
thread 0 :
thread 0 :
thread 0 :
thread 1 :
thread 1 :
thread 1 :
thread 1 :
...

Alors que je m'attendais plutôt à un truc du genre :
thread 0 :
thread 1 :
thread 0 :
thread 1 :
...

Est ce que ça vient du fait qu'ils font tous les 2 appele à la même fonction pour tester si un nombre est premier ou pas ?


Mercdi d'avance

[bacelar]

Code :

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

Est ce que ça vient du fait qu'ils font tous les 2 appele à la même fonction pour tester si un nombre est premier ou pas ?

Non.
Chaque thread peut exécuter la fonction "simultanément".
J'ai mis des guillemets car, si l'exécution des threads est parallèle de manière logique, elle ne l'est pas sur une machine mono-CPU, mono-coeur.
Le thread doit, pour s'exécuter sur un CPU.
Les OS modernes choisissent un thread par coeur qui y sera exécuté pendant un certain l'apse de temps, dit quantum.
A la fin de ce quantum de temps, l'OS peut donné le coeur à un autre thread qui est prêt.
Votre affichage montre que votre thread arrive à faire quatre passage durant un quantum de temps.

Si vous êtes sur une plateforme multi-coeur, rien ne vous garantie que chacun des coeur exécute un de vos thread. Il y a beaucoup de programme avec chacun plusieurs threads, qui tournent en permanence dans un OS.

[Jackyzgood]

Merci pour la réponse.

Je me permet une autre petite question.

J'ai testé mon programme en le configurant pour qu'il lance 6 threads sur un cluster d'un ami, qu'il a monté avec kerrighed, mais seul 2 processeurs tournaient à fond sur les 6.

D'où ma question : Est ce que la SDL est limité au niveau des threads ?

[bacelar]

Aucune idée.
Mais un processeur peut avoir plusieurs coeur physique et logique (via l'hyperthreading), donc 2 CPU peuvent exécuter simultanément bien plus que 2 threads.

[Jackyzgood]

ok, bah je vais essayer avec plus que 6 threads

merci encore