Acteurs: Comment gérer efficacement les données principalement en lecture

Question

Supposons que j'ai un acteur qui a un seul champ. 99 sur 100 messages à un acteur lire la valeur, et les mises à jour de la 100ème valeur. Dans ce cas, je voudrais processus se lit en parallèle. En d'autres termes, comment puis-je obtenir les performances de lecture / écriture des serrures avec des acteurs? Est-ce pratique avec des acteurs Scala standard ou Akka? Ou suis-je manque le point d'acteurs:)

Mise à jour: langue confusion fixe, désolé

Answer 1

[Avertissement: Je suis le bon de commande de Akka]

Je suggère d'utiliser à la place d'agents, la lecture peut se faire à tout moment, mais seulement une écriture à la fois.

http://doc.akkasource.org/agents-scala

EDIT: http://doc.akka.io /docs/akka/2.1.0/scala/agents.html (essayez ce lien)

Answer 2

Vous êtes absent tout à fait peut-être le point d'acteurs. Je suppose que vous voulez un acteur auquel vous envoyez une requête, puis il renvoie une réponse. Il y a un montant équitable des machines impliquées dans l'envoi d'un acteur un message, le traitement, et l'envoi d'un retour de réponse. La génération actuelle du message de réponse sera créé comme une tâche et soumise à un pool de threads. Entre la file d'attente des messages et le pool de threads il y a plusieurs endroits qui nécessitent des serrures ou au mieux les opérations de CAS. Habituellement, le point est que l'acteur fera un travail hors dans un thread séparé en fonction de ce message.

Si vous voulez juste lire et les données rarement écrire (comme incrémenter un compteur, ou l'accès à une valeur sur une carte), vous serez beaucoup mieux d'utiliser une classe appropriée de java.util.concurrent.

Answer 3

Je suppose que vous voulez dire que tous les messages sont immuables et que presque tous les messages ne mutent pas l'état de l'acteur. Dans ce cas, les acteurs ne sont probablement pas le meilleur choix de design. Les acteurs vous permettent de gérer tout état mutable comme si vous traitez avec le code seul thread.

En effet, chaque acteur a une boîte aux lettres à laquelle les messages sont envoyés et ensuite traitées une à la fois. Dans votre scénario, ce serait tout à fait inutile. Comme l'a suggéré, en utilisant quelque chose de java.util.concurrent serait plus efficace.

Answer 4

Les acteurs sont conçus pour traiter les messages en série. Cela les rend facile à raisonner sur: vous obtenez un message à la fois, donc toutes les variables de l'acteur (tant qu'ils ne sont pas mutées par quelqu'un d'autre) peuvent être modifiés sans penser à la concurrence. Est-ce la méthode la plus efficace? Absolument pas! Mais un code peu efficace qui fonctionne correctement est presque toujours mieux que Code très efficace qui est cassé .

Ce que vous demandez est exactement le contraire: vous voulez penser explicitement à propos afin de concurrency gagner de la vitesse de traitement ( « Je sais que 99% des accès sera lit et peut donc se produire en parallèle! »). Dans ce cas, vous voulez probablement utiliser java.util.concurrent.locks.ReentrantReadWriteLock pour contrôler l'accès directement à une variable mutable (si le type d'accès trouvée dans java.util.concurrent.atomic._ ne fonctionne pas pour vous). Rappelez-vous que vous avez maintenant pris la charge d'obtenir le verrouillage à droite et être correctement prudent.