Usaste GemStone? 2011/6/24 Guillermo Schwarz <[email protected]>: > Hernán, > Está bueno, creo que no es factible solucionarlo en Smalltalk dado como se > manejan las tareas. > En Java, cuando habìan GreenThreads en vez de threads del sistema operativo > pasaba lo mismo y lo resolvieron justamente usando threads del sistema > operativo. > Lo que encuentro interesante del asunto es que el modelo de programación en > Smalltalk es lineal, como si los threads/tareas no existieran, a excepción > del "yield" ocasional que dice "ahora sí me pueden interrumpir". Otro modelo > similar pero sin yield es el de los EJBs. Lo interesante es que en el mnundo > J2EE se prohibe el uso de threads y de sincronización, sin embargo por > debajo todo corre con threads, de modo que se podrìa decir que un > programador de EJBs es un progrmador de Smalltalk que actúa de manera > completamente ignorante de que por debajo todo ejecuta en paralelo, y eso es > posible porque no puede ocupar un singleton (que serìa la memoria > compartida), ni ocupar synchronized ni nada de eso, sino que todo debe pasar > por la base de datos. > Ahora bien, la base de datos es un sistema más. Si lo tienes programado por > ejemplo en H2, todo sigue estando en Java y ejecutando en threads, de modo > que ¿còmo se resuelven los temas de sincronización? Lo ùnco que has hecho es > trasladar el problema del espacio Java de los EJBs al espacio de las > transacciones en BD, pero sigue siendo el mismo problema y sigue siendo un > problema a resolver en Java... y está resuelto. ¿Cómo lo hace entonces? > Entonces te encuentras con que en el mundo de las BD este tema tiene 2 modos > de resolución: > 1. El sistema típico que pasan introducción a las BD en la U en el que se > bloquean los registros de las tablas y en caso de deadlock se mata una > transacción y luego se rehace, o bien se establece un orden por tabla y por > registro para tomar locks y evitar los deadlocks. > 2. El sistema que no es tan típico pero que es más eficiente, conocido como > versionamiento de registros o lock free synchronization, en los que se > minimiza el uso de locks (en el tiempo y en el espacio), de modo que casi > nunca se topan 2 locks y cuando se topan, se sigue la misma estrategia del > punto 1. > De ahí tengo la intuición que debería poder hacerse algo parecido en > Smalltalk, sòlo que deberìa ser necesario construir un modelo de > programación similar a EJB SLSB (Stateless Session Beans) en la que el > estado se maneje en una BD necesariamente, y luego esa BD sea implementada > de nuevo en Smalltalk con transacciones con lock free synchronization. > La experiencia que he tenido con los EJBs es que si los haces funcionar así > funcionan rapidísimo y es muy escalable, quizás no tanto como Terracotta > (acá hablan de 80 mil transacciones por > segundo http://www.theserverside.com/news/1364132/Terracottas-Scalability-Story), > pero sigue siendo impresionante. > Saludos, > Guillermo. > 2011/6/24 Hernan Wilkinson <[email protected]> >> >> Cuando se graba la imagen, como en todo smalltalk común, la misma se >> freeza. Pero uno de los grandes problemas que tuvieron que resolver los >> chicos fue el tema de la circularidad... o sea, como grabar los objetos que >> graban? :-) >> >> 2011/6/24 Guillermo Schwarz <[email protected]> >>> >>> Hernán, >>> Què interesante. La ùnica duda que me surgió es si al hacerlo sìncrono >>> significa que la imagen Smalltalk queda suspendida hasta que se resuelve o >>> bien que otros threads de la misma imagen pueden seguir ejecutando mientras >>> tanto. Todo esto lo pregunto porque resolver un acceso a disco con la >>> tecnología actual (sin SSD) es del orden de entre 10 y 100 veces más caro >>> que un acceso a RAM. >>> Saludos, >>> Guillermo. >>> >>> 2011/6/24 Hernan Wilkinson <[email protected]> >>>> >>>> por si les interesa... >>>> >>>> ---------- Forwarded message ---------- >>>> From: Hernan Wilkinson <[email protected]> >>>> Date: 2011/6/24 >>>> Subject: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS >>>> To: docentes <[email protected]>, alumnos <[email protected]> >>>> >>>> >>>> Defensa de Tesis de Licenciatura >>>> Aula 2, Pab I, 1ro de Julio de 2011, de 17hrs. a 18hrs. >>>> Título: Persistencia en SqueakNOS >>>> Alumnos: Guido Chari y Javier Pimás >>>> Directores: Hernán Wilkinson y Gerardo Richiarte >>>> Jurado: Máximo Prieto y Gabriela Arevalo. >>>> Resumen: >>>> SqueakNOS es una reificación de los conceptos de "Computadora" y de >>>> "Sistema Operativo" dentro del dialecto Squeak del lenguaje de programación >>>> Smalltalk. >>>> La filosofía de SqueakNOS establece que el desarrollo del mismo debe >>>> hacerse completamente en Smalltalk, utilizando código de bajo nivel >>>> únicamente en los casos en que no sea posible utilizar Smalltalk o que el >>>> deterioro de rendimiento sea extremadamente ostensible. >>>> El proyecto es un trabajo aún en desarrollo, y como tal, varias >>>> funcionalidades comunes a los Sistemas Operativos no han sido implementadas >>>> aún debido a su complejidad. Es por ello que esta investigación se centra >>>> en >>>> analizar varios interrogantes relacionados con la persistencia de los >>>> objetos, interrogantes que se presentan al momento de querer grabar el >>>> grafo >>>> de objetos que representa el modelo desarrollado. >>>> Para poder responder estos interrogantes, se desarrolló un controlador >>>> de discos ATA y un modelo de filesystem FAT32 completamente en Smalltalk, >>>> lo >>>> que brinda compatibilidad con otros sistemas operativos y con el entorno >>>> Squeak genérico. Así por ejemplo, se logra acceder al código fuente de los >>>> métodos y se avanza hacia el grabado de la imagen, característica que aún >>>> no >>>> estaba disponible en el sistema. >>>> Luego, se desarrolló una técnica de persistencia cuyo objetivo principal >>>> era la simplicidad y su principal desventaja el requerir una utilización >>>> importante y de manera ineficaz de memoria. A pesar de sus desventajas, fue >>>> el primer paso para lograr la atomicidad necesaria para grabar los objetos >>>> mientras estos estaban siendo modificados. >>>> Finalmente, se implementó un esquema de manejo de memoria basado en >>>> paginación, modificando el mecanismo de manejo de interrupciones original >>>> de >>>> SqueakNos para que pudiera funcionar en forma sincrónica, requisito >>>> indispensable para resolver los fallos de página. Esta solución >>>> permitió resolver los fallos de página completamente desde Smalltalk, lo >>>> cual dio lugar a la experimentación y al desarrollo de formas novedosas de >>>> utilización del mismo. Gracias a esto, resultó posible por ejemplo, >>>> implementar una técnica alternativa de persistencia de la imagen, que >>>> utiliza mucha menos memoria que la original debido a la asistencia del >>>> mecanismo de paginación y la utilización de la técnica de copy on write. >>>> Por último, se analizan aspectos relacionados con la manera de trabajar >>>> en este tipo de entornos y plataformas, sus ventajas, sus dificultades y >>>> complicaciones. >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Hernán Wilkinson >>>> Agile Software Development, Teaching & Coaching >>>> Mobile: +54 - 911 - 4470 - 7207 >>>> email: [email protected] >>>> site: http://www.10Pines.com >>>> >>>> -- >>>> To post to this group, send email to [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected] >>>> >>>> http://www.clubSmalltalk.org >>> >>> >>> -- >>> Saludos cordiales, >>> >>> Guillermo Schwarz >>> Sun Certified Enterprise Architect >>> >>> -- >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> >>> http://www.clubSmalltalk.org >> >> >> -- >> Hernán Wilkinson >> Agile Software Development, Teaching & Coaching >> Mobile: +54 - 911 - 4470 - 7207 >> email: [email protected] >> site: http://www.10Pines.com >> Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >> >> -- >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> >> http://www.clubSmalltalk.org > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org
-- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
