TEMA 2. GESTIÃN DE PROCESOS - Universidad de AlmerÃa
TEMA 2. GESTIÃN DE PROCESOS - Universidad de AlmerÃa
TEMA 2. GESTIÃN DE PROCESOS - Universidad de AlmerÃa
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Diseño <strong>de</strong> Sistemas Operativos<br />
Tema <strong>2.</strong> Gestión <strong>de</strong> Procesos<br />
• Observemos que es necesario borrar la dirección <strong>de</strong>l manejador <strong>de</strong> señal <strong>de</strong> usuario <strong>de</strong> la u-Area (si<br />
el proceso quiere volverla a usar <strong>de</strong>be volver a usar signal (esto se hace porque el código <strong>de</strong> usuario<br />
ejecuta en modo usuario y podría llegar otra vez la misma señal e invocar el mismo código<br />
mientras se está manejando la previa), pero queda un problema que es ... ¿qué hacer si llega otra<br />
vez la misma señal antes que el proceso usuario haya restaurado su manejador <strong>de</strong> señal?. Cierto es<br />
que la estrategia aparece apropiada sólo para lo que fue diseñada inicialmente (señales equivalían a<br />
situaciones que eran fatales o que <strong>de</strong>bían ser ignoradas). Ahora haría falta una llamada al sistema<br />
que permitiera bloquear la recepción <strong>de</strong> señales <strong>de</strong> un <strong>de</strong>terminado tipo y que en el <strong>de</strong>sbloqueo el<br />
kernel enviara las señales pendientes.<br />
• Otra anomalía se pue<strong>de</strong> observar en el manejo <strong>de</strong> señales que ocurren cuando el proceso duerme en<br />
un nivel interrumpible, La señal provoca que el proceso haga un longjmp fuera <strong>de</strong> su sleep, regrese<br />
a modo usuario y llame al manejador <strong>de</strong> señal. Cuando el manejador <strong>de</strong> señal finaliza, el proceso<br />
pareciera regresar <strong>de</strong> una llamada al sistema con un error, indicando que la llamada al sistema ha<br />
sido interrumpida. El usuario pue<strong>de</strong> controlar el error en la llamada al sistema y relanzarla, pero no<br />
siempre lo hace, así que pue<strong>de</strong> ser mejor que sea el kernel quien vuelva a lanzar la llamada al<br />
sistema en esta situación.<br />
• También se presentan anomalías cuando un proceso ignora una señal. Si la señal llega cuando el<br />
proceso está bloqueado a un nivel interrumpible, el proceso será <strong>de</strong>sbloqueado pero no hará un<br />
longjmp. Esto es, el kernel solo se da cuenta que el proceso ignora la señal cuando lo ha <strong>de</strong>spertado<br />
y ejecutado. Una práctica más consistente sería <strong>de</strong>jar al proceso bloqueado. El problema es que la<br />
información sobre ignorar la señal se encuentra en la u-Area que no es accesible cuando llega una<br />
señal a un proceso que no está ejecutando (la mayor parte <strong>de</strong> las veces). La solución <strong>de</strong> este punto<br />
pasa por incluir en la entrada <strong>de</strong>l proceso en la Tabla <strong>de</strong> Procesos las acciones ante las señales <strong>de</strong><br />
forma que el kernel pudiera controlarlas en la recepción <strong>de</strong> las mismas. Otra alternativa es volver a<br />
dormirse en el algoritmo sleep si <strong>de</strong>scubre que no <strong>de</strong>bió ser <strong>de</strong>spertado.<br />
• Finalmente, la señal SIGCHLD tiene el efecto <strong>de</strong> <strong>de</strong>spertar a un proceso bloqueado a una prioridad<br />
interrumpible y recibe un tratamiento especial. En particular, cuando un proceso la recibe <strong>de</strong>sactiva<br />
el indicador <strong>de</strong> señal en la entrada <strong>de</strong>l proceso en la Tabla <strong>de</strong> Procesos y proce<strong>de</strong> <strong>de</strong> la siguiente<br />
forma:<br />
− Si se mantiene la acción por <strong>de</strong>fecto, entonces actúa como si la señal no se hubiera recibido.<br />
− Si el proceso ha especificado un manejador <strong>de</strong> señal, entonces él invoca a su manejador <strong>de</strong><br />
señales como en los otros casos.<br />
− Si el kernel <strong>de</strong>be ignorar la señal, entonces se revisará en la llamada al sistema wait.<br />
− Si un proceso invoca la llamada al sistema signal con parámetro SIGCHLD, entonces el<br />
kernel envía al mismo proceso una señal con kill(pid, SIGCHLD) si este proceso tiene algún<br />
hijo en estado Zombie (este caso se revisará también en la llamada al sistema wait).<br />
<strong>2.</strong>9.4. Descriptores <strong>de</strong> Señales.<br />
Ahora vamos a indicar un estudio comparativo <strong>de</strong> la interfaz <strong>de</strong> manejo <strong>de</strong> señales que brindan UNIX<br />
System V, 4.3 BSD y el estándar POSIX.1 (norma IEEE POSIX 1003.1-1988) (Linux sigue este último<br />
estándar pero incorpora a<strong>de</strong>más otras funciones).<br />
Descripción System V 4.3 BSD POSIX<br />
Tratamiento <strong>de</strong> señales (1). signal() signal() signal()<br />
Envío <strong>de</strong> señales. kill() o raise() kill() o raise() kill() o raise()<br />
En espera <strong>de</strong> señales. pause() sigpause() sigsuspend() o pause()<br />
Tratamiento <strong>de</strong> señales (2). signal() sigvector() o sigvec() sigaction() <br />
Protección <strong>de</strong> zonas críticas (1). sigblock() sigprogmask() o sigpending()<br />
<br />
Protección <strong>de</strong> zonas críticas (2). sigsetmask() sigprogmask() o sigpending()<br />
<br />
Tratamiento <strong>de</strong> stack <strong>de</strong> señales.<br />
sigstack()<br />
Interrupción <strong>de</strong> las llamadas al<br />
siginterrupt()<br />
siginterrupt()<br />
sistema.<br />
Gestión <strong>de</strong> alarmas. alarm() alarm() alarm()<br />
Departamento <strong>de</strong> Lenguajes y Computación. <strong>Universidad</strong> <strong>de</strong> Almería Página <strong>2.</strong>57