Andres, Yo nunca. No sé si hay una versión gratuita.
Saludos, Guillermo. 2011/6/24 Andres Valloud <[email protected]> > 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 > -- 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
