concurrency - lenguaje - joe armstrong

Estilo Erlang concurrencia en el lenguaje de programación D (3)

Creo que la concurrencia de estilo Erlang es la respuesta al crecimiento exponencial del recuento de núcleos. Puedes simularlo con otros lenguajes principales. Pero las soluciones siempre me dejan con ganas. No estoy dispuesto a renunciar a la programación multi-paradigma (C ++ / D) para cambiar a la sintaxis draconiana de Erlang.

¿Qué es la concurrencia de estilo Erlang?

De uno de los autores del lenguaje ( ¿Cuál es el modelo de concurrencia de Erlang en realidad? ):

Concurrencia ligera
Barato para crear hilos y barato para mantener números locos.
Comunicación asíncrona.
Los hilos solo se comunican vía mensajes.
Manejo de errores.
Proceso de aislamiento.

O de un blogger informado ( ¿Qué es la concurrencia al estilo Erlang? ):

Proceso rápido de creación / destrucción
Capacidad para soportar >> 10 000 procesos concurrentes con características prácticamente sin cambios.
Rápido paso de mensajes asíncronos.
Copiar semántica de paso de mensajes (concurrencia de compartir-nada).
Seguimiento de procesos.
Recepción selectiva de mensajes.

Creo que el paso de mensajes de D puede lograr la mayoría de estas características. Los temas sobre los que me pregunto son " >> 10,000 procesos concurrentes (subprocesos) " y " creación / destrucción rápida de procesos ".

¿Qué tan bien maneja D estos requisitos?

Creo que para apoyarlos correctamente tendrías que usar hilos verdes . ¿Se pueden usar las funciones de paso de mensajes de D con la biblioteca de hilos verdes?

Esta funcionalidad se usa con frecuencia en combinación con E / S asíncrona para comunicarse de manera eficiente con fuentes de datos externas. El marco vibe.d parece ofrecer tanto el modelo de subprocesos de subprocesos de muchas fibras en unos pocos SO como las bibliotecas de E / S asíncronas (además de un montón de bibliotecas de aplicaciones web y herramientas de gestión de proyectos).

Como una nota al margen no relacionada, es bastante alucinante que D sea lo suficientemente bajo como para que puedas escribir este marco y lo suficientemente alto como para ser un lenguaje atractivo para escribir tus aplicaciones web en la parte superior del marco. Otros lenguajes populares con marcos similares (node.js, Ruby''s EventMachine, coroutines en Python y Go) no pueden competir con D en la codificación de sistemas de bajo nivel. Otros lenguajes populares con instalaciones de programación de sistemas similares (C, C ++) no pueden competir en la codificación de aplicaciones de alto nivel.

Soy nuevo en D, pero tengo que decir, me gusta lo que veo.

Por lo poco que sé sobre D: su infraestructura de paso de mensajes está construida sobre sus instalaciones de subprocesos. Si la biblioteca de subprocesos del núcleo es una envoltura en los subprocesos del sistema operativo, hay pocas posibilidades de que la concurrencia en D alcance la magnitud (>> 10000) de Erlang. Además, D no impone la inmutabilidad en los objetos, por lo que es fácil desordenar las cosas. Entonces, Erlang es la mejor opción para la concurrencia pesada. Probablemente pueda escribir las cosas de concurrencia en Erlang y el resto del proyecto en D. Aun así, es posible tener hilos verdes eficientes en C como lenguajes (C ++, D, etc.) - vea Protothreads y ZeroMQ . Puede implementar marcos de mensajería muy eficientes utilizando estos, y llamándolos a través de un C o directamente desde D.

El almacenamiento es de subprocesos por defecto en D, por lo que no se comparte nada entre los subprocesos a menos que se marque específicamente como shared . Si marca una variable como shared , puede utilizar las exclusiones y condiciones tradicionales, así como los objetos sincronizados y similares para tratar la concurrencia. Sin embargo, el medio preferido de comunicación entre subprocesos es usar las facilidades de paso de mensajes en std.concurrency y dejar que todos los datos permanezcan en subprocesos locales, solo usarlos cuando sea necesario. Todos los objetos pasados entre subprocesos que utilizan std.concurrency deben pasarse por valor o ser inmutables, por lo que no se produce el intercambio y es completamente seguro para subprocesos. Sin embargo, actualmente puede ser un poco molesto obtener un tipo de referencia inmutable que no sea una matriz ( idup generalmente facilita las matrices), por lo que puede ser un poco molesto pasar algo que no sea tipos de valor o matrices ( aunque es de esperar que la situación mejore pronto a medida que el compilador y los errores de la biblioteca estándar relacionados con const e immutable se solucionan y más código se hace const-correct).

Ahora, mientras que el paso de mensajes en D definitivamente resultará en un código más limpio y más seguro que lo que obtendría en lenguajes como C ++ o Java, está construido sobre la normalidad, los subprocesos C (por ejemplo, Linux usa pthreads), por lo que no tiene el tipo de hilos livianos que hace Erlang, y así tratar con múltiples hilos no va a ser tan eficiente como Erlang.

Por supuesto, no veo ninguna razón por la que no se pueda escribir un sistema de subprocesos más eficiente usando D, en cuyo punto es posible que pueda obtener una eficiencia de subprocesos similar a la de Erlang, y presumiblemente podría usar una API similar a la de std.concurrency, pero todo el material de subprocesamiento estándar de D se basa en los subprocesos C normales, por lo que tendría que hacer todo eso usted mismo, y dependiendo de cómo lo implementó y dependiendo de cómo exactamente el subproceso local. / El compilador y el tiempo de ejecución se encargan de las cosas shared , podría ser difícil obtener el sistema de tipos para hacer que todo sea local en los subprocesos con los subprocesos "verdes". Me temo que no sé lo suficiente sobre cómo se implementa el uso shared o cómo funcionan los hilos "verdes" para saberlo con seguridad.

En cualquier caso, el sistema de paso de mensajes de D sin duda dará como resultado que los hilos sean más agradables que C ++ o incluso Java, pero no está diseñado para simplificarse de la misma manera que Erlang. D es un lenguaje de sistemas de propósito general, no un lenguaje diseñado específicamente para usar hilos para todo y, por lo tanto, para usarlos de la manera más eficiente posible. Una gran parte de las instalaciones estándar de D se construyen sobre C, por lo que muchas de sus características de eficiencia serán similares a las de C.