Discussion :

[seal3]

Salut !

Je ne suis pas expert en C++, j'ai ecris pas mal de programes mais je ne me suis jamais vraiement lancé sur les threads.

Je bosse sous linux, j'ai etudié à droite et à gauche les threads mais je n'ai pas trouvé de réponse à ma question. Il me semble avoir compris que pour lire des données, les threads ne pausent pas de soucis. La ou ça coince c'est quand on modifie des variables. La dessus vive les mutex et autres sémaphores. Ce que je ne pige pas c'est quel est le seuil critique...

Je veux dire est-ce critique si 2 thread cherchent à modifier le même int en même temps ? Est-ce q'un troisieme thread qui cherche à lire ce int peut avoir autre chose que la valeur du thread 1 ou 2 ? Est-ce qu'il peut y avoir un crash du preocess à ce stade ?


Je me pose la même question pour ce qui est des pointeurs. Si je cherche à acceder à un objet :

a->b->c->monInt=10

Est-ce q'il peut se passer qq chose entre a->b et b->c ? Est-ce q'un thread peut avoir le temps d'effectuer une tache alors que le premier est en train de rentrer dans l'arbre ?

Merci à vous !

[loufoque]

Les problèmes de concurrence ne peuvent se poser bien évidemment que si plusieurs threads tentent de modifier une valeur de manière concurrente, ou si certains tentent de lire pendant que d'autres la modifient.

Avec un seul cœur, réaliser toute opération non atomique en concurrence est dangereux.
Avec plusieurs cœurs, réaliser toute opération atomique en concurrence sans barrières est aussi dangereux.

En pratique, je doute que ça puisse planter, tu auras juste une valeur non définie.

Pour bien faire les choses, il faut donc utiliser les primitives de synchronisation de la bibliothèque de threads que tu utilises.

[seal3]

Merci loufoque

Donc j'imagine que a->b->c->monInt=10 est pas atomique !

Comment savoir ce que fait le compilateur deriere tout ça pour determiner ce qui est atomique et ce qui ne l'est pas ?

EDIT : Je pose cette question pour eviter les deadlock qui dans mon cas risque de couter cher au systeme :/

[ram-0000]

Donc j'imagine que a->b->c->monInt=10 est pas atomique !

Ca dépend, c'est quoi la variable/zone mémoire partagée et à protéger ?

Si c'est juste "monInt", cette opération doit être atomique. par contre si l'un des pointeurs a, b et/ou c qui est partagé entre les threads, là effectivement, l'opération risque de ne plus être atomique puisque l'évaluation doit être faite.

Pour info, monInt = monInt + 5 n'est pas atomique non plus.

Comment savoir ce que fait le compilateur deriere tout ça pour determiner ce qui est atomique et ce qui ne l'est pas ?

En regardant le code assembleur généré ou alors en lisant les spec (désolé, j'ai pas mieux). En général, les opérations atomiques sont clairement indiquées.

[seal3]

Merci beaucoup pour les infos

[nicroman]

J'ajouterai (comme l'a dis loufoque mais peut être en moins clair), sur les processeurs actuels, *aucune* opération n'est vraiment atomique sans la pose explicite de "barrière". De toute manière, cette manière de programmer ne "tiens" pas la route (machines multi-processeurs).

Il ne sert donc à rien de regarder le code généré... par telle ou telle instruction C++ elle ne sera de toute manière pas protégée (à moins de forcer explicitement le programme à tourner sur un seul coeur).

Tous les OS (et CPU multi-coeurs) proposent des instructions de barrieres (comme InterlockedIncrementAcquire / InterlockedIncrementRelease ...)... mais qui ne sont pas sans coût...