Actores: Cómo manejar eficientemente los datos leídos en su mayoría

Question

Supongamos que tengo un actor que tiene un solo campo. 99 de cada 100 mensajes a un actor leyó el valor, y los cambios de valor del número 100. En este caso, me gustaría proceso lee en paralelo. En otras palabras, ¿cómo puedo conseguir el rendimiento de lectura / escritura utilizando cerraduras actores? Es esta práctica con actores Scala estándar o Akka? O me estoy perdiendo el punto de actores:)

Actualización: fijo lenguaje confuso, lo siento

Answer 1

[exención de responsabilidad: Soy el PO de Akka]

sugiere emplear Agentes lugar, la lectura se puede hacer en cualquier momento, pero sólo una escritura a la vez.

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

EDIT: http://doc.akka.io /docs/akka/2.1.0/scala/agents.html (tratar este enlace)

Answer 2

Usted está muy posiblemente perdiendo el punto de actores. Estoy asumiendo que usted quiere un actor al que se envía una consulta, y luego se devuelve una respuesta. Hay una buena cantidad de maquinaria involucrada en el envío de un actor un mensaje, procesarla, y enviar una copia de la respuesta. La generación actual del mensaje de respuesta se creará como una tarea y presentó a un grupo de subprocesos. Entre la cola de mensajes y el grupo de subprocesos hay varios lugares que requieren cerraduras o en el mejor de operaciones CAS. Por lo general, el punto es que el actor va a hacer algún trabajo fuera en un hilo separado sobre la base de ese mensaje.

Si lo que desea es leer y escribir datos rara vez (por ejemplo, incrementando un contador, o el acceso en un valor en un mapa) será mucho mejor usar una clase apropiada de java.util.concurrent <. / P >

Answer 3

Supongo que significa que todos los mensajes son inmutables y que casi todos los mensajes no mutan el estado del actor. En este caso, los actores no son probablemente la mejor opción de diseño. Actores permiten administrar cualquier estado mutable como si se tratara de código de un solo subproceso.

Efectivamente, cada actor dispone de un buzón al que se envían los mensajes y luego se procesan de una en una. En su escenario, esto sería muy derrochador. Como se ha sugerido, usando algo de java.util.concurrent sería más eficaz.

Answer 4

Los actores están diseñados para procesar mensajes en serie. Esto hace que sean fáciles de razonar acerca de: se obtiene un mensaje a la vez, por lo que cualquier variables en el actor (siempre y cuando ellos no están mutados por cualquier otra persona) puede ser modificado sin pensar en la concurrencia. Es este el método más eficiente? ¡Absolutamente no! Pero Código algo ineficaz que funciona correctamente es casi siempre mejor que código altamente eficiente que se rompe .

Lo que se está pidiendo es exactamente lo contrario: que quiere pensar explícitamente sobre la concurrencia con el fin de obtener la velocidad de procesamiento ( "Yo sé que el 99% de los accesos será lee y por lo tanto puede ocurrir en paralelo!"). En este caso, es probable que desee utilizar java.util.concurrent.locks.ReentrantReadWriteLock que directamente controlan el acceso a una variable mutable (si el tipo de acceso encuentra en java.util.concurrent.atomic._ no funciona para usted). Sólo recuerde que usted ahora ha asumido la carga de conseguir el bloqueo correcto, y estar debidamente cuidado.