Je ne suis pas d'accord avec tes définitions de concurrence et parallélisme.
La concurrence est d'abord le fait de partager un bout de la mémoire avec plusieurs processus (ou fils d'exécutions).
Le parallélisme consiste en l'exécution de plusieurs processus en même temps, sur des données disjointes.
Pour moi, la concurrence, c'est la description de tâches et de leurs dépendances éventuelles. Le parallélisme, c'est une exécution de tâches concurrentes par un ensemble de threads. Voir aussi Concurrency is not Parallelism, une présentation de Rob Pike (un des inventeurs du langage Go) qui dit sensiblement la même chose.
Tes définitions me semblent fausses. Typiquement, quand j'exécute une commande avec un pipe, j'ai deux processus concurrents qui ne partagent pas de mémoire (ils partagent des données via un mécanisme de synchronisation, le pipe). Et inversement, quand je fais du parallélisme avec des threads, je peux avoir des données partagées (c'est bien à ça que servent les mécanismes types mutex, à protéger les données partagées).
Auparavant, la distinction entre concurrence et parallélisme n'était pas aussi évidente parce que les deux étaient mélangés. Dans OpenMP ou MPI, on décrit la concurrence entre les tâches mais on a aussi la manière dont l'exécution va se passer. Avec les threads, c'est pareil, les deux sont intimement liés. Ces dernières années, on s'est aperçu que décrire la concurrence entre les tâches sans s'occuper de savoir comment elles vont être exécutées étaient une meilleure stratégie parce qu'alors, on peut utiliser des modèles de parallélisme adaptés à chaque situation. Par exemple, dans Go, on décrit la concurrence avec des goroutines et des channels mais derrière, ça ne dit rien sur la manière dont l'ensemble sera exécuté (et on peut l'exécuter sur un seul thread si on veut).
À mon avis, cette manière de faire a de l'avenir, parce qu'on peut alors séparer le travail en deux : trouver les bons modèles de concurrence, c'est-à-dire les bonnes abstractions qui permettent de raisonner facilement sur le programme (les goroutines/channels sont un exemple mais il y en a beaucoup d'autres); trouver les bons modèles de parallélisme, même si, à mon avis, le travail est déjà plus avancé de ce côté.
# Concurrence / Parallélisme
Posté par rewind (Mastodon) . En réponse à la dépêche Instantané sur le parallélisme et le code. Évalué à 10.
Je ne suis pas d'accord avec tes définitions de concurrence et parallélisme.
Pour moi, la concurrence, c'est la description de tâches et de leurs dépendances éventuelles. Le parallélisme, c'est une exécution de tâches concurrentes par un ensemble de threads. Voir aussi Concurrency is not Parallelism, une présentation de Rob Pike (un des inventeurs du langage Go) qui dit sensiblement la même chose.
Tes définitions me semblent fausses. Typiquement, quand j'exécute une commande avec un pipe, j'ai deux processus concurrents qui ne partagent pas de mémoire (ils partagent des données via un mécanisme de synchronisation, le pipe). Et inversement, quand je fais du parallélisme avec des threads, je peux avoir des données partagées (c'est bien à ça que servent les mécanismes types mutex, à protéger les données partagées).
Auparavant, la distinction entre concurrence et parallélisme n'était pas aussi évidente parce que les deux étaient mélangés. Dans OpenMP ou MPI, on décrit la concurrence entre les tâches mais on a aussi la manière dont l'exécution va se passer. Avec les threads, c'est pareil, les deux sont intimement liés. Ces dernières années, on s'est aperçu que décrire la concurrence entre les tâches sans s'occuper de savoir comment elles vont être exécutées étaient une meilleure stratégie parce qu'alors, on peut utiliser des modèles de parallélisme adaptés à chaque situation. Par exemple, dans Go, on décrit la concurrence avec des goroutines et des channels mais derrière, ça ne dit rien sur la manière dont l'ensemble sera exécuté (et on peut l'exécuter sur un seul thread si on veut).
À mon avis, cette manière de faire a de l'avenir, parce qu'on peut alors séparer le travail en deux : trouver les bons modèles de concurrence, c'est-à-dire les bonnes abstractions qui permettent de raisonner facilement sur le programme (les goroutines/channels sont un exemple mais il y en a beaucoup d'autres); trouver les bons modèles de parallélisme, même si, à mon avis, le travail est déjà plus avancé de ce côté.