Hola gente! Muy interesante las respuestas! Por ejemplo, recien me entero por @hernanwilkinson que muchas implementaciones son "green threads". cuales son? Imagino Squeak y Pharo, es asi? otra mas?
Interesante tambien lo de las transacciones, no esperaba llegar a ese tema... pero me interesa ;-) Bueno, en mi implementacion de una VM open source, presentada en Smalltalks 2010, tome la decision de que hay objetos transaccionales. Es decir, el programador decide QUE objetos son transaccionales. Y a esos objetos, se los decora, para que los set y los get de sus valores internos, tengan el codigo para controlar si estan en una transaccion o no. Algo escrito en: http://ajlopez.wordpress.com/2010/11/15/transactional-objects-in-ajtalk-a-quick-intro/ Como tambien tengo elementos de objetos remotos http://ajlopez.wordpress.com/2010/10/28/distributed-objects-in-ajtalk/ mi idea es llegar a: - Exponer para afuera, objetos que decido explicitamente que son transaccionales - El cliente remoto, interactua con esos objetos - Solo en ese caso de uso los set/get de ESOS objetos se justifica el tema de STM (Software Transactional Memory) Los demas objetos quedan pipi cucu. Tiembla GemStone! ;-) ;-) Mis enlaces sobre STM: http://delicious.com/ajlopez/stm Tendria que recordar casos de uso de Clojure http://delicious.com/ajlopez/stm+clojure Nos leemos! Angel "Java" Lopez @ajlopez 2012/11/20 Andrés Fortier <[email protected]> > El tema con la memoria transaccional es el rendimiento. Básicamente, si > tenemos un código basado en locks para proteger datos compartidos, > cuando un procesador toma un lock puede modificar los datos a su antojo. > En cambio, si lo hacemos mediante una transacción, es necesario guardar > las dos versiones (la vieja y la nueva) por si eso falla. Esto hace que > las operaciones a memoria se dupliquen, el tamaño necesario para > bufferes de escritura (o undo-logs) se dispare en caso de tener > transacciones grandes. De esta forma, si tenemos un código con poca > "contención" en el acceso a los datos compartidos (y generalmente está > optimizado para que así sea, ya que eso es el cuello de botella en > programas paralelos) entonces la versión basada en locks proporcionará > un rendimiento mejor. Además, tendremos numerosas llamadas al runtime > que se encarga de proporcionar esas características (atomicidad, > consistencia...) que enlentecen la ejecución. > > También hay propuestas hardware o híbridas, de Universidades o de > fabricantes (como el sistema híbrido de Intel o el Rock de Sun, que > también es híbrido). En estas propuestas, se pasa a algún mecanismo HW > las tareas de mantenimiento de versiones, detección de colisiones, > inicialización y commit de las transacciones, etc. > > A mi parecer, uno de los principales problemas, que creo que no se > comenta en el artículo, es la falta de aplicaciones "serias" que > utilicen memoria transaccional. Sí, tenemos micro-benchmarks (todos los > artículos implementan de alguna manera red-black trees y linked lists), > tenemos kernels de aplicaciones, pero en cualquier caso son aplicaciones > generadas a base de "cambiar locks por transacciones". Una de las > ventajas de las transacciones es que se pueden componer, es decir, se > puede anidar una transacción dentro de otra sin ningún problema, y en > cualquier orden. Esto no se puede hacer con locks, ya que puede llevar a > deadlock (si dos threads pretenden tomar dos locks dados en orden > inverso), lo que obliga al programador a ser consciente de todos los > posibles caminos que puedan tomar los threads en el sistema. De esta > forma, el diseño de una aplicación paralelo (el diseño completo, desde > las estructuras de datos hasta el código de cada función) sería > completamente diferente con memoria transaccional, y la mayoría de las > aplicaciones de prueba que tenemos, simplemente, no son válidas. > > Pero ese no es el único problema, y es que la programación paralela no > se simplifica tanto como se pudiera pensar en un principio. Las tareas > de sincronización entre threads siguen siendo complejas, y existen > estructuras de datos que son inherentemente muy paralelas utilizando > locks, pero muy poco utilizando transacciones (como el acceso a un > RB-tree, con congestión en la raíz). En muchos casos, un problema se > soluciona de manera más sencilla utilizando un lock que una transacción > (como la gestión de una cola de trabajo, a la que acceden los threads > para determinar qué tienen que hacer) pero ambos sistemas, locks y > transacciones, son incompatibles. De esta forma, difícilmente se pueden > conseguir aplicaciones de prueba realmente válidas. > > Sin aplicaciones válidas para verificar la hipotética ventaja (de > rendimiento, simplicidad de programación, etc) los fabricantes del > hardware no se van a tirar a la piscina, y los programadores no tienen > una herramienta válida (que no tarde días en ejecutar un micro-benchmark > por simulación) para evaluar su sistema. Estamos en la pescadilla que se > muerde la cola. Hay mucha gente y muchas empresas interesadas en que > esto salga adelante (Intel, Sun, Microsoft, IBM, y muchos grupos de > investigación por todo el mundo) pero la situación real no está clara. > Ya veremos dentro de 15 años... > > Ahhh, ahora se lo que se siente ser un troll! > > Saludos! > Andrés (el otro) > > Texto original: > > http://barrapunto.com/comments.pl?sid=79131&op=&threshold=1&commentsort=0&mode=thread&cid=1103532 > > > On mar, 2012-11-20 at 16:57 -0300, Guillermo Schwarz wrote: > > Si tienes memoria transaccional y las transacciones son versionadas > > (optimistic locking), entonces se mantiene la coherencia transaccional > > de cada una de las transacciones aunque ejecuten en paralelo. > > > > > > > > > > 2012/11/20 Andres Valloud <[email protected]> > > Si hay cosas como generaciones, entonces become: aun con > > object table > > es un quilombo porque te pueden quedar referencias cruzadas > > que no se > > permiten en tu implementacion. A veces puede que no te quede > > otra que > > copiar object bodies. Y ademas actualizar los remember tables > > de > > turno, hacer algo especial si esta andando el IGC, y todas > > esas cosas. > > > > 2012/11/20 Hernan Wilkinson <[email protected]>: > > > dependiendo de la implementacion del manejo de memoria, el > > become puede ser > > > simple o complejo... en el caso de usar forward references > > (implementacion > > > que usa la mayoria) el become es similar el paso del mark de > > un gc de mark & > > > sweep, o sea, hay que buscar todas las referencias, y por lo > > tanto su > > > implementacion sera similar a la del gc y en la mayoria de > > los smalltalks el > > > gc hace un "stop the world"... tene en cuenta que la mayoria > > de las > > > implementaciones usan green threads. > > > > > > En el caso de gemstone que usa object table, el become es un > > simple swap de > > > referencias y resuelven el conflico de concurrecia > > simplemente por utilizar > > > memoria transaccional, no tienen que hacer nada raro mas > > alla de lo que ya > > > proveen para trabajar concurrentemente (segun lo que > > entiendo, puedo estar > > > equivocado) > > > > > > Saludos > > > Hernan. > > > > > > > > > 2012/11/19 Angel Java Lopez <[email protected]> > > >> > > >> Hola gente! > > >> > > >> Hoy, mientras leia el Smalltalk-80 the language and its > > implementation en > > >> el desayuno, se me ocurrio pensar: > > >> > > >> Como hace un Smalltalk para hacer un become: si hay > > multithreading (es > > >> decir, si hay varios threads ejecutandose)? > > >> Pues me imagino que mientras se hace > > >> > > >> a become: b > > >> > > >> alguno otro thread puede estar operando con b o con a (por > > ejemplo, tomo > > >> la clase de b ANTES del become, lookup de un metodo, y > > luego lo aplica a b > > >> DESPUES del become) > > >> (o, si la implementacion interna es un object table (una > > celda por > > >> objeto), accedo a la celda de b, tomo algo de la celda (por > > ejemplo, el > > >> puntero a la clase), y mientras me cambian la celda, donde > > esta el puntero > > >> al resto de los datos) > > >> (tambien me puedo imaginar una implementacion por object > > table (una celda > > >> por objeto), donde haya menos cosas que confundan a un > > become: a medio > > >> hacer; por ejemplo, que tenga apenas el puntero al > > contenido del objeto, y > > >> ahi en el contenido este el puntero a la clase). > > >> > > >> Bueno, no se si me explico .. > > >> > > >> Tienen idea? > > >> > > >> Me imagino respuestas: > > >> > > >> - No, los Smalltalks X, Y, Z solo manejan un thread, y todo > > lo demas son > > >> "green threads" > > >> - En el Smalltalk W, hacemos become: multithreading, pero > > sin controlar > > >> nada (sin poner locks, semaforos o lo que sea) > > >> - En el Smalltalk T, tenemos multithread y hacemos un lindo > > bolonki para > > >> hacer que el become: sea thread-safe > > >> - En el Smalltalk S, tenemos multithread y la > > implementacion interna > > >> (object table con celda atomica, con pocos datos; o puntero > > directo, o lo > > >> que sea) es tal, que el become termina siendo thread-safe > > por naturaleza > > >> > > >> Cual es? > > >> > > >> Nos leemos! > > >> > > >> Angel "Java" Lopez > > >> @ajlopez > > >> > > >> -- > > >> 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 > > > Phone: +54 - 011 - 6091 - 3125 > > > Mobile: +54 - 911 - 4470 - 7207 > > > email: [email protected] > > > site: http://www.10Pines.com > > > Address: Alem 693, Floor 5 B, 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 > > > > -- > > To post to this group, send email to > > [email protected] > > To unsubscribe from this group, send email to clubSmalltalk > > [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 clubSmalltalk > > [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 > -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
