Una implementación transparente de memoria transaccional en un lenguaje dinámico orientado a objetos

• Autores: Leveroni, Luciano
• Año de publicación: 2017
• Idioma: español castellano
• Tipo de recurso: tesis de grado
• Colaborador/a o director/a de tesis: Wilkinson, Hernán Alfredo
• Materia: STM; MEMORIA TRANSACCIONAL; ORIENTADO A OBJETOS; DINAMICAMENTE TIPADO; RUBY; MRI; RUBINIUS; PRIMITIVAS; META MODELO RUBY; INMUTABILIDAD; RUBY VM; SMALLTALK; GENERACION DINAMICA DE CODIGO; TRANSACTIONAL MEMORY; OBJECT ORIENTED; DYNAMIC TYPING; RUBINIUS; PRIMITIVES; RUBY META MODEL; INMUTABILITY; SMALLTALK; DYNAMIC CODE GENERATION
• Institución: Universidad Nacional de Buenos Aires. Facultad de Ciencias Exactas y Naturales

Memoria Transaccional (de ahora en adelante, STM) emerge como una alternativa a técnicas tradicionales de control de concurrencia, basadas principalmente en la idea de locks y sus variantes (semáforos, monitores, etc). En los últimos años la investigación sobre este tema se encuentra en auge. Este trabajo describe una implementación transparente de STM sobre el lenguaje Ruby. Entendemos por transparente a una implementación que, a diferencia de otras implementaciones existentes, no resulta intrusiva para el programador-usuario de esta extensión del lenguaje. La implementación realizada es compatible con MRI, la implementación oficial de Ruby, así como Rubinius, una implementación alternativa realizada sobre Ruby mismo. La técnica utilizada se basa en la generación dinámica de código, en tiempo de ejecución, fuertemente basada en el trabajo Transactional Memory for Smalltalk [7] (2008, Lukas Renggli et. al). La investigación se centra en exhibir las ventajas y limitaciones del lenguaje Ruby al momento de implementar STM, así como los obstáculos y beneficios particulares de las dos implementaciones de Ruby mencionadas. Se muestra como las distintas capacidades reflexivas, características del meta-modelo y de meta-programación del lenguaje inciden en la posibilidad de implementar esta técnica sin modificaciones necesarias a las VMs asociadas (salvo algunas excepciones). Como conclusión, Ruby como lenguaje ofrece en principio las herramientas para lograr una de STM robusta y completa. Sin embargo, la problemática de las primitivas de lenguaje junto con algunas deficiencias de implementación y limitaciones del meta-modelo, derivaron en una implementación más compleja y acoplada a particularidades implementativas. No obstante, se logró una implementación funcional que requiere modificaciones a nivel implementación del lenguaje / VM para solventar las limitaciones expuestas.
Transactional Memory (from now on, STM) emerges as an alternative to traditional concurrency control techniques based mainly in the idea of locks and it’s variants (semaphores, monitors, etc). Over the last years, research on this topic is booming. This work describes a transparent implementation of STM for the Ruby language. By transparent, we mean an implementation that, in contrast with existing ones, is nonintrusive for the programmer-user of this language extension. The implementation presented is compatible with MRI, the official Ruby implementation, as well as Rubinius, an alternative implementation based on Ruby itself. The technique used is strongly based on the work Transactional Memory for Smalltalk (2008, Lukas Renggli et. al.). Research is focused on showing the advantages and limitations of the Ruby language in relationship with implementing STM, as well as obstacles and benefits particularly linked with the two implementations mentioned. It is shown how reflexive capabilities, meta-programming and meta-model characteristics of the language affect the possibility of implementing this technique without needing to modify the corresponding VMs (with some exceptions). In conclusion, Ruby as a language offers the tools needed to achieve a robust and complete STM implementation. However, issues with language primitives, together with some implementation deficiencies and limitations of the meta-model, derived in a more complex implementation, somewhat fragile and coupled to implementation details. Nonetheless, a functional implementation was achieved that requires changes at the language implementation level / VM to solve the exposed limitations.
Fil: Leveroni, Luciano. Universidad de Buenos Aires. Facultad de Ciencias Exactas y Naturales; Argentina.