Tu peux enlever les guillemets à « "modèles de programmation parallèle" ». ;-)
Plus sérieusement, tu as techniquement raison, mais ce qui est intéressant avec les langages qui offrent un modèle de programmation parallèle, c'est qu'ils ont aussi tendance à définir un modèle d'execution parallèle qui va avec. Dans le cas de C11/C++1x c'est un modèle très (trop) relâché selon moi, mais c'est parce qu'ils sont tributaires de l'existant (Pthreads en particulier, mais aussi le besoin de pouvoir laisser une machine parallèle optimiser tout un tas de trucs à sa façon).
Mais les langages/modèles de prog de type OpenMP offrent un modèle d'exécution expliquant quand une région parallèle peut être créée (modèle de concurrence), quel est le mode d'orchestration des threads (modèle de synchronisation), et comment et dans quel ordre la mémoire peut être accédée (modèle mémoire). Dans le modèle de synchro, on compte par exemple une proposition de moniteurs dans OpenMP (via la construction critical), etc. Maintenant, ça n'empêche pas qu'il reste possible d'avoir une data race, mais justement, c'est l'intérêt d'un modèle d'exécution : il spécifie un modèle mémoire. Dedans, on spécifie le mode d'adressage (au minimum, si on a une mémoire partagée ou distribuée), et le modèle de constance mémoire (memory consistency). Dans ce dernier cas, on spécifie dans quel ordre les différentes opérations mémoire peuvent arriver, s'il y a une différence entre des opérations normales ou des opérations « synchronisantes » (par exemple dans OpenMP, il y a la clause atomic; dans Java, il y a le mot-clef volatile; etc.).
De façon générale, la question n'est pas tant de savoir s'il peut y avoir un conflit sur les données partagées — dès lors que tu autorises le partage mémoire implicite, ça peut arriver. Cependant, si le modèle mémoire que tu utilises est logique/compréhensible, tu peux espérer débugger ton code plus facilement qu'avec un modèle complexe. Ironiquement, je pense qu'il est plus facile de débugger du code C++ concurrent, car data race = UB, et donc généralement ça veut dire « on laisse le matériel sous-jacent se débrouiller », alors qu'en Java par exemple, c'est plus subtil, et potentiellement le compilateur a fait des trucs pas cool (aka « des optimisations » — qui sont légales hein).
[^] # Re: Rust et SIMD
Posté par lasher . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 3. Dernière modification le 14 août 2018 à 16:55.
Tu peux enlever les guillemets à « "modèles de programmation parallèle" ». ;-)
Plus sérieusement, tu as techniquement raison, mais ce qui est intéressant avec les langages qui offrent un modèle de programmation parallèle, c'est qu'ils ont aussi tendance à définir un modèle d'execution parallèle qui va avec. Dans le cas de C11/C++1x c'est un modèle très (trop) relâché selon moi, mais c'est parce qu'ils sont tributaires de l'existant (Pthreads en particulier, mais aussi le besoin de pouvoir laisser une machine parallèle optimiser tout un tas de trucs à sa façon).
Mais les langages/modèles de prog de type OpenMP offrent un modèle d'exécution expliquant quand une région parallèle peut être créée (modèle de concurrence), quel est le mode d'orchestration des threads (modèle de synchronisation), et comment et dans quel ordre la mémoire peut être accédée (modèle mémoire). Dans le modèle de synchro, on compte par exemple une proposition de moniteurs dans OpenMP (via la construction
critical), etc. Maintenant, ça n'empêche pas qu'il reste possible d'avoir une data race, mais justement, c'est l'intérêt d'un modèle d'exécution : il spécifie un modèle mémoire. Dedans, on spécifie le mode d'adressage (au minimum, si on a une mémoire partagée ou distribuée), et le modèle de constance mémoire (memory consistency). Dans ce dernier cas, on spécifie dans quel ordre les différentes opérations mémoire peuvent arriver, s'il y a une différence entre des opérations normales ou des opérations « synchronisantes » (par exemple dans OpenMP, il y a la clauseatomic; dans Java, il y a le mot-clefvolatile; etc.).De façon générale, la question n'est pas tant de savoir s'il peut y avoir un conflit sur les données partagées — dès lors que tu autorises le partage mémoire implicite, ça peut arriver. Cependant, si le modèle mémoire que tu utilises est logique/compréhensible, tu peux espérer débugger ton code plus facilement qu'avec un modèle complexe. Ironiquement, je pense qu'il est plus facile de débugger du code C++ concurrent, car data race = UB, et donc généralement ça veut dire « on laisse le matériel sous-jacent se débrouiller », alors qu'en Java par exemple, c'est plus subtil, et potentiellement le compilateur a fait des trucs pas cool (aka « des optimisations » — qui sont légales hein).