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.

 

 

 

El mejor consejo que puedo dar a un joven ingeniero

Etiquetas

consejos, programación

En unos meses cumplo 25 años desde que presenté mi proyecto final de carrera de Ingeniería en Informática («la tesis» le llamaban en mi universidad) y algo más de 15 desde que leí mi tesis doctoral. Llevo años pensando en escribir sobre cuál fue el mayor error de mi carrera profesional y curiosamente -o no- me parece el mejor consejo -doble- que puedo dar, no hacer lo mismo:

No te adelantes, no te dejes seducir por puestos de dirección, gestión o representación. Durante los primeros 20 años de carrera sólo preocúpate de aprender y practicar para ser un experto de élite en el área en que estás trabajando. Cuando la domines creerás que lo sabes todo pero en realidad no sabes nada, aprende una nueva y repite el proceso: ganarás tanta humildad como conocimiento.

Ya llegará el momento -si lo deseas- de ocupar cargos de dirección o gestión, cuando seas un profesional reconocido: tendrás ya mucha experiencia en proyectos, sabrás bastante de la psicología y sus problemas sociales, tomarás mejores decisiones y serás de ayuda -que no un gestor molesto- y la gente a tu cargo te respetará y confiará desde el primer día. Afortunadamente con el dominio del software en tantas áreas se puede vivir bien como un buen ingeniero con experiencia. Además -desafortunadamente- es muy difícil encontrar ingenieros de alta calidad y con conocimientos en diferentes áreas.

No puedo dejar de poner otros que aprendí con errores que ahora intento no volver a cometer:

1. Cuando trabajes en grupo, sobre todo si estáis intentando solucionar un problema, no eches la culpa de nada a tus compañeros, déjales que se equivoquen -es parte de la búsqueda-, colabora y asume las responsabilidades aunque no hayan sido tuyas.
2. Por el contrario, si alguien nunca asume una responsabilidad o error, o culpabiliza a otros hasta de que no le dejan hacer nada, intenta que quede fuera del equipo. O que al menos no moleste.
3. Participarás en proyectos interesantes y en otros que son marrones. En realidad todos pueden ser interesantes, depende de la actitud con que los encares: siempre hay cosas que mejorar y aplicar ideas creativas. Tengo el ejemplo reciente de un compañero que le tocó uno de esos proyectos marrones hasta que se dio cuenta que podía reducir los tiempos de ejecución de batches con threads concurrentes, se lo pasó pipa aprendiendo y practicando. No sólo le quedó un programa mucho más rápido y eficiente,  ahora él es un profesional mucho más formado y capaz que hace un par de meses.
4. Puedes ser un doctor o un graduado en el MIT, pero a la hora de verdad tu compañero autodidacta y tú ejercéis de ingenieros. Trátalo como tal, los títulos formales solo sirven como carné de autoridad para la universidad ;), entre colegas no cuentan, solo lo que has demostrado saber hacer.
5. Lee mucho código de terceros, fundamentalmente de las librerías, módulos y programas que usas habitualmente. Es una de las mejores formas de aprender.
6. No dejes de leer, no solo de libros técnicos específicos, también de historia de la informática y ciencia, un poco de filosofía y psicología, álgebra, estadística y algo de cálculo.
7. No te contentes con dominar una herramienta o lenguaje, aprende cómo funciona toda la pila que lo sustenta: el hardware, el sistema operativo, la máquina virtual o compilador, el API, las librerías, etc. Aprende C o ensamblador, son clarificadores de cómo funcionan las máquinas y todo lo que hay por encima.
8. Domina al menos tres lenguajes diferentes que cubran: compilados, dinámicos, y funcionales.
9. Tus programas nunca serán perfectos ni lo suficientemente buenos. Con el paso de los años te avergonzarás de tu propio código. Esto es bueno, has mejorado.
10. Cuando programes piensa en los lectores de ese programa: escribe y comenta en inglés, que el código sea elegante, si el código te parece espagueti o ilegible descártalo y empieza de nuevo, no dejes de refactorizar mientras programas. No tengas miedo de descartar programas, no es tiempo perdido. Programar es como escribir un libro pero más complejo, si hasta los mejores autores siempre descartan capítulos o textos completos, ¿por qué tú habrías de acertar a la primera?
11. No empieces a programar como un mono, pasa horas pensando, camina, conversa con colegas, pregunta, haz un prototipo, descártalo y vuelve a empezar hasta que esas primeras líneas no te den asco ni te generen desasosiego por lo que se viene: todo lo contrario, deberían entusiasmarte a seguir programando.
12. De todas las ideas o propuestas, elige siempre la opción más sencilla (el KISS). Si no hay ninguna que sea claramente sencilla es porque falta pensar más. Si durante el desarrollo te das cuenta que hay soluciones más simples para hacer lo mismo (es muy habitual), descarta y comienza de nuevo.
13. No hagas optimizaciones prematuras ni tampoco diseño de lo desconocido. Lo primero genera código más difícil de verificar y lo segundo complica el sistema con funcionalidades que nunca se usarán.
14. Si cuando sale una nueva tecnología eres capaz de darte cuenta en qué podría servirte pero te ríes del hype y buzzwords es señal de que estás madurando como profesional.
15. Si además de acabar tus proyectos en tiempos razonables y con programas fiables, los haces con buen humor, te acaban ilusionando hasta los más coñazos y festejas como un crío cuando pudiste solucionar una tontería que te tomó horas, ya eres un buen profesional. O al menos no un coñazo de profesional. Que es casi lo mismo.

PS: Ahora veo que me falta algo fundamental, siempre explica a tus colegas por qué haces algo o tomas una decisión. En el código o tomando un café.

 

Las cosas que no soporto que diga un programador

Etiquetas

informática, programación

…y quizás tampoco las soportan los demás programadores.

En mi ordenador funciona

Si el código no funciona en un ordenador con toda las dependencias adecuadas instaladas es un error de tu programa, sin dudas, no hay excusas. Nunca digas esta frase, sólo demuestra que todavía no estás preparado ni para asumir la responsabilidad de tu propio código. Si eres alumno demuestra que no te interesa aprender sólo aprobar con el menor esfuerzo posible… además de tomar como tonto al profesor, como si nunca hubiese oído esta excusa (la oímos decenas de veces cada vez que se presentan prácticas).

¿Qué tecnologías utilizarías?

Etiquetas

go, java, perl, PHP, programación, python, scala

Hoy un viejo conocido me hizo esta pregunta:

. @gallir a día de hoy si te planteases construir menéame, que tecnologías utilizarías? (suponiendo que la idea siguiese siendo única)

— César Aguilera (@Cs4r) January 19, 2015

Estuve a punto de contestar pero me di cuenta que soy incapaz, y que tampoco debería. Lo haré al final, como una cuestión muy personal y después de un rant de matizaciones.

Las elecciones de Podemos, voto electrónico, y AgoraVoting (y 2)

Etiquetas

agoravoting, podemos, seguridad, voto electónico

Hace unos días escribí un apunte sobre las tan comentadas elecciones electrónicas de Podemos. Comencé el artículo con una descripción de los requisitos que tiene que tener un sistema de votación (de papeleta y electrónico) y el procedimiento que se seguía en las votaciones tradicionales para asegurar que se cumplan esos requisitos (voto secreto y anónimo, no adulteración, impedir agregar votos, auditoría…).

En ese apunte me limité a comentar el problema del censo de Podemos, y cómo sólo eso hacía que se incumpliesen varios de los requisitos mencionados anteriormente. Aquí introduzco un leve paréntesis para dejar claras algunas cosas (lo pongo «entrecomillado» para que te lo puedas saltar).

Ciencias de la computación e ingeniería, y [algunas de] sus diferencias

Etiquetas

concurrencia, exlcusión mutua

Hay un tema que se estudia en todas las carreras de informática, el de «sincronización, concurrencia y exclusión mutua entre procesos». Surgió en la década de 1950 cuando empezaron a desarrollarse los primeros sistemas con multiprogramación. Aunque surgió como problemática de sistemas operativos se ha convertido en un tema de general y fundamental en informática. Todas las carreras de informática incluyen su estudio tanto en las asignaturas de sistemas operativos como en otras específicas de programación concurrente.

El tema de concurrencia (y su hermano más complejo «programación distribuida») es un típico tema de «ciencias de la computación», donde se estudian los algoritmos y se prueban formalmente que funcionan: se demuestra que aseguran exclusión mutua, que no produce inanición (starvation), ni interbloqueos (deadlocks). No es simple enseñar estos temas y sus soluciones obligan a pensar de otro manera, un programa ya no es una serie secuencial de instrucciones, sino que se mete por medio una intercalación «no controlada» y no determinística de otras instrucciones de procesos independientes.

El tema de exclusión mutua es un tema relativamente sencillo de demostrar, por ejemplo este código que suma una variable desde cero hasta 99.999.999 (cien millones menos uno), pero no lo hace de una forma tradicional, sino que son dos hilos (threads) los que la incrementan individualmente. Podéis compilarlo y probarlo (no olvidéis de compilarlo con la opción -pthread), veréis que produce unos errores enormes. El problema es que dos procesos diferentes acceden al mismo recurso compartido (la variable count) y se «pierden» operaciones debido a las interrupciones e intercalaciones.

Este caso es muy estudiado y todas las asignaturas comienzan con algo similar, es la exclusión mutua entre [solo] dos procesos. Así se estudian los «cuatro intentos» para solucionarlo, luego el algoritmo de Dekker y finalmente el de Peterson (aquí los tenéis a todos).

Así se puede demostrar formalmente que funciona correctamente, que asegura exclusión mutua y tal y cual. Pero si lo implementas (aquí lo tenéis listo para compilar y ejecutar con el ejemplo anterior) y lo pruebas en cualquier ordenador moderno verás que… falla como escopeta de feria.

¿Qué pasó? ¿Falla la teoría? ¿Fallan las demostraciones? ¿Los teóricos de las ciencias de la computación no sirven para nada?

Actualización: la respuesta.

Ninguna de ellas, este es un típico ejemplo donde la teoría se distanció de la «realidad», o mejor dicho, donde la evolución tecnológica de los microprocesadores modernos hace que las técnicas de concurrencia que dábamos por buenas (y que lo son formalmente y con todos los modelos de computación y/o de lenguajes «tradicionales») ya no funcionen. Es la diferencia entre hacer «sólo ciencia» y la «ingeniería» (es decir, resolver problemas que te impone la realidad, no tan perfecta como la teoría).

Tampoco es para los ingenieros se feliciten y miren por encima del hombro a los teóricos, porque la mayoría de «ingenieros» tampoco saben explicar o resolver este problema, muchas veces ni siquiera son capaces de identificarlo (no, si estás leyendo este blog no eres de la «media», eres bastante friki y al menos lo habrás oído, o sabrás buscar rápidamente en la Wikipedia o Stackoverflow 😉 ).

Si no tienes idea de qué está pasando, ya lo explicaré en un comentario (si nadie lo hace antes), pero mientras tanto puedes ir probando este otro código que sí funciona y sólo difiere en una línea con el anterior.

Sólo quería recordar que aún en ciencias tan «formales» como la informática la teoría no siempre funciona en la práctica, que el tema de concurrencia tiene sus complejidades no siempre a la vista, que un buen ingeniero debe saber reconocer esos problemas y poder solucionarlo, y que esto exige que conozcamos bastante de detalles del hardware y microprocesadores actuales.

No es nada simple, lleva su tiempo, y tendemos a pensar que lo sabemos todo. O que la «ingeniería informática» consiste en saber liderar sprints de Scrums con postits de colores fosforitos.

PS: Por estas cosas, entre muchas, la informática es apasionante.

La compleja coreografía porque presionaste la letra A

Etiquetas

sistemas operativos, X11

Tu teclado detectó que presionaste la letra A, sus chips lo codifican en un scancode, este código es convertido en un señales eléctricas que se transmitirán por el cable USB al controlador que está conectado a la placa del ordenador. Este controlador detecta las señales eléctricas, las reconstruye en números binarios que almacena en un área de memoria del dispositivo, a continuación genera una solicitud de interrupción (IRQ) que será transmitida al microprocesador.

Esta interrupción está codificada y se recibe en el procesador en unas pins especiales para ellas, cuando llega la generada por la tecla que presionaste el procesador decide a qué core o procesador enviar esa petición (enrutamiento de interrupciones). Éste interrumpe lo que estaba ejecutando en ese momento,  analiza el IRQ, accede a una tabla de interrupciones (que fue rellenada cuando el sistema operativo se inició) donde le indica la dirección de la rutina del kernel que debe ejecutar. Cambia los registros necesarios, posiblemente invalida (flush) las cache y TLB del proceso anterior, cambia el nivel de ejecución del procesador a uno de con más privilegios y pasa a ejecutar la dirección indicada en la tabla de interrupciones.

La rutina del núcleo del sistema operativo analiza los registros y llama al gestor del controlador USB, que puede acceder a la memoria del dispositivo vía instrucciones de E/S del procesaor para que copie los datos a la memoria RAM. También llamará al gestor específico de teclado por USB (lo más probable es que sea el usbhdi) que convierte el scancode original en un código de caracteres vía una tabla de conversión (o mapa del teclado).

Una vez realizada las operaciones de transferencia de datos desde el dispositivo, se llaman a las rutinas de E/S de caracteres del núcleo. Éstas analizan qué proceso es el que debe recibir esa entrada de teclado, si usas un GNU/Linux con interfaz gráfica el proceso es el servidor X (X.org), copian los datos al área de memoria de dicho proceso, lo desbloquean y llaman al scheduler para que decida qué proceso debe ejecutar a continuación.

Al desbloquearse el proceso, éste pasa de la lista de procesos bloqueado a la lista de procesos listos para ejecutar. Allí el servidor X competirá por el procesador con otros procesos, eventualmente será seleccionado por el scheduler, este procederá a preparar al procesador (o núcleo) para que lo ejecute (cambio de contexto o context switch), invalidará las caches del proceso anterior, preparará las tablas de páginas básicas, cambia el privilegio del procesador al de uno de proceso normal y finalmente transfiere el control al proceso X.

Éste continúa su ejecución desde la llamada epoll o select que hizo para recibir E/S, analiza los datos que le dejó el sistema operativo y decide que es un letra picada en el teclado (el editor de texto, o la terminal, o el navegador web….), analiza cuál era el proceso interactivo que tiene la ventana activa en ese momento, codifica el evento en el protocolo X11, y se lo envía a dicho proceso vía memoria compartido o socket UNIX.

Al enviar el mensaje a otro proceso, se llama otra vez a una rutina del sistema operativo en un proceso similar al IRQ inicial, pero esta vez iniciado por una instrucción especial (interrupción por software) que hace que el procesador la trate de forma similar, selecciona un procesador para que la trate, analiza el código de interrupción y los registros que dejó el programa, cambia a modo privilegiado y llama a la rutina del kernel que tratará esta interrupción (posiblemente las de UNIX socket).

Esta rutina mira en las tablas de sockets cuál es el proceso receptor (el editor, terminal, navegador…), copia los datos necesarios, desbloquea al proceso moviéndolo a la cola de listo para ejecutar y llama al scheduler.

Eventualmente el proceso que debe recibir esa letra A es seleccionado por el scheduler, pasa a ejecución, continúa su ejecución desde el select o epoll, analiza la entrada, decide que hay que mostrarlo en pantalla, codifica la información necesaria (caracter, tipo de letra, posición, color, etc.) y la envía nuevamente -mediante un mensaje en protocolo X11- al servidor X.

Se repite de nuevo el proceso, interrupción de software, llamada a una rutina del núcleo y desbloqueo del servidor X que eventualmente es ejecutado.

Éste analiza el mensaje, detecta que tiene que dibujar una letra en la pantalla y llama a sus rutinas de dibujo de fuentes TrueType. Estas rutinas recuperan la información de la fuente necesaria (consisten de puntos en 2D), aplican los fórmulas necesarias que definen cómo debe dibujarse en la pantalla y llaman a las rutinas de DRI del kernel que lo harán, vía ayuda del gestor de la placa gráfica, en un complicado procedimiento de sincronización entre el servidor X, el gestor de la placa y la propia placa gráfica (que es otro ordenador muy potente y complejo, con su propio «sistema operativo»).

La letra A es dibujada así en la memoria del back buffer de la tarjeta, también se dibujan las otras ventanas con complicadas combinaciones y copias (compositing) para intentar minimizar todo lo que hay que re-dibujar. Cuando el back buffer está completo, se notifica a la placa gráfica que lo intercambie con el front buffer (lo que se visualiza por la pantalla), ésta espera que llegue el momento justo de sincronización con el monitor (para que no parpadee con mezcla de imágenes de ambos buffers) y finalmente hace el cambio y puedes ver lo que esperabas:

Esta maravillosa coreografía de sincronización y paso de información ocurre cada vez que presionas una tecla, o mueves el ratón un pixel, o se empieza a bajar una imagen de la web. Y no sólo en tu PC o Mac, ocurre lo mismo en tu teléfono móvil, tu router WiFi, tu lector de libros, o tu smartwatch.

Todo esto que acabo de explicar ya funcionaba prácticamente igual desde finales de los años 70. Explico estas interacciones y algoritmos en mis clases de sistema operativo desde hace más de 20 años, pero nunca deja de maravillarme al nivel de complejidad y sofisticación al que hemos llegado en pocas décadas de informática.

 

 

 

Una técnica útil para el programador solitario (o sea, yo)

Etiquetas

lista de tareas, notas, tickets

No sé si os pasa a todos, yo creo que sí, pero tenía serios problemas de organización y productividad en el desarrollo de Menéame. Quizás sea un caso especial, es un sistema complejo:

• software relativamente grande y soy básicamente el único programador responsable de todos los módulos,
• diversidad de lenguajes, PHP para la web, Python para scripts y programas «off line», Perl por herencia de hace años,
• base de datos grande e imposible de hacer alteraciones de las tablas por el tamaño de las mismas (ya veremos con el MySQL 5.6),
• mucha manipulación de datos en la base de datos,
• interacciones complejas de usuarios,
• muchos controles de entradas y acciones de usuarios «externos»,
• los usuarios piden muchas modificaciones, correcciones y detectan bugs que ni se te pasaron por la cabeza que podían ocurrir,
• cada vez que se implementa una nueva característica (cada vez más complejas), aparecen nuevos bugs y sobre todo, los usuarios demandan muchas modificaciones y ań nuevas características complementarias.

Con todo esto, a veces me ocurría que me bloqueaba porque no sabía por dónde comenzar, o que pasos seguir, o cuál era el trabajo pendiente, cuáles son importantes, cuáles son urgentes, y cuáles secundarios que pueden esperar hasta tener ese momento de inspiración. Soy bastante desorganizado, y odio profundamente usar programas (los tipos «gestión de tickets») para esto. Ya demasiado tengo con ventanas de editores, consolas de administración y páginas de manuales para encima tener que estar buscando una ventana perdida para ir leyendo y apuntando lo que estoy haciendo.

Tendencias («trends») históricas del uso de palabras con Sphinx

Etiquetas

menéame trends, sphinx

Hace unos días quise saber desde cuándo se empezó a hablar de desahucios y suicidios en la prensa en España. Fui a Google Trends y el gráfico mostraba una evolución demasiada plana, que no se correspondía con tantas noticias que leímos en la prensa española. Me pregunté si, y cómo, podía obtener esas estadísticas en Menéame. Se me ocurrió que debería haber un truco relativamente sencillo usando los índices de de búsqueda de Sphinx (lo usamos para el buscador de Menéame). Así fue que en pocas horas pude implementar un sistema similar a Google Trends en Menéame.

Esto es lo que salió con las tendencias de esas dos palabras por su frecuencia de aparición por meses: