CAPÍTULO 3
EJERCICIO 3.1
¿Cuál de los siguientes mecanismos hardware no es un requisito para construir un sistema operativo multiprogramado con protección entre usuarios? Razone su respuesta.
A.- Memoria virtual.
B.- Protección de memoria.
C.- Instrucciones de E/S que sólo pueden ejecutarse en modo kernel.
D.- 2 modos de operación: kernel y usuario.
A) Memoria Virtual. De las opciones dadas esta es la unica que no es necesaria para la proteccion entre usuario en un sistema operativo multiprogramado. Las otras opciones sin embargo son necesarias ya sea para la seguridad entre usuarios, como en los casos de los 2 modos de operacion y en la proteccion de memoria o para el aprovecho maximo del tiempo de ejecucion, como es en el caso de las instrucciones de E/S que solo pueden ejecutarse en modo Kernel.
EJERCICIO 3.2
¿Puede degradarse el rendimiento de la utilización del procesador en un sistema sin memoria virtual siempre que aumenta el grado de multiprogramación?
No es motivo de degradación del rendimiento aumentar el índice de multiprogramación, ya que no hay paginación ni ninguno de los efectos que empiezan a ocurrir cuando hay memoria virtual y un conjunto de trabajo insuficiente. Por tanto, el aprovechamiento del procesador aumentará a medida que lo haga también el nivel de multiprogramación, ya que nuestra única limitación viene dada por el tamaño de la memoria principal y de los procesos.
EJERCICIO 3.3
Indique cuál de estas operaciones no es ejecutada por el activador:
A.- Restaurar los registros de usuario con los valores almacenados en la tabla del proceso.
B.- Restaurar el contador de programa.
C.- Restaurar el puntero que apunta a la tabla de páginas del proceso.
D.- Restaurar la imagen de memoria de un proceso.
D) restaurar la imagen de memoria del proceso, no se lleva a cabo en la activación. La imagen se restaura a medida que se producen fallos de página y estas se van trayendo a memoria.
EJERCICIO 3.4
¿Siempre se produce un cambio de contexto cuando se produce un cambio de proceso? Razone su respuesta.
En procesos independientes SI. En procesos ligeros NO. Procesos ligeros son aquellos cuya ejecucion se puede lanzar en paralelo con otros.
EJERCICIO 3.5
¿Cuál es la información que no comparten los procesos ligeros de un mismo proceso?
Información referente al espacio de pila, a la identificación del proceso, a las señales y una pequeña información de entorno.
EJERCICIO 3.6
¿Puede producirse un cambio de contexto en un sistema con un planificador basado en el algoritmo primero el trabajo más corto además de cuando se bloquea o se termina el proceso? Razone su respuesta.
No, ya que si no tenemos en cuenta las posibilidades de bloqueo y terminación del proceso, sólo nos quedaría la posibilidad de la expulsión, pero en esta política de planificación, esa operación queda descartada.
EJERCICIO 3.7
¿Qué algoritmo de planificación será más conveniente para optimizar el rendimiento de la UCP en un sistema que sólo tiene procesos en los cuales no hay entrada/salida?
FIFO, porque en este no tenemos que cambiar los procesos que se
ejecutan, el proceso se queda hasta que termina su ejecución, a no ser que los procesos se bloqueen de forma voluntaria.
EJERCICIO 3.8
¿Cuál de las siguientes políticas de planificación es más adecuada para un sistema de tiempo compartido?
A.- Primero el trabajo más corto.
B.- Round-Robin.
C.- Prioridades.
D.- FIFO.
La política de Round Robin. Este algoritmo es especialmente adecuado para los sistemas de tiempo compartido por que se basa en el concepto de rodaja de tiempo (slot) y reparte su atención entre todos los procesos, lo que al final viene a significar entre todos los usuarios. Los procesos están organizados en forma de cola circular y cuando han consumido su rodaja de tiempo son expulsados y pasan a ocupar el último lugar en la cola, con lo que se ejecutan otro proceso. Con este mecanismo, los usuarios tienen la sensación de avance global y continuado, lo que no está garantizado con los otros algoritmos descritos.
EJERCICIO 3.9
¿Cuál es el criterio de planificación más relevante en un sistema de tiempo compartido, el tiempo de respuesta o la optimización en el uso del procesador? Razone su respuesta.
El tiempo de respuesta de los procesos que ejecuten cada uno de los usuarios, debe ser lo suficientemente rápido para evitar esperas por parte de los usuarios, ya que estos piensan que estan conectados directamente a la maquina y no a una terminal.
EJERCICIO 3.10
¿Cuál de las siguientes transiciones entre los estados de un proceso no se puede producir en un sistema con un algoritmo de planificación no expulsivo?
A.- Bloqueado a listo.
B.- Ejecutando a listo.
C.- Ejecutando a bloqueado.
D.- Listo a ejecutando.
B) ejecutando a listo. Ya que no podrá pararse la ejecución sin pasar antes por bloqueado, que será solicitado por el sistema operativo. Por ejemplo no habría problema alguno de bloqueado a listo, de ejecutando a bloqueado(donde será el sistema operativo quien solicite ese bloqueo),o de listo a ejecutando.
EJERCICIO 3.11
Sea un sistema que usa un algoritmo de planificación de procesos round-robin con una rodaja de tiempo de 100 ms. En este sistema ejecutan dos procesos. El primero no realiza operaciones de E/S y el segundo solicita una operación de E/S cada 50 ms. ¿Cuál será el porcentaje de uso de la UCP?
El porcentaje de uso de la UCP será el 100% ya que cuando no se está ejecutando uno de los procesos se está ejecutando el otro.
EJERCICIO 3.12
Considere el siguiente conjunto de procesos planificados con un algoritmo round-robin con 1 u.t. de rodaja, ¿Cuánto tardan en acabar todos ellos?
Proceso. Llegada. Duración
P1 2 8
P2 0 5
P3 1 4
P4 3 3
Supondré que al final de cada unidad de tiempo, primero se encola el proceso que ha acabado de ejecutar y después se encola el proceso que llegue en ese instante. Tienen que transcurrir 12 unidades de tiempo para que el proceso P2 finalice. Tienen que transcurrir 14 unidades de tiempo para que P3 finalice. Tienen que transcurrir 15 unidades de tiempo para que P3 finalice. Para que finalice P1 tienen que transcurrir 20 unidades de tiempo.
EJERCICIO 3.13
En un sistema que usa un algoritmo de planificación de procesos round-robin, ¿cuántos procesos como máximo pueden cambiar de estado cuando se produce una interrupción del disco que indica que se ha terminado una operación sobre el mismo?
puede ocurrir que un proceso que estaba bloqueado, al recibir la señal causada por la interrupción pase a listo, colocándose en la última posición de la cola de control de procesos. Si además suponemos que en el instante en que ese proceso pasa de bloqueado a listo el que está en la cabecera ha consumido su rodaja de tiempo y pasa a ejecutarse el que estaba a continuación, obtenemos que han cambiado de estado 3 procesos, siendo este el número máximo de procesos que pueden cambiar de estado cuando se produce una interrupción de disco que indica que se ha terminado una operación sobre el mismo bajo un algoritmo de planificación Round-Robin.
EJERCICIO 3.14
Se tienen los siguientes trabajos a ejecutar:
trabajos Unidades de tiempo Prioridad
1 8 2
2 5 4
3 2 2
4 7 3
Los trabajos llegan en el orden 1, 2, 3 y 4 y la prioridad más alta es la de valor 1, se pide:
a) Escribir un diagrama que ilustre la ejecución de estos trabajos usando:
1. Planificación de prioridades no expulsiva
2. Planificación cíclica con una rodaja de tiempo de 2
3. FIFO
b) Indicar cuál es el algoritmo de planificación con menor tiempo medio de espera
b) el cíclico, ya que un proceso no tiene que esperar a que termine de ejecutar el anterior.
EJERCICIO 3.15
¿Qué sucede cuando un proceso recibe una señal? ¿y cuando recibe una excepción?
Se puede decir que una señal es una interrupción al proceso. El proceso se comporta de la siguiente forma cuando recibe una señal:
1. El proceso detiene su ejecución que está ejecutando en la instrucción máquina.
2. Ejecuta una rutina de tratamiento de la señal (el código forma parte del proceso).
3. Cuando acaba la rutina de tratamiento, continua con la ejecución del proceso de la instrucción máquina.
Estas señales pueden proceder de un proceso o del sistema operativo.
Cuando ocurre una excepción, el sistema operativo toma el control e indica la excepción al proceso. Si el proceso había capturado la excepción. La ejecución salta al código de la rutina de tratamiento de excepción. Si no existiere, aborta la ejecución del proceso. Habitualmente, las excepciones sólo se pueden tratar al final del código fuente de una función y dicha función termina después de tratar dicha excepción. Las excepciones se entienden mejor como tratamiento de un error o situación anómala.
EJERCICIO 3.16
¿Cómo se hace en POSIX para que un proceso cree otro proceso que ejecute otro programa? ¿y en Win32?
En POSIX son necesarios dos servicios: el servicio fork crea un nuevo proceso de uno original, y el servicio exec hace que el proceso hijo ejecute otro programa distinto al del padre.
En WIN32 el servicio CreateProcess (que es un servicio similar a la combinación fork-exec de POSIX) crea los procesos. WIN32 no permite a un proceso cambiar su imagen de memoria y ejecutar otro programa distinto. Este servicio crea a un proceso nuevo y su proceso ligero principal, ejecutando el archivo ejecutable especificado en la llamada al servicio.
EJERCICIO 3.17
¿Qué información comparten un proceso y su hijo después de ejecutar el siguiente código?
if (fork()!=0)
wait (&status);
else
execve (B, parámetros, 0);
ambos compartirán:
Datos.
Pila.
PC (contador de programa).
Descriptores de archivos abiertos.
En un sistema operativo conforme a la norma POSIX, ¿cuándo pasa un proceso a estado zombie?
En el estándar POSIX un proceso pasa a estado zombie cuando su función ha finalizado pero no se han liberado sus recursos debido a que el padre no ha ejecutado un wait(). No se puede liberar el BCP donde se almacena la información de quién es el padre del proceso hasta que se le pueda informar de que el proceso ha finalizado.
EJERCICIO 3.19
Tras la ejecución del siguiente código, ¿cuántos procesos se habrán creado?
for (i=0; i <>
fork();
se crean (2**n-1) procesos.
EJERCICIO 3.20
Cuándo un proceso ejecuta una llamada fork y luego el proceso hijo un exec, ¿qué información comparten ambos procesos?
Cuando el primer proceso invoca al servicio fork, el Sistema Operativo realiza una clonación de este proceso en el estado que tenía al realizar la llamada. Cuando el proceso hijo llama a exec no se crea un nuevo proceso, si no que se permite que este proceso ejecute un programa distinto. El Sistema Operativo procede salvando el entorno de proceso y algunas informaciones del BCP, y se carga la imagen de memoria que corresponda. Este nuevo proceso hijo ya no tiene que ver con su padre más que esta relación de padre-hijo, los identificadores de usuario y grupo y las tablas de archivos abiertos que tenía el padre, que ahora están compartidas. Estos archivos abiertos se pueden usar para hacer trabajo en común o como una forma de comunicación.
EJERCICIO 3.21
¿Qué diferencia existe entre bloquear una señal e ignorarla en POSIX?
Cuando una señal es ignorada por un proceso, el sistema operativo transmite la señal al proceso, pero este la ignora. Para ignorar una señal basta con darle un tratamiento definido por SIG_IGN en la llamada al sistema signal. Como resultado, las señales ignoradas se suponen tratadas desde el sistema operativo, por lo que no se apuntan en ninguna parte. Un buen ejemplo son los programas que ignoran la señal que origina el teclado cuando se pulsa CTRL-C para evitar que se pueda matar al proceso.
Sin embargo cuando una señal es bloqueada, se almacena en el BCP asociado al proceso, la información necesaria para que la señal sea tratada cuando el proceso la desbloquee. Cuando ocurra esto último, el sistema operativo enviará de nuevo la señal al proceso basándose en la información almacena en el BCP. La señal no será enviada al proceso hasta que sea desbloqueada. Para ello, se define una máscara de señal mediante la llamada al sistema sigprocmask con un argumento SIG_BLK. Para desbloquearla, se usa el argumento SIG_UNBLOCK.
EJERCICIO 3.22
Escribir un programa en C que active unos manejadores para las señales SIGINT, SIGQUIT y SIGILL. Las acciones a ejecutar por dichos manejadores serán:
a) para SIGINT y SIGQUIT, abortar el proceso con un estado de error.
b) para SIGILL, imprimir un mensaje de instrucción ilegal y terminar.
#include
#include
void abortar_proceso (void){
exit(-1);
}
void msg_y_terminar (void){
printf(“Instrucción ilegal\n El proceso terminará. \n”);
exit(-1);
}
void main(void){
struct sigaction act;
sigset_s mask;
act.sa_handler = abortar_proceso;
sigemptyset(&act.mask);
sigaction(SIGINT,&act, NULL);
sigaction(SIGQUIT,&act, NULL);
act.sa_handler = msg_y_terminar;
sigemptyset(&act.mask);
sigaction(SIGILL,&act, NULL);
}
EJERCICIO 3.23
Dado el siguiente programa en C
void main(int argc, char argv) {
int i;
for (i =1; i <= argc; i++)
fork();
....
se pide:
a) Dibujar un esquema que muestre la jerarquía de procesos que se crea cuando
se ejecuta el programa con argc igual a 3.
b) ¿Cuántos procesos se crean sin argc vale n?
A) Aunque a primera vista parece que solo se crean argc procesos debido a las argc iteraciones del bucle, en realidad se crean (2**argc-1). Es decir, si argc = 3, se crean 7 procesos.
Proceso1
Proceso1 Proceso2 (i = 1)
Proceso1 Proceso3 Proceso2 Proceso4 (i = 2)
Proc1 Proc5 Proc3 Proc6 Proc2 Proc7 Proc4 Proc8 (i = 3)
B)Se crean (2**n-1) procesos nuevos, Proceso 1 ya existía.
EJERCICIO 3.24
Responder a las siguientes preguntas sobre las llamadas al sistema wait de POSIX y WaitForSingleObject de Win32 cuando está se aplica sobre un manejador de proceso.
a) ¿Cuál es la semántica de estas llamadas?
b) Indicar en qué situaciones puede producirse cambio de proceso y en qué casos no.
c) Describir los pasos que se realizan en estas llamadas al sistema desde que se llama a la rutina de biblioteca hasta que ésta devuelve el control al programa de usuario. Indicar cómo se transfiere el control y parámetros al sistema operativo, cómo realizaría su labor el sistema operativo y cómo devuelve el control y resultados al programa de usuario.
a)
Para wait de Posix
pit_t wait (int *status)
- Permite a un proceso padre esperar hasta que termine la ejecución de un proceso hijo.
ParawaitForSingleObject de Win32
DWORD WaitForSingleObject (Handle hObject, DWORD dwTimeOut)
- Bloquea al proceso hasta que el proceso con manejador hObject finalice su ejecución.
B)
Se producirán cambios de proceso cuando el proceso padre pase a bloqueado por la llamada wait. En este caso pasaría a ejecutar el proceso hijo. Cuando este proceso hijo
Finalice su ejecución el proceso padre deja de estar bloqueado y continua su ejecución.
Para Win32 y su llamada WaitForSingleObject se producira un cambio de proceso por el tiempo especificado en dwTimeOut. Un proceso permanecera bloquedo durante este tiempo mientras ejecuta otro. Si el tiempo concluye o el proceso con el manejador termina su ejecución se continúa ejecutando el proceso antes bloqueado.
c)
Cuando se hace una llamada a wait esta suspende la ejecución del proceso padre que se queda bloqueado hasta que finaliza la ejecución de uno de sus procesos hijos. Esta función devuelve el valor del identificador del proceso hijo que ha finalizado. Si status es distinto de null, entonces se almacena en esta variable información relativa al proceso que ha terminado.
Otra situación se produce cuando un proceso hijo ha terminado su ejecución y se encuentra con que el padre no esta bloqueado con un wait. Este proceso hijo almacenara su información en BCP del hijo hasta que el padre la adquiera con el servicio wait. A este proceso hijo se le llama zombie.
La ultima situación se produce cuando un proceso con hijos termine antes que estos. Estos procesos huerfanos pasarían a cargo del proceso init.
En la llamada WaitForSingleObject para win32 se bloquea un proceso hasta que el proceso con manejador hObject termine su ejecución. En el argumento dwTimeOut se especifica el tiempo máximo que el proceso quedara bloqueado. Un valor de 0 hace que la función vuelva inmediatamente después de comprobar si el proceso termino su ejecución. Un valor INFINITE hace que el proceso quede bloqueado hasta que no termina la ejecución del proceso con manejador hObject.
EJERCICIO 3.25
Escribir un programa similar al programa 3.15, que utilice los servicios de Win32 para temporizar la ejecución de un proceso
// Programa temporizador
#include
#include
#include
#include
HANDLE hnd;
void matar(){
TerminateProcess(hnd,0);
printf("\n");
printf("Ha terminado el tiempo de ejecución del proceso");
}
void main(int argc,char **argv)
{
static STARTUPINFO si;
static PROCESS_INFORMATION pi;
UINT tid;
UINT tiempo=20;
UINT idEvent=2;
MSG msg;
if(argc == 2){
if (!CreateProcess(NULL,argv[1],NULL,NULL,FALSE,0,NULL,NULL,&si,&pi)){
printf ("Error al crear el proceso. Error: %x\n",
GetLastError ());
ExitProcess(0);
}
hnd= OpenProcess(PROCESS_ALL_ACCESS,FALSE,pi.dwProcessId);
tid = SetTimer(NULL,NULL,tiempo,matar);
msg.hwnd = NULL;
if (GetMessage(&msg,NULL,NULL,NULL)!= 0 &&
GetMessage(&msg, NULL, NULL, NULL) != -1){
if (msg.message == WM_TIMER) msg.hwnd = NULL;
TranslateMessage(&msg); // traducir códigos virtuales
DispatchMessage(&msg); // enviar el mensaje a la ventana
}
KillTimer(NULL,tid);
WaitForSingleObject(hnd,INFINITE);
}
else printf("faltan argumentos");
/* el proceso acaba */
exit(0);
}
// Programa Hola de prueba
#include
void main(){
while(1 == 1){
printf("Hola");
}
}
A continuación se incluye una posible solución con threads:
#include
#include
#define MAX_THREADS 10
void func (void)
DWORD WINAPI ThreadFunc (LPVOID);
{
printf (“Thread %d /n”, GetCurrentThreadId()/*pthread_self()*/);
ExitThread (DWORD dwExitCode);
}
void main()
{
int j, i;
pthread_t thid[MAX_THREADS];
for (j = 0; j <>
Manejador_Proceso = CreateThread (NULL,NULL,func,NULL,0,&thid[j]);
for( i = 0; I <= 5; i++) SuspendedThread(Manejador_Proceso);
ResumeThread(Manejador_Proceso);
}
