become: y threads

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

become: y threads

Angel Java Lopez
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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Esteban A. Maringolo
El día 19 de noviembre de 2012 10:39, Angel Java Lopez
<[hidden email]> escribió:

> 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?

Habria que ver cual es el soporte de GemStone con respecto al
#become:, AFAIR su uso era bastante limitado.

En el caso de Dolphin tiene un object-table, y el #become: lo unico
que hace es intercambiar pointers de los cuerpos de los objetos
receptor y argumento, es una operación muy rápida. El #oneWayBecome:
tiene que recorrer toda la object table.

Igual cuando haces become, y tu objeto estaba en una hashed
collection, y se "convirtió" en un objeto que devuelve un hash
distinto empiezan los quilombos :D

Yo creo que la "solución" es dartelo sin que sea thread-safe, y hacete cargo :D
A los smalltalkers no nos gusta el quilombo :)

Saludos!

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Sebastian Calvo


Yo creo que la "solución" es dartelo sin que sea thread-safe, y hacete cargo :D
A los smalltalkers no nos gusta el quilombo :)


Preguntale a Vallould :)

Saludos 

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Hernan Wilkinson-3
In reply to this post by Angel Java Lopez
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 <[hidden email]>
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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org



--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Phone: +54 - 011 - 6091 - 3125
Mobile: +54 - 911 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com
Address: Alem 693, Floor 5 B, Buenos Aires, Argentina

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Andres Valloud-5
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 <[hidden email]>:

> 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 <[hidden email]>
>>
>> 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 [hidden email]
>> To unsubscribe from this group, send email to
>> [hidden email]
>>
>> http://www.clubSmalltalk.org
>
>
>
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Phone: +54 - 011 - 6091 - 3125
> Mobile: +54 - 911 - 4470 - 7207
> email: [hidden email]
> site: http://www.10Pines.com
> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Guillermo Schwarz
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 <[hidden email]>
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 <[hidden email]>:
> 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 <[hidden email]>
>>
>> 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 [hidden email]
>> To unsubscribe from this group, send email to
>> [hidden email]
>>
>> http://www.clubSmalltalk.org
>
>
>
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Phone: <a href="tel:%2B54%20-%20011%20-%206091%20-%203125" value="+541160913125">+54 - 011 - 6091 - 3125
> Mobile: <a href="tel:%2B54%20-%20911%20-%204470%20-%207207" value="+5491144707207">+54 - 911 - 4470 - 7207
> email: [hidden email]
> site: http://www.10Pines.com
> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org



--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Andres Valloud-5
In reply to this post by Esteban A. Maringolo
Si hay forwardeo de punteros en el object table, entonces si
oneWayBecome: se puede implementar mirando el object table.  Si no,
hay que mirar todos los object bodies.

Ahora, viste que cuando haces un oneWayBecome: de una clase a otra,
las instancias del receptor no se transforman en instancias del
argumento?... o que por lo menos no deberian transformarse?... que
detalle, no?...

2012/11/19 Esteban A. Maringolo <[hidden email]>:

> El día 19 de noviembre de 2012 10:39, Angel Java Lopez
> <[hidden email]> escribió:
>> 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?
>
> Habria que ver cual es el soporte de GemStone con respecto al
> #become:, AFAIR su uso era bastante limitado.
>
> En el caso de Dolphin tiene un object-table, y el #become: lo unico
> que hace es intercambiar pointers de los cuerpos de los objetos
> receptor y argumento, es una operación muy rápida. El #oneWayBecome:
> tiene que recorrer toda la object table.
>
> Igual cuando haces become, y tu objeto estaba en una hashed
> collection, y se "convirtió" en un objeto que devuelve un hash
> distinto empiezan los quilombos :D
>
> Yo creo que la "solución" es dartelo sin que sea thread-safe, y hacete cargo :D
> A los smalltalkers no nos gusta el quilombo :)
>
> Saludos!
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Andres Valloud-5
In reply to this post by Sebastian Calvo
Que?

2012/11/19 GallegO <[hidden email]>:

>
>>
>> Yo creo que la "solución" es dartelo sin que sea thread-safe, y hacete
>> cargo :D
>> A los smalltalkers no nos gusta el quilombo :)
>>
>
> Preguntale a Vallould :)
>
> Saludos
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Andres Fortier-2
In reply to this post by Guillermo Schwarz
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 <[hidden email]>
>         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 <[hidden email]>:
>         > 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 <[hidden email]>
>         >>
>         >> 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
>         [hidden email]
>         >> To unsubscribe from this group, send email to
>         >> [hidden email]
>         >>
>         >> http://www.clubSmalltalk.org
>         >
>         >
>         >
>         >
>         > --
>         > Hernán Wilkinson
>         > Agile Software Development, Teaching & Coaching
>         > Phone: +54 - 011 - 6091 - 3125
>         > Mobile: +54 - 911 - 4470 - 7207
>         > email: [hidden email]
>         > site: http://www.10Pines.com
>         > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
>         >
>         > --
>         > To post to this group, send email to
>         [hidden email]
>         > To unsubscribe from this group, send email to
>         > [hidden email]
>         >
>         > http://www.clubSmalltalk.org
>        
>         --
>         To post to this group, send email to
>         [hidden email]
>         To unsubscribe from this group, send email to clubSmalltalk
>         +[hidden email]
>        
>         http://www.clubSmalltalk.org
>        
>
>
>
>
> --
> Saludos cordiales,
>
> Guillermo Schwarz
> Sun Certified Enterprise Architect
>
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to clubSmalltalk
> +[hidden email]
>  
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Angel Java Lopez
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:

Como tambien tengo elementos de objetos remotos

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 <[hidden email]>
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 <[hidden email]>
>         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 <[hidden email]>:
>         > 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 <[hidden email]>
>         >>
>         >> 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
>         [hidden email]
>         >> To unsubscribe from this group, send email to
>         >> [hidden email]
>         >>
>         >> http://www.clubSmalltalk.org
>         >
>         >
>         >
>         >
>         > --
>         > Hernán Wilkinson
>         > Agile Software Development, Teaching & Coaching
>         > Phone: +54 - 011 - 6091 - 3125
>         > Mobile: +54 - 911 - 4470 - 7207
>         > email: [hidden email]
>         > site: http://www.10Pines.com
>         > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
>         >
>         > --
>         > To post to this group, send email to
>         [hidden email]
>         > To unsubscribe from this group, send email to
>         > [hidden email]
>         >
>         > http://www.clubSmalltalk.org
>
>         --
>         To post to this group, send email to
>         [hidden email]
>         To unsubscribe from this group, send email to clubSmalltalk
>         +[hidden email]
>
>         http://www.clubSmalltalk.org
>
>
>
>
>
> --
> Saludos cordiales,
>
> Guillermo Schwarz
> Sun Certified Enterprise Architect
>
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to clubSmalltalk
> +[hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Guillermo Schwarz
In reply to this post by Andres Fortier-2
+1

En memoria RAM típicamente se usa algún tipo de non-blocking synchronization:

1. wait-free-concurrency
2. lock-free-concurrency.


Típicamente se implementan usando un número de versión y primitivas a nivel de CPU conocidas como CAS y LL/SC. Casi todas las CPUs impĺementan alguna de las 2.

Pero eso de tener transacciones es aún mejor. Es más grande y por ende requieres algunos de los 2 anteriores + necesitas poder volver a una versión particular para poder implementar el rollback (y automatic retry si es que se quiere).


Lo que dice ahí es que no es necesario comprar una CPU especial ni una memoria especial, sino que basta con usar algunas estructuras de datos + CAS o LL/SC y se tiene memoria trasaccional.

Saludos,
Guillermo.


2012/11/20 Andrés Fortier <[hidden email]>
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 <[hidden email]>
>         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 <[hidden email]>:
>         > 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 <[hidden email]>
>         >>
>         >> 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
>         [hidden email]
>         >> To unsubscribe from this group, send email to
>         >> [hidden email]
>         >>
>         >> http://www.clubSmalltalk.org
>         >
>         >
>         >
>         >
>         > --
>         > Hernán Wilkinson
>         > Agile Software Development, Teaching & Coaching
>         > Phone: <a href="tel:%2B54%20-%20011%20-%206091%20-%203125" value="+541160913125">+54 - 011 - 6091 - 3125
>         > Mobile: <a href="tel:%2B54%20-%20911%20-%204470%20-%207207" value="+5491144707207">+54 - 911 - 4470 - 7207
>         > email: [hidden email]
>         > site: http://www.10Pines.com
>         > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
>         >
>         > --
>         > To post to this group, send email to
>         [hidden email]
>         > To unsubscribe from this group, send email to
>         > [hidden email]
>         >
>         > http://www.clubSmalltalk.org
>
>         --
>         To post to this group, send email to
>         [hidden email]
>         To unsubscribe from this group, send email to clubSmalltalk
>         +[hidden email]
>
>         http://www.clubSmalltalk.org
>
>
>
>
>
> --
> Saludos cordiales,
>
> Guillermo Schwarz
> Sun Certified Enterprise Architect
>
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to clubSmalltalk
> +[hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org



--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Mariano Martinez Peck
No responde a la pregunta original de Angel, pero, para tener un "fast become" (o por lo menos no tener que escanear toda la memoria solo para eso), mas allá de las obvias (object tables (GemStone) o direct pointers pero con los headers separados apuntando a los bodies (VW), hay una más que yo conozco para implementar el becomeForward (no become): lazy become.  La idea es (por lo que yo entiendo) es que al objeto viejo le pones unos flags en el OH y le pones un pointer al nuevo. Luego (lazily) el GC se encarga de actualizar las referencias al nuevo, hasta que ya no haya nadie apuntando al viejo. Bue, por si mandé fruta, copio lo que dijo Eliot:

lazy become.  The JIT's use of inline cacheing provides a cheap way of avoiding scanning the heap as part of a become (which is the simple approach to implementingbecome in a system with direct pointers).  A becomeForward: on a (set of) non-zero-sized object(s) turns the object into a "corpse" or "forwarding object" whose first (non-header) word/slot is replaced by a pointer to the target of the becomeForward:.  The corpse's class index is set to one that identifies corpses and, because it is a hidden class index, will always fail an inline cache test.  The inline cache failure code is then responsible for following the forwarding pointer chain (these are Iliffe vectors :) ) and resolving to the actual target.  We have yet to determine exactly how this is done (e.g. change the receiver register and/or stack contents and retry the send, perhaps scanning the current activation).  See below on how we deal with becomes on objects with named inst vars.  Note that we probably don't have to worry about zero-sized objects.  These are unlikely to be passed through the FFI (there is nothing to pass :) ) and so will rarely be becommed.  If they do, they can become slowly.  Alternatively we can insist that objects are at least 16 bytes in size (see a8-byte alignment below) so that there will always be space for a forwarding pointer.  Since none of the immediate classes can have non-immediate instances and since we allocate the immediate classes indices corresponding to their tag pattern (SmallInteger = 1, Character = 3, SmallFloat = 4?) we can use all the class indices from 0 to 7 for special uses, 0 = forward, and e.g. 1 = header-sized filler.


2012/11/20 Guillermo Schwarz <[hidden email]>
+1

En memoria RAM típicamente se usa algún tipo de non-blocking synchronization:

1. wait-free-concurrency
2. lock-free-concurrency.


Típicamente se implementan usando un número de versión y primitivas a nivel de CPU conocidas como CAS y LL/SC. Casi todas las CPUs impĺementan alguna de las 2.

Pero eso de tener transacciones es aún mejor. Es más grande y por ende requieres algunos de los 2 anteriores + necesitas poder volver a una versión particular para poder implementar el rollback (y automatic retry si es que se quiere).


Lo que dice ahí es que no es necesario comprar una CPU especial ni una memoria especial, sino que basta con usar algunas estructuras de datos + CAS o LL/SC y se tiene memoria trasaccional.

Saludos,
Guillermo.


2012/11/20 Andrés Fortier <[hidden email]>
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 <[hidden email]>
>         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 <[hidden email]>:
>         > 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 <[hidden email]>
>         >>
>         >> 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
>         [hidden email]
>         >> To unsubscribe from this group, send email to
>         >> [hidden email]
>         >>
>         >> http://www.clubSmalltalk.org
>         >
>         >
>         >
>         >
>         > --
>         > Hernán Wilkinson
>         > Agile Software Development, Teaching & Coaching
>         > Phone: <a href="tel:%2B54%20-%20011%20-%206091%20-%203125" value="+541160913125" target="_blank">+54 - 011 - 6091 - 3125
>         > Mobile: <a href="tel:%2B54%20-%20911%20-%204470%20-%207207" value="+5491144707207" target="_blank">+54 - 911 - 4470 - 7207
>         > email: [hidden email]
>         > site: http://www.10Pines.com
>         > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
>         >
>         > --
>         > To post to this group, send email to
>         [hidden email]
>         > To unsubscribe from this group, send email to
>         > [hidden email]
>         >
>         > http://www.clubSmalltalk.org
>
>         --
>         To post to this group, send email to
>         [hidden email]
>         To unsubscribe from this group, send email to clubSmalltalk
>         +[hidden email]
>
>         http://www.clubSmalltalk.org
>
>
>
>
>
> --
> Saludos cordiales,
>
> Guillermo Schwarz
> Sun Certified Enterprise Architect
>
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to clubSmalltalk
> +[hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org



--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org



--
Mariano
http://marianopeck.wordpress.com

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Angel Java Lopez
Ah! Gracias Mariano, interesante... muy interesante.... diria el Dr. Vicker de Supercar #soytanviejo ;-)... el "viejo truco" de usar el OH ;-)

Se me habia ocurrido algo asi en otro contexto, el anio pasado lo moleste en Smalltalks 2011 al bueno de McClure tratando de explicarlo en Anglish ;-) 

Resulta que por lo que entendi de la charla de McClure, cuando en GemStone agregan una variable de instancia a una clase, como que se bailan la conga para reorganizar todos los objetos instancias (hacerle lugar a esa variable) y tener los metodos recompilados (creo que no hace falta, por lo menos al agregar una variable, puede que no haya metodos que la referencien todavia, a no ser que algun metodo tenga ese nombre de variable y la hubiera compilado como global o algo asi, bue....) Eso me hizo acordar a lo que hace Smalltalk/X que tambien, necesita recompilar o algo asi para cuando se agrega una variable de instancia a una clase ya definida.

Mi propuesta es:

- x instancia de clase X. X es un objeto, como todos sabemos.
- A la definicion de X le agregamos una variable de instancia, una nueva variable que tienen que tener todas sus instancias. Se crea un nuevo objeto clase X2, y X tiene un puntero (hasta entonces en 0) a la nueva X2. El diccionario Smalltalk apunta con el nombre #X a X2
- x tiene como clase a X, y esta, tiene un puntero interno (usualmente en 0) con "nueva version" a X2. X2 tiene un diccionario de metodos, los de X, recompilados para usar la nueva estructura de los objetos instancia (si es que hace falta recompilarlos, por ejemplo, no solo ante un agregado de variable, sino tambien ante una remocion de variable de instancia).
- Cuando se accede a un metodo de x, se accede a X, y ahi, la VM dice: "oia, la pucha, x tiene la estructura de X, pero X ahora tiene una nueva version, X2, aplico los cambios a la estructura interna de x (ahora tiene una nueva variable o dos o lo que sea), y luego de hacer ese cambio, ahora x tiene como clase y apunta directamente a X2.
- A medida que el sistema va funcionando, todas las instancias x1, x2, xn de X pasan a ser "refactorizadas" poco a poco, apuntan a X2, y X original no es usada por nadie, y queda pasible de recoleccion de basura

No es fino? ;-)

Tambien al serializar la imagen, se podria forzar la conversion de todos las instancias x que todavia apuntan a X, pero seria volver al esquema McClure/GemStone/MeBailoLaCongaTodaDeGolpe

Angel "Lazy" Lopez

2012/11/21 Mariano Martinez Peck <[hidden email]>
No responde a la pregunta original de Angel, pero, para tener un "fast become" (o por lo menos no tener que escanear toda la memoria solo para eso), mas allá de las obvias (object tables (GemStone) o direct pointers pero con los headers separados apuntando a los bodies (VW), hay una más que yo conozco para implementar el becomeForward (no become): lazy become.  La idea es (por lo que yo entiendo) es que al objeto viejo le pones unos flags en el OH y le pones un pointer al nuevo. Luego (lazily) el GC se encarga de actualizar las referencias al nuevo, hasta que ya no haya nadie apuntando al viejo. Bue, por si mandé fruta, copio lo que dijo Eliot:

lazy become.  The JIT's use of inline cacheing provides a cheap way of avoiding scanning the heap as part of a become (which is the simple approach to implementingbecome in a system with direct pointers).  A becomeForward: on a (set of) non-zero-sized object(s) turns the object into a "corpse" or "forwarding object" whose first (non-header) word/slot is replaced by a pointer to the target of the becomeForward:.  The corpse's class index is set to one that identifies corpses and, because it is a hidden class index, will always fail an inline cache test.  The inline cache failure code is then responsible for following the forwarding pointer chain (these are Iliffe vectors :) ) and resolving to the actual target.  We have yet to determine exactly how this is done (e.g. change the receiver register and/or stack contents and retry the send, perhaps scanning the current activation).  See below on how we deal with becomes on objects with named inst vars.  Note that we probably don't have to worry about zero-sized objects.  These are unlikely to be passed through the FFI (there is nothing to pass :) ) and so will rarely be becommed.  If they do, they can become slowly.  Alternatively we can insist that objects are at least 16 bytes in size (see a8-byte alignment below) so that there will always be space for a forwarding pointer.  Since none of the immediate classes can have non-immediate instances and since we allocate the immediate classes indices corresponding to their tag pattern (SmallInteger = 1, Character = 3, SmallFloat = 4?) we can use all the class indices from 0 to 7 for special uses, 0 = forward, and e.g. 1 = header-sized filler.


2012/11/20 Guillermo Schwarz <[hidden email]>
+1

En memoria RAM típicamente se usa algún tipo de non-blocking synchronization:

1. wait-free-concurrency
2. lock-free-concurrency.


Típicamente se implementan usando un número de versión y primitivas a nivel de CPU conocidas como CAS y LL/SC. Casi todas las CPUs impĺementan alguna de las 2.

Pero eso de tener transacciones es aún mejor. Es más grande y por ende requieres algunos de los 2 anteriores + necesitas poder volver a una versión particular para poder implementar el rollback (y automatic retry si es que se quiere).


Lo que dice ahí es que no es necesario comprar una CPU especial ni una memoria especial, sino que basta con usar algunas estructuras de datos + CAS o LL/SC y se tiene memoria trasaccional.

Saludos,
Guillermo.


2012/11/20 Andrés Fortier <[hidden email]>
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 <[hidden email]>
>         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 <[hidden email]>:
>         > 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 <[hidden email]>
>         >>
>         >> 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
>         [hidden email]
>         >> To unsubscribe from this group, send email to
>         >> [hidden email]
>         >>
>         >> http://www.clubSmalltalk.org
>         >
>         >
>         >
>         >
>         > --
>         > Hernán Wilkinson
>         > Agile Software Development, Teaching & Coaching
>         > Phone: <a href="tel:%2B54%20-%20011%20-%206091%20-%203125" value="+541160913125" target="_blank">+54 - 011 - 6091 - 3125
>         > Mobile: <a href="tel:%2B54%20-%20911%20-%204470%20-%207207" value="+5491144707207" target="_blank">+54 - 911 - 4470 - 7207
>         > email: [hidden email]
>         > site: http://www.10Pines.com
>         > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
>         >
>         > --
>         > To post to this group, send email to
>         [hidden email]
>         > To unsubscribe from this group, send email to
>         > [hidden email]
>         >
>         > http://www.clubSmalltalk.org
>
>         --
>         To post to this group, send email to
>         [hidden email]
>         To unsubscribe from this group, send email to clubSmalltalk
>         +[hidden email]
>
>         http://www.clubSmalltalk.org
>
>
>
>
>
> --
> Saludos cordiales,
>
> Guillermo Schwarz
> Sun Certified Enterprise Architect
>
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to clubSmalltalk
> +[hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org



--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org



--
Mariano
http://marianopeck.wordpress.com

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Esteban A. Maringolo
In reply to this post by Andres Valloud-5
El día 20 de noviembre de 2012 17:10, Andres Valloud
<[hidden email]> escribió:
> Si hay forwardeo de punteros en el object table, entonces si
> oneWayBecome: se puede implementar mirando el object table.  Si no,
> hay que mirar todos los object bodies.

En el caso de Dolphin, entiendo que es asi.

> Ahora, viste que cuando haces un oneWayBecome: de una clase a otra,
> las instancias del receptor no se transforman en instancias del
> argumento?... o que por lo menos no deberian transformarse?... que
> detalle, no?...

Nunca me puesto a pensar que pasa con el receptor de oneWayBecome,
seguramente se lo lleve el GC.


Saludos!

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Andres Valloud-5
>> Ahora, viste que cuando haces un oneWayBecome: de una clase a otra,
>> las instancias del receptor no se transforman en instancias del
>> argumento?... o que por lo menos no deberian transformarse?... que
>> detalle, no?...
>
> Nunca me puesto a pensar que pasa con el receptor de oneWayBecome,
> seguramente se lo lleve el GC.

En el caso de las clases no porque la clase vieja sigue teniendo instancias...

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: become: y threads

Guillermo Schwarz
En el caso de las clases viejas, es SystemDictionary (Smalltalk) que tiene el nombre asociado al objeto que representa la clase.

De modo que la clase vieja podría dejar de existir (ser GC) si no es porque las instancias viejas tienen punteros a la clase vieja. Cuando esas instancias ya no son referenciadas por nadie más, no se pueden activar y son GC junto con la clase vieja.

Es trivial, ¿no?

En el caso de tener CPU threads accediendo a objetos Smalltalk, lo peor que puedes hacer es proteger todo. En el mejor de los casos generas "contention" (live lock) y en el peor de los casos "dead lock".

Lo mejor es lo que hace Lisp: no bloquea nada nunca, porque nunca comparte nada. Y si comparte algo es porque es inmutable.

Saludos,
Guillermo.


2012/11/21 Andres Valloud <[hidden email]>
>> Ahora, viste que cuando haces un oneWayBecome: de una clase a otra,
>> las instancias del receptor no se transforman en instancias del
>> argumento?... o que por lo menos no deberian transformarse?... que
>> detalle, no?...
>
> Nunca me puesto a pensar que pasa con el receptor de oneWayBecome,
> seguramente se lo lleve el GC.

En el caso de las clases no porque la clase vieja sigue teniendo instancias...

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org



--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org