Paso de mensaje frente a bloqueo

Question

¿Cuál es exactamente la diferencia entre los esquemas de simultaneidad de paso de mensajes y los esquemas de simultaneidad basados ​​en bloqueos, en términos de rendimiento? Un subproceso que está esperando en un bloque de bloqueo, para que se puedan ejecutar otros subprocesos. Como resultado, no veo cómo el envío de mensajes puede ser más rápido que la concurrencia basada en bloqueos.

Editar: Específicamente, estoy discutiendo un enfoque de paso de mensajes como en Erlang, en comparación con un enfoque de datos compartidos utilizando bloqueos (o operaciones atómicas).

Answer 1

Usando el mensaje que pasa cuando todo lo que desea hacer es bloquear es incorrecto. En esos casos, use el bloqueo. Sin embargo, la transmisión de mensajes le ofrece mucho más que solo bloquear, como su nombre lo indica, le permite pasar mensajes, es decir, datos, entre hilos o procesos.

Answer 2

La transmisión de mensajes (con mensajes inmutables) es más fácil de hacer bien. Con bloqueo y estado mutable compartido es muy difícil evitar errores de concurrencia.

En cuanto al rendimiento, es mejor que lo mida usted mismo. Cada sistema es diferente: cuáles son las características de la carga de trabajo, las operaciones dependen de los resultados de otras operaciones o son total o principalmente independientes (lo que permitiría el paralelismo masivo), latencia o rendimiento más importante, cuántas máquinas hay, etc. podría ser más rápido, o de nuevo el mensaje puede pasar, o algo completamente diferente. Si el mismo enfoque que en LMAX se ajusta al problema en cuestión, entonces tal vez podría ser. (Yo clasificaría la arquitectura LMAX como paso de mensaje, aunque es muy diferente al paso de mensajes basado en actores.)

Answer 3

Como han sugerido otros ("manzanas y naranjas"), veo estas dos técnicas como ortogonales. La suposición subyacente aquí parece ser que uno elegirá uno u otro: o usaremos recursos bloqueados y compartidos o usaremos el paso de mensajes, y el otro hace innecesario el otro, o tal vez el otro no está disponible .

Al igual que, por ejemplo, un evaluador metacircular, no es obvio cuáles son los verdaderos primitivos aquí. Por ejemplo, con el fin de implementar mensaje de paso, es probable que necesite atomic CAS y semántica de visibilidad de memoria particular, o tal vez algún bloqueo y estado compartido. Uno puede implementar operaciones atómicas en términos de bloqueos, o uno puede implementar bloqueos en términos de operaciones atómicas (como lo hace Java en sus tipos java.util.concurrent.locks).

Del mismo modo, aunque es cierto que es un estiramiento, uno podría implementar el bloqueo con el envío de mensajes. Preguntar cuál tiene un mejor rendimiento no tiene mucho sentido en general, porque en realidad se trata más de una pregunta sobre qué se construye en términos de qué. Lo más probable es que el que está en el nivel inferior puede manejarse mejor por un programador capaz que el construido en la parte superior —, como ha sido el caso con los autos de transmisión manual hasta hace poco (un debate allí también).

Por lo general, el enfoque de paso de mensajes no es alabado por un mejor rendimiento, sino por seguridad y conveniencia, y generalmente se vende al denegar al programador el control de bloqueo y recursos compartidos. Como resultado, apuesta contra la capacidad del programador; si el programador no puede adquirir un bloqueo, no puede hacerlo mal y ralentizar el programa. Al igual que un debate sobre la gestión manual de la memoria y la recolección de basura, algunos afirmarán ser "buenos conductores", aprovechando al máximo el control manual; otros — especialmente los que implementan y promueven el uso de un recolector de basura — alegarán que, en conjunto, el recolector puede hacer un mejor trabajo que los "controladores no tan buenos" con la gestión manual.

No hay una respuesta absoluta. La diferencia aquí radicará en el nivel de habilidad de los programadores, no con las herramientas que pueden manejar.

Answer 4

En mi humilde opinión, la transmisión de mensajes probablemente no es exactamente un esquema de simultaneidad. Básicamente es una forma de comunicación entre procesos (IPC), una alternativa a los objetos compartidos. Erlang solo favorece el envío de mensajes a objetos compartidos.

contras de objetos compartidos (Pros od paso de mensajes):

• El estado de los objetos mutables/compartidos son más difíciles de razonar acerca de en un contexto en el que múltiples hilos se ejecutan simultáneamente.
• La sincronización en un objeto compartido daría lugar a algoritmos que son inherentemente no wait free o no lock free.
• En un sistema de multiprocesador, un objeto compartido se puede duplicar en cachés de procesador. Incluso con el uso de algoritmos basados ​​en Comparar y Cambiar que no requieren sincronización, es posible que se gasten muchos ciclos de procesador enviando mensajes de coherencia de caché a cada uno de los procesadores.
• Un sistema construido con Semántica de pase de mensajes es intrínsecamente más escalable. Como el paso de mensajes implica que los mensajes se envían de manera asincrónica, no se requiere que el remitente bloquee hasta que el receptor actúe sobre el mensaje.

Pros de objetos compartidos (Contras de paso de mensajes):

• algunos algoritmos tienden a ser mucho más simple.
• Un sistema de paso de mensajes que requiere que los recursos se bloqueen eventualmente degenerará en un sistema de objeto compartido. Esto es a veces evidente en Erlang cuando los programadores comienzan a usar las tablas de ets, etc. para almacenar el estado compartido.
• Si los algoritmos son de espera, verá un mejor rendimiento y una menor huella de memoria, ya que hay mucha menos asignación de objetos en forma de mensajes nuevos.

Answer 5

paso de mensajes no utilizan la memoria compartida, lo que significa que no necesita cerraduras, hacer que cada hilo (proceso) sólo se puede cargar o almacenar su propia memoria, la manera en que se comunican entre sí es enviar & recibir mensajes.