Un actor útil y eficiente en Go

Etiquetas

actor, actores, golang

Este es un truco en Go muy útil y eficiente para hacer tareas de «mantenimiento» en estructuras de forma concurrente (y seguramente paralela).

Supongamos que tenéis una lista de elementos, a esta lista se agregan u obtienen elementos pero hay que mantener solamente los últimos N, donde N puede estar basado en una límite temporal.

Las operaciones sobre la lista deben responder muy rápidamente por lo que no es posible llamar a la función que elimina los más antiguos porque tiene un coste computacional (O(n) o O(log n) en el mejor de los casos) que retrasaría la respuesta.

Hay dos técnicas muy habituales en Go:

1. Lanzar al principio una goroutine que periódicamente se ejecute después de una espera con time.Sleep() o usar el time.Ticker que ya hace ambas cosas. El problema con esta solución es que se ejecuta y consume CPU aunque no haya actividad.
2. Lanzar la goroutine cada vez que hay actividad, por ejemplo al agregar u obtener elementos de la lista. El problema, además del pequeño overhead de lanzar la goroutine, es que si hay muchas operaciones se creará un número idénticos de goroutines y seguramente cada una de ellas tendrá que esperar que la otra acabe (se necesitan mutex, la estructura es compartida entre varios hilos de ejecución) y el trabajo se estará haciendo trabajo de más sin ninguna utilidad.

Una tercera forma muy eficiente, algunos le llaman actor (por el modelo de actores). Como en el caso 1 anterior, se lanza una goroutine -el actor– cuando se crea la estructura (o la interfaz), esta rutina sólo espera recibir un mensaje de un canal específico para ella. Cuando recibe un mensaje hace su trabajo y vuelve a esperar por uno nuevo.

Cuidado con las «clever solutions» de concurrencia

Etiquetas

concurrencia, race condition

Ayer a última hora me encontré con este código:

Quité algunas líneas para que no se pudiese deducir la empresa, que no es importante. Tampoco el programador que lo hizo, no es mi intención criticar a nadie en particular sino a una mala práctica de solucionar problemas de concurrencia con «ideas geniales» que no lo son tanta.

El código anterior recibe consultas B2B, graba los resultados en un fichero (por requerimientos de negocio) y luego lee desde esos mismos ficheros para enviar la respuesta a la agencia que hizo la consulta.

Es un software que factura millones de euros al año y pasó semanas de tests y QA. No se descubrió el problema hasta que una de los clientes optimizó sus consultas enviando varias en paralelo. Allí descubrieron que obtenían resultados erróneos: eran duplicados (con un riesgo financiero bastante importante).

Moraleja 1: Los errores de concurrencia son difíciles de encontrar y cuando aparecen suelen ser difíciles de debuguear, ten mucho cuidado antes de implementar soluciones ad-hoc.

El código intenta resolver el problema de concurrencia de varios procesos que podrían escribir en el mismo fichero verificando primero si el fichero existe, si es así incrementa el contador -que forma parte del nombre- hasta que encuentra uno que no coincida.

Además de detalles de eficiencia tiene un problema grave, las operaciones de verificación (file_exists) y creación del fichero (fopen) no son atómicas. Eso significa que varios procesos concurrentes (con una o varias CPUs) verifican, les da falso a todos y luego todos escriben en el mismo fichero. Una race condition de libro.

Moraleja 2: Si has tardado en encontrar el problema o no entiendes la importancia de operaciones atómicas ya deberías estar aprendiendo más de concurrencia.

Afortunadamente entre los tres que estábamos analizando el código en plan «emergencia» y por vídeoconferencia (la captura es del chat de Skype de Linux) desde países diferentes nos dimos cuenta enseguida del bug y de una solución simple: agregar el PID del proceso al nombre del fichero. Como el PID es único en el sistema y cada proceso individual es secuencial no hay riesgos de que sobreescriban en el mismo fichero.

No es la solución más eficiente (ya lo corregiremos estos días con más tranquilidad) pero es una solución segura y que podía implementarse en pocos minutos y sin efectos colaterales que podrían afectar a la lógica del programa.

Además, el bug podría haber sido menos perjudicial si en vez de escribir los resultados en el fichero y luego leerlos para responder se hubiese enviado directamente la respuesta ya almacenada en el proceso local.

Moraleja 3: Si no te has dado cuenta de la diferencia entre datos locales y compartidos y los problemas que pueden generar estos últimos, ponte ya a aprender de concurrencia.

Moraleja 4: Los problemas de concurrencia son muchos más habituales de los que crees y las soluciones no son tan obvias como parecen a primera vista.

Obviamente tengo que recomendar el libro que ya sabéis (y aparece a la izquierda 😉 ) pero ni aún así se puede asegurar que no cometerás errores, se requiere práctica y ser muy cuidadoso.

 

 

 

Versión impresa de «Principios y algoritmos de concurrencia»

Etiquetas

concurrencia, edición impresa

Ya se puede comprar el libro en versión en papel. Está disponible en Amazon (también en .COM y todos los Amazon europeos) y en CreateSpace. En los próximos días y semanas estará disponible en otros canales de distribución, también para universidades e instituciones académicas.

Si adquirís la versión impresa en Amazon luego se puede comprar la versión Kindle por menos de 1 € ($ 0.99). Si tenéis algún problema o si queréis la versión para otro lector avisadme por email (gallir en gmail).

En breve haré una presentación conjuntamente con APSL en el Parc Bit en Palma. En octubre está planificado en Madrid, organizado por Open Innovation de BBA. Iré avisando.

Breve historia

No pensaba sacar, al menos en plazo tan breve, la versión impresa. El libro fue diseñado para un ebook por lo que tenía que solucionar dos problemas:

1. Conversión adecuada a PDF.
2. Editar y modificar porque el código completo no podía ser incluido en el papel. Serían al menos unas doscientas páginas más y tampoco se cuenta con la facilidad de hiperenlace directo a la página del código.

Pero gente de Create Space se puso en contacto conmigo para que lo saque en papel, les expliqué el problema y el trabajo adicional que me costaría la conversión. Consultaron a sus técnicos para ver si podrían convertir desde asciidoc (el formato original en el que escribí) o DocBook (el formato intermedio que usa) pero respondieron que no sabían cómo hacerlo.

Siguieron insistiendo en que haga el esfuerzo hasta que al final me convencieron (gracias Yasmin y Alessandro). El conversor más moderno, asciidoctor-pdf, no funciona correctamente todavía. Era imposible usarlo por lo que tuve que usar el «tradicional» Apache-FO. No es nada simple usarlo, de hecho es muy complicado para hacer funcionar todo el toolchain.

Una solución la dan los scripts de aciidoctor-fopub, al que tuve que hacer algunas modificaciones para que incluya el separador de sílabas. Luego aprender el formato y esquema de las hojas de estilo en XSLT que usa el Apache-FO para poder darle el formato adecuado (tamaño, páginas, fuentes, colores, cabeceras y pie de páginas, etc.).

Una vez solucionado la conversión a PDF el trabajo consistió en eliminar los apéndices y modificar las referencias para indicar los ficheros en el repositorio de Github.

Pero lo que más trabajo me llevó, diría que más de 40 horas, fue solucionar lo de la conversión a PDF que expliqué antes. Luego todo fue más sencillo, y la verdad es que en papel ha quedado muy bien. Bueno, IMHO 🙂

Principios y algoritmos de concurrencia: Fe de erratas

Etiquetas

concurrencia, fe de erratas

Estas son las fe de erratas (disculpas) de las diferentes versiones del libro Principios y algoritmos de concurrencia. Cuando las hago actualizo inmediatamente las versiones de Amazon y Google Play. Pero si la habéis comprado antes no las recibís a menos que notifique que es un error importante, en cuyo caso recibiréis una versión actualizada.

El número de versión y fecha sale al principio, en la página de créditos:

Principios y algoritmos de concurrencia
© Ricardo Galli Granada
Diseño de portada: Damián Vila
Ilustraciones: Juan Ramón Mora «JRMora»
Foto: Spaghetti Worlds, Carl Milner (Flickr)
Corrección: Marilín Gonzalo y Juan Sosa
Versión: 1.0.7, 2015-06-20
Palma de Mallorca, 2015
ISBN: 978-84-606-8761-0
Licencia: CC BY-NC-ND 4.0

Las viñetas de «Principios y algoritmos de concurrencia»

Etiquetas

concurrencia, jrmora, viñetas

No sé cómo, pero conseguí que JRMora se enrolle para hacer las viñetas introductorias de cada capítulo del libro Principios y algoritmos de concurrencia. Quería darle un toque de humor sutil relacionado con el tema de cada capítulo . El pobre JRMora tuvo que escuchar explicaciones de temas muy técnicos. Creo que los dibujos, aunque muy simples (de concepto, no de trabajo),  son representativos.

Por las dudas: Copyright: JRMora Licencia, como el resto del libro: CC BY-NC-ND 4.0

Manifiesto

Principios y algoritmos de concurrencia: Prefacio

Etiquetas

concurrencia, prefacio

Este artículo es el primer manuscrito del Prefacio y concurrencia del libro que estoy escribiendo Principios y algoritmos de concurrencia. Todo el código de los ejemplos están en Github.

Nota: me gustaría leer opiniones.

Manifiesto

Hace más de veinte años que enseño Concurrencia en las asignaturas de Sistemas Operativos I y II y en Programación Concurrente y Distribuida de la carrera de informática en la Universitat de les Illes Balears. A pesar de la cantidad de notas y presentaciones que elaboré en todos estos años, nunca se me pasó por la cabeza escribir un libro. Ni siquiera el típico libro de apoyo a la asignatura. Es sumamente complicado transmitir las sutilezas y conflictos generados por ejecuciones que no cumplen con la secuencialidad de sus programas. Si ya me resultaba difícil en clases magistrales y prácticas en laboratorio, me parecía tarea imposible escribir un libro.

Pero eso cambió en diciembre de 2014.

Principios de concurrencia: Soluciones por hardware

Etiquetas

compare&swap, link-load/store-conditional, ll/sc, problema ABA, test&set

Este artículo es el primer manuscrito del capítulo Soluciones por hardware del libro que estoy escribiendo Principios de concurrencia para programadores. Todo el código de los ejemplos están en Github.

Soluciones por hardware

Hasta ahora hemos visto soluciones al problema de la exclusión mutua sin soporte de hardware y con solo registros de lectura-escritura atómicos, todos ellos son spinlocks pero muy ineficientes. Por un lado por el consumo de memoria, tanto para la solución de dos procesos (Dekker y Peterson) como para N procesos (Panadería) el número de registros necesarios es proporcional al número de procesos máximos que sincronizarán^[31]. Esta necesidad de memoria impone una sobrecarga importante para mantener la consistencia de la memoria caché, además del consumo de CPU por la espera activa todos los procesos involucrados tienen que acceder al mismo rango de memoria que los demás. Es una penalización muy importante para sistemas con varios procesadores o núcleos. Por otro lado, si se tiene un único procesador el avance es tan lento que lo que tarda décimas en uno puede tomar horas en otros^[32] en el caso de que exista mucha competencia (contention) porque varios procesos desean entrar a la sección crítica de forma casi simultánea.

Desde el inicio se buscaron soluciones por hardware que permitiesen implementar algoritmos de sincronización de forma mucho más eficiente.