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 [email protected] http://www.clubSmalltalk.org
