Mon avis sur la question s'exprime en une ligne : L'idéal serait de cacher au maximum cette complexité au programmeur, bref faire en sorte que le compilateur gère lui-même.
C'est un modèle qui propose une syntaxe pour Eiffel permettant de définir quand est-ce qu'un appel de message est asynchrone ou non.
Eiffel Software l'a implémenté en 1995.
Puisque la nature revient au galop ;-) je précise que le brouillon de publication que j'ai présenté sur ce site, n'est autre que l'adaptation du modèle SCOOP à un langage objet à prototype compilé.
L'idée de ce modèle est de permettre de la programmation parallèle, en pensant son code en tant que système multi agent.
Les problèmes de multithread ne se posent pas trop car les zones mémoires entre thread sont, dans ce modèle, étanches. C'est un peu l'idée de SCOOP.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par Ontologia (site web personnel) . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 3.
Bertrand Meyer, le concepteur d'Eiffel à conçu pour cela le modèle SCOOP : http://se.inf.ethz.ch/teaching/ss2004/0268/lectures/251-0268(...) pour Simple Concurrent Object-Oriented Computation
C'est un modèle qui propose une syntaxe pour Eiffel permettant de définir quand est-ce qu'un appel de message est asynchrone ou non.
Eiffel Software l'a implémenté en 1995.
Puisque la nature revient au galop ;-) je précise que le brouillon de publication que j'ai présenté sur ce site, n'est autre que l'adaptation du modèle SCOOP à un langage objet à prototype compilé.
https://linuxfr.org/~Montaigne/20582.html
L'idée de ce modèle est de permettre de la programmation parallèle, en pensant son code en tant que système multi agent.
Les problèmes de multithread ne se posent pas trop car les zones mémoires entre thread sont, dans ce modèle, étanches. C'est un peu l'idée de SCOOP.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker