L'acteur modèle fonctionne sur la transmission de messages. Les processus individuels (les acteurs) sont autorisés à envoyer des messages de manière asynchrone les uns aux autres. Ce qui distingue à partir de ce que nous avons l'habitude de penser que le modèle de thread, c'est qu'il y a (en théorie au moins) aucun état partagé. Et si l'on estime (à juste titre je pense) que l'état partagé est la racine de tous les maux, alors le modèle de l'acteur devient très intéressant.
Nous ne devrions pas obtenir plus excité, cependant. L'acteur modèle n'est pas (contrairement à certaines allégations), il sera impossible d'avoir des blocages. L'acteur modèle ne vous empêche pas d'avoir de conflit pour les ressources entre les différents processus -- files d'attente de messages, par exemple. Le modèle n'est qu'un "lock-free" au-dessus d'un certain niveau. À un niveau inférieur, de la coordination des files d'attente de messages, le verrouillage est toujours nécessaire.
Ne peut pas d'un fil être considéré comme un acteur et envoyer des messages à d'autres threads?
Eh bien, oui et non. Non, si vous êtes juste en utilisant l'approche de la mise mutex de partage des emplacements de mémoire. Le nombre de threads de partager cet état -- ils ont tous deux accès à cette mémoire, peut à la fois lire, ré-écrire, etc. Mais vous pouvez construire un acteur modèle sur un modèle de thread, et en effet tous les acteur de la mise en œuvre n'ont des fils en dessous. J'ai bidouillé quelque chose comme ceci (très mal) en donnant à chaque thread d'une file d'attente protégée par un mutex -- juste pour le plaisir. Pour avoir une idée de la façon dont l'acteur-fil impédance est géré, voir ma question d'il y a un an.
Puis-je utiliser le Modèle de l'Acteur dans une autre langue à l'aide de threads différemment?
Oui, mais ça va prendre un peu plus de travail. La langue de votre choix peut très bien avoir un message de passage de la bibliothèque, alors que ce serait la première chose à étudier. Aussi, vous devez enquêter sur l'utilisation des données immuables structures. Notez que si une structure de données est immuable, alors vous avez essentiellement traitées avec le "partagée-état" problème -- plusieurs threads peuvent contenir des références à des données immuables, sans quelque chose de mauvais se produise. Il ya une raison pourquoi acteur langues ont également tendance à être les langages fonctionnels (erlang, scala).
Vous pouvez aussi avoir un oeil sur le Logiciel de la Mémoire Transactionnelle, ce qui est différent, mais tout aussi convaincantes modèle. Clojure est mon préféré exemple.