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