Pag. 1. CAP.

2: SERVICIOS QUE BRINDA UN SO

Dijimos que un SO provee el ambiente para que los programas puedan ser ejecutados.
Como el SO es el único que puede realizar operaciones de E/S, el usuario debe pedir la
realización de las mismas al SO. Veremos qué servicios brinda el SO y cómo los realiza.

2.1. TIPOS DE SERVICIO

El SO brinda ciertos servicios al usuario y a sus programas. Los servicios variarán de un

SO a otro, pero hay cierta clase común de servicios que podemos identificar. Estas
funciones están para conveniencia del programador.
* Ejecución de programas: Los usuarios desearán ejecutar programas. El SO debe
cargar esos programas a memoria y ejecutarlos. El programa debe terminar su ejecución,
ya sea normal o anormalmente.
* Operaciones de E/S: Un programa en ejecución puede requerir operaciones de E/S,
que involucrarán a archivos o a cualquier otro dispositivo. Para dispositivos específicos
puede necesitarse funciones especiales ( tales como rebobinar una cinta, limpiar la
pantalla, etc.).
* Manipulación del sistema de archivos: Es obvio que los programas necesitarán leer
y escribir archivos; también podremos necesitar crear y borrar archivos por su nombre.
* Detección de errores: El SO necesita permanentemente estar alerta sobre posibles
errores. Pueden ocurrir en el hardware de cpu o memoria (error de direccionamiento o
falla de alimentación), en dispositivos de E/S (error de paridad en cintas, falta de papel
en impresoras) o en programas de usuario (overflow en operaciones aritméticas,
intento de acceder a locaciones de memoria prohibidas o exceso en uso de cpu). Para
cada tipo de error, el SO debe tomar las acciones necesarias para asegurar una operación
del sistema correcta y consistente.

Adicionalmente, existe otro conjunto de funciones del SO no destinadas directamente al

usuario, sino para una eficiente operación del SO propiamente dicho.
* Asignación de recursos: cuando existen múltiples usuarios o trabajos corriendo al
mismo tiempo, los recursos deben repartirse entre ellos. (ciclos de cpu, memoria
principal, almacenamiento de archivos, códigos de pedido y liberación de periféricos).
* Contabilidad: se desea siempre saber qué tipos de recursos y cuánto usa cada usuario.
Estos datos pueden necesitarse para su cobro posterior o solo a efectos estadísticos.
Estos datos son muy útiles para mejorar la performance del sistema
* Protección: No debe permitirse que un trabajo interfiera con otros. Además, demandas
de varios dispositivos pueden entrar en conflicto, el cual debe resolverse con una
planificación razonable.
Todas estas tareas, el SO las realiza con administradores, que como vimos inicialmente
son:
1) Administrador de memoria:
* Llevar registro del recurso (memoria). Cuántos componentes están usados, quién las

Sistemas Operativos - I.S.I. Servicios del Sistema Operativo - Página 1 Prof. Exp. Mario R. Iribas
usa. Qué bloques de memoria están libres.
* En multiprogramación, decidir el proceso que obtiene el control de la memoria, cuándo
y cómo.
* Asignar el recurso cuando los procesos lo solicitan, de acuerdo a una política
predeterminada.
* Recuperar el recurso cuando el proceso ya no lo necesita o ha abortado.
* Llevar control de los procesos y de su estado. Al programa se lo llama controlador de
tráfico.
2) Administrador de cpu:
* Decidir quién tendrá la oportunidad de utilizar la cpu; el planificador de trabajos
escoge uno y decide a quién se le permite entrar al sistema. En multiprogramación
decidir el proceso que obtiene la cpu, cuándo y cuánto: a este programa se lo llama
planeador de procesos.
* Asignar el recurso de proceso posicionando los registros necesarios de hardware; a
este programa a menudo se lo llama despachador.
* Recuperar el recurso cuando el proceso cede el uso del procesador, aborta si excede la
cantidad permisible de utilización.
3) Administrador de dispositivos (o de E/S):
* Mantener el control del recurso (dispositivo, canales y unidades de control)
típicamente se le llama el controlador de trafico de E/S.
* Decidir cuál es la forma eficiente de asignar el recurso. En caso de compartirse, decidir
quién lo recibe y cuanto recibirá; se lo llama planificador d E/S.
* Asignar el recurso y arrancar la operación de E/S.
* Recuperar el recurso. En la mayoría de los casos la E/S termina automáticamente.
4) Administrador de información (o de archivos).
* Mantener el control del recurso, su posición, estado, etc. A estas facilidades se llama
sistema de archivos.
* Decidir quién utiliza los recursos, imponer los procedimientos de protección y
proporcionar rutinas de acceso.
* Asignar el recurso, por ejemplo abrir archivo.
* Desasignar el recurso, por ejemplo cerrar archivo.

Sistemas Operativos - I.S.I. Servicios del Sistema Operativo - Página 2 Prof. Exp. Mario R. Iribas
2.2. PUNTO DE VISTA DEL USUARIO
Los servicios de SO se proveen de muchas formas. Dos métodos básicos de dar servicios
son las llamadas al sistema y los programas del sistema. Cada método tiene sus
ventajas.
2.2.1. Llamadas al Sistema:
El nivel fundamental de servicios se maneja a través del uso de llamadas al sistema. Estas
proveen una interfaz entre el programa del usuario y el SO. Estas generalmente están
disponibles como instrucciones en assembler y puede agruparse básicamente en 3
categorías: control de trabajos o procesos, manejo de archivos y dispositivos y
mantenimiento de información.
Control de trabajos y procesos
Un programa en ejecución necesita terminar normalmente (end) o anormalmente
(abort). Si el programa encuentra un error en sus entradas y debe terminar
anormalmente, puede ser necesario definir un nivel de error o gravedad. Errores más
severos, por ejemplo, pueden indicarse con un nivel mayor. Es común definir el fin de un
programa en forma normal como error de nivel cero. Un proceso o trabajo ejecutando un
programa puede requerir cargar y ejecutar otros programas. Para esto tenemos llamadas
al sistema especificas como ser create process o submit job.
Si creamos nuevos trabajos o procesos debemos controlar su ejecución.
Esto requiere la posibilidad de determinar atributos de un trabajo, prioridad, máximo
tiempo de ejecución permitido, etc. (get process attributes y set process attributes).
Podremos también terminarlos cuando ya no sean necesarios (terminate process).
Luego de crearlos podemos desear esperar su terminación por un cierto tiempo (wait
time) o por la ocurrencia de un cierto evento (wait event). Llamadas de este tipo lo
veremos al estudiar Procesos Concurrentes.
Otro conjunto de llamadas son útiles para la depuración de programas. Muchos sistemas
poseen llamadas para realizar un vuelco (dump) de memoria. Esto es útil en assembler.
Otros sistemas permiten visualizar cada instrucción a medida que se ejecuta (trace).
Manejo de archivos
Lo que primero necesitaremos son llamadas al sistema para crear y borrar archivos. Para
ello usaremos nombre del archivo y quizás algún atributo. Un vez creado el archivo se
debe abrir para su uso. Luego podremos leer, escribir o reposicionar. (ir al comienzo o
final del archivo). Finalmente debemos cerrar el archivo para indicar que no lo usaremos
más.
Necesitaremos el mismo conjunto de llamadas al sistema para directorios si estamos en
un sistema con estructura de directorios. Los atributos de directorio y archivos incluyen
nombre, tipo, códigos de protección, información de contabilidad, etc. Necesitamos
2 llamados para esto: get file attribute y set file attribute.
Manejo de dispositivos
Los archivos pueden tratarse como dispositivos virtuales o abstractos. Por lo tanto
muchas de las llamadas al sistema para archivos también son necesarias para el manejo de
dispositivos. Si existen varios usuarios en el sistema primero debemos pedir (request) el
dispositivo. Luego debemos liberar (release).
Una vez obtenido el dispositivo podremos leer, escribir o reposicionar, igual que en
manejo de archivos. Las similitudes entre archivos y dispositivos son tan grandes (en su

Sistemas Operativos - I.S.I. Servicios del Sistema Operativo - Página 3 Prof. Exp. Mario R. Iribas
tratamiento) que muchos SO mezclan ambos en una estructura archivos/dispositivos
combinada. En este caso, los dispositivos de E/S se identifican con nombres especiales.
Mantenimiento de información
Muchos SO poseen llamadas al solo efecto de transferir información entre programas de
usuario y el SO. Por ejemplo tendremos llamadas al sistema para obtener la información
de la hora y fecha.
* Process Control
o End, Abort
o Load, Execute
o Create Process, Terminate Process
o Get Process Attributes, Set Process Attributes
o Wait for Time
o Wait Event, Signal Event

* File Manipulation
o Create File, Delete File
o Open, Close
o Read, Write, Reposition
o Get File Attributes, Set File Attributes

* Device Manipulation
o Request Device, Release Device
o Read, Write, Reposition
o Get Device Attributes, Set Device Attributes

* Information Maintenance
o Get Time or Date, Set Time or Date
o Get System Data, Set System Data
o Get Process, File, or Device Attributes, Set Process, File, or Device Attributes

Figure 2. 1 Types of system calls

Otras llamadas darán información de la versión de SO en uso, número de usuarios
activos, cantidad de disco libre etc. Adicionalmente, como el SO guarda mucha
información sobre el uso del sistema, tendremos llamadas para acceder a dicha
información.
2.2.2. Implementación de Llamadas al Sistema
Las llamadas al sistema se realizan de diversas formas de acuerdo a cada arquitectura de
equipo. En una IBM 360/370 existe una llamada al sistema especial que hace un trap
directamente al SO. Los 8 bits menos significativos son un número que identifica el tipo
de llamada. El CP/M no posee una instrucción de llamada al sistema especial: se carga en
el registro C el número de función y se realiza un salto a la dirección 5 de memoria.
A menudo se necesita pasar al SO información adicional al tipo de llamada al sistema.
Por ejemplo, para leer una imagen de entrada en tarjetas debemos especificar el archivo o
dispositivo a usar y la dirección y longitud del buffer de memoria del cual será leído.
El dispositivo o archivo puede ya estar implícito en la llamada al sistema y como las
tarjetas tienen siempre 80 caracteres, podría no ser necesario el dato de longitud.
Dos métodos generales son usados para pasar parámetros al SO, el más simple es a
través de registros, y el otro, a través de bloques o tabla en memoria.

Sistemas Operativos - I.S.I. Servicios del Sistema Operativo - Página 4 Prof. Exp. Mario R. Iribas
 X
Registro
X:parám. p/call

load address X Usar parámetros de código

SVC 13 la tabla X para
SVC 13

Programa del Usuario

Sistema Operativo

Figura 2.2 Pasaje de Parámetros como una tabla

Las llamadas al sistema están disponibles generalmente en assembler. La mayoría de los
sistemas permiten realizar llamadas al sistema desde lenguajes de alto nivel (Pascal,
Fortran, etc.), en los cuales una llamada realmente involucra funciones predefinidas o
llamadas a subrutinas. Ellas pueden generar una llamada a una rutina especial de
ejecución que realiza una llamada o varias al sistema.
Algunos lenguajes como el C se han definido de forma tal de reemplazar el assembler por
instrucciones de alto nivel, permitiendo que las llamadas sean accedidas directamente.
Un ejemplo de cómo se usan las llamadas al sistema es considerar escribir un programa
que lea datos de un archivo y los copie a otro.
1) El programa necesita primeramente los nombres de los 2 archivos: el de entrada y el
de salida. Esto puede especificarse de 2 formas: que el programa pregunte al usuario los
nombres, el cual en un sistema interactivo requiere un secuencia de llamadas al sistema,
primero para escribir la pregunta en la pantalla y luego para leer lo que se contesta vía
teclado; en un sistema batch se especifican los nombres con tarjetas de control, en el cual
debe haber un mecanismo para pasar estos nombres al programa.
2) Luego se debe abrir el archivo de entrada y crear el de salida. Cada una de estas
operaciones requiere llamadas al sistema. Debe también preverse errores como la no
existencia del archivo de entrada o la existencia de protección de acceso al mismo.
(Se necesitan llamadas al sistema para manejar cada situación).
3) Una vez abiertos los archivos, se entra en un loop de lectura que lee el archivo de
entrada (una llamada al sistema) y escribe sobre el de salida (otra llamada al sistema).
Cada una de estas operaciones debe retornar información sobre posibles errores.
(Lectura: fin de archivo, error de paridad en la lectura; Escritura: sin espacio en disco, fin
de cinta físico, impresora sin papel.
4) Luego de copiar todo el archivo, el programa debe cerrar los mismos (otra llamada al
sistema), escribir un mensaje en la consola (otra llamada) y terminar normalmente
Como vemos, los programas hacen uso intensivo de los servicios del SO: toda
interacción entre el programa y su ambiente de trabajo lo realizan a través de pedidos al
SO. Sin embargo los usuarios, normalmente no alcanzan a ver estos detalles, ya que
todas las llamadas se realizan al momento de compilación.
2.2.3. Programas del Sistema
Otro aspecto importante de SO modernos es la colección de programas del sistema
disponibles, que pueden dividirse en varias categorías:

Sistemas Operativos - I.S.I. Servicios del Sistema Operativo - Página 5 Prof. Exp. Mario R. Iribas
* Manejo de archivos: estos programas crean, borran, copian, renombran,
imprimen, listan y generalmente manejan archivos y directorios
* Información de estados: simplemente preguntan al SO por fecha, hora, espacio en
disco disponible, número de usuarios, etc. Luego esta información es presentada en papel
o sobre pantalla.
* Modificación de archivos: se dispone de varios editores de textos para crear y
modificar archivos grabados en disco.
* Soporte de lenguajes de programación: Compiladores, ensambladores e intérpretes.
* Ejecución y carga de programas: una vez compilado y ensamblado un programa
debe cargarse en memoria para su ejecución. El sistema debe proveer de cargadores
absolutos y reubicables, link-editores y cargadores de overlays. También se necesitan
depuradores de lenguajes.
* Programas de aplicación: Programas que resuelven problemas particulares tales
como paquetes para graficación, análisis estadístico, bases de datos, etc. Quizás el
programa más importante de un SO es su INTERPRETE DE COMANDOS, que se
inicia en un sistema de tiempo compartido, al ingresar el usuario a la terminal. Los
comandos son los equivalentes a las tarjetas de control de un sistema batch.
A este programa se lo conoce con varios nombres de acuerdo al sistema: 1) Intérprete de
tarjetas de control; 2) Intérprete de líneas de comando (CLI); 3 Procesador de comandos
de consola (en CP/M) y 4) Shell (en Unix). Su función es muy simple: tome el próximo
comando y ejecútelo. Muchos de estos comandos manejan archivos: crear, borrar, listar,
imprimir, copiar, ejecutar, etc.
Existen 2 maneras de implementar estos comandos:
1) El programa CLI contiene el código para ejecutar estos comandos: ante un
comando, el programa salta a la dirección del mismo dentro del programa que toma los
parámetros necesarios y hace las llamadas al sistema para su ejecución. Aquí el número
de comandos determina la longitud del programa, y que cada comando requiere su
propio código.
2) Cada comando es un programa separadamente: En este caso el CLI no entiende el
comando directamente, sino que usa el nombre del comando para buscar un archivo con
ese nombre, lo carga en memoria y lo ejecuta. Así el comando BORRA PEPE, buscará
un archivo BORRAR, lo carga en memoria pasándole el parámetro PEPE. Aquí el CLI
propiamente dicho es bastante chico y el agregado de nuevos comandos es fácil de
implementar, pues es el agregado de nuevos archivos solamente. Pero como
contrapartida, el diseño del programa CLI es más complicado ya que debe existir un
mecanismo para pasar parámetros del CLI al programa que ejecuta el comando, lo que
en algunos casos puede acarrear problemas especialmente si ambos no se encuentran en
memoria simultáneamente.
Otro problema de esta solución es que la interpretación de parámetros la fija totalmente
el programador de los programas de comando, pudiendo surgir inconsistencia en el uso
de parámetros para los mismos usuarios, si los programas de comandos fueron escritos
por distintos programadores.
Lo que el usuario ve del SO es entonces sus programas de comandos y no la
llamadas al SO.

Sistemas Operativos - I.S.I. Servicios del Sistema Operativo - Página 6 Prof. Exp. Mario R. Iribas
2.3. EL PUNTO DE VISTA DEL SO
El usuario, entonces, ve del SO solo los programas de comandos, especialmente el CLI.
Desde el punto de vista opuesto, el diseñador del SO ve al mismo como un conjunto de
recursos físicos y dispositivos y debe convertirlos en disponibilidades lógicas para el
usuario. Veamos como se estructura un SO. El SO consiste en programas que son
manejados por EVENTOS. Si no hay programa para ejecutar ni dispositivos de E/S
sirviendo pedidos ni usuarios para responder, el SO no realiza ninguna acción: queda
esperando plácidamente que algo ocurra.
Los eventos casi siempre están producidos por interrupciones o traps. Por lo tanto un
SO está manejado por interrupciones. Esta naturaleza (manejo por interrupciones) del
SO define su estructura interna. Cuando ocurre una interrupción, el hardware transfiere
el control al SO. Primeramente, el SO salva los registros y el contador de programa;
luego determina el tipo de interrupción arribada, que puede ser:
* Una llamada al sistema
* Una interrupción de un dispositivo de E/S
* Un error de programa
Para cada tipo de interrupción, un segmento separado de código del SO determinará la
acción a tomar.
2.3.1. Llamadas al Sistema
Las llamadas se clasifican de acuerdo a su tipo. Cada una tiene su propio segmento de
código para implementarla. Podemos considerar los siguientes tipos:
* Terminación normal: si se realiza una llamada de terminación normal de un
programa, el SO debe transferir el control al CLI. Este lee el próximo comando y toma la
acción adecuada.
* Terminación anormal: Un programa que encuentre un error en su ejecución o en sus
datos de entrada y decide terminar anormalmente, puede necesitar un vuelco de memoria
y el envío de un mensaje de error. Luego se llama al CLI. En un sistema interactivo, el
CLI simplemente continúa ejecutando el próximo comando. En un sistema batch, el SO
termina el trabajo totalmente y continúa con el próximo.
* Pedidos de estado: Este tipo de llamadas simplemente preguntan al SO por
determinada información: fecha, atributos de archivos, estados de recursos. Se computa
esa información solicitada y continua la ejecución del programa.
* Pedido de recursos: Un programa en ejecución puede necesitar un recurso para poder
continuar, por ejemplo más memoria, cinta, acceso a archivos, etc. Si los recursos están
disponibles, el SO los otorga y el control vuelve al usuario; de lo contrario el programa
debe esperar hasta que logre los recursos necesarios.
* Pedidos de E/S: El mayor número de pedidos serán de este tipo, ya que la mayoría de
los programas requerirán lectura o grabación de archivos durante s ejecución.
2.3.2. Interrupciones de E/S
Es una categoría importante de interrupciones que un SO debe manejar. Un dispositivo
de E/S produce una interrupción cuando ha terminado un pedido de E/S.
Esto se produce, en general, como consecuencia del pedido de E/S de un usuario (vía
una llamada al sistema). Una vez comenzada la operación de E/S existen cursos de
acción: en el caso más simple, se comienza un pedido de E/S y se espera la terminación

Sistemas Operativos - I.S.I. Servicios del Sistema Operativo - Página 7 Prof. Exp. Mario R. Iribas
antes de retornar el control al usuario; la otra posibilidad es devolver el control al usuario
antes de completada la operación de E/S. La espera de la terminación de una operación
de E/S puede realizarse a su vez de 2 formas: máquinas como la IBM 370 y PDP-11
poseen una instrucción especial WAIT, que para la cpu hasta la próxima interrupción.
Los equipos que no poseen esta instrucción entrarán en un loop de espera por programa,
que continuará hasta que llegue la interrupción, transfiriendo control a otra parte del SO.
La primera solución parece mejor pues evita trabajo inútil de cpu, acceso a memoria, etc.
Una ventaja de esperar la terminación de la operación de E/S es que siempre tendrá solo
una operación de E/S ejecutándose al mismo tiempo y así cuando llega la interrupción el
SO ya conoce de qué dispositivo proviene. Sin embargo esta solución limita severamente
la cantidad de operaciones simultánea de E/S que pueden realizarse
Una alternativa es retornar el control al usuario inmediatamente después del comienzo de
una operación de E/S. Necesitamos una nueva llamada al sistema para permitir al usuario
que espera por la terminación de la operación de E/S. También necesitamos saber todas
las operaciones de E/S que se están ejecutando simultáneamente. Para esto el SO tiene
una tabla con una entrada por cada dispositivo de E/S: la tabla de estado de dispositivos.
Device: Card RDR #1
Status: Idle Request for Line
Device: Line PRT #3 Printer
Status: Busy Address: 38546
Device: Disk Unit #1
Status: Idle
Device: Disk Unit #2
Status: Idle
Device: Disk Unit #3 Request for Disk Request for Disk
Status: Busy Unit #3 Unit #3
File: xxx File: yyy
Operation: Read Operation: Write
Address: 43046 Address: 03458

Figura 2.3 Tabla de estado de dispositivos

Cada entrada de la tabla indica el tipo de dispositivo, su dirección y su estado (sin
funcionar, ocioso, ocupado). Si el dispositivo esta ocupado, ante un pedido, este se
almacena junto a algunos parámetros en la entrada a la tabla para ese dispositivo. Ya que
un programa puede emitir varios pedidos a un mismo dispositivo, tendremos una lista de
pedidos pendientes en espera. Así ademas el SO debe tener una tabla para cada
dispositivo con los pedidos.
2.3.3. Errores de Programa
Es el tercer tipo de interrupciones, tales como intento de ejecutar alguna instrucción
privilegiada, referencia a dirección de memoria ilegal, etc., que causan un trap al SO, que
actúa igual que una interrupción. Se despliega un mensaje de error y la terminación del
programa. En sistemas batch, el vuelco de memoria se imprime; en sistemas interactivos
ese vuelco se graba en un archivo.
2.3.4. DIAGRAMA GENERAL
La figura muestra el diagrama de flujo de un SO. Este diagrama es una simplificación de
lo que realmente sucede en la práctica.
Ahora podemos identificar algunas partes comunes que conforman un SO.

Sistemas Operativos - I.S.I. Servicios del Sistema Operativo - Página 8 Prof. Exp. Mario R. Iribas
 Interrupción

Salvar Registros

¿Qué Clase?

End Error Requer. no de E/S Requerim. de E/S Finaliz. de E/S

Próx. Job Dump Hacerlo Inicio de Requerim.

o comando
Marca Listo

Retorno
Wait

Retorno al Usuario

Figura 2.4 Flujo General de un Sistema Operativo

Un SO tendrá drivers de dispositivos, un administrador de interrupciones, un

conjunto de rutinas de llamadas al sistema y un intérprete de lineas de comando.
Otra parte importante es el sistema de archivos. Estos elementos ya son
suficientes para definir un SO. Por ejemplo el CP/M, tiene el BIOS (driver de
dispositivos), BDOS (sistema de archivos) y un interprete de comandos (CCP).
Muchos SO tendrán funciones adicionales y por ende estructuras mucho más
complejas, como veremos más adelante.

BIOS device drivers

BDOS file system

CCP console command interpreter

Usuario user or system program

Figura 2.5 Estructura del Sistema Operativo

CP/M

Sistemas Operativos - I.S.I. Servicios del Sistema Operativo - Página 9 Prof. Exp. Mario R. Iribas