Guido, Los threads son implementados a nivel del sistema operativo, pero tambièn tienen soporte en la CPU, de otra manera no tendrìan ninguna ventaja en cuanto a tiempo de ejecución. De hecho creo que el tema está resuelto desde el procesador x86 con los manejadores de interrupciones, lo que no estaba resuelto era el manejo de memoria, ya que toda la memoria era real y no era factible determinar cuando un proceso accede a la memoria de otro.
A nivel de hardware incluso para el acceso a memoria hay modo kernel y modo usuario, lo que signfica que la memoria se accede en modo real (las direcciones son reales) o modo protegido (las direcciones son ficticias y deben ser traducidas). Cuando está en modo protegido cada acceso a memoria debe traducir el espacio de memoria a modo real, de modo que cuando tienes varios procesos, todos pueden hacer referencia a la misma direcciòn protegida de memoria sin producir un segmentation fault ya que la direcciòn real es otra. Además si estás en modo protegido, puede que la memoria estè en una pàgina en disco y es el hardware que se da cuenta y llama a la señal para recuperar la pàgina. Esa llamada lllega al sistema operativo mediante un pedazo de còdigo que està en un àrea de memoria que no puede ser "paged out". ¿Es obvio porquè, no? Si estuviera en disco no habrìa còdigo para traerlo de vuelta. Imagino que ese es el problema al que te referìas anteriomente. Se supone que eso està resuelto a nivel de hardware y sòlo es necesario indicar cuàl es el còdigo que hace el page in e indicar que no debe ser paged out. En el antiguo procesador 8086 habìa un par de instrucciones parecidas que se llamaban STI y CLI. Si no me equivoco STI era para decir "no me interrumpan porque estoy en un segmento de còdigo delicado" y CLI era lo contrario. ¿Porquè digo que es parecido? Porque si estoy resolviendo un page in, no puedo generar otro page in (o quizàs sì si tuviera un stack de page in por resolver). En el caso del STI y CLI es lo mismo, si estoy manejando una interrupciòn no quiero que me interrumpan, pero podrìamos usar u stack tambièn, aunque por otro lado puede que sea una mala idea si tengo un tiempo limitado para atenderla. El problema en Smalltalk, imagino, es que gracias al polimorfismo tomas un dato que es un entero y de pronto ese paràmetro puede recibir cualquier clase que acepte el mismo protocolo, lo que significarìa que podrìa ejecutar còdigo arbitrario que si estoy resolviendo un page in, no quiero que me cause otro page in, ¿no?. Algo menciona Alan Kay cuando crearon Squeak en Smalltalk respecto de que implementaron un pequeño traductor de Smalltalk a C (de un sobconjunto de Smalltalk) y que era factible implementar el intèrprete de Smalltalk en ese subconjunto. Imagino que ese subconjunto de Smalltalk es justamente el subconjunto que: 1. No tiene polimorfismo. 2. Permite ejecutar el intèrprete de Smalltalk. 3. Es el que necesitas para ejecutar tu proceso de page in en Smalltalk. 4. Al escribirlo en Smalltalk, lo puedes convertir a C... Creo que justamente el chiste del hypervisor es que es como VMWare, permite ejecutar un OS encima al simular un hardware, salvo que no requiere un sistema operativo debajo, ya que el hypervisor ejecuta sobre el metal. Puedes usar el hypervisor hecho por Xen por ejemplo (http://www.xen.org/) de modo que podrìas ejecutar varias instancias de SqueakNOS, cada una creyendo que està funcionando sobre el metal. Ahora bien, lo que propone Andy Tannenbaum, el creador de Minix, es que en el futuro todos los sistemas operativos seràn hypervisors y cada driver correrà como si estuviera en su propio sistema operativo. Lo dificil ahì no es que ejecute, ni que si se cae el driver no se caiga el sistema operativo. Todo eso ya estarìa resuelto. Lo dificl serìa còmo comunicar los distintos procesos y creo que la respuesta obvia es a travès de sockets. Hacer una VM con threading no me parece una buena idea porque estàs cambiando un modelo simple que funciona. Saludos, Guillermo. 2011/6/24 Guido Chari <[email protected]> > Hola Guillermo, > > La diferencia con un sistema operativo moderno sera simplemente que estos > tienen soporte multi-thread nativo. Entonces ante un fallo de pagina, > mientras la pagina de memoria es transferida desde el disco, este podria > llegar a cambiar de thread. Sinceramente no conosco la implementacion, si > alguno conoce como se resuelve este detalle en un sistema operativo moderno > bienvenido su aporte. Tampoco estoy seguro que eso sea bueno en todos los > casos, habria que switchear a un thread que no genere otro fallo de > pagina...(?).No lo se... > > Pero si estoy seguro que el St queda esperando la pagina de disco es una > limitacion de la vm con la que trabajamos que en caso es la de Squeak/Pharo, > que de ser superada podria cambiarse tambien si es que cambiar de thread > mejorase el throughput. Tener un hypervisor o una vm que controle a la/las > otras creo que siempre fue una idea que estuvo dando vueltas en SqNOS. Pero > para los temas que estamos hablando en este thread, creo que en algun punto > podria verse como una forma de implementar el multithreading y seguro seria > mas "caro" que otras implementaciones. > > Saludos, > Guido. > > El 24 de junio de 2011 19:11, Guillermo Schwarz < > [email protected]> escribió: > > Hola GUido, >> >> Primero que nada felicitaciones. NO he visto còmo lo hicieron pero debe >> ser fascinante. >> >> Lo que dices, si te entiendo bien, es que es atendida desde Smalltalk, lo >> que significa que Smalltalk carga la página, ahora bien, esa página está en >> disco, de modo que hay una petición al hardware para que lea del disco y >> deje esa información en determinada posición en RAM, lo que implica un buen >> tiempo sin ejecutar Smaltalk. >> >> Claro desde el punto de vista de mirar el código uno ve: primero ejecuta >> esto, la memoria accedida no está en RAM sino en disco, se produce una >> interrupciòn y ejecuta código Smalltalk para rescatar la página del disco, >> de modo que está todo el tiempo ejecutando SMaltlalk, pero si se pudiera >> graficar cuànto tiempo ejecuta Smalltalk durante el proceso, la mayor parte >> del tiempo està leyendo del disco, es decir, la CPU està desocupada (ok en >> un OS moderno probablemente hay 20 procesos haciendo cosas inùtiles), pero >> en SqueakNOS no habría nada ejecutando nada, a menos que SqueakNOS tenga un >> modelo de varias imágenes ejecutando simultáneamente, algo parecido a lo que >> sería un hypervisor, que por cierto creo que sería una buena idea para >> ejecutar SqueakNOS. >> >> Saludos, >> Guillermo. >> >> >> 2011/6/24 Guido Chari <[email protected]> >> >>> Hola Guillermo, >>> >>> La sincronicidad tiene que ver con la atencion de interrupciones. >>> SqueakNOS previo a nuestro trabajo atendia todas las interrupciones de >>> hardware de manera asincronica. A bajo nivel se signalea un semaforo de alto >>> nivel y se retomo el curso de ejecucion anterior, el cual ingresa a la vm y >>> en ese momento la interrupcion es atendida desde Smalltalk, Esto no era >>> posible para resolver fallos de pagina, ya que de no resolverse la >>> interrupcion de hardware "en el momento" el procesador no puede seguir su >>> curso de ejecucion. Sin embargo esto no quiere decir que la imagen queda >>> suspendida ya que el fallo de pagina se resuelve desde Smalltalk. >>> >>> Saludos, >>> Guido. >>> >>> El 24 de junio de 2011 17:18, Guillermo Schwarz < >>> [email protected]> escribió: >>> >>> Hernán, >>>> >>>> Què interesante. La ùnica duda que me surgió es si al hacerlo sìncrono >>>> significa que la imagen Smalltalk queda suspendida hasta que se resuelve o >>>> bien que otros threads de la misma imagen pueden seguir ejecutando mientras >>>> tanto. Todo esto lo pregunto porque resolver un acceso a disco con la >>>> tecnología actual (sin SSD) es del orden de entre 10 y 100 veces más caro >>>> que un acceso a RAM. >>>> >>>> Saludos, >>>> Guillermo. >>>> >>>> >>>> 2011/6/24 Hernan Wilkinson <[email protected]> >>>> >>>>> por si les interesa... >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Hernan Wilkinson <[email protected]> >>>>> Date: 2011/6/24 >>>>> Subject: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS >>>>> To: docentes <[email protected]>, alumnos <[email protected]> >>>>> >>>>> >>>>> Defensa de Tesis de Licenciatura >>>>> Aula 2, Pab I, 1ro de Julio de 2011, de 17hrs. a 18hrs. >>>>> >>>>> Título: Persistencia en SqueakNOS >>>>> Alumnos: Guido Chari y Javier Pimás >>>>> Directores: Hernán Wilkinson y Gerardo Richiarte >>>>> Jurado: Máximo Prieto y Gabriela Arevalo. >>>>> >>>>> Resumen: >>>>> SqueakNOS es una reificación de los conceptos de "Computadora" y de >>>>> "Sistema Operativo" dentro del dialecto Squeak del lenguaje de >>>>> programación >>>>> Smalltalk. >>>>> La filosofía de SqueakNOS establece que el desarrollo del mismo debe >>>>> hacerse completamente en Smalltalk, utilizando código de bajo nivel >>>>> únicamente en los casos en que no sea posible utilizar Smalltalk o que el >>>>> deterioro de rendimiento sea extremadamente ostensible. >>>>> El proyecto es un trabajo aún en desarrollo, y como tal, varias >>>>> funcionalidades comunes a los Sistemas Operativos no han sido >>>>> implementadas >>>>> aún debido a su complejidad. Es por ello que esta investigación se centra >>>>> en >>>>> analizar varios interrogantes relacionados con la persistencia de los >>>>> objetos, interrogantes que se presentan al momento de querer grabar el >>>>> grafo >>>>> de objetos que representa el modelo desarrollado. >>>>> Para poder responder estos interrogantes, se desarrolló un controlador >>>>> de discos ATA y un modelo de filesystem FAT32 completamente en Smalltalk, >>>>> lo >>>>> que brinda compatibilidad con otros sistemas operativos y con el entorno >>>>> Squeak genérico. Así por ejemplo, se logra acceder al código fuente de los >>>>> métodos y se avanza hacia el grabado de la imagen, característica que aún >>>>> no >>>>> estaba disponible en el sistema. >>>>> Luego, se desarrolló una técnica de persistencia cuyo objetivo >>>>> principal era la simplicidad y su principal desventaja el requerir una >>>>> utilización importante y de manera ineficaz de memoria. A pesar de sus >>>>> desventajas, fue el primer paso para lograr la atomicidad necesaria para >>>>> grabar los objetos mientras estos estaban siendo modificados. >>>>> Finalmente, se implementó un esquema de manejo de memoria basado en >>>>> paginación, modificando el mecanismo de manejo de interrupciones original >>>>> de >>>>> SqueakNos para que pudiera funcionar en forma sincrónica, requisito >>>>> indispensable para resolver los fallos de página. Esta solución >>>>> permitió resolver los fallos de página completamente desde Smalltalk, lo >>>>> cual dio lugar a la experimentación y al desarrollo de formas novedosas de >>>>> utilización del mismo. Gracias a esto, resultó posible por ejemplo, >>>>> implementar una técnica alternativa de persistencia de la imagen, que >>>>> utiliza mucha menos memoria que la original debido a la asistencia del >>>>> mecanismo de paginación y la utilización de la técnica de copy on write. >>>>> Por último, se analizan aspectos relacionados con la manera de trabajar >>>>> en este tipo de entornos y plataformas, sus ventajas, sus dificultades y >>>>> complicaciones. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> * >>>>> Hernán Wilkinson >>>>> Agile Software Development, Teaching & Coaching >>>>> Mobile: +54 - 911 - 4470 - 7207 >>>>> email: [email protected] >>>>> site: http://www.10Pines.com <http://www.10pines.com/> >>>>> * >>>>> >>>>> -- >>>>> To post to this group, send email to [email protected] >>>>> To unsubscribe from this group, send email to >>>>> [email protected] >>>>> >>>>> http://www.clubSmalltalk.org >>>> >>>> >>>> >>>> >>>> -- >>>> Saludos cordiales, >>>> >>>> Guillermo Schwarz >>>> Sun Certified Enterprise Architect >>>> >>>> -- >>>> To post to this group, send email to [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected] >>>> >>>> http://www.clubSmalltalk.org >>>> >>> >>> -- >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> >>> http://www.clubSmalltalk.org >>> >> >> >> >> -- >> Saludos cordiales, >> >> Guillermo Schwarz >> Sun Certified Enterprise Architect >> >> -- >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> >> http://www.clubSmalltalk.org >> > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
