Est-ce que vous pensez que le livre C++ Concurrency in Action d'Anthony Williams est un bon livre pour apprendre le multithreading ? Je suis en train de le lire depuis quelques jours mais je le trouve vraiment vraiment vraiment pas évident à appréhender. Je trouve qu'on se noie dans la quantité de détails fournis.
Moi qui ait peu d'expérience en multithreading, j'ai peut-être pris une ressource trop avancée par rapport à mon niveau.
Est-ce qu'il y aurait un cours accessible pour comprendre ce que c'est qu'un pool par exemple ?
Alors, oui, c'est une bon livre. Mais quand je l'ai lu, je connaissais deja les threads, donc c'est plus dur a juger comme premier livre sur les threads.
Habituellement, tu commences les threads dans un livre plus général, par exemple dans "Tour of C++" ou "Professional C++" (pour citer 2 que j'aime bien), qui ont des chapitres d'intro sur la question. Si tu as juste lu un cours de base sur le C++ (comme le cours de ce site ou celui de Zeste de Savoir), c'est probablement un trop gros saut de passer directement a "C++ Concurrency in Action".
Je recommande de passer par une cours généraliste plus complet sur le C++ (comme ceux que j'ai cité) après avoir lu un cours débutant.
Ah mince non j'ai la première édition. Je m'en débarrasse pour passer immédiatement à la seconde édition ?
Merci je vais regarder Tour of C++ et Professional C++. J'avais lu C++ Primer pour apprendre le C++ à la base mais il me semble qu'il n'aborde pas le multithreading ce qui fait que je n'ai pas de très bonnes bases là-dessus.
Oui, C++ Primer est un livre débutant et il a été publié en 2012, c'est a dire juste après la sortie des threads en C++. Avant, on utilisait boost ou les threads du C.
Le MT c'est pour moi avant tout des patterns et des bonnes pratiques. Le machin que le langage va offrir en plus, c'est limite du détail de savoir lire ce qui existe et n'existe pas dans le standard et la lib standard.
J'ai acheté "C++ Concurrency in action" en 2016 environ et je trouve aussi que c'est un livre qui n' est pas très accessible aux débutants pour certains chapitres. Notamment la partie sur les types atomiques, les codes présentés dans ces chapitres sont biscornus pour dire les choses de manière un peu triviale. Sinon la théorie est bien expliquée, et il y a même des schémas pour comprendre certains mécanismes de libération de la mémoire via pointeurs ayant l' ownership en prenant parti du parallélisme ( je pense aux dangling pointers et aux opérations sur les types atomiques ). A l' issue de la lecture de ce livre, je dirais que si je devais créer une structure genre pile, file ou autre et utiliser le parallélisme, je ne la créerais pas avec des atomiques, mais plutôt des mutex pour garder une lisibilité de code et éviter ainsi des bugs (même rares) qui pourraient survenir. L' auteur du livre indique bien d' ailleurs qu' avec les atomiques certains bugs peuvent survenir très rarement et qu' il est difficile de concevoir une structure de données utilisant les atomiques du premier coup.
Une des différence entre une structure via atomiques et des mutex est la suivante (il peut y en avoir d'autres):
Le système d' exploitation donne du temps processeur à différentes taches de l' ordinateur. Notamment, une tache s' exécute et elle possède soit un mutex soit un atomique. Le système d' exploitation arrête de donner du temps à cette tache:
- Si la tache exécute du code via atomiques, alors une autre tache pourra reprendre la tache en cours (la tache arrêtée précédemment lègue l' ownership de la tache automatiquement avec un enrobage atomique de donnée).
- Si la tache dispose d'un mutex, alors il faudra attendre que le système d' exploitation redonne du temps processeur à cette même tache pour qu'elle continue un autre thread restera bloqué au moment de reprendre l' ownership du mutex (via spin lock).
Je range les atomiques dans "trucs pour experts qui serviront à écrire des structures de données adaptées de MT", et nous/moi on n'a surtout pas à écrire ces machins mais à utiliser ceux que l'on trouvera ailleurs car trop complexe à écrire correctement, stabiliser, etc.
Les mutex c'est pas très intéressant en terme de performance. Je sais pas comment ils sont implémentés en C++ mais si ça fait un appel système pour endormir le thread c'est très lent. Ce qu'il faut faire c'est endormir QUE SI il y a de la contention, sinon c'est pas la peine de faire de perdre tout ce temps. Les CriticalSection sur windows fonctionnent comme ça. Je pense que les std::mutex aussi mais il vaut mieux vérifier pour être sûr (on est jamais au bout de nos surprise en C++ )
Sinon malheureusement les atomiques sont nécessaires si on veut des structures thread safe efficaces. Si vous le faites pas vous même, faites plaisir à votre CPU et utilisez une librairie qui le fait plutôt que de les réimplémenter en moins bien avec des mutex.
Pour les atomiques, attention je vous vois venir en disant qu'il faut utiliser le std::memory_order_seq_cst de base, non non non ce n'est pas efficace . Il faut réfléchir à l'ordre des opérations pour utiliser les bons memory_order. Par exemple si vous voulez faire passer des données d'un thread A à un thread B, ce n'est pas la peine de faire du seq_cst. Une fois que le thread A a écrit ses données (ça peut être tout et n'importe quoi, même plusieurs gigas), il suffit qu'il écrive dans un flag (en gros un booléen) en std::memory_order_release, et ensuite que le thread B lise cette valeur en std::memory_order_acquire. Ça va permettre de synchroniser les 2 et de s'assurer que les données écrites par A sont visibles par B. C'est tout, pas besoin de seq_cst et encore moins de mutex (heaven help us!)
Attention cette synchronisation n'est pas forcément nécessaire dans certains cas, et dans ces cas là il vaut mieux utiliser une barrière pour ne synchroniser que quand c'est absolument nécessaire (voir l'exemple des mailboxes en bas de cette page https://en.cppreference.com/w/cpp/atomic/atomic_thread_fence)
Après je connais pas bien les processeurs (il faudrait demander à Helba) mais je crois que sur les CPU x64, toutes les écritures mémoire sont en release et toutes les lectures en acquire, donc sur ce genre de CPU on pourrait se contenter de std::memory_order_relaxed pour faire ça mais il vaut mieux quand même préciser les bons orders car sinon si un jour on veut le faire tourner sur un processeur à faible ordre mémoire ça marchera pas
- Edité par JadeSalina 17 décembre 2022 à 21:15:07
Jade, tais toi, osef de ton avis. Il veut juste un avis sur les livres pour apprendre.
@autechre Je viens de me souvenir que Rainer Grimm (l'auteur du blog moderncpp, de plusieurs livres et qui fait des présentations a la CppCon) a fait un livre sur le sujet. Je ne l'ai pas encore lu, donc je ne sais pas ce qu'il vaut, mais tu peux jeter un coup d'oeil dessus : https://leanpub.com/concurrencywithmodernc
En plus, elle prend un exemple avec des threads qui se transmettent des données entre eux (donc il peut y avoir du cache ping pong). Dans le livre d' Anthony Williams, l'auteur dit bien que c'est néfaste pour du multithreading. L' exemple de Jade Salina n'est pas terrible de mon point de vue, on a déjà vu mieux que ça pour du multithreading.
Jade, tais toi, osef de ton avis. Il veut juste un avis sur les livres pour apprendre.
Surtout quand c'est pour encore débiter de la merde par cartons de 12.
Si je dis des trucs faux n'hésitez pas à me corriger, je ne veux pas avoir des idées fausses en tête.
Warren79 a écrit:
En plus, elle prend un exemple avec des threads qui se transmettent des données entre eux (donc il peut y avoir du cache ping pong). Dans le livre d' Anthony Williams, l'auteur dit bien que c'est néfaste pour du multithreading. L' exemple de Jade Salina n'est pas terrible de mon point de vue, on a déjà vu mieux que ça pour du multithreading.
Oui vous avez raison, ce n'est pas efficace de faire communiquer des threads entre eux en plein milieu des opérations, le mieux serait de faire en sorte que chaque thread fasse un bout du travail dans son coin (en faisant attention à ce qu'ils ne se marchent pas sur les caches, sinon MESI va pas être content !), et une fois qu'ils ont fini on peut regrouper les résultats. Mais mon "exemple" c'était dans le cas malheureux où on a besoin de faire passer des données d'un thread à l'autre, c'était surtout pour dire qu'on n'a pas besoin d'un mutex pour ça, mais si vous voyez une encore meilleure solution je la veux bien
Sinon pour revenir à la question, oui je trouve que ce livre est bien mais je ne sais pas si il est pensé pour la performance maximale, car l'auteur explique des choses avancées certes, mais il met un peu trop souvent à mon gout le lecteur "en garde" quand on s'intéresse justement à faire des choses complexes et performantes. Je vous met quelques extraits, quand je met un c'est que je suis d'accord avec la phrase et un quand ça me plait pas.
"If you don’t need the stringency of sequentially consistent ordering for your atomic operations, the pair-wise synchronization of acquire-release ordering has the potential for a much lower synchronization cost than the global ordering required for sequentially consistent operations." (page 161 (138 édition 1)) (ça c'est ce que j'ai dit dans mon exemple donc je suis d'accord obvs)
"The trade-off here is the mental cost required to ensure that the ordering works correctly" (juste après la phrase précédente)
"In this chapter we’ll look at how the memory-ordering properties of the atomic operations introduced in chapter 5 can be used to build lock-free data structures." (page 206 (181 édition 1))
"You need to take extreme care when designing such data structures, because they’re hard to get right, and the conditions that cause the design to fail may occur very rarely." (juste après la phrase précédente)
"Writing wait-free data structures correctly is extremely hard [...] Given how hard it is to get a lock-free or wait-free data structure right, you need some pretty good reasons to write one; you need to be sure that the benefit outweighs the cost" (page 208 (182 édition 1))
Jade, tais toi, osef de ton avis. Il veut juste un avis sur les livres pour apprendre.
Surtout quand c'est pour encore débiter de la merde par cartons de 12.
Si je dis des trucs faux n'hésitez pas à me corriger, je ne veux pas avoir des idées fausses en tête.
Non, on s’en fout juste de ton avis sur les threads, les atomics, les performances, etc. Parce que oui, l’auteur ne recherche pas la performance maximale. Personne le fait, a part toi. Donc ton avis sur le livre, base sur ta facon moisie de penser la programmation, on s’en fout aussi.
Ouvre ta propre discussion si tu veux donner tes opinions moisies, ne pollue pas les discussions des autres.
@Autechre
Desole que ta discussion soit polluee par des discussions hors sujet. Pour resumer le probleme : Jade a un point de vue tres personnel sur les performances (”a tout prix, sans consideration pour les autres aspects”) alors que c’est juste un debutant sans experience pro et sans vrai projet. Et cet avis n’est pas du tout partage par l’auteur du livre et la grande majorite des devs C++ pro.
Le probleme, c'est surtout le manque de progressivité. La, tu veux lire un livre qui t'apprend a construire une formule 1, alors que tu ne sais pas construire un vélo.
Normalement, tu aurais du être introduit au sujet dans un livre d'introduction au C++ avec un chapitre sur le sujet, puis quelques chapitres dans un cours de C++ avance, puis finalement étudier le sujet en profondeur avec ce livre. Et bien sur, tu aurais du pratiquer sur quelques projets entre chaque lecture.
Pour ça que je te conseillais de lire dans un premier temps le chapitre sur le sujet de Tour of C++ (chapitre 18, 30 pages) puis le chapitre dans Professional C++(chapitre 27, 60 pages). Et de pratiquer entre 2 sur les notions elementaires que tu as appris.
@gbdivers Merci infiniment ! Oui je suis d'accord que j'aurai dû commencer par un livre intermédiaire mais je ne connaissais ni Tour of C++ ni Professional C++.
C++ Concurrency in Action : bon livre ?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Discord NaN. Mon site.
Mon site web de jeux SDL2 entre autres : https://www.ant01.fr
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Mon site web de jeux SDL2 entre autres : https://www.ant01.fr
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.