Quand tu programmes dans un langage impératif (comme le C) en mono-thread, tu sais dans quel ordre les instructions seront exécutées. Quand tu programmes en multi-thread, tu ne sais pas si telle instruction du thread 1 sera exécutée avant ou après telle autre du thread 2.
La solution la plus simple pour ne pas avoir de problèmes, c'est de mettre dans chaque thread des calculs complètement indépendants, de sorte qu'on n'a pas besoin de se préoccuper de leur ordre d'exécution. C'est plus ou moins facile selon le problème à traîter, mais en règle générale c'est très difficile.
Comme on ne peut pas en général faire ça, on essaye d'avoir des traitements relativement indépendants dans chaque thread, et de "verrouiller" les ressources partagées lorsqu'on les modifie, pour éviter que deux threads se perturbent l'un l'autre. On a différents outils pour ça: verrouiller une variable pour etre sur que personne ne la modifie tant qu'on n'a pas fini, attendre qu'une condition soit vraie, etc. Sécuriser complètement son code ainsi est assez lourd.
Enfin, une conséquence amusante (ou pas) de l'ordre apparemment "aléatoire" d'exécution des instructions, c'est qu'il est très difficile de reproduire les bugs. Parfois un bug c'est produit parce que telle instruction s'est produite avant telle autre, parce que tel coeur était plus chargé que l'autre à ce moment. Reproduire les mêmes conditions est pour l'instant assez compliqué.
La solution la plus satisfaisante intellectuellement parlent est d'utiliser un langage fonctionnel, dans lequel on n'a pas d'instuctions qui s'exécutent dans l'ordre, et pas d'effets de bord à l'exécution d'une fonction. Le compilateur est beaucoup plus à même de répartir les calculs entre plusieurs threads dans ce cas.
[^] # Re: Re:
Posté par Yusei (Mastodon) . En réponse au journal encoder sur du multicoeur. Évalué à 8.
La solution la plus simple pour ne pas avoir de problèmes, c'est de mettre dans chaque thread des calculs complètement indépendants, de sorte qu'on n'a pas besoin de se préoccuper de leur ordre d'exécution. C'est plus ou moins facile selon le problème à traîter, mais en règle générale c'est très difficile.
Comme on ne peut pas en général faire ça, on essaye d'avoir des traitements relativement indépendants dans chaque thread, et de "verrouiller" les ressources partagées lorsqu'on les modifie, pour éviter que deux threads se perturbent l'un l'autre. On a différents outils pour ça: verrouiller une variable pour etre sur que personne ne la modifie tant qu'on n'a pas fini, attendre qu'une condition soit vraie, etc. Sécuriser complètement son code ainsi est assez lourd.
Enfin, une conséquence amusante (ou pas) de l'ordre apparemment "aléatoire" d'exécution des instructions, c'est qu'il est très difficile de reproduire les bugs. Parfois un bug c'est produit parce que telle instruction s'est produite avant telle autre, parce que tel coeur était plus chargé que l'autre à ce moment. Reproduire les mêmes conditions est pour l'instant assez compliqué.
La solution la plus satisfaisante intellectuellement parlent est d'utiliser un langage fonctionnel, dans lequel on n'a pas d'instuctions qui s'exécutent dans l'ordre, et pas d'effets de bord à l'exécution d'une fonction. Le compilateur est beaucoup plus à même de répartir les calculs entre plusieurs threads dans ce cas.