Comment les acteurs fonctionnent-ils par rapport aux threads?
Y a-t-il une bonne et courte explication de la façon dont Acteurs fonctionne par rapport aux threads?
Un thread ne peut-il pas être vu comme un acteur et envoyer des messages à d'autres threads? Je vois une différence, mais ce n'est pas si clair pour moi. Puis-je utiliser Acteurs dans n'importe quelle langue en utilisant les threads différemment?
Le modèle d'acteur fonctionne sur le passage de messages. Les processus individuels (acteurs) sont autorisés à s’envoyer des messages de manière asynchrone. Ce qui le distingue de ce que nous considérons normalement comme le modèle de filetage, c'est qu'il n'y a (en théorie du moins) aucun état partagé. Et si l'on croit (à juste titre, je pense) que l'état partagé est la racine de tout mal, alors le modèle d'acteur devient très attrayant.
Nous ne devons cependant pas nous exciter. Le modèle d'acteur ne rend pas (contrairement à certaines allégations) impossible d'avoir des impasses. Le modèle d'acteur ne vous empêche pas non plus d'avoir des conflits de ressources entre différents processus - les files d'attente de messages, par exemple. Le modèle est seulement "sans verrouillage" au-dessus d'un certain niveau. À un niveau inférieur, pour la coordination des files d'attente de messages, le verrouillage est toujours requis.
Un fil de discussion ne peut-il pas être vu comme un acteur et envoyer des messages à d'autres fils de discussion?
Eh bien, oui et non. Non, si vous utilisez simplement l'approche consistant à placer des mutex autour des emplacements de mémoire partagée. Ensuite, les threads partagent cet état - ils ont tous les deux accès à cette mémoire, peuvent tous les deux le lire, le réécrire, etc. sous. J'ai piraté quelque chose comme ça (très mal) en donnant à chaque thread une file d'attente gardée par un mutex - juste pour le plaisir. Pour avoir une idée de la gestion de l'impédance du fil d'acteur, voir ma question d'il y a un an .
Puis-je utiliser le modèle d'acteur dans n'importe quelle langue en utilisant les threads différemment?
Oui, mais cela demandera un peu plus de travail. Votre langue préférée pourrait bien avoir une bibliothèque de transmission de messages, ce serait donc la première chose à étudier. Vous devez également étudier l'utilisation de structures de données immuables. Notez que si une structure de données est immuable, alors vous avez essentiellement traité le problème de "l'état partagé" - plusieurs threads peuvent contenir des références à des données immuables sans que rien ne se passe. Il y a une raison pour laquelle les langages d'acteurs sont également des langages fonctionnels (erlang, scala).
Vous pouvez également consulter la mémoire transactionnelle logicielle, qui est un modèle différent mais également convaincant. Clojure en est mon exemple préféré.
Je ne dirais pas que les acteurs passent toujours des messages de manière asynchrone - ce serait trop lent. À titre d'exemple, le projet JActor utilise des messages bidirectionnels (demande/réponse) pour mieux modéliser un appel de méthode. Et la plupart des demandes sont traitées de manière synchrone.
JActor (une bibliothèque Java) n'utilise pas non plus de verrous. Seules certaines structures de données atomiques et simultanées, avec quelques sémaphores ajoutés. Le passage des messages est d'environ 0,8 milliard de messages par seconde.