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...