Acabo de comenzar a aprender sobre seguridad de hilos. Esto me está haciendo codificar mucho más a la defensiva, quizás también a la defensiva.¿Puedo ignorar la seguridad del hilo cuando programo en Erlang?
¿Usar un lenguaje funcional como Erlang me libraría por completo de esta preocupación?
en Erlang el estado de la unidad de ejecución no es un hilo, sino un proceso. sí, es un tipo de proceso liviano implementado sobre los hilos; pero es más como un proceso que un hilo.
El punto principal es que los procesos no comparten estado, pasan mensajes; mientras que los hilos lo comparten todo por defecto, y tienen que arbitrar para evitar el caos.
por lo tanto, no necesita seguridad de subprocesos ya que no está trabajando con subprocesos.
Descargo de responsabilidad: I know almost no Erlang. Toma mi opinión con un grano de sal.
Un lenguaje puramente funcional que (obviamente) solo permite funciones "puras". Wiki dice que las funciones puras siempre son seguras para hilos, lo que confirma mi instinto sobre ese tema.
Pero no sé si Erlang es puramente funcional (wiki implica lo contrario, así que supongo que no). Tal vez use otros medios para lograr la seguridad de la hebra. De todos modos, sus estructuras de datos son (¿la mayoría? ¿Exclusivas?) Inmutables y, por lo tanto, inherentemente son seguras para subprocesos. Y al ser un lenguaje funcional, al menos el código idiomático de Erlang no usará (¿muc? Alguna?) Variables globales, sino que usará funciones puras en su lugar. Esos son seguros para subprocesos. Pero las cosas I/O pueden seguir siendo un problema ... si un programa Erlang lee y escribe un archivo al mismo tiempo, es poco probable que dicho código no sea seguro para subprocesos. Pero la mayoría de las veces, estarás bien gracias a las estructuras de datos inmutables y demás.
Javier tiene razón.
Sin embargo, me gustaría agregar algo como me ha llamado antes. Si está trabajando con un controlador integrado o nif, puede que ya no sea seguro para subprocesos. Parece obvio ya que el controlador o nif usará el código C o C++, pero vale la pena mencionarlo. Por lo tanto, no puede ignorar por completo la seguridad de las cadenas de caracteres simplemente porque está usando Erlang.
No. Consulte Erlang Style Actors Are All About Locking. Es mucho más fácil lograr seguridad de subprocesos en un lenguaje funcional, pero necesita pensar en ello.
Acabo de empezar a aprender sobre seguridad de hilos. Esto me está haciendo codificar mucho más defensivamente, quizás demasiado a la defensiva.
Tenga en cuenta que en ese caso es muy probable que todavía esté haciendo cosas incorrectas. La concurrencia de todo-compartido es muy difícil de obtener a la derecha en cualquier cosa excepto en la mayoría de los ejemplos triviales.
Artículo interesante, pero no creo que "thread-safe" signifique dead-lock gratis. En el mundo de Java/C# generalmente significa que un objeto está protegido contra actualizaciones simultáneas y se puede usar en un entorno de subprocesos múltiples de forma segura. La referencia del PO a la programación defensiva sugiere la misma perspectiva. – dsmith
Pero estás en lo cierto. Los nuevos programadores de Erlang no pueden ignorar la posibilidad de bloqueos irrecuperables. Pero lo interesante del artículo es que se escapa a una forma de "romper" un dead-lock sin detener la VM. Abre un shell de Erlang y envía un mensaje al proceso bloqueado. – dsmith
No, aún debe considerar la seguridad de las hebras en Erlang, pero los problemas son mucho más simples de resolver.
He leído an article en el cual el autor señaló que su mensaje API puede causar problemas de enhebrado. El ejemplo giró en torno a una cuenta bancaria. Su mensaje inicial API tenía operaciones GET y SET. Algunos códigos que querían depositar $ 100 obtendrían el valor actual, agregarían 100 y luego SET el resultado. Por supuesto, esto solo funciona si un proceso único está accediendo a la cuenta bancaria. Una vez que dos procesos están manipulando el saldo, todas las apuestas están desactivadas.
Su solución fue cambiar el mensaje API a DEPÓSITO y RETIRO (en realidad usa un mensaje - ACTUALIZAR - pero se entiende la idea). Esto hace que la interacción asuma semántica atómica: el proceso de escucha solo procesará un depósito o retiro a la vez, y bloqueará otras solicitudes hasta que se complete la primera.
Vale la pena señalar que este problema es esencialmente el mismo que el problema de memoria compartida. (Si usamos los mensajes GET y SET para interactuar con un proceso, esencialmente hemos creado alguna memoria compartida). Otro blogger compares ets to shared memory también. Sin embargo, siempre que comprenda dónde ha introducido construcciones similares a la memoria compartida y regule el acceso a esa memoria compartida, no debería tener ningún problema de subprocesamiento (que no sea un interbloqueo, por supuesto).
+1 exactamente –
Pero necesitas "seguridad en el proceso" :) –