Différence entre mutex et atomic

Bonjour,

Suite à un autre post j'aurais aimé connaître les différences qu'il y a entre std::mutex et std::atomic, en c++0x (mais qui doivent être semblable à ceux de boost).

Par différence j'entends les avantages et inconvénients de chacun, ainsi que le contexte le plus propice à leur utilisation.

Si j'ai dis une bétise faite moi remarquer :D

Merci à tous!

Si je comprends bien tu demandes la différence entre un mutex et un atomic, pas entre le mutex de la STL et le mutex de boost

la différence est qu'un atomic en soit n'est qu'un entier avec la propriété d'être mis a jour de manière correcte sur tous les threads. Parfois dans un environnement multithread, les valeurs peuvent se corrompre lorsqu'elles sont mises a jour sur deux threads exactement en meme temps; le résultat après deux incréments par exemple, devrait être la valeur originale + 2. Mais si deux threads entrent en conflit et font l'incrément exactement au même moment, alors la valeur devient parfois seulement +1 avec deux incréments; c'est juste un exemple.
On peut aussi faire des opérations de remplacement conditionnels, qui echouent si la valeur a changé. Ca permet de faire des boucles "tant que ca echoue (sous entendu, un autre thread avait la priorité) je reessaye". Ces boucles peuvent être infinies si une infinité de threads essayent de mettre a jour, mais en pratique, les congestions sont souvent faibles.

Cela permet la grosse propriété suivante: aucun thread n'est bloqué et tout s'execute en parallèle (même la boucle se fini très rapidement)

mais l'inconvénient c'est que a part incrémenter un pointeur ou un entier ca ne fait pas grand chose.

un mutex, en revanche, va assurer qu'aucun autre thread n'en est au même endroit; on s'en sert pour protéger les resources aussi. Un seul thread peut avoir le mutex, les autres sont mis en pause; celui qui a le mutex fait son opération (qui peut être longue et compliquée), puis libère le mutex et continue. A ce moment un autre thread peut prende le mutex et faire son opération.

L'avantage: on peut avoir n'importe quel type de code lorsque le mutex est protégé.
L'inconvénient: Un seul thread peut utiliser le mutex, les autres sont en pause. Sur un processeur multi-coeur on fait alors chuter l'utilisation du processeur (dramatiquement)
les threads mis en pause sont généralement mis en pause pour assez longtemps (l'intervalle est de plusieurs millisecondes) et ca coûte très cher en resources (un mutex est un objet lourd, et mettre en pause/reveiller un thread est une opération coûteuse)
Aussi, si on ne fait pas attention, on peut avoir un "deadlock"; les threads attendent des mutexes qui ne seront jamais libéré. Un exemple classique avec les mutex A et B; le thread 1 essaye de prendre A et B, effectue son opération, puis libère B et A
le thread 2 essaye de prendre B et A, fait son opération, puis libère A et B
si on a pas de bol, le thread 1 prend le mutex A au moment ou le thread 2 prend le mutex B
ensuite, le thread 1 attend le mutex B (qui est pris par le thread 2)
le thread 2 attend le mutex A (pris par le thread 1)
ni le mutex B, ni le mutex A ne seront libérés puisque chaque thread est bloqué; et donc les deux threads resteront bloqués "pour toujours".


on essaye donc d'utiliser des opérations atomiques quand on peut. Par exemple un moyen de contourner les mutex avec des atomiques est de faire ainsi:
Je fais mon opération dans un buffer intermediaire (privé, donc seul mon thread y accède, pas de synchronisation possible); lorsque c'est fini, j'essaye de remplacer le pointeur sur le résultat par le pointeur sor ma valeur intermédiare; si ca marche, tout le monde est content.
Si ca echoue, un autre thread a réussi a mettre a jour avant moi, donc je recommence depuis zéro, je recalcule le résultat;
ca marche si le calcul a effectuer est court, dans ce cas il vaut mieux calculer plusieurs fois plutot que prendre un mutex, ca pourra être plus rapide.

éviter la synchronisation complètement c'est encore mieux =) ne pas avoir de mutex ou d'atomiques c'est ce qu'il y a de mieux.

Réponse on ne peut plus parfaite =)

Merci c'est exactement ce qu'il me fallait. Je ne savais que lors de la prise d'un mutex, même si les autres threads font des choses qui n'ont rien à voir et de manière complement indépendante, ils se mettent en pause.

C'est vrai que mérite réflexion sur l'architecture finale. Et merci pour l'astuce finale!

euh non pas vraiment; ce sont les threadsqui ont besoin du mutex qui sont en pause, ceux qui n'y accèdent pas peuvent continuer, désolé si ce n'était pas clair.

Si une resource est accédée très osuvent par beaucoup de threads alors c'est la que es threads risquent d'être tout le temps bloqués, mais sinon tu peux avoir beaucoup de trheads sans problème.

(je le déconseille quand même si on peut s'en passer)