UTNianos

Versión completa: [SO] ULT y Entrada/Salida
Actualmente estas viendo una versión simplificada de nuestro contenido. Ver la versión completa con el formato correcto.
Hola como va?

Tengo una duda, cuando estoy planificando hilos de usuario (ULT) con la biblioteca de hilos. Y un ULT se va a entrada/salida, se bloquea todo el proceso. Cuando vuelve de la entrada/salia, sigue ejecutando ese ULT? O se ordena segun el algoritmo de planificacion de la biblioteca.

Doy un ejemplo rapido para que se entienda:

Algoritmo de la biblioteca de hilos: SJF (sin desalojo)
Proceso 1 con dos hilos: ULTA y ULTB
ULTA se va a entrada/salida y cuando vuelve ULTA tiene que consumir una rafaga de 3 instantes de cpu, mientras que ULTB, 2 instantes de cpu. Cual es el ULT que sigue a ejecutar en ese caso? Si le doy bola al algoritmo seria ULTB por que tiene menos rafaga, pero si despues de una E/S sigue ejecutando el mismo, seria ULTA

Alguno me puede ayudar?
Gracias!
Esto depende de si usás las llamadas al sistema "comunes" del Kernel, o si la biblioteca de usuario las wrappea.

En el primer caso, tu proceso hace la llamada al sistema común y corriente, por lo que no ejecuta código de la biblioteca de hilos - es decir, la biblioteca no se entera de que hiciste una llamada al sistema. Entonces, cuando tu proceso vuelve a ejecutar, sigue ejecutando la instrucción siguiente a la de la syscall - como cualquier proceso normal haría -, por lo que sigue ejecutando el hilo que había pedido la syscall.

El otro caso es cuando, ponele, en lugar de hacer "read()", hacés "mibiblioteca_read()". En ese caso, tu proceso ejecuta una función de la biblioteca que registra que hiciste una syscall antes de efectivamente ejecutar la syscall "original" ("read", en este caso), por lo que puede elegir replanificar tus hilos de usuario. En este caso, antes de ejecutar la syscall, la biblioteca replanificará y modificará el estado del proceso como sea necesario para que, al volver de la ejecución, pase a ejecutar el hilo que eligió durante la replanificación en lugar de que ejecute el hilo que acaba de pedir la syscall.


En los ejercicios, probablemente te indiquen cuál sea el caso (o preguntes y te lo aclaren). Se me ocurre que el default es la primer opción, pero por las dudas preguntá.
Yo tengo entendido que depende unicamente de como esté organizada la biblioteca de hilos.
Suponete que tenes 2 ULT en 1 KLT. Te dicen que los hilos de kernel son planificados por RR Q = 3 y que los ULT son planificados por FIFO. Ahi sigue el que mando a E/S. Ahora bien, si fuera que tenes que la biblioteca de hilos (o sea de usuario) son planificado por RR Q = 2, y viene el ULT en q = 2 y manda a un E/S, cuando vuelva, va a seguir el otro ULT porque ya consumió todo el quantum

Espero que se entienda
(14-11-2016 17:44)Desert69 escribió: [ -> ]Esto depende de si usás las llamadas al sistema "comunes" del Kernel, o si la biblioteca de usuario las wrappea.

En el primer caso, tu proceso hace la llamada al sistema común y corriente, por lo que no ejecuta código de la biblioteca de hilos - es decir, la biblioteca no se entera de que hiciste una llamada al sistema. Entonces, cuando tu proceso vuelve a ejecutar, sigue ejecutando la instrucción siguiente a la de la syscall - como cualquier proceso normal haría -, por lo que sigue ejecutando el hilo que había pedido la syscall.

El otro caso es cuando, ponele, en lugar de hacer "read()", hacés "mibiblioteca_read()". En ese caso, tu proceso ejecuta una función de la biblioteca que registra que hiciste una syscall antes de efectivamente ejecutar la syscall "original" ("read", en este caso), por lo que puede elegir replanificar tus hilos de usuario. En este caso, antes de ejecutar la syscall, la biblioteca replanificará y modificará el estado del proceso como sea necesario para que, al volver de la ejecución, pase a ejecutar el hilo que eligió durante la replanificación en lugar de que ejecute el hilo que acaba de pedir la syscall.


En los ejercicios, probablemente te indiquen cuál sea el caso (o preguntes y te lo aclaren). Se me ocurre que el default es la primer opción, pero por las dudas preguntá.

Desert69 te agradezco por la ayuda! Creo que es como vos decis, la default es la opcion 1.

Te consulto una duda mas que se me vino. Tengo planificacion de procesos con RR - Q= 3 y planificacion de la biblioteca de hilos con RR Q=2:
En el tiempo de inicio 0 corre el proceso 1 que tiene dos hilos (ULTA y ULTB), y ambos tienen que ejecutar 3 rafagas de CPU. Empieza el primero y hace 2 rafagas (por el RR con q=2 de la biblioteca) y cambia a ejecutar el ULTB, y hace 1 rafaga (por el RR, q=3 de la planificacion de procesos, le quedaba 1 rafaga al proceso 1). Luego de esto le da lugar a otro proceso a ejecutarse. Cuando vuelve a ejecutar el proceso 1, tiene que terminar el quantum que le quedo pendiente para completar el Q=2 la ULTB(solo habia corrido 1 rafaga de cpu)? O cambia al ULTA y se resetea el quatum.
Digo por que la biblioteca sigue corriendo por atras sin que el SO se entere de nada, por lo que me parece que tiene que completar el Quantum de 2, pero no estoy seguro que sea asi.

Gracias!!

Basicamente el ejercicio que me trae muchas dudas es este.

http://www.utnianos.com.ar/foro/tema-apo...operativos

El de planificacion
Cada loco con su tema.

La biblioteca de hilos del Proceso 1 controla a los hilos de ese proceso - es decir, a los hilos A y B. Esos se planifican con RR2, entonces la biblioteca va a repartir el tiempo de CPU que le asignen de a ráfagas de 2 entre estos dos hilos.

Pero el tiempo que le asignen depende del planificador del SO (el RR3). Esto significa que los "slots" de tiempo de CPU que pueda repartir la biblioteca de hilos no siempre van a ser contiguos - depende de cómo le planifiquen el proceso.

"En el vacío", la biblioteca de hilos intentará planificar AABBAABBAABBAABB y así siguiendo (siempre que estos se mantengan en Ready todo el tiempo que no están en Exec, obvio). Ahora, si hubiera un segundo proceso en el sistema, el tiempo de CPU no va a ser todo del Proceso 1: se lo van a repartir (según RR3) entre los procesos 1 y 2. Si volvemos a suponer que los 3 hilos de ejecución (hilos A y B del P1, y el P2) están todo el tiempo haciendo CPU (cosa de que no se bloqueen ni nada), en principio el planificador del sistema haría 111222111222111222111222... Ahora, cuando "entramos" al P1 y vemos que existen dos hilos que se alternan, entonces reemplazamos esos "1"s por el hilo correspondiente, teniendo 2 cada uno: AAB222BAA222BBA222ABB222...

En la vida real la biblioteca de planificación insumiría algo de tiempo, seguramente (una porcioncita del tiempo asignado al proceso 1 se usaría para planificar), pero en los ejercicios re despreciamos ese tiempo.

¿Se entiende cómo funciona? La clave es que el planificador del SO no sabe que existen los hilos de usuario - porque, para el SO, la biblioteca de usuario es simplemente código de usuario (igual que el código de tu TP, o lo que sea). Y la biblioteca de usuario, por ser código de usuario, no se entera nunca de cómo lo planifica el SO. Entonces, cada uno hace lo suyo, sin enterarse de que el otro existe. El resultado es lo que queda al aplicar ambos conjuntos de reglas con la precedencia correspondiente - es decir, el planificador de la biblioteca planifica como quiere el tiempo que el planificador del SO le asigna.
URLs de referencia