A ver si alguien me quita duda de este V y F.


En un proceso con dos o más ULT, si el que está en ejecución solicita una I/O bloqueante, cuando vuelva a ejecutar el proceso, podría seguir ejecutando el mismo hilo, independientemente del algoritmo de planificación de dicha biblioteca.


Tengo 2 versión al respecto:

1) Según el Stallings: Si un ULT hace una E/S bloqueante el proceso se bloquea pero la Biblioteca de Hilos no se da cuenta de esto y por lo tanto el ULT sigue ejecutando para la biblioteca. Cuando el proceso vuelva de bloqueado, continuara ejecutando el ULT que hizo la E/S bloqueante ya que para la biblioteca sigue en estado ejecutando.

2) En la cursada, cuando hacemos los ejercicios de planificación de procesos, cuando un ULT realizaba una E/S bloqueante, el proceso se bloqueaba, pero cuando el SO le devolvía la CPU al proceso, planificábamos que ULT se iba a seguir ejecutando.

La cuestión es que no se, si esta mal como hacíamos los ejercicios, o esta mal el Stallings, o tengo un error de interpretación yo.

Dejo de ejemplo un ejercicio que hicimos en clases y la ayudante subió la resolución del mismo a campus virtual.

Pd: En el instante 38 ejecuta el ULT3 y segun el Stallings deberia seguir ejecutando el ULT2

Ayer en la clase de consulta hice varias preguntas respecto a este tema porque la verdad que es muy confuso.

Lo que yo se, o al menos lo que yo creo que se es:

1) Lo que sea que haga la Biblioteca de Hilos, es totalmente invisible para el SO. Es decir, al SO no le importa y no tiene ni idea de cómo la Biblioteca de hilos está manejando la planificación de los ULTs.
2) Cuando un ULT solicita una I/O bloqueante, se bloquea TODO el KLT que lo contenga (obviamente esto incluye a todos los ULTs de ese KLT). Saaaaalvo que el ejercicio ACLARE EXPLÍCITAMENTE que las I/O que ejecutan los ULTs son NO BLOQUEANTES, si no me equivoco, esto es JACKETING, e indica que mientras un ULT esta corriendo una I/O, otro ULT del mismo KLT puede estar utilizando la CPU.
3) Lo que dice el libro de Stallings es correcto, según me dijo un ayudante, cuando un ULT solicita una I/O, la biblioteca de hilos ni se da cuenta de lo que pasó y hay una especie de puntero que queda apuntando a ese ULT. Por lo tanto, cuando el KLT que lo contiene vuelve a tener el procesador, sigue ejecutando desde dicho puntero, es decir, siempre se va a ejecutar el mismo ULT, hasta que termine.

Entonces, si el algoritmo de planificación de la biblioteca de hilos es FIFO por ejemplo, sabemos que siempre que el KLT obtenga el procesador, se va a ejecutar el mismo ULT hasta que este termine (por más solicitudes de I/O que haya hecho).
Ahora, ¿qué pasa si el algoritmo de planificación de la biblioteca de hilos es RR con quantum (como en la mayoria de los ejercicios)? Bueno, yo acá haría lo mismo que si el algoritmo fuese FIFO y aclararía por qué lo hago (por ejemplo justificando con lo que dice el libro de Stallings). Es decir, yo ejecutaría siempre el mismo ULT hasta que termine (por más solicitudes de I/O que haya hecho), salvo que en el ejercicio me aclaren explícitamente que luego de que un ULT hace una I/O, la biblioteca de hilos detecta dicha situación y permite el cambio de ULT (hay un ejercicio de final en el que esto pasa tal cual, fijate, es el ejercicio 2 del final del 17/12/13).

Sería ideal que un ayudante o profesor aparezca por acá para refutar o adherir a todo lo que dije, tené en cuenta que yo soy uno más que está preparando este final jaja.

Coincido. Para mi el ejercicio esta mal hecho, al menos que haya una aclaración de ese tipo.

Off-topic:

Tienen alguna idea sobre lo ultimo que pregunte en este post: http://www.utnianos.com.ar/foro/tema-sis...es-memoria ?
Gracias!

Gracias por la respuesta!

1) Coincido
2) Coincido
3) Esta era la duda, pero ahora con la justificación que me diste, verdaderamente es lo que dice el Stallings salvo que aclaren.

Ahora, una cosa, si tengo un KLT y adentro del mismo 3 ULTS. El KLT se planifica con RR y el ULT, mediante la biblioteca de hilos, tambien con RR, cuando el Q termina del ULT, ahí si se pasa a otro ULT.

Diferente sería que se acabe el Q del KLT, ahí si se bloquearía todo el proceso y cuando vuelva seguira ejecutando el mismo ULT (ya que para la biblioteca el ULT sigue ejecutando).

Ahora bien, cuando se acaba el Q del KLT y el ULT tenia todavia tiempo de su Q, cuando vuelve a ejecutar el proceso, ejecuta la parte de Q que le quedaba? o que? Porque supuestamente para la biblioteca, el ULT seguia "ejecutando"

Es como vos decís, por ejemplo:

Supongamos que los KLTs se planifican con RR de q=3 y la biblioteca de hilos planifica con RR de q=2. Entonces, si un KLT tiene 3 ULTs por ejemplo, arrancaría un ULT (cuál arranca lo decidís en base a un tiempo de llegada que sea dato por ejemplo), ejecutaría dos unidades tiempo de CPU, y ahí cambiarías a otro ULT de ese mismo KLT (también lo elegirías en base a un tiempo de llegada por ejemplo). Y tal como decís, el famoso "puntero" siempre está apuntando al ULT que está en ejecución, por lo cual al volver, ejecutarías el mismo ULT que fue desalojado por el quantum 3 de los KLTs

Respecto a lo de que el ULT ejecute la parte que le quedaba de quantum, OJO, eso es con Virtual Round Robin. Si estás planificando con Round Robin a secas, cada vez que se termina el quantum, se resetea, osea, volvés a ejecutar el quantum completo cuando volves, no "lo que te quedaba".

No se si me expliqué muy bien jaja.

Claro, pero yo digo si pasa al revés si el KLT es Q=2, y el ULT es Q=3

Cuando Q=2, el proceso se bloquea con el ULT en Q=1.

Cuando el proceso vuelve a ejecutar, vuelve con Q=2 del KLT, pero el ULT con que vuelve con Q=1? o el ULT vuelve con Q=3? o vuelve en Q=0 porque para la biblioteca siguió ejecutado?

Aaaaaah, ok, ya te entendí. Mmm la verdad que ni idea, para empezar habría que ver si es posible que la biblioteca de hilos planifique con un quantum superior al que el SO le provee a los KLTs. De hecho, creo que alguna vez leí un verdadero/falso que planteaba eso justamente.

Mi opinión personal es que no tendría sentido algo así, de ahí a que se pueda hacer o no, ni idea.

Basándonos en lo que dijimos antes (que para el SO es invisible lo que hace la biblioteca de hilos, y que a su vez la biblioteca de hilos no tiene ni idea de lo que está pasando con el SO), parecieeeeera que sería como vos decís. Es decir, que cuando q=2, el KLT se bloquea (antes que el ULT use el q=3 completo que la biblioteca de hilos le da). Entonces, cuando el KLT bloqueado vuelve a ejecutar, vuelve con q=2, pero la biblioteca de hilos ejecutaría al ULT desalojado anteriormente para llegar a su q=3 y cambiaría de ULT (dentro del mismo KLT).

Pero es todo muy tirado de los pelos, acá no puedo ayudarte mucho :/

Entonces el V/F es Falso ya que no es "podría seguir" sino es "siempre seguirá" ejecutando el mismo hilo.

Cierto?

Para los ejercicios cambia algo que sean ULT o KLT? Me refiero, por ejemplo, al ejercicio 11 de la guía, que los ULT del proceso 1 están a la misma altura que los UKL del proceso 2 y el UKL del proceso 3.

La respuesta es V.
La justificación: Si para realizar la entrada salida no estamos usando funciones de la biblioteca que envuelvan o "wrappeen" las llamadas al sistema y estamos haciendo un open() por ejemplo, la biblioteca de hilos no se enteraría de la misma, y cuando vuelva a ejecutar mi proceso, continuaría desde el mismo hilo, ya que la biblioteca no tiene la posibilidad de replanificar.