Вы находитесь на странице: 1из 8

Estructura de los sistemas operativos

Ya se ha visto el aspecto externo de los sistemas operativos (es decir, la interfaz con el
programador y con el usuario), en este apartado se echar un vistazo al interior del sistema
operativo. En las subsecciones siguientes se examinarn algunas de las formas posibles de
estructurar el cdigo de un sistema operativo. os dise!os estudiados no son exhaustivos, pero
dan una idea de las posibilidades.
Sistemas monolticos
Este tipo de organizacin es, con diferencia, la ms com"n. El sistema operativo se escribe
como una coleccin de procedimientos, cada uno de los cuales puede llamar a los dems cada
vez #ue as$ lo re#uiera. %uando se usa esta t&cnica, cada procedimiento del sistema tiene una
interfaz bien definida en t&rminos de parmetros y resultados, y cada uno de ellos es libre de
llamar a cual#uier otro, si &ste "ltimo proporciona un clculo "til para el primero.
'ara construir el programa ob(eto real del sistema operativo siguiendo este punto de vista, se
compilan de forma individual los procedimientos, o los ficheros #ue contienen los procedimientos,
y despu&s se enlazan en un slo fichero ob(eto con el enlazador. En t&rminos de ocultacin de
la informacin, &sta es prcticamente nula) cada procedimiento es visible a los dems (en
contraste con una estructura con mdulos o pa#uetes, en la #ue la mayor$a de la informacin es
local a un mdulo, y donde slo los datos se!alados de forma expresa pueden ser llamados
desde el exterior del mdulo).
os servicios (mediante llamadas al sistema) #ue proporciona el sistema operativo se solicitan
colocando los parmetros en lugares bien definidos, como los registros o la pila, para despu&s
e(ecutar una instruccin especial de trampa, a veces referida como llamada al ncleo o llamada
al supervisor. Esta instruccin cambia la m#uina del modo usuario al modo n"cleo (tambi&n
conocido como modo supervisor), y transfiere el control al sistema operativo, lo #ue se muestra
en el evento (*) de la figura +.*.
El sistema operativo examina entonces los parmetros de la llamada para determinar cual de
ellas se desea realizar, como se muestra en (,) de la figura +.*. - continuacin, el sistema
operativo analiza una tabla #ue contiene en la entrada k un apuntador al procedimiento #ue
implementa la k.&sima llamada al sistema. Esta operacin, #ue se muestra en (/) de la figura
+.*, identifica el procedimiento de servicio, al cual se llama. 'or "ltimo, la llamada al sistema
termina y el control vuelve al programa del usuario.
Esta organizacin sugiere una estructura bsica del sistema operativo)
0n programa principal #ue llama al procedimiento del servicio solicitado.
0n con(unto de procedimientos de servicio #ue lleva a cabo las llamadas al sistema.
0n con(unto de procedimientos de utilidades #ue ayudan a los procedimientos de
servicio.
En este modelo, para cada llamada al sistema existe un procedimiento de servicio #ue se
encarga de ella. os procedimientos de utilidad hacen cosas necesarias para varios
procedimientos de servicio, como por e(emplo, buscar los datos del programa del usuario. Esta
divisin de los procedimientos en tres capas se muestra en la figura +.,.
Modelo cliente-servidor
0na tendencia de los sistema operativos modernos es la de trasladar el cdigo a capas
superiores, y eliminar la mayor parte posible del sistema operativo para mantener un n"cleo
m$nimo. El punto de vista usual es el implantar la mayor$a de las funciones del sistema operativo
como procesos de usuario. 'ara solicitar un servicio, como la lectura de un blo#ue de cierto
fichero, un proceso de usuario (denominado en este caso proceso cliente) env$a la solicitud a
un proceso servidor, #ue realiza el traba(o y devuelve la respuesta.
En este modelo, #ue se muestra en la figura +./, lo "nico #ue hace el n"cleo es controlar la
comunicacin entre los clientes y los servidores. -l separar el sistema operativo en partes, cada
una de ellas controla una faceta del sistema, como el servicio a ficheros, servicio a procesos,
servicio a terminales o servicio a la memoria1 cada parte es pe#ue!a y controlable. -dems,
puesto #ue todos los servidores se e(ecutan como procesos en modo usuario, y no en modo
n"cleo, no tienen acceso directo al hardware. En consecuencia, si hay un error en el servidor de
ficheros &ste puede fallar, pero esto no afectar en general a toda la m#uina.
2tra de las venta(as del modelo cliente.servidor es su capacidad de adaptacin para su uso en
sistemas distribuidos (v&ase la figura +.3). 4i un cliente se comunica con un servidor mediante
mensa(es, el cliente no necesita saber si el mensa(e se gestiona de forma local, en su m#uina,
o si se env$a por medio de una red a un servidor en una m#uina remota. En lo #ue respecta al
cliente, lo mismo ocurre en ambos casos) se envi una solicitud y se recibi una respuesta.
a idea anterior de un n"cleo #ue slo controla el transporte de mensa(es de clientes a
servidores, y viceversa, no es totalmente real. -lgunas funciones del sistema operativo (como la
introduccin de rdenes en los registros f$sicos de los controladores de E/S) son dif$ciles, si no
es #ue imposible de realizar, a partir de programas de usuario. Existen dos formas de afrontar
este problema. 0na es hacer #ue algunos procesos de servidores cr$ticos (por e(emplo, los
gestores de los dispositivos de E54) se e(ecuten en realidad en modo n"cleo, con acceso total al
hardware, pero de forma #ue se comuni#uen con los dems procesos mediante el mecanismo
normal de mensa(es.
a otra forma es construir una cantidad m$nima de mecanismos dentro del n"cleo, pero
manteniendo las decisiones de poltica relativos a los usuarios dentro del espacio de los
usuarios. 'or e(emplo, el n"cleo podr$a reconocer #ue cierto mensa(e enviado a una direccin
especial indica #ue se tome el contenido de ese mensa(e y se cargue en los registros del
controlador de alg"n disco, para iniciar la lectura del disco. En este e(emplo, el n"cleo ni si#uiera
inspeccionar$a los bytes del mensa(e para ver si son vlidos o tienen alg"n sentido1 slo los
copiar$a ciegamente en los registros del controlador del disco. Es evidente #ue debe utilizarse
cierto es#uema para limitar tales mensa(es slo a los procesos autorizados. a separacin entre
mecanismos y poltica es un concepto importante, aparece una y otra vez en diversos
contextos de los sistemas operativos.
El esquema que suele usarse para el estudio de los sistemas operativos recibe
el nombre de modelo de cebolla, debido a que esta formado por capas
concntricas al rededor del ncleo (ver figura 1.5). a parte interna del con!unto
!er"rquico de programas que forman un sistema operativo recibe el nombre de
ncleo o #ernel. as otras capas se encargan del mane!o de la memoria, el
procesador, los dispositivos de E$% & los arc'ivos.
(igura 1.5 )n modelo de estudio para los sistemas operativos
Gestin de interrupciones
%omencemos este apartado con una clasificacin de los tipos de interrupcin. -un#ue algunos
autores utilizan criterios distintos, nosotros veremos las siguientes)
0n usuario realiza una llamada al sistema, concretamente una instruccin trampa (a
veces, a las llamadas al sistema se les llaman interrupciones software).
En un proceso de usuario se da una condicin de error (por e(., una divisin entre cero).
Esta condicin puede tratarse como una 6interrupcin interna6 generada por el procesador y
ser gestionada en primera instancia por una rutina de interrupcin. - estas condiciones de
error algunas veces se les llama excepciones.
4e intenta e(ecutar un instruccin reservada estando en modo usuario. Ello puede
considerarse como un tipo particular de error y tratarse, pues, como en b).
0n controlador de un dispositivo de E54 genera una interrupcin para indicar el fin de la
E54.
a ocurrencia de cual#uiera de estas circunstancias, incluida las interrupciones, provoca el
cambio automtico del procesador de modo usuario a modo supervisor.
El controlador de interrupciones de primer nivel .789, del ingl&s First-Level Interrupt Handler. es
la parte del sistema operativo responsable de proporcionar la respuesta adecuada a las se!ales
procedentes tanto del exterior de la %'0 (interrupciones de un controlador) como de dentro del
procesador (excepciones y llamadas al sistema). a misin del 789 es doble) a) determinar el
origen de las interrupciones y b) iniciar el servicio de las mismas.
Ya hemos visto #ue era el mecanismo de interrupcin del ordenador el responsable de salvar al
menos el valor del contador de programa del proceso interrumpido. 9ay #ue asegurar tambi&n
#ue se salven lo otros registros #ue vaya a emplear el 789 y #ue estuviesen siendo utilizados
por el proceso interrumpido. 4i esto no lo realiza el mecanismo de interrupcin, debe ser la
primera operacin #ue realice el 789. %omo #ue &ste es un programa relativamente sencillo,
definido adems sobre una zona dedicada de memoria, el con(unto de registros afectados no
ser muy grande, posiblemente slo un acumulador. 4er desde luego considerablemente menor
#ue la informacin de estado del procesador del proceso interrumpido, #ue no hace falta #ue se
guarde en su totalidad, ya #ue puede reemprenderse dicho proceso tan pronto como se haya
atendido la interrupcin.
0na estrategia alternativa a la de salvar el valor de los registros, adoptada por e(emplo por
algunos ordenadores de la serie ':'.**, es la de disponer de un con(unto suplementario de
registros para ser utilizados slo en modo supervisor. El 789 puede entonces usar estos
registros y de(a los del proceso interrumpido intactos.
a determinacin del origen de la interrupcin puede llevarse a cabo ms o menos fcilmente
dependiendo del hardware de #ue se disponga. En el caso ms elemental, en el #ue todas las
interrupciones transfieren el control del programa a la misma posicin de memoria, debe
realizarse la identificacin a trav&s de una secuencia de consultas de los status (estados) de
todas las posibles fuentes de interrupcin. Esta secuencia se conoce frecuentemente con el
nombre de cadena de saltos.
En algunos ordenadores (por e(emplo el ':'.**), la cadena de saltos se hace innecesaria
gracias a la utilizacin de un hardware capaz de distinguir las diferentes fuentes de interrupcin y
transferir el control del programa a una posicin de memoria distinta para cada una de ellas. Ello
reduce el tiempo empleado en reconocer una interrupcin a costa de utilizar un con(unto
adicional de posiciones de memoria. 0na solucin de compromiso #ue aparece en varios
ordenadores, es la de disponer de un n"mero reducido de posiciones de memoria de
interrupcin, cada una de las cuales est compartida por un grupo de dispositivos. :e esta
forma, la primera etapa del reconocimiento de la interrupcin la realiza el ardware, siendo
suficiente para completar la identificacin, una pe#ue!a cadena de saltos asociada a cada una
de las posiciones de memoria. a diferenciacin entre interrupciones generadas por un
controlador, excepciones y llamadas al sistema se lleva a cabo muy a menudo de esta forma. El
mecanismo de interrupcin puede facilitar la identificacin guardando informacin acerca de la
interrupcin en alguna posicin prefi(ada de memoria.
;ormalmente se inhiben las interrupciones del procesador central cuando se cambia de modo
usuario a modo supervisor. %on ello se asegura #ue el valor de los registros almacenados al
entrar en el 789 no pueda alterarse debido a una interrupcin posterior #ue se d& antes de salir
del 789. 0na interrupcin #ue ocurra mientras el mecanismo de interrupcin est inhibido,
#ueda pendiente hasta #ue este mecanismo sea reactivado al volver al modo usuario. Este
sistema no es vlido en situaciones en las #ue alg"n dispositivo necesite una respuesta mucho
ms rpida #ue otros, si, por e(emplo, no se #uiere #ue se pierda informacin. En tales casos es
conveniente introducir la nocin de prioridad entre la distintas fuentes de interrupcin,
permitiendo #ue una rutina de interrupcin sea a su vez interrumpida por una solicitud de servicio
de un dispositivo de ms alta prioridad.
-lgunos ordenadores permiten hacer todo esto desautorizando de forma selectiva algunas
interrupciones dentro del 7891 cuando &ste sirve una interrupcin, inhibe todas las otras #ue
tengan igual o menor prioridad. 9ay #ue tener la precaucin, evidentemente, de guardar los
registros de programa del proceso interrumpido en posiciones distintas de memoria, seg"n sea el
nivel de prioridad de la interrupcin recibida.
<ambi&n es posible #ue el hardware de interrupcin pueda distinguir por s$ mismo los diferentes
niveles de interrupcin, y transfiera el control del programa y guarde el contenido de los registros
en posiciones distintas de memoria seg"n cada nivel. 0na interrupcin de una determinada
prioridad inhibe automticamente las otras de niveles iguales o inferiores.
a segunda misin del 789 es la de iniciar el servicio de un interrupcin a trav&s de la llamada a
una rutina de servicio apropiada al tipo de se!al recibida. 9ay #ue destacar el hecho de #ue
debido a la circunstancia de #ue las rutinas de interrupcin se e(ecutan en modo supervisor, con
las otras interrupciones total o parcialmente inhibidas, es conveniente #ue dichas rutinas sean lo
ms cortas posible. En general van a llevar a cabo una accin m$nima, como por e(emplo
transferir un carcter de un dispositivo de entrada a un buffer, de(ando a cargo de un proceso
#ue se e(ecuta con las interrupciones permitidas la tarea de emprender la accin adecuada al
carcter recibido.
Es importante destacar la circunstancia de #ue el #ue se d& una interrupcin puede #ue altere el
estado de un proceso. -s$, por e(emplo, un proceso #ue haya puesto en marcha una
transferencia con un dispositivo, mientras dure la misma, ser blo#ueado1 aun#ue pasar a ser
listo al recibir la interrupcin #ue se!ale el final de la transferencia en curso. -lgunas llamadas
al sistema, como una solicitud de E54, provocarn #ue el proceso en curso no pueda proseguir.
En todos los casos, el cambio de status lo realiza la rutina de interrupcin al modificar el campo
correspondiente al estado del proceso en el !"# del proceso.
0na consecuencia de este cambio de status es #ue el proceso #ue se estaba e(ecutando antes
de darse la interrupcin puede #ue no sea el ms adecuado para e(ecutarse despu&s de la
misma. 'uede darse el caso, por e(emplo, de #ue la interrupcin vuelva e(ecutable un proceso
#ue tenga mayor prioridad #ue el proceso en curso. En el tema siguiente vamos a discutir la
cuestin de cundo conmutar la %'0 entre procesos, as$ como la de decidir el proceso #ue debe
ocupar la %'0.