Efectivamente, un usuario puede acaparar tiempo de CPU si el número de procesos a su nombre es superior al del resto de usuarios del sistema, puesto que el RR reparte equitativamente el tiempo de CPU entre procesos, pero no entre usuarios. La afirmación sólo es cierta, salvo que todos los usuarios entren en una "carrera de armamentos", lanzando todos ellos una elevada cantidad de procesos, en cuyo caso nadie resulta beneficiado. Tampoco es válida la afirmación si los procesos de este usuario son muy intensivos en E/S, porque en este caso no cubren por completo las rodajas de tiempo asignadas.
Las modificaciones al RR para evitar acaparamientos por usuarios son innumerables, pero todas pasan por tener en cuenta a los propietarios de los procesos. Algunas técnicas pueden ser:
a) mantener una cola por cada usuario con sus procesos, y repartir la CPU en rodajas de tiempo por usuarios: en cada rodaja de un usuario se ejecuta un fragmento de uno de sus procesos.
b) asignar a los procesos un cuanto de tiempo inversamente proporcional al número de procesos pertenecientes al usuario propietario. Tiene el inconveniente de que se producen muchos cambios de contexto si un usuario mantiene muchos procesos.
c) aplicar prioridades al RR, de forma que los procesos de un usuario con mucha concurrencia tengan baja prioridad. La prioridad puede implementarse reencolando a los procesos en posiciones de la cola más avanzadas cuanto más prioridad tengan los procesos. Riesgo de inanición y el tiempo de respuesta no está acotado.
etc. etc.
Pregunta
2. Dos cuestiones de respuesta corta
2.1.
Comparar el núcleo con una biblioteca de software
Similitudes:
· proporcionan servicios
· tienen una interfaz funcional
· funcionan como "cajas negras": no se puede/debe retocar la implementación
Diferencias:
· los servicios del núcleo funcionan siempre en modo privilegiado
· la biblioteca se puede usar o no; el núcleo siempre está presente en el sistema
Si las operaciones de E/S no son privilegiadas, un proceso de usuario puede:
· utilizar sin restricciones los dispositivos, saltándose los mecanismos del S.O. de asignación de recursos a los usuarios
· efectuar operaciones no válidas sobre dispositivos, que pueden quedar no operativos
· acceder directamente a periféricos de almacenamiento, saltándose las protecciones sobre la información, tanto en lectura como en escritura
Hay multitud de ejemplos que se pueden plantear, como accesos indiscriminados a sectores de disco, enviar operaciones incorrectas a un periférico, entremezclar envíos a la impresora sin respetar la exclusión mutua, etc.
Pregunta
3. Cierto o falso, tres enunciados
3.1.
Un sistema operativo ha de contener forzosamente un sistema de ficheros
FALSO.
Aunque un sistema operativo de propósito general contiene normalmente un sistema de ficheros o similar, no es un componente imprescindible. Un sistema informático puede carecer de almacenamiento masivo, y tener todo su software en ROM, como podría ocurrir en un controlador industrial. Los sistemas operativos primitivos no disponían de sistema de ficheros.
Piénsese que la pregunta se podría formular como "si a un sistema operativo le quitamos el sistema de ficheros, ¿seguiría siendo sistema operativo?"
La ejecución de la sección crítica impedirá progresar sólo a procesos interesados en ejecutar una sección de código que entre en conflicto con la actual, pero no afecta al resto de los procesos.
Incluso se podría ceder la CPU a un proceso que no puede progresar, por ejemplo si el mecanismo que se adopta para el bloqueo es mediante espera activa.
Algunas de las nuevas interrupciones pueden atenderse, por ejemplo si tienen mayor prioridad que la interrupción en curso. También puede ocurrir que se sigan reconociendo TODAS las interrupciones, al menos guardando en una cola las interrupciones que se vayan produciendo, pero que se tengan que atender más adelante.
Pregunta
4. Gestión de memoria
Apartado
4.1
a. Bits de dirección virtual: 4 bits para páginas (se
codificarían 16 páginas aunque sólo se tengan 10) y 10
bits para desplazamiento dentro de la página, en total 14 bits.
b. Bits de dirección física: se tendría un memoria de 32*1024 palabras, por tanto necesitaríamos 15 bits para codificar una dirección física.
Política Mejor ajuste:
Petición: 1200 Kb se le asignaría hueco de tamaño 1200 Kb quedando la lista:
1000 Kb, 400 Kb, 1800 Kb, 700 Kb, 900 Kb, 1500Kb
Petición: 1000 Kb se le asignaría hueco de tamaño 1000 Kb quedando la lista:
400 Kb, 1800 Kb, 700 Kb, 900 Kb, 1500Kb
Petición: 900 Kb se le asignaría hueco de tamaño 900 Kb quedando la lista:
1000 Kb, 400 Kb, 1800 Kb, 700 Kb, 900, 1500Kb
Política peor ajuste:
Petición: 1200 Kb se le asignaría hueco de tamaño 1800 Kb quedando la lista:
1000 Kb, 400 Kb, 600 Kb, 700 Kb, 900 Kb, 1200 Kb, 1500Kb
Petición: 1000 Kb se le asignaría hueco de tamaño 1500 Kb quedando la lista:
1000 Kb, 400 Kb, 600 Kb, 700 Kb, 900 Kb, 1200 Kb, 500Kb
Petición: 900 Kb se le asignaría hueco de tamaño 1200 Kb quedando la lista:
1000 Kb, 400 Kb, 600 Kb, 700 Kb, 900 Kb, 300 Kb, 500Kb
Política siguiente ajuste: (asumimos que el puntero apunta al primer elemento de la lista de huecos libres)
Petición: 1200 Kb se le asignaría hueco de tamaño 1800 Kb quedando la lista:
1000 Kb, 400 Kb, 600 Kb, 700 Kb, 900 Kb, 1200 Kb, 1500Kb comenzando la siguiente búsqueda a partir del hueco de 700 Kb
Petición: 1000 Kb se le asignaría hueco de tamaño 1200 Kb quedando la lista:
1000 Kb, 400 Kb, 600 Kb, 700 Kb, 900 Kb, 200 Kb, 1500Kb comenzando la siguiente búsqueda a partir del hueco de 1500 Kb
Petición: 900 Kb se le asignaría hueco de tamaño 1500 Kb quedando la lista:
1000 Kb, 400 Kb, 600 Kb, 700 Kb, 900 Kb, 200 Kb, 600Kb comenzando la siguiente búsqueda a partir del hueco de 1000 Kb
Política del algoritmo óptimo:
(8,-.-), (8,1,-), (8,1,2), (3,1,2), (3,1,2), (3,1,4), (3,1,4), (3,5,4), (3,5,4), (3,5,4), (1,5,4), (1,5,4)
Política LRU:
(8,-.-), (1,8,-), (2,1,8), (3,2,1), (1,3,2), (4,1,3), (1,4,3), (5,1,4), (3,5,1), (4,3,5), (1,4,3), (4,1,3)
Política NRU:
(8,-.-), (8,1,-), (8,1,2), (3,1,2), (3,1,2), (3,1,4), (3,1,4),
(5,1,4), (5,3,4), (5,3,4), (1,3,4), (1,3,4)
Pregunta
5. Estructura de control de un sistema de ficheros
Cada archivo deberá poseer (como mínimo) los siguientes campos de control pertenecientes a una estructura de datos que podemos llamar entrada de directorio (como en MSDOS) o nodo de información básica (inode en UNIX):
Nombre: 12 bytes
Tipo: 3 bits (1 byte si se toma el byte como unidad mínima) para codificar si se trata de un archivo normal, de directorio o de tipo enlace.
Número de referencias: 1 byte como mínimo.
Tamaño del archivo expresado en bytes: 3 bytes.
Primer bloque de datos: 2 bytes
Como además se deberá soportar una organización jerárquica se tendrá que especificar como se organizan los directorios. Una propuesta válida sería: "archivo especial organizado en registros cuya estructura se corresponde con la descrita anteriormente".
Para la gestión del espacio libre se necesitará un campo de 384 bytes para representar el estado de cada bloque de datos del sistema de archivos.
Pregunta Opción correcta
1 b
2 b
3 b
4 c
5 b
6 b
7 a
8 d
9 c
10 d
11 c
12 d
13 a
14 b
15 a
16 d
17 a
18 c
19 b
20 b