Estructuras mundiales dispersas en Erlang

Question

Estoy pensando en cómo proteger un "simulador de granja" de Erlang. Aquí está el resumen básico:

1) Definir un mundo de 100x100 "slots"

2) Las hormigas ocupan una ranura

3) La colonia de hormigas ocupa ubicación 50,50

4) Alimentos se coloca aleatoriamente por el mapa

5) las hormigas mover un espacio a la hora de buscar comida y traerlo de vuelta a la colonia

6) Sólo un objeto puede estar en una ranura a la vez.

El objetivo de este problema es mantener el sistema lo más concurrente posible. En Clojure, el problema anterior se resuelve al tener un grupo de subprocesos de Agentes que cada uno ejecuta la IA para una sola hormiga. Luego estas hormigas actualizan el estado global a través de una transacción.

Es ese estado global en el que sigo pensando. ¿Cómo hacemos para construir el "mundo del juego"?

Mi primer pensamiento es tener un proceso de Erlang para cada hormiga, y luego un proceso para cada ranura en el mapa. Para mover, una hormiga hace lo siguiente:

1) La hormiga le dice a su ranura actual "Quiero mover Norte"

2) La ranura llama la ranura hacia el norte y dice "Por favor, actualice sus contenidos a ahora contiene la hormiga "pid" "

3) Si la ranura norte ya tiene una hormiga, envía una respuesta" denegada "que baja hasta la ranura que contiene la hormiga (y luego a la hormiga). Si la actualización funciona, entonces "concedido" se envía por la cadena y la hormiga actualiza su estado interno.

Lo único que no me gusta de este método es que durante un proceso de movimiento, la hormiga, su ranura y la ranura de destino están todas "bloqueadas" hasta que se completa la transacción. Esto luego se abre para bloqueos. Es decir, dos hormigas podrían estar intentando intercambiar lugares al mismo tiempo, cada ranura estaría esperando a la otra.

¿Alguien puede sugerir una solución mejor?

--- ---- EDITAR

permítanme dar un paso a través del problema de interbloqueo:

1) Ant 1 pide ranura de la A a la "transferencia norte" a la ranura 2 2) Ant 2 pide ranura B a "transferencia sur" a la ranura 1 3) ranura 1 envía una solicitud de transferencia a la ranura 2 y espera una respuesta 4) ranura 2 envía una solicitud de transferencia a la ranura 1 y espera una respuesta

partir de un código perspectiva, esto sería fácil de implementar, pero también bloquearía, ya que cada ranura solo escucha las respuestas f rom la otra ranura. Supongo que la "forma correcta" podría ser rechazar automáticamente todas las solicitudes de transferencia mientras se está realizando una transferencia.

Answer 1

Haga que su hormiga se cuele en la ranura a la que se está mudando, solicitando permiso para moverse. La hormiga espera una respuesta de lanzamiento, diciéndole si la jugada fue exitosa o no. Si la jugada fue exitosa, la hormiga actualiza su propio estado para indicar que está en la nueva ranura. Si falló, nuevamente ejecuta su lógica de búsqueda. Si terminas con A y B tratando de intercambiar máquinas tragamonedas, no tendrás un punto muerto, pero ambos pensarán que tienen que buscar otras opciones.

Si su red está muy ocupada, puede querer que las ranuras ejecuten una lógica de sondeo, entregando permiso a las hormigas vecinas, diciéndoles que si su lógica las conduce allí, pueden ingresar. (Imagine una cuadrícula con 50x50-2 hormigas, y verá por qué esto sería un buen cambio de lógica.)

Nunca use llamadas a menos que absolutamente, sin lugar a dudas, no pueda sobrevivir sin ellos. Y luego, intente deshacerse de ellos si existe la posibilidad de que procesos del mismo tipo se llamen entre ellos o de tipos que puedan llamarse entre sí.

Answer 2

Supongo que cuando no vaya hacia el norte, intentará una dirección diferente después? ¿Dónde está el punto muerto entonces?

Me imagino morir de hambre si el campo está bastante lleno, pero no hay puntos muertos.