Reporte Técnico RT-ID-/ de Diciembre 2009 Revisado

Transcripción

1 Reporte Técnico RT-ID-/009 Erlang Está Listo para Sistemas de Alta Integridad? Nora Sabina María Blet Departamento de Sistemas e Informática Escuela de Ingeniería Electrónica Facultad de Ciencias Exactas, Ingeniería y Agrimensura Universidad Nacional de Rosario Disciplina: Informática, Lenguajes de Programación 4 de Diciembre 2009 Revisado Secretaría de Ciencia y Técnica Facultad de Ciencias Exactas, Ingeniería y Agrimensura Universidad Nacional de Rosario Av. Pellegrini Rosario Argentina

2 Este documento es publicado por la FCEIA para su consulta externa. El mismo se publica como Reporte de Investigación para divulgación de las tareas científicas que se desarrollan en la FCEIA, Universidad Nacional de Rosario. Los autores conservan los derechos de autoría y copia de la totalidad de su trabajo aquí publicado. Luego de su posterior eventual publicación externa a la FCEIA, los requerimientos deberán dirigirse a los autores respectivos. El contenido de este reporte refleja la visión de los autores, quienes se responsabilizan por los datos presentados, los cuales no necesariamente reflejan la visión de la SeCyT-FCEIA. Tanto la SeCyT-FCEIA como los autores del presente reporte no se responsabilizan por el uso que pudiera hacerse de la información y/o metodologías publicadas. Cualquier sugerencia dirigirla a: rtsecyt@fceia.unr.edu.ar 2

3 Erlang Está Listo para Sistemas de Alta Integridad? Nora Sabina María Blet * Departamento de Sistemas e Informática Escuela de Ingeniería Electrónica Facultad de Ciencias Exactas, Ingeniería y Agrimensura Universidad Nacional de Rosario Resumen. Este informe resume una evaluación del lenguaje de programación funcional Erlang, en comparación con los estrictos requisitos impuestos a lenguajes de programación para aplicaciones relacionadas con la fiabilidad. Para este propósito se escogen veintitrés criterios, disponibles en la literatura, que examinan el uso de Java en el desarrollo de sistemas de alta integridad. En base a lecciones aprendidas en proyectos industriales Erlang a gran escala, se discuten algunas posibles mejoras. Palabras Claves: Erlang, Programación Concurrente, Programación Distribuida, Tolerancia a Fallos, Evaluación de Lenguajes de Programación, Sistemas Totalmente Fiables. Is Erlang Ready for Use in Safety-Critical Systems? Abstract. This report summarises an assessment of the Erlang programming language against the strict requirements imposed on programming languages for safety related applications. For this purpose twenty-three criteria, available in the literature, for investigating the use of Java in the development of high integrity systems have been chosen. Based on some lessons learned on industrial projects possible further enhancements are discussed. Keywords: Erlang, Concurrent Programming, Distributed Programming, Fault-Tolerance, Assessment of Programming Languages, Safety-Critical Systems. * nblet@fceia.unr.edu.ar 3

4 1 Introducción En el contexto de sistemas distribuidos de control (NCS, por Networked Control Systems) tolerantes a fallos software mediante manejo de excepciones, un lenguaje que ofrece algunas características muy interesantes e inusuales, es Erlang. Erlang es un lenguaje funcional, concurrente y distribuido, desarrollado a fines de los 80 en los laboratorios de la corporación Ericsson, con el fin de manejar la complejidad propia del desarrollo de grandes sistemas distribuidos de control, tolerantes a fallos y con características de tiempo real flexibles (soft). La idea original era utilizar un lenguaje de alto nivel en el dominio de sistemas de telecomunicaciones de misión crítica, con requisitos de disponibilidad de hasta un %. Las aplicaciones Erlang son configurables dinámicamente, resilientes ante fallos de software o hardware y capaces de garantizar una operación non-stop, lo cual se consiguió llevando al extremo el modelo de procesos UNIX. A nivel software estos requerimientos son similares a aquellos de aplicaciones basadas en Internet, resultando Erlang un buen candidato para el desarrollo de servicios basados en Web. Usuarios tales como Amazon, Google, Yahoo, Facebook, entre otros, confían en las capacidades del lenguaje para implementar sus sistemas. Demás áreas en las cuales ha sido aplicado: organización del control de tráfico aéreo/ferroviario y de otros sistemas embebidos complejos, mensajería instantánea, sistemas de seguridad crítica para pago electrónico, bases de datos, modelado 3D, implementación de robots autónomos móviles, etc. Con el convencimiento que Erlang ofrece una visión muy reveladora para los futuros diseños de sistemas de manejo de excepciones distribuidas y concurrentes, sería un ejercicio interesante y esclarecedor evaluarlo en comparación con los estrictos requisitos impuestos a un lenguaje de programación para aplicaciones relacionadas con la fiabilidad. Para este análisis se utilizan los veintitrés criterios propuestos en un artículo de la literatura [16] que investiga el uso de Java en el desarrollo de sistemas de alta integridad. Tomando como base algunas lecciones aprendidas en proyectos industriales y transmitidas por desarrolladores Erlang, se discuten aspectos del lenguaje que deberían mejorarse. El resto del informe está estructurado de la siguiente forma: en Sección 2 se analizan cada uno de los veintitrés criterios mencionados, separados en dos niveles: obligatorios (Subsección 2.1) y aconsejables (Subsección 2.2). Los requisitos obligatorios son aquellos que un lenguaje de programación debe satisfacer para ser considerado en la implementación de sistemas de software de alta integridad. Aquéllos aconsejables se consideran favorables para obtener sistemas más eficientes, claros y estructurados. En Sección 3 se realiza el veredicto final y se propone la adopción de Erlang para la implementación de un middleware orientado a mensajes para sistemas distribuidos de control (NCS), que constituye en realidad el origen y motivo de este estudio. 2 Requisitos del lenguaje de programación 2.1 Requisitos obligatorios Seguridad de tipos. La especialidad de Erlang, en contraste con la mayoría de los lenguajes funcionales, es su naturaleza fuertemente dinámica: las variables son dinámicamente 4

5 tipificadas, es decir, no son verificadas en tiempo de compilación sino que son estrictamente chequeadas en tiempo de ejecución (type-safe), lo cual probablemente produce una significativa disminución de la performance. Aunque los mecanismos del lenguaje que proveen tolerancia a fallos ayudan a cubrir errores residuales en el código de producción, un sistema de tipos estáticos produciría claros beneficios en la práctica; más aún, es un tema recurrente año a año en las Erlang Users Conference. La alta flexibilidad del lenguaje, hace muy difícil introducir un sistema de tipos sin eliminar parte de esta propiedad. En lugar de introducir tipos estáticos, el uso de herramientas como XREF y DIALYZER (por Discrepancy AnaLYZer of Erlang programs) constituye un balance ideal entre la flexibilidad de un desarrollo Erlang con el requerimiento de obtener código robusto y seguro. DIALYZER [18], [19] es una herramienta de análisis estático automático que detecta defectos, a los que se los denomina discrepancias, en código fuente o en bytecode y que, podrían estar ocultos especialmente en aquellas partes del programa que no son comúnmente ejecutadas o ensayadas. DIALYZER es aplicado en proyectos reales del área telecomunicaciones con más de un millón de líneas de código. Efectos secundarios. La mayor parte del lenguaje y, posiblemente la menos interesante, es el subconjunto secuencial del mismo el cual, puede caracterizarse como lenguaje estrictamente funcional y que, en su mayoría está libre de efectos secundarios: sólo hay unas pocas operaciones que los producen y prácticamente no se utilizan [1]. En la parte que maneja concurrencia, típicamente se producen efectos secundarios al invocar funciones que envían o reciben mensajes, leen de una cola de ellos o generan nuevos procesos. Erlang fue intencionalmente diseñado para ser un lenguaje pequeño utilizado conjuntamente con librerías que contienen un conjunto muy grande de funciones incorporadas, comúnmente denominadas BIFs (por las siglas de built-in functions); parecen estar escritas en Erlang, pero como sería muy ineficiente o imposible hacerlo están implementadas en C en la máquina virtual Erlang (llamada BEAM). Se producen efectos secundarios al invocar algunas de estas BIFs, lo cual hace el código menos reutilizable puesto que, causan cambios permanentes a su entorno y debe conocerse el estado exacto de un proceso antes de esta operación. Debido a que Erlang se diseñó como un lenguaje para controlar aplicaciones en tiempo real, donde la manipulación del hardware y la estricta secuencia de eventos son muy importantes, no puede comportarse como un lenguaje puramente funcional: una invocación a función puede producir una acción en el hardware y no hay garantías que éste responderá siempre de la misma forma; comportándose Erlang en este caso como un lenguaje imperativo, antes que estrictamente funcional. Por tanto, si no pueden eliminarse completamente los efectos secundarios, deben mantenerse restringidos a un número pequeño de módulos del programa, escritos, ensayados y documentados por los programadores más experimentados; las reglas de programación en Erlang [1] apoyan este enfoque. En [22] se propone como posible mejora, el desarrollo de un mini-lenguaje que entre otros requisitos a satisfacer, no debería permitir que los efectos secundarios sean visibles fuera del código del mismo; tal vez inspirado en el lenguaje funcional SISAL diseñado para computación paralela. Modularidad. Armstrong [1], uno de los creadores de Erlang, aplica viejos principios fundamentales para obtener un lenguaje de programación de sistemas tolerantes a fallos, tales como aquellos descriptos en un artículo de Gray [13]; una de las claves para ello: modularidad a través de procesos y mensajes. El proceso, ciudadano de 1ª clase en Erlang, provee una bien definida unidad de modularidad, servicio y contención de fallos. La filosofía fail-fast es central en el lenguaje; el lema de Erlang es: falle! y deje que otro proceso se ocupe de la recuperación de errores. Cada proceso puede pensarse como una máquina virtual 5

6 autocontenida en cada uno de ellos; procesos auténticos son comunes en sistemas operativos mientras que extremadamente inusuales en los lenguajes de programación de producción. La unidad de compilación es el módulo, con un nombre exclusivo y que contiene funciones (como en cualquier lenguaje funcional, objetos de 1ª clase); sólo aquellas marcadas como exportadas pueden invocarse desde otros módulos. Erlang se usa a menudo en sistemas de muy alta disponibilidad denominados nueve nueves, operables el % del tiempo o inactivos menos de 31ms. al año; tales sistemas no pueden detenerse para mejorar las prestaciones o instalar mecanismos de recuperación de errores; por tanto el lenguaje provee soporte para actualizar el código mientras el sistema está en funcionamiento ( hot-code loading ) [2]. Cuando se carga una nueva versión de un módulo, los nuevos procesos generados la ejecutarán mientras que, aquellos que estaban ejecutándose lo continuarán haciendo sin perturbarse. Los usuarios pueden controlar en detalle este proceso, ya sea en el momento de la carga inicial (en sistemas embebidos) o cuando se necesite (sistemas de propósito general). Armstrong [2] propone como posible mejora considerar a los módulos objetos de 1ª clase al igual que las funciones: debería permitirse tener múltiples versiones de ellos y dejar que el recolector de basura se encargue del código viejo que ya no pueda evaluarse. Semántica formal/ Estándares internacionales. Puesto que la historia de Erlang comienza en la industria y no en la universidad, fue definido principalmente en términos de su implementación; aún no tiene definida una semántica formal. Hubo varios intentos de formalización semántica, directamente o utilizando como base el cálculo-π [21]. La semántica obtenida fue empleada en varios proyectos de verificación [10] y para realizar una traslación del lenguaje, a la que se le aplicó model checking [4]. No existen estándares estables para el lenguaje. Bien comprendido. Algunas de las razones por las cuales Erlang es tan popular en la industria son su simpleza y elegancia, más allá de que requiere un cambio de mentalidad o de forma de pensar un programa. Este lenguaje basado en la sencillez del modelo de Actor para la comunicación interprocesos, permite escribir código con menos bugs, incrementando la productividad de un programador en un factor entre 4 y 10. Erlang está ganando reputación como lenguaje para crear un prototipo en forma muy rápida y, con pequeñas modificaciones, la versión final luego de una curva de aprendizaje inicial pronunciada. De las experiencias realizadas con el lenguaje [11], se considera que cualquier programador con espíritu aventurero, en menos de un mes puede realizar un aporte no trivial a cualquier proyecto Erlang. En cuanto a la dificultad para contratar programadores, proclamada en muchas publicaciones, se considera que es la misma que en el caso de programadores expertos en aplicaciones multihilos C++ o Java. La mayoría de los programadores de lenguajes funcionales son apasionados de la programación, lo cual en general, hace que sean muy buenos en su trabajo. Erlang es open source desde hace más de una década con lo cual la comunidad de usuarios y desarrolladores crece en forma sostenida, con beneficio adicional para Ericsson puesto que, han comenzado a reparar algunos bugs y proponer mejoras al lenguaje. Soporte para aplicaciones embebidas. Erlang es utilizado hoy en día por muchas compañías para implementar sistemas embebidos complejos con características de tiempo real flexibles, donde se manejen tiempos de respuesta del orden de milisegundos, a pesar que carece de características esenciales de los lenguajes de programación en tiempo real; el elemento tiempo no es tenido en cuenta salvo por el uso de timeouts y manejo de excepciones en tiempo real. 6

7 En un artículo reciente [20] se propone la implementación de un planificador de tareas de tiempo real estrictas (hard), enteramente escrito en Erlang y perfectamente integrado con la máquina virtual, mejora esperada en el área de robótica [23]. El trabajo está aún en la etapa inicial y no encara problemas tales como, paso de mensajes en tiempo real y efectos del comportamiento impredecible del recolector de basura. Este último es un problema crucial que, debe resolverse antes de obtener verdadero soporte para tiempo real estricto. Concurrencia. Erlang fue diseñado para construir programas concurrentes non stop [1]; usa procesos concurrentes, fuertemente aislados que no utilizan memoria compartida y se comunican mediante paso de mensajes asincrónicos. Los procesos Erlang son extremadamente livianos y pertenecen al lenguaje, no al sistema operativo; pueden ejecutarse en un único procesador, en uno multicore o en una red de ellos. En el mundo de Erlang no se necesita exclusión mutua ni mecanismos de sincronización. El emulador Erlang puede crear un nuevo proceso en menos de 1µs y ejecutar millones simultáneamente [17]; cada uno ocupa menos de 1KB de memoria y el paso de mensajes entre ellos se realiza en centésimas de nanosegundos. Para obtener tolerancia a fallos el lenguaje hace uso extensivo de procesos fail-fast, una técnica muy utilizada en plataformas hardware para conseguir este fin pero no tanto en soluciones software. El modelo de programación usado comúnmente, basado en threads, hace extremadamente difícil aislar componentes entre sí: un error en uno de ellos puede propagarse hacia otros y dañar la consistencia interna del sistema. El lenguaje fue diseñado con el objetivo en mente de proveer una mejor forma de escribir programas para aplicaciones en el área de telecomunicaciones que, por naturaleza son altamente concurrentes y tolerantes a fallos: un switch maneja decenas o cientos de miles de transacciones simultáneamente. En realidad más que un lenguaje, Erlang implica toda una filosofía que se denominó Programación Orientada a Concurrencia (COP por Concurrency-Oriented Programming), por analogía con Programación Orientada a Objetos (OOP). COP provee dos de las principales ventajas de usar OOP: el polimorfismo y el uso de protocolos definidos que tienen las mismas interfaces de paso de mensajes entre instancias de diferentes tipos de procesos. En COP la estructura concurrente del programa imita aquella de la aplicación, por tanto es apropiada para aplicaciones que modelen o interactúen con el mundo real, en el cual las actividades puramente secuenciales son una rareza. A pesar de la extrema resiliencia frente a sobrecargas que exhiben las aplicaciones distribuidas Erlang, el aislamiento entre procesos no es perfecto. Un proceso puede realizar un ataque de denegación de servicio a otro y llegar a agotar recursos considerados críticos, entre otros daños. En [25] se investiga la posibilidad de detectar este tipo de ataques, en un ambicioso intento de añadir capacidades basadas en control de acceso y comunicaciones seguras mediante criptografía. Actualmente, Erlang tiene un modelo de seguridad basado en cookies (o sea, basado en la confianza), el cual puede ser adecuado para redes con firewalls pero no para aquellas abiertas. Otra posible mejora apuntada por Armstrong [2] es la modificación del actual modelo de seguridad todo o nada de Erlang, para permitir distintos niveles de seguridad o confianza. En [25] se propone una jerarquía de nodos con distintos niveles de permiso de acceso a los recursos. Predictibilidad functional. Los análisis de flujo en los lenguajes funcionales son más complejos que en el caso de lenguajes imperativos; usualmente se basan en grafos de flujo que modelan el flujo de datos y de control del fragmento de código verificado. Al momento existe una propuesta de análisis de flujo para programas en Erlang [26]. 7

8 Predictibilidad temporal. El uso de máquina virtual y recolector de basura automático complican el análisis del tiempo de ejecución en el peor caso (WCET). Análisis de la utilización de recursos. Una aplicación típica Erlang utiliza una gran cantidad de procesos livianos, cuyo requerimiento de memoria es extremadamente difícil de predecir de antemano puesto que varía dinámicamente. Se están llevando a cabo investigaciones al respecto [25]. En algunas aplicaciones descartan el uso del lenguaje por el tamaño de memoria utilizada [7]. La cuestión reside en el método actual de recolección de basura pensado para sistemas en tiempo real flexibles; la actual performance parece ser aceptable en aplicaciones con procesos de vida corta y cuya necesidad de memoria es pequeña. Se desconoce si los autores de [7] probaron invocar la función erlang:hibernate [15] entre pasos de mensajes, que reduce drásticamente el uso de memoria sin incrementar significativamente el consumo de CPU. En [27] se exploran dos arquitecturas de memoria alternativas a fin de mejorar el desempeño global; ambas están aún en etapa experimental. Sigue pendiente la investigación del uso de recolectores de basura de tipo sin interrumpir, en lugar del actual parar el mundo que no es apropiado para la implementación de sistemas de tiempo real estrictos y que complementaría el estudio realizado en [27]. En una de las últimas revisiones de Erlang (2006) se incorpora soporte completamente transparente para SMP (Symmetric Multi Processing); los tests demuestran que aplicaciones ya existentes [8], sin modificaciones al utilizar arquitecturas multicore, mejoran significativamente su performance. Compilador y entorno de ejecución validados. La validación del compilador y la máquina virtual Erlang son temas pendientes de investigación. Run-time system support. El conjunto de librerías, aplicaciones, utilidades y módulos producidos simultáneamente con cada nueva versión de Erlang, se agrupan bajo el nombre de Open Telecom Platform (OTP) y se utiliza la denominación Erlang/OTP para referirse a la plataforma completa. Erlang está constituido por un núcleo (Erlang Runtime System) sobre el cual se ejecutan las librerías, incluyendo además la máquina virtual y las librerías estándares. Estas últimas incluyen módulos para la manipulación de las principales estructuras de datos del lenguaje además de componentes genéricos encapsulados como patrones de diseño (llamados behaviors), resultado de la experiencia de muchos años de construir sistemas tolerantes a fallos. También se incluye un conjunto muy completo y documentado de librerías y aplicaciones de propósito general; más aún, existe toda una filosofía homogénea de programación subyacente a esta plataforma. Aunque el lenguaje provee muchas características de alto nivel, la verificación de componentes de Erlang/OTP es aún no trivial; una forma posible de hacerlo es mediante model checking [5], [4], [14] que utiliza como base el álgebra de procesos µcrl. Debido al uso de patrones de diseño, los espacios de estados obtenidos a partir del modelo de fallas, son relativamente pequeños y pueden generarse automáticamente, haciendo factible el uso de esta técnica de verificación. 2.2 Requisitos aconsejables Manejo de excepciones/comportamiento frente a fallos. Erlang tiene un sencillo sistema de manejo de excepciones [6] que ha probado ser muy eficiente. Aunque dicho sistema ofrece primitivas simples mediante la composición de las mismas pueden implementarse sistemas 8

9 muy complejos. Las primitivas de concurrencia no sólo posibilitan crear hilos de control sino que, permiten a partes de una aplicación el monitoreo de otras y la reinicialización de aquéllas que fallen, aún si se ejecutan en distintos hosts conectados mediante una red. Erlang propicia el enfoque de detección dinámica y manejo de errores denominado programación ofensiva (contrapuesta a la programación defensiva) o, filosofía let it crash o fail-fast ; esto lo logra usando patrones de diseño denominados árboles de supervisión, que semejan la organización jerárquica de una empresa y encapsulan el monitoreo de un proceso por otro. Este patrón de supervisión, la versión Erlang de una niñera, es magistralmente explicado en detalle por Jim Larson en [17]: determinados procesos denominados supervisores monitorean todos los procesos importantes llamados trabajadores, los cuales son los que realmente hacen el trabajo. Si un proceso termina anormalmente, el supervisor correspondiente recibe un mensaje al respecto y, dependiendo de la razón de la finalización puede realizar diferentes acciones: registrar un mensaje de error, enviar un mensaje a otro proceso acerca de este evento o arrancar nuevamente el mismo proceso o uno nuevo que lo reemplace. Dentro de esta filosofía se modelan todas las fallas como permanentes; manteniendo simple el modelo de fallas, el algoritmo de recuperación de las mismas, también lo hará. Esta estrategia permite además obtener una clara separación entre el código correspondiente a la corrección de errores, de aquél dedicado al funcionamiento normal de la aplicación, posibilitando el diseño de aplicaciones altamente escalables y robustas. Este tipo de modelo puede reproducirse en otros lenguajes. La posibilidad de reconfiguración dinámica (hot load), ya mencionada, actúa como otro mecanismo de tolerancia a fallos. Modelo de matemáticas. Erlang usa enteros con precisión arbitraria [3], sólo limitada por la memoria disponible; la aritmética entera es exacta, por lo cual no hay que preocuparse de overflows o de no poder representar enteros en ciertos tamaños de palabras. Los números en punto flotante se almacenan internamente en el formato IEEE 754 doble precisión (64-bits), pudiendo representar números reales en el rango a Larson en [17], considera que el lenguaje no es bueno en cálculos de punto flotante intensivos. Soporte para documentación del usuario. El símbolo del % indica el comienzo de un comentario hasta el final de línea y, no posee ninguno para marcar aquellos de más de una línea. Al ser Erlang un lenguaje con tipos dinámicos requiere de comentarios para describir las estructuras de datos del programa a fin de mejorar la legibilidad. Existe además un generador de documentación llamado EDOC [19], inspirado en la herramienta JAVADOC de Java y adaptado a las convenciones del mundo Erlang; EDOC genera documentación en forma automática a partir de anotaciones manuales de tipos. Subtipos y enumeraciones. Erlang no soporta enumeraciones aunque podrían emularse. Tampoco soporta subtipos; se intentó desarrollar un sistema de tipos basado en subtipos pero el proyecto no tuvo éxito en la comunidad Erlang, quizás porque en el intento de detectar más errores en tiempos de compilación, se trató de imponer un estilo de programación que es más cercano al de los lenguajes con tipos estáticos, a costa de eliminar parte de la flexibilidad característica del lenguaje. Pautas para el estilo de codificación. En [9] hay una guía para escribir buen código en Erlang basada en la experiencia de varios proyectos comerciales. 9

10 Soporte para la abstracción y ocultamiento de la información. En Erlang los procesos son los mecanismos más sólidos para proveer encapsulamiento, abstracción y aislamiento puesto que, la máquina virtual evita que el código cruce las fronteras del proceso: el paso de mensajes es el mecanismo normal para la comunicación a través de las interfaces sin violar el principio de aislamiento; los protocolos de los mensajes implementan la abstracción de dichas interfaces. Aserciones. En Erlang las variables se comportan tal como en matemáticas, cuando se realiza la única asignación posible a las mismas, en realidad se enuncia una aserción que si se viola genera una excepción. Herramientas de análisis certificadas. Se han desarrollado distintas herramientas de análisis para asistir en la depuración de programas Erlang aunque no están certificadas por organismos o normas confiables. Los programas concurrentes son difíciles de depurar y verificar. Una forma posible de verificar un programa Erlang implica obtener un modelo formal intermedio al cual puede aplicársele técnicas de model checking; en particular se utiliza álgebra de procesos μcrl como lenguaje formal [5]. Interface con otros lenguajes. Un programa Erlang tiene posibilidad de interactuar con código escrito en otro lenguaje, que correrá fuera del sistema de tiempo de ejecución Erlang a través de un puerto (port); un canal de comunicación orientado a byte. La implementación actual de este mecanismo [3] depende de la plataforma, en Unix se utiliza el concepto de pipes. Teóricamente, el programa externo podría estar escrito en cualquier lenguaje mientras pueda manejar el mecanismo de comunicación interprocesos, con el cual está implementado el puerto. Usando este mismo principio básico de operación, un proceso Erlang puede abrir un socket para comunicar entre sí nodos Erlang distribuidos. Como ayuda a los programadores existen librerías para la interfaz entre Erlang y C o Java. Por tanto es muy fácil crear drivers, por ejemplo en C, para controlar hardware o implementar partes del sistema cuya performance sea crítica y delegar a Erlang el manejo de actividades concurrentes o distribuidas complejas. En [24] se propone una interfaz a código nativo de forma simple y eficiente, utilizada para simulación de procesos físicos. Un aspecto positivo del uso del mecanismo de puertos es que cualquier error fatal en el software externo no afecta el sistema ejecutando Erlang. Una desventaja es que el cambio de contexto y la comunicación entre procesos pueden ser muy costosos. Si el tiempo es una cuestión crítica, una posible solución es el uso de linked in drivers [12], con una latencia de comunicación entre 10 y 25 veces más pequeña que en el caso de los puertos. Esto implica escribir un programa en C, de acuerdo a ciertos principios y, enlazarlo dinámicamente al sistema en tiempo de ejecución de Erlang, preservando la ilusión de que los drivers son procesos escritos en este lenguaje. Este mecanismo compromete seguridad a cambio de velocidad: un error en él puede colapsar la máquina virtual y todas las aplicaciones que se estén ejecutando. Este es un aspecto negativo de Erlang [2] que debería mejorarse. Optimización del código. La implementación por defecto de Erlang es un intérprete de bytecode HIPE, el compilador a código nativo, completamente integrado en la versión open source, translada bytecode de la máquina virtual BEAM, just-in-time o ahead-of-time a código nativo (actualmente de ULTRASPARC, x86, y AMD64). HIPE soporta la ejecución mixta de código nativo e interpretado a nivel de granularidad de funciones individuales, otorgando al usuario un control de grano fino sobre el trade-off velocidad de ejecución/tamaño de código [18]. 10

11 Durante los últimos años se experimentaron formas de generar código nativo más rápido, tratando de eliminar estadísticamente y tanto como es posible, la sobrecarga introducida por la verificación de tipos en tiempo de ejecución. Portabilidad. Erlang se basa en el uso de máquina virtual con recolector de basura lo que permite obtener portabilidad a un gran número de plataformas (Windows, Linux, BSD, MacOSX, Solaris, VxWorks, etc.). 3 Conclusiones y trabajo futuro Se evaluó el lenguaje de programación Erlang en base a veintitrés estrictos requisitos, disponibles en la literatura, para examinar el uso de un lenguaje de programación en el desarrollo de sistemas de alta integridad. Erlang no cumple con muchos de los requisitos obligatorios o lo hace sin excesivo rigor. La respuesta a la pregunta planteada en el título: Erlang aún no es apropiado para el desarrollo de sistemas totalmente confiables. Sin embargo, puede afirmarse con seguridad que es perfectamente adecuado para sistemas de importancia empresarial crítica (BCS, por businesscritical systems), donde las consecuencias de un fallo no son tan graves, en el sentido que no producen daños físicos a personas sino que, las implicancias negativas pueden ser una amenaza a la confianza o economía. Es en este área donde Erlang ha tenido un éxito considerable; uno de los aspectos por el cual es tan popular entre los desarrolladores de BCS es la inclusión de constructos para obtener tolerancia a fallos. Teniendo en mente este hecho se piensa utilizar Erlang para la implementación de un middleware orientado a mensajes, basado en el modelo arquitectural de un microkernel, para sistemas distribuidos de control (NCS) con características de tiempo real flexible. Referencias 1. Armstrong, J. L.: Making reliable distributed systems in the presence of software errors. PhD thesis, Royal Institute of Technology, Estocolmo, Suecia, (2003). 2. Armstrong, J.: A history of Erlang. En HOPL III: Proceedings of the third ACM SIGPLAN Conference on History of Programming Languages, , (2007). 3. Armstrong, J.: Programming Erlang: Software for a Concurrent World. Pragmatic Bookshelf, ISBN X, (2007). 4. Arts, T, Benac Earle, C. y Sánchez Penas, J. J.. Translating Erlang to µcrl. En Fourth International Conference on Application of Concurrency to System Design, , Canada, (2004). 5. Benac-Earle, C., Fredlund, L. y Derrick, J.: Verifying Fault-Tolerant Erlang Programs. En Proceedings of ACM SigPlan Erlang 2005 Workshop, ACM Press, (2005). 6. Carlsson, R., Gustavsson, B., y Nyblom, P.: Erlang s Exception Handling Revisited. En: Proceedings of the Third ACM SIGPLAN Erlang Workshop, 16-26, (2004). 7. Convey, C., Fredricks, A., Gagner, C., Maxwell D. y Hamel, L.: Experience Report: Erlang in Acoustic Ray Tracing. The 13th ACM SIGPLAN International Conference on Functional Programming (ICFP 2008), ACM SIGPLAN Notices 43(9): , (2008). 8. Ericsson: Erlang goes multi-core, news/archive/erlang_goes multi_core.shtml, (2006). Accedido: 21/07/09. 11

12 9. Eriksson, K., Williams, M. y Armstrong, J.: Program Development Using Erlang - Programming Rules and Conventions. Internal Ericsson document EPK/NP 95:035, (1996). Accedido: 21/07/ Fredlund, L.-A., Gurov, D., Noll, T., Dam, M., Arts, T y Chugunov, G.: A verification tool for Erlang. International Journal on Software Tools for Technology Transfer (STTT), 4(4): , (2003). 11. Fritchie, S.L., Larson, J., Christenson, N., Jones, D. y Ohman, L.: Sendmail Meets Erlang: Experiences Using Erlang for Applications. Sixth International Erlang/OTP User Conference. Stockholm, (2000). 12. Fritchie, S. L.: The evolution of Erlang drivers and the Erlang driver toolkit. En Proceedings of the 1st ACM SIGPLAN Erlang Workshop, 34 44, (2002). 13. Gray, J.: Why do computers stop and what can be done about it?. Technical Report 85.7, Tandem Computers, (1985). 14. Guo, Q. y Derrick, J.: Verification of Timed Erlang/OTP Components Using the Process Algebra µcrl. 6th ACM SIGPLAN Erlang Workshop, 55-64, (2007). 15. Jones, R., A: Million-user Comet Application with Mochiweb, Part 2. Accedido: 21/07/ Kwon, J., Wellings, A. y King, S.: Assessment of the Java Programming Language for Use in High Integrity Systems. SIGPLAN Not., 38(4):34 46, (2003). 17. Larson, J.: Erlang for concurrent programming. Commun. ACM, Vol. 52, No. 3., 48-56, (2009). 18. Lindahl, T. y Sagonas, K.: Detecting software defects in telecom applications through lightweight static analysis: A war story. En Programming Languages and Systems: Proceedings of the Second Asian Symposium (APLAS'04), Vol de LNCS, , Springer, (2004). 19. Lindahl T. y Sagonas. K.: Typer: a type annotator of Erlang code. En Proceedings of the 2005 ACM SIGPLAN Erlang Workshop, 17 25, (2005). 20. Nicosia, V.: Towards hard real-time erlang. En Erlang '07: Proceedings of the 2007 SIGPLAN workshop on Erlang Workshop, 29-36, (2007). 21. Noll, T. y Roy. C. K.: Modeling Erlang in the π-calculus. En Proceedings of the ACM SIGPLAN 2005 Erlang Workshop (Erlang 05), 72 77, ACM, (2005). 22. Nyström, S.: Ideas for a new Erlang. Technical Report , Department of Information Technology Uppsala University, (2009). 23. Santoro, C.: An Erlang framework for autonomous mobile robots. En Proceedings of the 2007 SIGPLAN workshop on Erlang Workshop, Germany, (2007). 24. Scalas, A., Casu, G. y Pili, P.: High-performance technical computing with Erlang. En Proceedings of the 7th ACM SIGPLAN workshop on ERLANG, 49-60, (2008). 25. Teller, D.: Towards a resource-safe Erlang. En Proceedings of the 3rd Workshop on Collaboration and Security, 66-71, (2007). 26. Widera, M.: Adapting Structural Testing to Functional Programming. Software Engineering Research and Practice, CSREA Press, 86-92, (2006). 27. Wilhelmsson, J.: Exploring Alternative Memory Architectures for Erlang: Implementation and Performance Evaluation. Master s Thesis, Uppsala Unviversity, (2002). 12