Hola gente! Hmmm.... sigue siendo lineal en Smalltalk el tema "threads"? Pense que ya en estos anios cada Processor (disculpen, no conozco el termino exacta), se ejecutaba en un thread de usuario por lo menos.
Cuales Smalltalk (implementaciones) hacen eso? Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez 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 <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 <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
