Je suis plutôt d'accord avec ce point de vue, mais le problème c'est que parfois tu ne peux pas repenser l'architecture du code pour ne pas avoir d'état partagé à cause de contraintes externes.
C'est peut être un exemple de niche, mais c'est le premier qui me vient à l'esprit : l'api POSIX. Si tu veux implémenter un noyau respectant l'API POSIX, tu es quasiment obligé d'avoir des états partagés à beaucoup d'endroits (même si tu peux t'en passer la plus possible), parce que l'api a justement étée concue dans cette optique : le système de fichier est un espace global partagé.
Evidemment, tu peux inventer de nouveaux types de noyau, par exemple basés sur les capabilities, auquel tu peux appliqué le model acteur et organisé la cooperation des différents composants du système à l'aide de messages et d'états locaux en utilisant les capabilities comme noms vers un état conservé chez le processus distant, voire créer quelque chose de complétement stateless globalement ayant juste des états locaux par sous-système et par cpu par sous-système en utilisant des techniques de hashing pour répartir la charge.
Mais cela requiert souvent de modifier l'API que tu exportes. Encore une fois, les noyaux ne sont qu'un exemple, c'est aussi le cas pour des bibliothèques ancienne que tu voudrais mettre à jour pour en améliorer les performances sur les cpu modernes.
Il y a un autre point important à prendre en compte à mon avis : même si je suis convaincu que ne pas partager d'état global est gagnant sur le long terme parce que cela simplifie beaucoup la manière de raisonner sur des bases de code assez larges, cela peu sembler beaucoup plus contraignant à court terme. En effet, je trouve qu'il y a un effort de reflexion supplémentaire pour créer une architecture basée sur des modules entièrement découplés, comparé à l'ajout de verrous un peu partout.
En pratique, les paradigmes de programmation principaux, que ça soit la programmation orientée objet ou la programmation fonctionnelle sont entièrement basés sur ce principe là et devrait conduire à des design qui se parallélise sans trop d'effort, mais force est de constater que ça reste de la responsabilité du programmeur d'archicturer le code proprement. No silver bullet, le langage ne te force jamais à faire les choses comme il faut, il fournit juste des abstractions pour le permettre.
[^] # Re: Mon expérience
Posté par Enj0lras . En réponse à la dépêche Instantané sur le parallélisme et le code. Évalué à 2.
Je suis plutôt d'accord avec ce point de vue, mais le problème c'est que parfois tu ne peux pas repenser l'architecture du code pour ne pas avoir d'état partagé à cause de contraintes externes.
C'est peut être un exemple de niche, mais c'est le premier qui me vient à l'esprit : l'api POSIX. Si tu veux implémenter un noyau respectant l'API POSIX, tu es quasiment obligé d'avoir des états partagés à beaucoup d'endroits (même si tu peux t'en passer la plus possible), parce que l'api a justement étée concue dans cette optique : le système de fichier est un espace global partagé.
Evidemment, tu peux inventer de nouveaux types de noyau, par exemple basés sur les capabilities, auquel tu peux appliqué le model acteur et organisé la cooperation des différents composants du système à l'aide de messages et d'états locaux en utilisant les capabilities comme noms vers un état conservé chez le processus distant, voire créer quelque chose de complétement stateless globalement ayant juste des états locaux par sous-système et par cpu par sous-système en utilisant des techniques de hashing pour répartir la charge.
Mais cela requiert souvent de modifier l'API que tu exportes. Encore une fois, les noyaux ne sont qu'un exemple, c'est aussi le cas pour des bibliothèques ancienne que tu voudrais mettre à jour pour en améliorer les performances sur les cpu modernes.
Il y a un autre point important à prendre en compte à mon avis : même si je suis convaincu que ne pas partager d'état global est gagnant sur le long terme parce que cela simplifie beaucoup la manière de raisonner sur des bases de code assez larges, cela peu sembler beaucoup plus contraignant à court terme. En effet, je trouve qu'il y a un effort de reflexion supplémentaire pour créer une architecture basée sur des modules entièrement découplés, comparé à l'ajout de verrous un peu partout.
En pratique, les paradigmes de programmation principaux, que ça soit la programmation orientée objet ou la programmation fonctionnelle sont entièrement basés sur ce principe là et devrait conduire à des design qui se parallélise sans trop d'effort, mais force est de constater que ça reste de la responsabilité du programmeur d'archicturer le code proprement. No silver bullet, le langage ne te force jamais à faire les choses comme il faut, il fournit juste des abstractions pour le permettre.