Documento 954719

 Calificación
1
2
Fundamentos de los Sistemas Operativos (GII)
Examen Final
15 de Junio de 2012 - PRIMERA PARTE -
3
Grupo
Nombre
SOLUCIONES
Dispones de hora y media para completar el examen
1 (6 puntos) Contestar de forma precisa (máximo 5 líneas) a las siguientes cuestiones: 1. ¿Por qué es necesario establecer dos modos de ejecución de instrucciones de un procesador?
Ver apartado 1.5.6 del libro de la asignatura 2. Se considera el algoritmo de planificación del tipo Round Robin de quantum q. ¿Puede afirmarse que
todo proceso de la cola de preparados disfrutará exactamente de q unidades de tiempo de recurso de
CPU? ¿Puede ocurrir que un proceso llegue a utilizar la CPU n unidades de tiempo sin interrupción,
siendo n>q? Justificar la respuesta.
Primera pregunta: no puede afirmarse, ya que no se conoce la duración de los procesos en la cola. Si un proceso finaliza su ejecución antes de cumplirse el quantum q, abandonará la CPU y por tanto no se cumplirá el enunciado. Segunda pregunta: puede ocurrir, por ejemplo si un proceso es el único no bloqueado y reclama más de q segundos de CPU. El sistema lo mantendrá en el procesador indefinidamente, hasta que se bloquee o que entre otro proceso en la cola de preparados. 3. Se tienen 3 procesos: P1, P2 y P3 con tiempos de ejecución: 85, 45 y 118 mseg respectivamente. Si
actúa el PLP según el algoritmo SJF, ¿qué contiene la cola de preparados antes de que empiece a trabajar
el PCP?
P2, P1, P3, en ese orden. 4. Sean dos procesos, P1 con tiempo de ejecución 20 mseg y P2 con 15 mseg. El PCP actúa según un
RR(10mseg) y tiempo de cambio de contexto de 5ms. ¿Cuál es el tiempo de retorno de P1?
NOTA: durante el examen se aclaró que se asuma que P1 y P2 acaban de llegar a la cola de preparados, y que se consideren los dos casos posibles de ordenación (P1 antes que P2 y P2 antes que P1). Primer caso (P1, luego P2): 10(p1)+5+10(p2)+5+10(p1) = 40 mseg Segundo caso (P2, luego P1): 10(p2)+5+10(p1)+5+5(p2)+5+10(p1) = 50 mseg 5. Estamos desarrollando un intérprete de órdenes o Shell. Necesitamos escribir el código que lanza el
programa que el usuario le encarga ejecutar al Shell. Para ello necesitamos elegir entre lanzar un nuevo
hilo o bien lanzar un nuevo proceso pesado. ¿Cuál de las dos opciones le parece más adecuada, y por
qué?
Un Shell va a lanzar una aplicación diferente al propio Shell, cuyo código habrá que cargar en memoria desde el fichero ejecutable. Esto no se puede realizar con un hilo, que comparte el código del proceso padre. Debe realizarse necesariamente con un proceso pesado, para que el Shell y la aplicación puedan coexistir en el sistema. 6. Sea un archivo que contiene registros de 250 bytes cada uno. Dicho archivo está almacenado en un
sistema de ficheros con bloques de tamaño 1K y que usa FAT para asignación de espacio. Sabiendo
que el primer bloque ocupado por el archivo es el número 3 y considerando la siguiente tabla FAT,
FSO-­‐ examen 20120615 -­‐ primera parte -­‐ p1/5 ¿qué bloque(s) hay que leer para acceder registro 4? (los registros se numeran comenzando por 0)
¿Cuántos registros contiene actualmente el fichero?
0
EOF
1
2
3
6
4
0
5
6
4
...
Primera pregunta: son los bloques 3 y 6. El registro 4 está ocupando el rango de direcciones desde la 1000 hasta la 1249 (inclusive), desde el principio del archivo. Estas se encuentran en el primer bloque asignado al archivo (que contiene de la 0 a la 1023) y el segundo (que contiene de la 1024 a la 2047). Por tanto hemos de buscar dónde se encuentran en la FAT esos dos primeros bloques. El primero ya nos lo da el enunciado: es el bloque 3. El segundo es el siguiente apuntado por la FAT, que es el bloque 6. Segunda pregunta: tal y como muestra la FAT, el archivo está formado por los bloques 3, 6, 4 y 0. Por tanto tiene 4Kb asignados, que dan una capacidad para 4096/250 = 16 registros. En realidad la ocupación real podría ser menor de 16, ya que el enunciado no nos da información sobre el uso efectivo que el archivo está haciendo de su espacio ocupado. 7. En un equipo se ha observado la carga del planificador de procesos y resulta que en los últimos diez
minutos se han estado ejecutando cien procesos. Todos ellos siguen sin finalizar en el momento actual.
Por su parte, el tamaño medio de la cola de preparados ha sido de 0,17 procesos durante ese intervalo.
Habiendo tantos procesos activos, ¿cómo puede explicarse un tamaño tan pequeño para la cola de
preparados?
Este tamaño tan escaso implica, lógicamente, que la mayoría de los procesos han estado fuera de la cola de preparados. Pueden haber estado en dos lugares: o bien en algún procesador; o bien en una cola de espera por algún dispositivo o evento. Si es el primer caso, se trataría de una máquina multiprocesadora con una buena cantidad de procesadores. Si es el segundo caso, los procesos están continuamente reclamando operaciones de E/S que les hacen estar bloqueados con mucha frecuencia: es decir, hay muchos procesos intensivos en E/S. 8. Un lote de 5 procesos A, B, C, D y E se lleva a ejecución en un sistema informático. Los tiempos de
llegada son, respectivamente, 0, 1, 3, 9 y 12. Las duraciones estimadas son, respectivamente, 3, 5, 2, 5 y
5. Si el PCP emplea la política SRTF, ¿cuál es el tiempo de espera medio y el tiempo de retorno medio?
Para calcular las medias, hace falta obtener los tiempos de cada proceso. La planificación habrá sido: AAACCBBBBBDDDDDEEEEE Tiempos de espera: A=0, B=4, C=0, D=1, E=3. MEDIA=(0+4+0+1+3)/5 = 8/5 Tiempos de retorno: A=3, B=9, C=2, D=6, E=8. MEDIA=(3+9+2+6+8)/5 = 28/5 2 (1,5 puntos) Un sistema de archivos utiliza asignación indexada como método de asignación de espacio. La estructura de inodo consta, entre otras cosas, de 16 referencias a bloques directos, 4 referencias a un bloque indirecto sencillo, 2 referencias a un bloque indirecto doble y 1 referencia a un bloque indirecto triple. Sabiendo el tamaño de bloque es de 2K y que en el sistema de ficheros hay 2^64 bloques, calcula el número máximo de bloques de datos que puede ocupar un archivo.
Si hay 264 bloques, para poder direccionarlos necesitamos al menos 64 bits, es decir, 64/8 = 8 bytes. Cada entrada de un bloque de índices ocupa por tanto 8 bytes. Como los bloques de datos son de 2K, en cada bloque caben 2048/8 = 256 apuntadores a bloques. Con estos datos podemos hacer el cálculo general: * 16 referencias directas, más * 4 bloques indirectos x 256 apuntadores/bloque = 210 * 2 bloques doble indirecto x 256 x 256 = 217 * 1 bloque triple indirecto x 256 x 256 x 256 = 224 El total es 224+217+210+16 = 16.909.328 bloques de datos. FSO-­‐ examen 20120615 -­‐ primera parte -­‐ p2/5 Nombre 3 (2,5 puntos)
a) (0,75 puntos) Usando semáforos, sincronice los siguientes procesos de manera que la secuencia de ejecución de las funciones siga el orden especificado a continuación: B1() --> C1() --> C2() --> A1() --> B2() --> A2()
Utilice el menor número de semáforos posible. No olvide especificar claramente la inicialización de los semáforos. Proceso A
Proceso B
Proceso C
A1();
A2();
B1();
B2();
C1();
C2();
La forma más inmediata de resolver el problema es utilizar, por cada punto de espera, una operación WAIT sobre un semáforo inicializado a cero. Y al finalizar la instrucción que desbloquea, invocar a una operación SIGNAL sobre ese semáforo. He aquí el resultado de aplicar esa técnica: Semáforos SA1=0, SA2=0, SB2=0, SC1=0 Proceso A WAIT(SA1); A1(); SIGNAL(SB2); WAIT(SA2); A2(); Proceso B B1(); SIGNAL(SC1); WAIT(SB2); B2(); SIGNAL(SA2); Proceso C WAIT(SC1); C1(); C2(); SIGNAL(SA1); Si se quiere reducir al mínimo la cantidad de semáforos, sin añadir más artefactos al programa (ej. variables de estado), se puede reutilizar el semáforo SC1 para el último acto de sincronización. Semáforos s1=0, s2=0, s3=0 Proceso A WAIT(s2); A1(); SIGNAL(s3); WAIT(s1); A2(); Proceso B B1(); SIGNAL(s1); WAIT(s3); B2(); SIGNAL(s1); Proceso C WAIT(s1); C1(); C2(); SIGNAL(s2); El algoritmo se podría escribir con un solo semáforo, pero requeriría añadir una variable de estado, para conocer cuál es el proceso que tiene permiso para continuar. Además, sería una solución de espera activa. 3 b) (1,75 puntos) Se dispone de una sala de juegos y jugadores. Para entrar a la sala se necesitan exactamente 5 jugadores. A medida que los jugadores llegan esperan hasta completar 5 y luego entran a jugar a la sala. Suponga que la sala tiene una capacidad ilimitada, es decir, pueden ir entrando en tandas de 5 sin ninguna limitación. Sólo es necesario especificar el protocolo de entrada a la sala y las pertinentes declaraciones e inicializaciones de variables. Proceso Jugador(){
//Inicialización
//Protocolo de entrada a la sala
//Jugar en la sala
…
}
NOTA: el algoritmo está implementado mediante semáforos. Se utiliza una variable de estado que registra cuántos jugadores están esperando. Cuando un jugador llega y observa que no hay todavía cinco, se bloquea en un semáforo que hace de cola de espera. Cuando llega un quinto jugador, desbloquea a todos los procesos que estaban esperando y reinicia el contador. Como la variable de estado es compartida, debe ser accedida mediante un cerrojo (un semáforo inicializado a uno). Variables globales Semáforo mutex = 1 Semáforo cola = 0 int esperando = 0; Código de entrada en la sala WAIT(mutex); esperando++; if (esperando < 5 ) { SIGNAL(mutex); // liberamos el cerrojo para evitar interbloqueos WAIT(cola); // nos mantenemos bloqueados hasta ser cinco } else { // esperando = 5, desbloqueamos a todos esperando=0; for i in 1..4 { SIGNAL(cola); } // hay cuatro compañeros bloqueados en cola SIGNAL(mutex); } FSO-­‐ examen 20120615 -­‐ primera parte -­‐ p4/5 Nombre Otro algoritmo En este otro algoritmo, el quinto jugador sólo desbloquea a uno de los compañeros en cola, el desbloqueado a su vez libera a otro compañero y así hasta completar los cinco. Los semáforos y variables de estado son los mismos que en el primer algoritmo. // entrar a jugar WAIT(mutex); if (esperando < 4 ) { esperando++; SIGNAL(mutex); // liberamos el cerrojo para evitar interbloqueos WAIT(cola); // nos mantenemos bloqueados hasta ser cinco esperando-­‐-­‐; // uno menos para desbloquear if ( esperando > 0 ) { // si quedan compañeros bloqueados, desbloqueo a uno SIGNAL(cola); } else { // si soy el último, libero el cerrojo SIGNAL(mutex); } } else { // esperando = 4, iniciamos la secuencia de desbloqueo SIGNAL(cola); } 5