Apunte So

Sistemas Operativos
Apuntes, Cdigos y Ejercicios o

(borrador)
Esteban De La Fuente Rubio esteban@delaf.cl 21 de abril de 2012
Resumen Este documente tiene por objetivo servir como gu para quin se esta introduciendo a e en conceptos relacionados al area de Sistemas Operativos, cubriendo aspectos tericos y o prcticos comnmente analizados en esta area. Al ir avanzando en el documento el lector a u obtendr conocimiento en las areas de gestin de procesos, memoria principal y secundaria a o principalmente. Se agradecer enviar un correo electrnico al autor, esteban@delaf.cl, en caso de cualquier a o sugerencia sobre el contenido, reporte de errores o solicitud de algn tema que haya sido u omitido o no cubierto en la profundidad esperada para futuras versiones del documento. Denicin RAE o Sistema Operativo: programa o conjunto de programas que efectan la gestin de los u o procesos bsicos de un sistema informtico, y permite la normal ejecucin del resto de las a a o operaciones. Licencia de uso Copyright (C) 2012 Esteban De la Fuente Rubio. Se autoriza la copia, distribucin o modicacin de este documento bajo los trminos de o o e la versin 1.3 o posteriores de la Licencia de documentacin libre de GNU (GFDL, ver o o http://www.gnu.org/copyleft/fdl.html ), publicada por la Fundacin para el Software Libre; o sin secciones invariantes (invariant sections), ni textos de portada (front-cover texts), ni textos de contraportada (back-cover texts).
21 de abril de 2012
pg. 2 a
Indice general
1. Introduccin o 1.1. Visin general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 1.2. Objetivos del sistema operativo . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1. Objetivos del usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2. Objetivos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Servicios ofrecidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1. Gestin de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 1.3.2. Gestin de memoria principal . . . . . . . . . . . . . . . . . . . . . . o 1.3.3. Gestin de memoria secundaria . . . . . . . . . . . . . . . . . . . . . o 2. Historia 2.1. Tipos de sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. Erase una vez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2. Sistemas por lotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3. Sistemas de operacin oine o . . . . . . . . . . . . . . . . . . . . . . 7 8 11 11 12 12 12 13 13 15 15 15 16 17 19 19 20 21 21
2.1.4. Sistemas con buering . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5. Sistemas de operacin online o . . . . . . . . . . . . . . . . . . . . . .
2.1.6. Sistemas multiprogramados . . . . . . . . . . . . . . . . . . . . . . . 2.1.7. Mquinas o procesadores virtuales . . . . . . . . . . . . . . . . . . . . a 2.1.8. Sistemas de tiempo compartido . . . . . . . . . . . . . . . . . . . . . 3
INDICE GENERAL 2.1.9. Computadores personales
INDICE GENERAL . . . . . . . . . . . . . . . . . . . . . . . . 22 23 23 23 24 24 25 25 26 26 27 29 30 30 31 33 33 36 38 38 39 41 41 42 43 43 44
2.1.10. Redes de computadores personales . . . . . . . . . . . . . . . . . . . 2.1.11. Sistemas en tiempo real . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.12. Sistemas distribu dos . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.13. Sistemas multiprocesadores . . . . . . . . . . . . . . . . . . . . . . . 2.2. Tendencias ultimas dos dcadas . . . . . . . . . . . . . . . . . . . . . . . . . e 2.3. Logros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. Procesos y memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. Seguridad y proteccin . . . . . . . . . . . . . . . . . . . . . . . . . . o 2.3.3. Gestin de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 2.3.4. Estructura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Estructura y dise o n 3.1. Interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2. GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. API y llamadas al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Tipos de llamadas al sistema . . . . . . . . . . . . . . . . . . . . . . . 3.3. Diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . n 3.3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2. Pol ticas y mecanismos . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3. Requerimientos para proteccin de procesos . . . . . . . . . . . . . . o 3.4. Estructura del sistema operativo . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1. Estructura simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2. Estructura en niveles . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3. Microkernels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.4. Mdulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 3.5. Implementacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 21 de abril de 2012
pg. 4 a
INDICE GENERAL 4. Procesos
INDICE GENERAL 47 47 49 50 51 52 56 57 57 58 61 64 67 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 68 68 71 72 76 76 77 77 78 81 82 83 83
4.1. Distribucin de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.2. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1. Atributos del proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2. Cambios de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. Clasicacin de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.4.1. Procesos preemptive y non-preemptive . . . . . . . . . . . . . . . . . 4.5. Paralelismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1. Data races . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.3. Starvation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Sincronizacin o 5.1. Busy-waiting
5.2. Problemas clsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 5.2.1. Productor consumidor . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2. Cena de lsofos chinos o . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3. Lector / escritor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. Semforos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 5.3.1. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2. Modo de operacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 5.3.3. Problema productor consumidor . . . . . . . . . . . . . . . . . . . . . 5.3.4. Problema lsofos chinos . . . . . . . . . . . . . . . . . . . . . . . . . o 5.4. Monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2. Problema productor consumidor . . . . . . . . . . . . . . . . . . . . . 5.4.3. Problema lsofos chinos . . . . . . . . . . . . . . . . . . . . . . . . . o 21 de abril de 2012
pg. 5 a
INDICE GENERAL
INDICE GENERAL 83 83 84 84 84 84 85 85 87 89 91 93 95 97 98 98
5.4.4. Problema lectores escritores . . . . . . . . . . . . . . . . . . . . . . . 5.5. Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1. Exclusin mutua con mensajes . . . . . . . . . . . . . . . . . . . . . . o 5.5.2. Implementacin de semforos a partir de mensajes . . . . . . . . . . . o a 5.5.3. Problema lectores escritores . . . . . . . . . . . . . . . . . . . . . . . 5.6. Monitores de Hoare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Planicacin en monoprocesadores o 6.1. Planicacin en Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 7. Memoria principal 8. Memoria secundaria 9. Proteccin y seguridad o 10.Mdulos en Linux o A. Mquinas virtuales a B. nSystem B.1. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.1.1. Creacin de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
21 de abril de 2012
pg. 6 a
Cap tulo 1 Introduccin o

El Sistema Operativo (Operating System, OS ) corresponde a un programa en ejecucin o que se encarga de actuar como intermediario entre el usuario y la mquina. Sus dos principales a objetivos corresponden a la administracin del hardware y a ser una interfaz para el o usuario, de tal forma que este pueda interactuar con la mquina. a El sistema operativo deber proveer entonces de un ambiente para ejecutar los programas a del usuario, siendo este el unico con privilegios de acceso directo al hardware y los procesos debern mediante el OS acceder a los recursos disponibles. a Los principales requisitos que se le piden al sistema operativo corresponden a lo relacionado con ser cmodo en cuanto a su interfaz y eciente de tal forma que el OS no utilice o todos los recursos de la mquina dejndolos libres para los procesos de los usuarios. a a Al estudiar la historia de los sistemas operativos se podr apreciar como estos han ido a evolucionando en el tiempo. Se ver que inicialmente no exist un sistema operativo como a a tal, sino que el hardware era programado directamente recibiendo los trabajos (jobs) que los usuarios deseaban ejecutar. Ms adelante, cuando ya aparece el concepto de un programa que a administra la mquina, nos daremos cuenta que el mismo siempre se encuentra cargado a en memoria principal. 7
1.1. VISION GENERAL
CAP ITULO 1. INTRODUCCION
1.1.
Visin general o
En la gura 1.1 se puede apreciar una visin global del sistema operativo, en esta se o muestran las principales partes que se vern en el sistema. A continuacin se describir cada a o a uno de estos componentes y como es la interaccin que estos tienen entre s o . Hardware: recursos disponibles en la mquina, veremos que tambin podrn ser disa e a positivos virtuales, por estos los procesos competirn y desearn su uso. a a Drivers: cdigo que permite el uso del hardware (o dispositivo virtual) al que estn o a asociados. N cleo: componente principal del sistema operativo, es el intermediario entre aplicau ciones y el hardware, se encarga de las tareas de administracin de la mquina. o a Llamadas al sistema: es la forma en que una aplicacin hace alguna solicitud a un o servicio del sistema operativo, generalmente con acceso privilegiado por lo cual son accedidas mediante una API. API: corresponde a una interfaz que pueden utilizar las aplicaciones para interactuar con el sistema operativo, las llamadas al sistema y eventualmente el hardware disponible, algunas ventajas de esto son la abstraccin y el escribir menos cdigo. o o Utilitarios: aquellas aplicaciones que vienen inclu das con el sistema operativo al momento de realizar la instalacin, sin embargo esto depender mucho del sistema operao a tivo propiamente tal y del contexto en que cada uno se instala. Aplicaciones: corresponden al software til que le interesa ejecutar al usuario. u Usuario: usuario del equipo que esta interesado en ejecutar sus aplicaciones. Al existir solicitudes por parte de las aplicaciones hacia la API, esta generar interrupa ciones que mediante el ncleo, y este a su vez utilizando los drivers, acceder al hardware. u a 21 de abril de 2012 pg. 8 a
1.1. VISION GENERAL
Aplicaciones
Aplicaciones
Aplicaciones Utilitarios
Utilitarios
API
Llamadas al sistema
Utilitarios
Ncleo
Drivers Drivers
Disco
Pantalla
Figura 1.1: Visin global del Sistema Operativo o
21 de abril de 2012
pg. 9 a
1.1. VISION GENERAL
En la gura 1.1 se observa una l nea divisora entre los componentes superiores (Aplicaciones, Utilitarios y API) y la parte inferior (Llamadas al sistema, Ncleo, Drivers y Hardu ware). Esta divisin corresponde a la separacin de privilegios necesarios para ser utilizadas. o o Si bien una aplicacin podr acceder directamente a una llamada a sistema o al hardware o a (en Unix todo es un archivo, incluso el hardware) deber tener los permisos adecuados para a hacerlo. Se hablar ms al respecto ms adelante en el cap a a a tulo 3.
Una caracter stica importante del sistema operativo, como ya se mencion antes, es que o es el unico proceso que necesariamente debe estar siempre cargado en memoria principal. Lo anterior implicar que todo el cdigo del sistema operativo, incluyendo sus drivers debern a o a estar cargados siempre en RAM. Imagine que desea tener soporte para todos los tipos de impresoras disponibles, esto implicar tener cargado todos los drivers en la memoria principal a por si en algn momento usted la conecta. Son parte de la estructura del sistema operativo u y su diseo la consideracin de diferentes mtodos de construccin del ncleo del sistema n o e o u operativo, la que permita cargar por partes el mismo, sin tener que tener cargado todo el cdigo que eventualmente se pueda requerir en la memoria. Una de estas alternativas es lo o que se utiliza en Linux correspondiente al uso de de mdulos donde el ncleo los levanta a o u medida que los requiere. De esto tambin se hablar ms en el cap e a a tulo 10.
Si bien los recursos con que se cuenta hoy en d son muy superiores a los que se contaban a cuando comenzaron los sistemas operativos, como se comentar en el cap a tulo 2, tenga en cuenta que la teor de sistemas operativos sigue siendo la misma. Existen avances en teca nolog pero lo que se abordar en este documento corresponde a lo tradicional relacionado as, a con sistemas operativos. Por lo cual si usted no considera problema tener cargado 5, 15, 30 o 200 MB de ncleo RAM, recuerde que hace unos aos los equipos no ten las mismas u n an capacidades y hace dcadas eran impensables. e 21 de abril de 2012 pg. 10 a
1.2. OBJETIVOS DEL SISTEMA OPERATIVO
1.2.
Objetivos del sistema operativo
El sistema operativo debe preocuparse de cumplir diferentes objetivos, estos se pueden dividir, segn el interesado, en objetivos del usuario y objetivos del sistema. u
1.2.1.
Objetivos del usuario
Los usuarios nales en general no desean preocuparse por que tipo de hardware estn a utilizando. Un usuario que quiere guardar una fotograf en su computador no le interesa a saber en que disco se esta guardando, de que tipo es el disco (IDE o Sata) o que tipo de sistema de archivos contiene (ext3, reiserfs o xfs), al usuario le interesa guardar la fotograf a. El objetivo esperado por los desarrolladores tendr que ver con hacer fcil el desarrollo de a a aplicaciones sobre el sistema operativo, sin tener que, el programador de la aplicacin, tener o que llegar a trabajar con lenguaje de bajo nivel o instrucciones privilegiadas para acceder al hardware de la mquina. a Servicios que sern de inters para los usuarios: a e Creacin de programas: herramientas para realizar las tareas de desarrollo de aplio caciones para el sistema operativo. Ejecucin de programas: administracin de los procesos que se ejecutan en el siso o tema. Acceso a los dispositivos de E/S: simplicacin de las tareas de uso del hardware, o tales como escribir en una pantalla o leer datos desde el teclado. Almacenamiento: administracin de los discos, la bsqueda de informacin en estos, o u o su formato y gestin en general. o Memoria: administracin del uso de memoria principal disponible, as como la asigo nacin de memoria virtual de ser necesario. o 21 de abril de 2012 pg. 11 a
1.3. SERVICIOS OFRECIDOS
Deteccin y respuesta contra errores: que sea capaz de detectar y proteger al o sistema frente a eventuales anomal as. Estad sticas: llevar una recopilacin con informacin sobre el uso de los recursos y o o parmetros generales sobre el sistema. a
1.2.2.
Objetivos del sistema
Desde el punto de vista del sistema la principal preocupacin es el realizar una adminiso tracin eciente y justa de los recursos de la mquina. Esto signica que todos sean atendidos o a en algn momento de tal forma que se les permita realizar sus operaciones de forma satisfacu toria. El sistema operativo ser el encargado de determinar cuando y quin utilizar cierto a e a recurso del sistema, tal como el procesador, la memoria principal, disco duro, etc. Y ser el a encargado de interrumpir al proceso que haga uso del recurso de tal manera de entregrselo a a otro que tambin lo quiera utilizar. e
1.3.
Servicios ofrecidos
Histricamente se estudian principalmente tres areas de la gestin realizada por el sistema o o operativo, aquellas relacionadas con los procesos, memoria principal y secundaria. Adicionalmente se vern en el curso otros aspectos como proteccin y seguridad. a o
1.3.1.
Gestin de procesos o
Un proceso corresponde a un programa en ejecucin, el cual posee diferentes estado a lo o largo de su vida como proceso. Principalmente interesan los estados listos y ejecucin, que o corresponden a la espera antes de ser planicado para entrar a la CPU y el de ejecucin de o cdigo dentro de la CPU. Existen otros estados que sern vistos en detalle en el cap o a tulo 4. 21 de abril de 2012 pg. 12 a
Todo proceso requerir hacer uso de, al menos, memoria principal y CPU para su ejea cucin, por lo cual el sistema operativo deber ser capaz de asignar estos recursos de una o a forma eciente y justa, de tal forma que todos los procesos sean servidos segn los vayan u requiriendo. Se estudiarn problemas que ocurren por la ejecucin de mltiples procesos al mismo tiema o u po, concepto conocido como concurrencia, la forma de solucionarlo mediante sincronizacin, o y algoritmos de planicacin que permitirn elegir que proceso deber entrar a al cpu. o a a
1.3.2.
Gestin de memoria principal o
Todo proceso requerir del uso de memoria principal para su ejecucin, en este espacio de a o memoria se encontrar no solo el cdigo del programa, sino tambin sus datos y su contexto. El a o e sistema operativo deber asignar, de algn modo, espacios de memoria para que el proceso los a u utilice, y si eventualmente el proceso requiere ms espacio poder cumplir con su requerimiento. a Qu sucede si no disponemos de ms memoria principal? La primera idea, ser decir que e a a no podemos iniciar ms procesos, lo cual ser cierto, sin embargo se discutir el mtodo de a a a e memoria virtual el cual permite utilizar un dispositivo de memoria secundaria para obtener memoria para los procesos.
1.3.3.
Gestin de memoria secundaria o
El sistema operativo debe ser capaz de almacenar datos en medios de memoria secundaria, la cual ser permanente, a diferencia de la memoria principal que es voltil. Se deber prea a a ocupar de la mantencin de una estructura de archivos y de poder realizar operaciones sobre o esta estructura de tal forma que las aplicaciones no se preocupen de escribir fsicamente el archivo que desean guardar en el disco.
21 de abril de 2012
pg. 13 a
21 de abril de 2012
pg. 14 a
Cap tulo 2 Historia

Los sistemas operativos han evolucionado enormemente desde sus inicios, durante este cap tulo se mencionarn aspectos relacionados con los diferentes tipos de sistemas operativos a existentes o que han existido junto a lo que se ha logrado a lo largo de los aos n
2.1.
2.1.1.
Tipos de sistemas
Erase una vez
Cuando se comenzaron a utilizar grandes mquinas para realizar cmputos no exist un a o a sistema operativo propiamente tal, solo hab hardware y las aplicaciones (trabajos o jobs) a de los usuarios. Se le el programa a ejecutar y se ejecutaban sus instrucciones de manera a secuencial. Las aplicaciones en esta poca deb incluir todo el cdigo, incluyendo aquel para manejar e an o cada uno de los dispositivos de hardware que la mquina tiene disponible. Se debe acceder a directamente al espacio de direcciones, tanto de memoria principal como memoria secundaria. No existe estructura de directorios ni archivos en la memoria. Si se desea ejecutar una nueva aplicacin, se debe cargar el nuevo trabajo y la mquina o a 15
2.1. TIPOS DE SISTEMAS
CAP ITULO 2. HISTORIA
debe ser reiniciada. La depuracin de la aplicacin se realiza de forma presencial, observando o o las salidas indicadas mediante las luces del computador. El equipo es utilizado solo por un usuario al mismo tiempo y por un per odo largo de tiempo para realizar todas las tareas involucradas. El principal problema de esta etapa es el bajo uso del hardware disponible, donde existe mucho tiempo que no es utilizado en cmputo. Siendo que el componente caro es el hardware o y no el programador se debe buscar una solucin a este problema. o A pesar de lo anterior, y lo rudimentario que podr parecer frente a los computadores a que actualmente existen, estas mquinas eran capaces de procesar clculos mucho ms rpido a a a a que un gran nmero de calculistas trabajando en conjunto. u
2.1.2.
Sistemas por lotes
En un sistema operativo por lotes se requiere que todos los componentes del programa, ya sea el mismo cdigo del programa, los datos y las llamadas al sistema que permiten usar o el hardware sean introducidos, comnmente, mediante tarjetas perforadas, ver gura 2.1, de u 80 caracteres cada una. Este conjunto de instrucciones es conocido como un trabajo o un job, el cual pose poca o ninguna interaccin con el usuario. a o Este tipo de sistemas operativos era util con programas que fuesen largos y sin interaccin o con el usuario. Donde un operador recib los trabajos de los programadores y los introduc a a en la mquina, estos eran procesados en orden FIFO, o sea el primer trabajo que llegaba era a el primero que se procesaba. La planicacin del procesador y administracin de la memoria es simple, en el primer caso o o bastaba pasar el control del mismo al job y que este lo devolviera al terminar su ejecucin. o En el caso de la memoria tambin la administracin era simple, ya que el espacio se divid e o a en dos partes, una para el monitor residente (el sistema operativo) y otra para el trabajo en ejecucin. o Al aparecer el monitor residente, tambin aparece el concepto de API, donde el prograe 21 de abril de 2012 pg. 16 a
Figura 2.1: Tarjetas de un sistema por lotes mador ya no deb escribir todas las instrucciones para acceder al hardware, sino que se le a entregaba ya una herramienta para facilitar su trabajo. Si ocurr algn error durante la ejecucin del trabajo se entregaba al programador un a u o dump de la memoria, de tal forma que este pudiera corregir el error en el programa y volver a entregar un conjunto de tarjetas para su ejecucin. Esto evitaba que el programador tuviese o que estar frente al computador para depurar su cdigo. o A pesar de que el computador se encontraba ms tiempo ocupado, porque siempre que a hubiesen tarjetas se estar procesando, su componente ms costosa, la CPU, que es ms an a a rpida comparada con los dispositivos de entrada o salida de datos, no se encontraba necea sariamente ocupada todo el tiempo. Las tareas de lectura y escritura son bloqueantes y mantienen a la CPU en un ciclo de busy-waiting.
2.1.3.
Sistemas de operacin oine o
La idea principal tras las operaciones fuera de l nea, o oine, corresponde a la lectura y escritura de los elementos utilizados en los sistemas operativos por lotes, o sea las tarjetas, en forma externa al computador principal. Lo anterior buscaba no utilizar en tareas lentas, 21 de abril de 2012 pg. 17 a
leer tarjetas, el procesador ms caro disponible, sino utilizar otras unidades que traspasaban a las tarjetas perforadas a cintas y luego estas cintas eran cargadas en la mquina principal. a Anlogamente a lo explicado, la salida del computador principal era generada en cintas a magnticas, las cuales en una etapa posterior a la ejecucin del programa eran llevadas a un e o equipo de impresin donde se obten una salida que se le entregaba al programador. o a Con este sistema fuera de l nea, se lograba un mejor rendimiento del procesador principal, utilizndolo para tareas de cmputo y dejando las tareas de lectura y escritura a otros equipos a o ms econmicos. a o La cantidad de mquinas perifricas utilizadas depender de la capacidad del procesador, a e a o sea, mientras existiera tiempo de CPU sin uso, se pod seguir agregando cintas al coman putador principal. Una vez el tiempo de CPU ya hab alcanzado su uso constante, no ten a a sentido agregar ms impresoras (o lectoras) ya que no se generar ms cintas para imprimir a an a por unidad de tiempo. El trabajo solo entrega el control del sistema al monitor residente en caso de trmino, que e se requiera algn servicios de entrada o salida o en caso de error. u A pesar de esta mejora en la velocidad de lectura y escritura, el procesador, mientras se realizan dichas operaciones, contina estando ocioso, sigue existiendo problema de busyu waiting en cintas. Consideremos que para leer una l nea de la cinta se tomaban 80 caracteres (misma cantidad que una tarjeta perforada) y se escrib de a 80 caracteres (en caso de an cintas) y de a 132 caracteres en impresoras. El leer una l nea implicaba hacer girar la cinta, lo cual generaba inercia en la cinta y hac que hubiese que ajustarla (retrocediendo) para a leer la prxima l o nea en el futuro. Adicionalmente exist un mayor tiempo para los programadores, que deb esperar que a an sus programas fueran traspasados a cinta, ejecutados, luego los resultados traspasados a cinta e impresos. 21 de abril de 2012 pg. 18 a
2.1.4.
Sistemas con buering
Para ayudar a solucionar el problema de leer l nea a l nea las instrucciones de una cinta se empezaron a leer de a 10 l neas, o sea de a 800 caracteres, lo cual permit disminuir a los tiempo de lectura. En vez de leer de a una l nea, se le 10 considerando que en algn an u momento futuro esas l neas podr ser utilizadas, las l an neas le das eran guardadas en un buer a la espera de ser solicitadas. Por lo tanto cuando eventualmente el trabajo requer a una l nea, esta era le desde el buer y no desde la cinta, reduciendo los tiempos. da De la misma forma para escribir en la cinta, se guardaba en un buer lo que se quisiera escribir, una vez lleno este buer se escrib todo en la cinta de una vez. a Mediante el uso de canales, uno para la lectura y otro para la escritura, se pod conseguir an mejoras en los tiempos y rendimiento de la CPU. Ya que la tarea de leer y llevar al buer o sacar del buer y escribir la realizaban los canales propiamente tal, y la CPU no era necesaria durante toda la operacin de E/S, con lo que la misma pod ser utilizada para tareas de o a cmputo. o El rendimiento de esta tcnica depender bsicamente de si el proceso es intensivo en e a a CPU, en E/S o es igual en ambos casos. A pesar de lo anterior el porcentaje de utilizacin o de CPU, gracias al buering y uso de canales aumentar. a El principal problema de esta tcnica sigue siendo el tiempo de espera extra agregado al e tener que leer las tarjetas y cargarlas en cintas y luego las cintas imprimirlas, esto bsicamente a por el transporte de un sistema perifrico al computador principal. e
2.1.5.
Sistemas de operacin online o
En este tipo de sistemas la lectura de tarjetas e impresin de resultados ya no es realizada o en equipos perifricos. Las lectoras e impresoras se conectan directamente al computador e central y hacen uso de los canales de E/S que se agregaron en el sistema oine. Esto fue posible gracias a la aparicin de discos los cuales conten la entrada de los trabajos y o an 21 de abril de 2012 pg. 19 a
2.1. TIPOS DE SISTEMAS almacenaban las salidas de los mismos.
En este tipo de sistemas el monitor residente es quien se encarga de leer tarjetas y dejarlas en el disco y de imprimir los resultados. Para ejecutar un trabajo debe haber sido le do completamente al disco, as mismo para imprimir los resultados de un trabajo este debe haber terminado su ejecucin habiendo dejado la salida en el disco. o Esto mejora el tiempo de proceso de un trabajo, ya que no se deben utilizar lectores o impresoras externas al computador principal, ahorrando tiempo en el traspaso f sico de las mismas de un equipo a otro. El problema sigue siendo la ociosidad del procesador cuando se deben realizar operaciones de entrada o salida.
2.1.6.
Sistemas multiprogramados
El principal problema con un sistema de operacin online es que la CPU no est siendo o a utilizada todo el tiempo, esto a pesar que pueden existir trabajos que pudiesen ser atendidos. Esto es bsicamente porque no se permite la ejecucin de ms de un trabajo en paralelo y a o a se debe esperar a que uno termine para iniciar el otro. En este tipo de sistemas se aprovecha el tiempo de E/S para ejecutar otros trabajos. Durante esta poca (nes de los 60s) aparece el concepto de planicacin de procesos/trabajos e o (o scheduling) y con esto el concepto ya de Sistema Operativo. Ya que varios procesos deben ejecutarse, todos ellos deben estar residentes en memoria principal. La multiprogramacin o implica multiprocesos, o sea programas se ejecutan de forma paralela, ver gura 2.2. Principal problema es la no existencia de un entorno protegido para la ejecucin de los o procesos, si un proceso comet algn error pod botar todo el sistema. a u a 21 de abril de 2012 pg. 20 a
Figura 2.2: Sistemas por lotes vs sistema multiprogramado
2.1.7.
Mquinas o procesadores virtuales a
En este tipo de mquinas, se da soporte para la emulacin de varias mquinas o procea o a sadores a partir de un solo procesador real. Cada mquina virtual entrega al proceso un a entorno protegido, frente a otras mquinas virtuales, de tal forma que lo ejecutado en dicho a entorno solo afecta a esa mquina virtual. a El tiempo de CPU utilizado por cada mquina es una tajada de tiempo del procesador a real. Con esto se logra el mayor rendimiento del computador, utilizando multiprogramacin, o ya que la CPU siempre estar atendiendo a alguien que lo requiera. a El problema aqu comienza a ser la baja productividad de los programadores. Lo tiempos de ejecucin total de un proceso sigue siendo alto, y la depuracin de los trabajos comienza o o a tomar importancia como problema.
2.1.8.
Sistemas de tiempo compartido
Los sistemas de tiempo compartido corresponden a entornos multiprogramados y multiusuario, los cuales entregaban un buen mejor de respuesta. Los usuarios (programadores) pueden trabajar de forma interactiva con los computadores mediante terminales conectadas a ellos. O sea, vuelven a trabajar directamente con el computador, como lo hac en los an inicios, el operador ya no existe. 21 de abril de 2012 pg. 21 a
Cada programador dispone de una terminal con una consola, donde puede realizar una depuracin de forma ms rpida, no debiendo esperar la entrega de los resultados de la o a a ejecucin de su programa. o En un sistema de tiempo compartido los usuarios comparten recursos, por lo cual se debe hacer un reparto equitativo de los mismos y adems contar con sistemas de proteccin para a o ellos. Ahora se habla de sesiones de usuarios y no de trabajos. El problema aqu surge con la cantidad de usuarios y procesos que estos ejecutan, donde el procesador no es capaz de atender a innitos usuarios y el sistema puede ir degradndose a con cada nuevo que entra. Esto ya que el recurso CPU que realiza los cmputos, y el recurso o memoria que se requiere para mantener los procesos en ejecucin son limitados o
2.1.9.
Computadores personales
Gracias al uso de componentes cada vez ms pequeos se logro empezar a comercializar a n microprocesadores, los cuales permit por su bajo costo, que fuesen adquiridos por usuarios an, personales. De esta forma ya no se requer compartir el recurso CPU o memoria con mltiples a u usuarios, sino que cada usuario (o programador) dispon de un equipo dedicado a sus labores. a Originalmente los computadores personales, destinados al uso por parte de un unico usuario, no requer caracter an sticas de sistemas de tiempo compartido. Con esto su diseo n era ms simple y requer menos soporte del hardware para su funcionamiento. Un ejemplo a an de este tipo de sistemas operativos es MS-DOS. Cada usuario posee su propia mquina, sin embargo el compartir datos entre mquinas a a resultaba un proceso complicado. Cada mquina deb tener su propia impresora y/o lectora a a de discos. 21 de abril de 2012 pg. 22 a
2.1.10.
Redes de computadores personales
A mediados de los 80s surgen las redes de computadores personales, bajo esta modalidad los usuarios pod compartir discos e impresoras con otros equipos y de esta forma an economizar en la compra de recursos. Este esquema utiliza uno de los equipos como servidor de disco y/o impresora, y los dems a computadores se conectan v red a este. Los usuarios conectados a estas terminales, ve el a an disco o la impresora como si estuviese conectada en su equipo, esto es conocido comnmente u como terminales tontas. Ya que el sistema operativo utilizado, en realidad un monitor residente, no pose caraca ter sticas de proteccin es que era poco recomendable ejecutar aplicaciones de usuario en el o servidor, ya que la ca de la aplicacin podr botar todo el sistema. da o a Las primeras redes solo permit compartir directorios en modo solo lectura. an
2.1.11.
Sistemas en tiempo real
Este tipo de sistemas corresponde a los utilizados en aplicaciones de tiempo real, donde los tiempos de respuesta a eventos del mundo f sico son cr ticos. Por ejemplo el uso en control de trco o procesos industriales. a Deben poseer tiempo de respuestas muy rpidos, para esto es requisito que los procesos a residan permanentemente en memoria principal. Adicionalmente cualquier interrupcin debe o ser atendida inmediatamente.
2.1.12.
Sistemas distribu dos
Corresponden a un conjunto de estaciones de trabajo o terminales inteligentes conectadas entre s para trabajar de manera conjunta y como una sola. Este modo de operacin ha sido o inuenciado por el decaimiento del costo de los procesadores, donde es ms barato tener dos a CPU funcionando conjuntamente que una sola CPU del doble de velocidad. 21 de abril de 2012 pg. 23 a
2.2. TENDENCIAS ULTIMAS DOS DECADAS
Se hace uso de las redes de computadores, donde cada nodo de la red es una pieza del computador conformado. Con esto se consigue una serie de ventajas tales como alto rendimiento, alta disponibilidad, balanceo de carga y escalabilidad.
2.1.13.
Sistemas multiprocesadores
Un sistema con mltiples procesadores permite la ejecucin real en paralelo de al menos u o dos procesos, considerando que como m nimo existirn dos procesadores. a Cuando el nmero de procesos en ejecucin supera el nmero de procesadores se debe u o u recurrir al uso de algn mecanismo de planicacin de procesos, donde se deber, al igual u o a que en sistema monoprocesador, compartir el tiempo de CPU entre los interesados.
2.2.
Tendencias ultimas dos dcadas e
Durante las ultimas dos dcadas, o sea desde los 90s, han existido diversas tendencias en e lo referente al desarrollo de sistemas operativos. El gran crecimiento que han experimentado las redes computacionales junto a las velocidades de acceso a Internet han permitido un mayor uso de computacin distribuida, mediante o el uso de plataformas multiprocesadoras y procesadores conectados en red. El rea de sistemas multimedia, datos ms sonido ms imgenes ha experimentado un alto a a a a desarrollo. Se estn desarrollando cada vez dispositivos de entrada ms rpidos y ecientes a a a como los sistemas de reconocimiento automtico de voz o imgenes. Dichos sistemas tienen a a directa relacin con los mencionados como sistemas de tiempo real. o Adicionalmente la tendencia va hacia el diseo e implementacin de sistemas abiertos, n o tales como: Normas de comunicacin abiertas, como el modelo de referencia OSI. o Normas de Sistemas Operativos abiertos como Linux. 21 de abril de 2012 pg. 24 a
2.3. LOGROS
Normas de interfaces de usuario abiertas, como el sistema de ventanas X desarrollado por MIT. Normas de aplicaciones de usuario abiertas, como las entregadas por la FSF1 .
2.3.
Logros
Durante los aos de desarrollo se han obtenido diferentes logros, que perduran en los n sistemas hasta hoy en d A continuacin se mencionan brevemente estos, en cap a. o tulos posteriores se discutir en detalle cada uno de ellos. a
2.3.1.
Procesos y memoria
Un proceso corresponde, en principio, a cualquier programa en ejecucin. Este posee o diversos estados, donde lo ms comn es encontrar: ejecucin (proceso en cpu), bloqueado a u o (en espera de un recurso) y listo (esperando entrar a cpu). Cualquier proceso requerir si o si al menos el uso de memoria principal y CPU, adicionala mente puede requerir utilizar otros dispositivos, en general cualquiera destinado a operaciones de entrada y salida. Esto implicar que diversos procesos podrn tratar de acceder a un misa a mo recurso al mismo tiempo, por lo cual existir competencia por dicho recurso. Para esto, a a lo largo de los aos, se han diseado diversos algoritmos que permiten al sistema operativo n n decidir que proceso utilizar que recurso. a Adems un proceso para funcionar requerir algo ms que su cdigo, un proceso estar fora a a o a mado por el programa o cdigo, sus datos y un contexto (o descriptor del proceso). o Finalmente el sistema operativo debe ser capaz de prevenir o mitigar los problemas ms a comunes correspondientes a data races, deadlock y starvation. Para esto, existen mecanismos de sincronizacin que se pueden utilizar. o
1
Free Software Foundation / http://www.gnu.org/licenses/gpl.html
21 de abril de 2012
pg. 25 a
2.3. LOGROS
2.3.2.
Seguridad y proteccin o
Se debe garantizar la proteccin de los procesos en ejecucin, se mencion ya que sistemas o o o operativos de tiempo compartido deb proteger a los procesos corriendo, ya que mltiples an u usuarios podr estar trabajando en la mquina. Espec an a camente se deben implementar pol ticas que permitan controlar el acceso a un recurso solicitado por ms de un proceso, a a este recurso se le conocer como seccin cr a o tica y algunas medidas que se pueden tomar son: No comparticin: procesos se encuentran aislados. o Comparticin solo como lectura, para escribir un recurso se requieren mecanismos (o o condiciones) especiales. Subsistemas connados: similar a una proteccin por ocultacin donde un proceso evita o o que otros sepan como opera. Diseminacin controlada: en este caso existen credenciales de seguridad para acceder a o los recursos, por lo cual se especica quien podr y quien no podr acceder al recurso. a a
2.3.3.
Gestin de recursos o
La gestin de recursos corresponde a como se debern asignar los recursos a un proceso o a que los solicite, considerando para esto que deber existir algn tipo de planicacin que a u o determine el orden en que sern atendidas las solicitudes. Se deben considerar los factores: a Equidad: igualdad de preferencias frente a una solicitud. Sensibilidad: poder priorizar ciertos procesos. Eciencia: maximizar la productividad y minimizar los tiempos de respuestas. 21 de abril de 2012 pg. 26 a
2.3. LOGROS
Ms adelante se hablar de la planicacin de CPU y como el sistema operativo asigna a a o este recurso a un proceso, se deber considerar que conceptos mencionados para ese recurso a sern anlogos a los utilizados en la planicacin de otro tipo de recurso. a a o
2.3.4.
Estructura del sistema
La estructura o arquitectura del sistema, determinar como se comportar y que capacia a dades podr el sistema operativo entregar a los procesos y usuarios que estn ejecutndose a a a sobre el. Es importante mencionar que la estructura del software utilizada dentro del sistema operativo puede afectar considerablemente el funcionamiento de este. No ser lo mismo una a rutina programada de cierta forma que de otra, una puede ser ms o menos eciente depena diendo de la implementacin realizada. As mismo un sistema con ms o menos instrucciones o a no signica que sea un sistema ms o menos eciente, ni mucho menos ms o menos simple. a a Ya se habr visto en lenguajes de programacin que existen instrucciones que utilizan muy a o pocas l neas, sin embargo son entendibles despus de un tiempo. e Se deber dividir el sistema operativo, de tal forma de que cada una de las partes de este a cumpla una funcin espec o ca. Si bien se puede tener un unico sistema que implemente todas las funcionalidades (este es el caso de un sistema operativo monol tico), aun as internamente deber estar organizado de tal forma que sea sencillo de mantener y programar. De no rea alizarse lo anterior de forma correcta podr existir problemas con los tiempos de entrega del an software, fallos y rendimiento en el momento de poner en funcionamiento un nuevo sistema. El cap tulo 3 discute los conceptos de la estructura del sistema operativo en un nivel ms a profundo.
21 de abril de 2012
pg. 27 a
2.3. LOGROS
21 de abril de 2012
pg. 28 a
Cap tulo 3 Estructura y dise o n

El sistema operativo es el encargado de ofrecer diferentes servicios, tanto al usuario como a otros procesos. Es importante mencionar que aqu se contrapondrn los objetivos que tiene a el sistema con los requerimientos de los usuarios. A continuacin se lista una serie de servicios que deben ser considerados al momento de o disear un sistema operativo, las cuales se discutirn ms adelante. n a a a. Interfaz de usuario: servicio que entrega un mtodo para que el usuario pueda interace tuar con el sistema operativo, ya sea una CLI o una GUI. b. Ejecucin de programas: el sistema operativo se debe encargar de mantener a los o procesos en ejecucin durante todo su ciclo de vida, esto implica la administracin de los o o mismos durante sus posibles estados de ejecucin. o c. Operaciones de entrada/salida (E/S): un proceso no podr acceder directamente a a los recursos disponibles en la mquina, debe ser el sistema operativo quien, mediante una a interfaz de acceso, permita a los diferentes procesos acceder a los dispositivos de entrada y salida de forma concurrente y controlada. d. Sistema de archivos: se debe proveer de una forma de acceder al disco con alguna 29
3.1. INTERFAZ DE USUARIO
CAP ITULO 3. ESTRUCTURA Y DISENO
estructura, donde no se deban escribir directamente posiciones de memoria, sino que los procesos puedan escribir y leer archivos dentro de los dispositivos. e. Comunicacin entre procesos (IPC o Inter Process Communication): correo sponde al mecanismo que permite que diferentes procesos se comuniquen entre s por , ejemplo mediante el uso de memoria compartida, sockets o tuber as. f. Deteccin de errores: sistema deber capturar los errores, tanto f o a sicos como lgicos, o que un proceso pueda generar y evitar que dicho error afecte a otros procesos en ejecucin. o g. Asignacin de recursos: los diferentes dispositivos en la mquina podrn ser utilizados o a a concurrentemente por muchos procesos, por lo que deber existir algn algoritmo que a u permita planicar quien utilizar un recurso en un momento dado. a h. Estad sticas: estas son llevadas con propsitos contables, para detectar errores o para, o por ejemplo, predecir el comportamiento futuro de un proceso y poder tomar decisiones de planicacin al respecto. o i. Proteccin y seguridad: el acceso a los recursos disponibles debe ser controlado, se debe o evitar que cualquier proceso pueda utilizar cualquier dispositivo, en cualquier momento.
3.1.
Interfaz de usuario
Las interfaces de usuario permiten al usuario realizar una interaccin con el sistema o operativo, se dividen bsicamente en dos tipos Command Line Interface (CLI) y Grapha ical User Interface (GUI).
3.1.1.
CLI
La interfaz de l nea de comando o simplemente la shell corresponde a un intrprete en e modo texto que permite introducir ordenes para que sean ejecutadas por el sistema operativo. 21 de abril de 2012 pg. 30 a
Su tarea principal es recibir las solicitudes del usuarios, y en la mamyor de los casos ejecutar a un programa asociado a dicha solicitud. Algunos ejemplos de shells conocidas en diferentes sistemas operativos like Unix son: sh: Steve Bourne, Unix v7, 1978. ash: usada como base para las shell de BSD. bash: parte del proyecto GNU. dash: ash mejorada en Debian. La shell ejecutar los comandos que el usuario introduzca, algunos de ellos sern comndos a a a bsicos (como listar directorios, crear una carpeta, ver la fecha) o podr ser programas ms a an a complejos (como un editor de texto o una aplicacin en modo texto). Adicionalmente se o puede utilizar un lenguaje de programacin para realizar scripts, donde existe un estndar o a denominado shell scripting, pero cada intrprete puede implementar extensiones para el mise mo. Un comando al ser ejecutado deber ser buscado dentro del PATH del sistema, el cual a corresponde a la ruta de directorios donde posiblemente se podr encontrar dicho comando, a si luego de revisar todos los directorios del PATH el comando no es encontrado se informa al usuario. En caso de ser encontrado el comando puede estar implementado como un programa externo de la shell o como un programa dentro de la shell, como el caso de algunas extensiones. La ventaja de utilizar el primer mtodo,fuera del intrprete, es que no se debe modicar este e e para agregar nuevos comandos, bastar agregarlos a alguna de las rutas en el PATH. a
3.1.2.
GUI
La interfaz de usuario grca corresponde al entorno de ventanas, el cual permite tener a diversas aplicaciones encapsuladas dentro de un cuadro (ventana) y de esta forma compartir 21 de abril de 2012 pg. 31 a
de manera fcil un unico recurso, la pantalla, con mltiples procesos que quieren dibujar en a u ella. En sistemas like Unix es conocido como X en honor a Xerox que lo ideo en los aos 70s1 . n Algunos entornos de escritorio y gestores de ventanas son KDE, Gnome, XFCE, Lxde, Fluxbox y OpenBox. Algunos de estos pueden apreciarse en la gura 3.1. El entorno grco no es propiamente una funcin del sistema operativo, de hecho es a o una aplicacin ms que funciona sobre este, la cual entrega una forma ms amigable de o a a interactuar con el sistema.
(a) KDE 3.5
(b) KDE 4
(c) Gnome
(d) XFCE
(e) LXDE
(f) Fluxbox
Figura 3.1: Diversos entornos grcos a
Si! mucho antes que Microsoft Windows empezara a usarlas
21 de abril de 2012
pg. 32 a
3.2. API Y LLAMADAS AL SISTEMA
3.2.
API y llamadas al sistema
Las llamadas al sistema corresponden a una interfaz para utilizar los servicios del sistema operativo, algunos ejemplos de estos son: Errores de procesos (hardware o software). Lectura, creacin o borrado de archivos. o Imprimir texto por pantalla. Acceso a dispositivos de E/S. Una API o Aplication Program Interface son el conjunto de intrucciones y procedimientos que se ofrecen como una cierta biblioteca. En el caso del sistema operativo, es la biblioteca que entrega las funciones que permiten hacer uso de las llamadas al sistema. La API es dependiente del sistema operativo, y algunos ejemplos de estas son la API POSIX2 , la API Win32 y la API de Java. La principal ventaja de utilizar una API para el desarrollo de aplicaciones tienen que ver con la abstraccin que el programador realiza del sistema, donde no necesita conocer a o fondo el sistema y puede generar una menor cantidad de cdigo e instrucciones ms simples. o a Lo anterior implica una mayor facilidad al momento de portar el cdigo desde un sistema o operativo a otro.
3.2.1.
Tipos de llamadas al sistema
Las llamadas a sistemas se pueden dividir en cinco grupos principales, los cuales corresponden a control de procesos, manipulacin de archivos, manipulacin de dispositivos, o o mantenimiento de informacin y comunicaciones. Estas sern discutidas a continuacin. o a o
2
Portable Operating System Interface, utilizada en sistemas like Unix
21 de abril de 2012
pg. 33 a
3.2. API Y LLAMADAS AL SISTEMA Control de procesos
Estas llamadas a sistema se encargan de diferentes tareas que tienen relacin con los o estados y vida de un proceso. Por ejemplo se debe manejar el trmino donde en caso de errores se podr producir un e a volcado de memoria y el programador deber proceder a depurar el programa, por ejemplo a utilizando una herramienta como gdb. En el caso de trmino el sistema operativo deber pasar e a a la siguiente tarea a realizar, generalmente planicando un nuevo proceso. En caso del retorno de salida, existen distintos niveles de error, donde 0 corresponde a un retorno normal y cualquier valor positivo a un error, donde entre ms alto el nmero ms grave debiese ser a u a el error. Tambin se deben manejar temas relacionados con la carga y ejecucin del proceso, e o donde puede ser necesario cargar y/o ejecutar otro programa, por ejemplo cuando un proceso A llama a un proceso B. Una vez termina la ejecucin del proceso B el control deber volver o a al proceso A. Esto ultimo se observa claramente al ejecutar un comando en un interprete, ya que al ejecutar, por ejemplo, el comando ls cuando este termine el control volver al a interprete. Otra llamada al sistema tiene relacin con los atributos de procesos, donde el sistema o operativo deber obtener y jar los mismos, como prioridad o tiempo mximo de ejecucin a a o del proceso. Tiempos de espera los cuales son determinados por un tiempo X de espera o bien por la espera de algn suceso que se requiera. O llamadas al sistema para la asignacin u o de memoria principal. La llamada al sistema kill permite enviar seales a los procesos. Estas seales env una n n an intruccin al proceso con diferentes objetivos, por ejemplo para matar el proceso (KILL), o terminar el proceso (TERM), suspender el proceso (STOP) o ejecutar una alarma (ALRM). Para enviar una seal en sistemas like Unix se utiliza el comando kill. n Algunos ejemplos de llamadas al sistema relacionadas son fork (crea un proceso hijo), exec (carga programa en memoria y ejecuta), wait (espera hasta la nalizacin del proceso o 21 de abril de 2012 pg. 34 a
CAP ITULO 3. ESTRUCTURA Y DISENO hijo) y exit (termina la ejecucin del proceso). o
3.2. API Y LLAMADAS AL SISTEMA
Manipulacin de archivos o Las llamadas a sistema relacionadas con la manipulacin de archivos tienen principalmente o las funciones de realizar operaciones bsicas sobre archivos y determinar atributos o a cambiarlos, como el nombre el tipo del archivo, los permisos que tiene un usuario, etc. Algunos ejemplos de llamadas al sistema relacionadas son create, delete, open, read, write, reposition y close.
Manipulacin de dispositivos o Permiten controlar el acceso a los dispositivos, el cual debe ser controlado, si un proceso requiere un recurso y este esta ocupado el proceso deber esperar por el recurso. a Los dispositivos que se debern manipular pueden ser tanto f a sicos, como el disco duro, y virtuales, como archivos. En sistemas like Unix los dispositivos pueden ser encontrados en el directorio /dev. Algunos ejemplos de llamadas al sistema relacionadas son request, release, open, close, read, write y reposition.
Mantenimiento de informacin o El propsito de estas llamadas al sistemas es transferir informacin entre el programa de o o usuario y el sistema operativo. Ejemplos de este tipo de informacin son tiempo, usuarios, o versin S.O., memoria libre (o disco duro), etc. Informacin general del funcionamiento del o o sistema operativo puede ser encontrada, en sistemas like Unix, en el directorio /proc. Algunos ejemplos de llamadas al sistema relacionadas son time, date y sysinfo (usada por comando uname). 21 de abril de 2012 pg. 35 a
3.3. DISENO Comunicaciones
En este tipo de llamadas al sistema se incluyen aquelals que permiten realizar la comunicacin entre procesos, por ejemplo mediante el modelo por paso de mensajes, usando o sockets o el modelo de memoria compartida, donde se debe eliminar restriccin del o sistema operativo para proteger datos en memoria en el caso de proceso pesados. Algunos ejemplos de llamadas al sistema relacionadas son get hostid, get processid, open, close, accept connection, wait for connection, read message, write message, shared memory create y shared memory attach.
3.3.
Dise o n
Durante el diseo del sistema operativo se deber considerar que los dispositivos sean n a mapeados en la memoria del computador como si fuesen posiciones en ella, si se lee en dicha direccin de memoria, en el fondo, se accede al dispositivo en si, anlogamente si se escribe o a en esa direccin de memoria se har escritura en el disco. Esto es bsicamente los que sucede o a a con los cheros que se encuentran en /dev que representan dispositivos f sicos de la mquina. a Sigamos con el ejemplo del disco, una vez terminada la ejecucin de la rutina llamada o para realizar la lectura no signica que se haya realmente terminado de leer desde el disco. En realidad la rutina que se ejecuta es el comando que se introduce para que se inicie la verdadera lectura y el disco tiene su propio microcontrolador que se encarga de realizar la operacin. La CPU consultar entonces reiteradamente para vericar si se completo o no la o a lectura en un ciclo conocido como busy-waiting, esto es lo que en suced originalmente en a los primeros sistemas operativos como ya fue discutido anteriormente en el cap tulo 2. El problema de este enfoque es que se pierde tiempo mientras se realiza la operacin de lectura, o alrededor de 10 [ms], donde no se hace otro trabajo util. Mucho mejor podr ser ejecutar otros procesos, mientras se espera que se lea el disco, y se a traigan los datos que requiere el proceso para continuar. En este caso el proceso quedar bloa 21 de abril de 2012 pg. 36 a
3.3. DISENO
queado y deber esperar porque el sistema operativo le notique que los datos solicitados ya a se encuentran listos para su uso. El uso de interrupciones permite al disco avisar a la CPU que la operacin en disco o termin, se suspende al proceso que est actualmente en la CPU y se ejecuta una rutina o a para atender la interrupcin. Esta rutina de atencin informa al proceso que lo solicitado del o o disco ya esta disponible y se pasa el proceso a un estado listo para esperar a ser planicado nuevamente. Existe dentro del ncleo del sistema operativo un vector de interrupciones con todas las u posibles fuentes de las mismas, como de disco o las del cronmetro regresivo. Un proceo so que se esta ejecutando podr acaparar la CPU, entonces el sistema operativo utiliza la a interrupcin del cronmetro regresivo para interrumpir al proceso que se esta ejecutando, o o por ejemplo despus de 10 a 100 [ms], y asignar la CPU a otro proceso, con mecanismo se e implementan las tajadas de tiempo. Si estas son sucientemente pequea da la sensacin n o que todo avanza al mismo tiempo, o sea, ejecucin en paralelo. Otros ejemplos de intero rupciones son aquellas que ocurren al hacer divisiones por 0 o la ejecucin de instrucciones o ilegales (cdigo de operacin indenida, operacin que no existe en el procesador o operacin o o o o privilegiada). No confundir interrupciones con seales, estas son interrupciones virtuales y su mbito n a es en los procesos. Cada proceso maneja su propio cronmetro regresivo virtual. El ncleo o u tiene una agenda con todas las seales que debe generar y revisa cual es la prxima que debe n o ocurrir y entonces el cronmetro regresivo coloca la alarma a dicha seal que se requiere para o n dicho proceso. Mandar una seal a un proceso implica activar el proceso para que este pueda n atender la seal. n Otro aspecto a considerar en el diseo del sistema operativo son los canales que se utin lizan para acelerar la entrada y salida de datos, que pueden ayudar a transferir muy rpido a los datos. Lo anterior se logra utilizando un mecanismo del mismo hardware que permite hacer una transferencia directa entre dispositivos y memoria. Una vez ocurrida terminada la 21 de abril de 2012 pg. 37 a
3.3. DISENO
transferencia se genera una interrupcin que indica que los datos ya estn en la memoria. o a Con lo anterior el ncleo evita tener que mover los datos el mismo desde el dispositivo a u la memoria, esta tarea la realiza el canal. Estos canales son conocidos como DMA o Direct Memory Access, donde el dispositivo, a travs de este mecanismo, accede directamente a la e memoria.
3.3.1.
Objetivos
Se deben denir objetivos y especicaciones, por ejemplo el hardware que se requerir y a el tipo de sistema operativo que se desea implementar. Estos se dividirn en objetivos del a usuario y objetivos del sistema. El usuario esta preocupado por que el sistema operativo sea cmodo de utilizar, fcil de o a aprender y usar, able, seguro y rpido. a El sistema esta preocupado por que el sistema operativo sea exible, able, libre de errores, eciente, fcil de disear, implementar y mantener. a n Los objetivos tanto de usuario como de sistema a veces pueden no ser compatibles, por ejemplo, para hacerlo muy eciente, quizs se deba sacricar usabilidad. Por lo anterior es a que se deber encontrar un equilibrio entre los objetivos de ambos lados. a
3.3.2.
Pol ticas y mecanismos
Se deben denir pol ticas que indicarn qu hacer? y mecanismos que indicarn cmo a e a o hacerlo?. Es recomendable que pol ticas y mecanismos se encuentren separados esto permitir tener una mayor exibilidad ya que si se desea modicar una se puede minimizar el a impacto en la otra. Las pol ticas determinarn todas las decisiones que el sistema operativo debe tomar. Por a ejemplo si se debe o no asignar un recurso, deber existir una pol a tica que indique cuando se aceptar la asignacin y cuando se rechazar. Asociado a esta pol a o a tica debe ir un mecanismo 21 de abril de 2012 pg. 38 a
CAP ITULO 3. ESTRUCTURA Y DISENO que me indique como hacer la asignacin o como indicar el rechazo. o
3.3. DISENO
3.3.3.
Requerimientos para proteccin de procesos o
La proteccin de procesos signica que un proceso no deber interferir con otros o a procesos, un proceso que esta corriendo no deber poder acceder a los datos que otro esta a manipulando. Ejemplos de estos sistemas operativos son Unix y Windows NT, y los derivados de ambos. Modo dual En este modo de operacin se deben implementar dos modos bsicos de operacin, el o a o primero corresponde al user mode, modo usuario o modo no protegido. En donde se ejecutan todos los procesos, incluyendo aquellos que son ejecutados por el usuario root. Ejemplo clsico a de este modo son las interrupciones, la instruccin que permite deshabilitar las interrupciones o no se ejecuta en este modo. Ya que un proceso cualquiera podr desactivar, por ejemplo, a el cronmetro regresivo, y evitar que otros ocupen la CPU. En este modo, dicha instruccin o o es privilegiada, por lo cual al ejecutarse ocurrir una interrupcin de software (interrupcin a o o de comando ilegal). Uno si podr desactivar las seales en procesos (no ignorar, desactivar), a n excepto la seal KILL. Si el proceso hab programado una seal la interrupcin ocurrir pero n a n o a el sistema operativo no la entregar al proceso hasta que estn habilitadas nuevamente. a e Importante mencionar que solo se desactivan seales de ese proceso, ya que al ser modo n usuario un proceso no puede interferir con otro. El otro modo corresponde al kernel mode, modo sistema, modo supervisor o modo privilegiado. En este modo todo es permitido, por ejemplo aqu si se podr desactivar las an interrupciones. El ncleo es el unico que corre sobre modo sistema, incluyendo sus mdulos. u o Importante mencionar que dentro del ncleo no hay segmentation fault, en caso de existir u algn error podr derivar en un kernel panic, es por esta razn que solo el usuario root puede u a o cargar mdulos al ncleo. o u 21 de abril de 2012 pg. 39 a
3.3. DISENO
En la gura 3.2 se ilustra cada una de las partes que estn involucradas en el modo usuario a y el modo sistema en GNU/Linux. Las aplicaciones de los usuarios y la API glibc corren sobre el modo usuario, mientras que las llamadas a sistema, el ncleo y las instrucciones directas u al hardware lo hacen en modo sistema. Si un usuario requiere hacer uso de una llamada a sistema deber hacerlo a travs de la API correspondiente, entonces el sistema operativo a e conceder solo por la ejecucin de esa parte del cdigo acceso a modo sistema, revocndoselo a o o a una vez la instruccin termine y siguiendo su ejecucin en modo usuario. Si un usuario quisiera o o acceder directamente a una llamada a sistema privilegiada deber hacerlo como usuario root. a
Figura 3.2: Componentes presentes en el modo usuario y el modo sistema
Unidad de gestin de memoria o La MMU o Memory Management Unit bsicamente lo que hace es traducir de direcciones a virtuales a direcciones reales. Las direcciones utilizas por los procesos son virtuales, varios 21 de abril de 2012 pg. 40 a
CAP ITULO 3. ESTRUCTURA Y DISENO 3.4. ESTRUCTURA DEL SISTEMA OPERATIVO pueden usar la direccin 0x3A, pero cuando se mapean a la memoria real se mapean a o direcciones f sicas distintas, esto lo hace la MMU. Esto ser cubierto en detalle en el cap a tulo 7. Los primeros procesadores para computadores personales que aparecieron con MMU fueron los x86, por el ao 1985, y la fabricacin de lo equipos con estos procesadores n o comenz por el ao 1987. Antes ya hab equipos con MMU, pero eran los mainframes 3 , o n an ya que estos eran para sistemas multiusuarios. Como ejemplo de sistemas operativos que la requieren esta Unix que al ser multiusuario necesita MMU, Linux es derivado de Unix por lo que tambin la requiere y Android al ser derivado de Linux igualmente la necesita. e
3.4.
Estructura del sistema operativo
Se deber elegir un mtodo para estructurar las funcionalidades que se proveern. Aca e a tualmente los sistemas operativos se encuentran divididos por jerarqu con funciones bien as denidas. Se mencionarn algunas formas de estructurar el sistema a continuacin. a o
3.4.1.
Estructura simple
La estructura simple esta orientada a sistemas operativos pequeos, simples y a su vez n limitados. Por ejemplo MS-DOS entregaba unas mximas funcionalidades en un tamao reducido, a n no pose una divisin cuidadosa de sus mdulos. Adicionalmente dicho sistema operativo a o o entregaba acceso directo a rutinas que pod utilizar el hardware, por lo cual no se considera an un sistema operativo con proteccin de sus procesos. o En el caso de Unix original el kernel a travs de las llamadas al sistema provee las fune cionalidades necesarias para acceder a los recursos.
3
Computadoras grandes, potentes y costosas
21 de abril de 2012
pg. 41 a
3.4. ESTRUCTURA DEL SISTEMA OPERATIVO CAP ITULO 3. ESTRUCTURA Y DISENO
3.4.2.
Estructura en niveles
En este tipo de estructuras se utiliza un mtodo de diseo arriba-abajo, el sistema resule n tante corresponder a un sistema por niveles donde la estructura jerrquica se determinar de a a a acuerdo a la complejidad de las funciones de cada nivel. Las ventajas de utilizar esta estructura radica en la independencia que se conseguir entre a los niveles, ya que cada uno se encargar de una tarea espec a ca que le entregar servicios a a otro nivel. Se debe preocupar mantener las mismas funcionalidades que se entregan a otras capas, no importando como se cambie esto internamente. Esto proporciona facilidad en la construccin, mantencin y depuracin. o o o Se debe tener especial cuidado en la denicin apropiada de los diferentes niveles, donde o esto debe hacerse de forma correcta para lograr la independencia anteriormente mencionada. Adems se debe considerar que ciertas capas podrn depender de otros para operar. Una a a desventaja es que al introducir niveles la operacin total podr resultar un poco ms lenta, o a a ya que se deben utilizar interfaces entre las diferentes capas del sistema. A continuacin se muestra un ejemplo de los posibles niveles de jerarqu para un siso a tema operativo. Notar los niveles del 1 al 4 no corresponden directamente a funciones del sistema operativo, estas son realizadas por hardware. Tambin observar que las capas sue periores requerirn servicios de capas inferiores como es el caso del nivel de directorios que a requiere servicios de la capa sistema de archivos y esta a su vez de la capa de almacenamiento secundario. 1. Circuitos electrnicos: registros, puertas, buses. o 2. Instrucciones: evaluacin de la pila, microprogramas, vectores de datos. o 3. Procedimientos: pila de llamadas, visualizacin. o 4. Interrupciones: manejo de interrupciones del hardware. 5. Procesos primitivos: semforos, colas de procesos. a 21 de abril de 2012 pg. 42 a
CAP ITULO 3. ESTRUCTURA Y DISENO 3.4. ESTRUCTURA DEL SISTEMA OPERATIVO 6. Almacenamiento secundario: bloques de datos. 7. Memoria virtual: paginacin. o 8. Comunicaciones: tuber as. 9. Sistema de archivos: almacenamiento en disco duro u otro medio. 10. Dispositivos: impresoras, pantallas, teclados. 11. Directorios: arbol de directorios. 12. Procesos de usuario: programas en ejecucin. o 13. Shell: interprete de comandos.
3.4.3.
Microkernels
Un sistema operativo que esta organizado como micro ncleo entrega solo las tareas u bsicas, como planicacin de procesos, gestor de memoria y comunicaciones. Otras tareas son a o realizadas por programas del sistema operativo y el ncleo es utilizado como un intermediario u para la comunicacin entre el usuario y los programas del sistema operativo que ofrecen los o servicios. Los programas nuevos para el sistema operativo son aadidos al espacio del usuario, n se ejecutan en modo usuario y no como modo sistema. El ncleo entonces se encarga de u realizar las llamadas al sistema a mensajes hacia los servicios correspondientes que entregan las funcionalidades. Minix es un ejemplo de este tipo de sistema operativo.
3.4.4.
Mdulos o
En este caso el sistema operativo esta compuesto por mdulos, donde lo fundamental se o encuentra en el ncleo en si, pero otras funcionalidades son entregadas como mdulos del u o 21 de abril de 2012 pg. 43 a
3.5. IMPLEMENTACION
ncleo. Ambos, tanto el ncleo como los mdulos corren en modo sistema. u u o Esto permite que componentes sean cargados dinmicamente al ncleo, evitando tener a u que disponer de el soporte para todos los dispositivos o funcionalidades permanentemente cargados en memoria principal. En Linux esto se puede realizar mediante el uso de las instrucciones lsmod, modprobe y rmmod. Algunos ejemplos de mdulos que pueden existir son controladores de disco, controladores o de tarjetas de red o el soporte para IPv6. Es importante mencionar que el soporte necesario para que la mquina pueda ser arrancada, en estricto rigor para que el disco duro que contiene a el sistema ra del sistema operativo sea abierto, no puede ir como mdulo del ncleo. Lo z o u anterior ya que los mdulos se cargan cuando el sistema esta iniciando, una vez que ya se o monto el sistema de archivos. Ejemplos de estos sistemas operativos son Unix modernos, Solaris, Linux y Mac OSX. Se hablar ms adelante de mdulos en Linux en el cap a a o tulo 10.
3.5.
Implementacin o
Una vez se hab decidido la estructura del sistema operativo y estn denidas las pol a a ticas del mismo se debe realizar la implementacin. Originalmente esto se realizaba programando o el hardware de la mquina, posteriormente se utilizaba un lenguaje de bajo nivel o lenguaje a de mquina (assembler) y actualmente se utilizan lenguajes de alto nivel (como C o C++). a La principal ventaja de utilizar lenguajes de alto nivel radica en que es fcil de prograa mar, el cdigo que se escribe es compacto, fcil de entender y depurar. Adicionalmente las o a mejoras introducidas en los compiladores signicarn mejoras en el cdigo generado, por lo a o tanto mejoras en el sistema operativo que se esta compilado. Finalmente colabora con la portabilidad de un sistema operativo de un hardware a otro, recordar que ser la API de a cada lenguaje la que se encargar de traducir las instrucciones a la arquitectura seleccionada. a Desde el punto de vista de la optimizacin del sistema operativo es recomendable atacar a o 21 de abril de 2012 pg. 44 a
3.5. IMPLEMENTACION
las estructuras de datos y los algoritmos utilizados en tareas cr ticas, tales como el planicador de la CPU y el gestor de memoria. Una vez identicados los problemas se deben optimizar, por ejemplo reemplazando el cdigo de alto nivel por cdigo de mquina. o o a
21 de abril de 2012
pg. 45 a
3.5. IMPLEMENTACION
21 de abril de 2012
pg. 46 a
Cap tulo 4 Procesos

La denicin ms simple para describir un proceso corresponde a un programa en o a ejecucin. Es importante notar que el proceso no es solo el cdigo, sino que es el cdigo ms o o o a los datos que conforman al proceso, su pila, registros del procesador, descriptores de E/S, etc, en general cualquier informacin que permita administrar el proceso, veremos que esto o ultimo es conocido como contexto del proceso. Adicionalmente se debe considerar que un proceso para ser ejecutado, deber ser plania cado por el sistema operativo, de esta forma podr hacer uso por un per a odo determinado de tiempo de la cpu. Lo anterior ocurre ya que el proceso esta siendo ejecutado en paralelo con otros procesos, y debe compartir los recursos, incluyendo la CPU.
4.1.
Distribucin de la memoria o
Todo proceso que se ejecuta dentro del sistema operativo, utilizando una MMU, ver dia recciones virtuales. En estas direcciones virtuales se ordena la memoria del proceso a partir de las direcciones ms bajas como se muestra en la gura 4.1. a
Cdigo del programa: instrucciones en cdigo de mquina a ejecutar por el proceso. o o a 47
4.1. DISTRIBUCION DE LA MEMORIA
CAP ITULO 4. PROCESOS
Datos: rea para variables globales, inicializadas o no inicializadas. a Stack : rea para datos de funciones. a Heap: espacio utilizado para la asignacin dinmica de memoria, por ejemplo mediante o a malloc. Existen implementaciones donde el stack y heap estn invertidos y el stack crece hacia a las direcciones bajas de la memoria virtual.
Figura 4.1: Distribucin de la memoria o
// Acceso arbitrario a la direccin de memoria 500000 o char *p = (char *) 500000; // Gran posibilidad que el siguiente printf genere un segmentation fault printf("%s", *p); En direcciones superiores, despus del heap, no se encuentra una asignacin realizada para e o el proceso, o sea no hay un mapeo de dichas direcciones virtuales a direcciones f sicas. Por lo cual si un proceso trata de acceder arbitrariamente a una zona ilegal de memoria, donde no hay asignacin o en algunos sistemas al rea del cdigo se producir una segmentation o a o a fault. 21 de abril de 2012 pg. 48 a
4.2. CONTEXTO
En caso de un segmentation fault el proceso se cae con una interrupcin real llamada o direccin ilegal, el sistema operativo determina la causa y env una seal al proceso indicando o a n el error ocurrido. Si esta seal no es capturada por el proceso hijo, entonces el proceso padre, n muchas veces la shell, recibir la seal y mostrar el mensaje Segmentation fault, el proceso a n a hijo terminar y el padre (shel ) continuar su ejecucin. a a o En direcciones virtuales superiores, se encuentra la memoria del sistema, la cual es solo accesible en modo sistema. Esta se encuentra ah para cuando ocurra una interrupcin, as el o ncleo atrapar la interrupcin y cuando ocurre el sistema operativo ejecutar, segn el u a o a u vector de interrupciones, las instrucciones que atienden dicha interrupcin. Esta parte de o la memoria, corresponde al ncleo del sistema operativo la cual esta siempre residente en u memoria y es compartida entre los procesos. Un proceso normal no puede ver el area de cdigo del sistema, solo se accede cuando hay interrupciones. Ningn cdigo que no pertenezca o u o al sistema podr ejecutarse en dicha rea de memoria. a a
4.2.
Contexto
El sistema operativo para gestionar el sistema requiere diferentes tablas, tales como: i. Tabla de memoria: asignacin de memoria principal, asignacin de memoria secuno o daria, (almacenamiento), atributos de proteccin o de comparticin e informacin para o o o la gestin de memoria virtual. o ii. Tabla de E/S: disponibilidad de recursos, estado de las operaciones de E/S y porcin o de memoria principal usada como origen/destino. iii. Tabla de archivos: existencia de archivos, posicin en memoria secundaria, estado o actual y otros atributos. iv. Tabla de procesos: contexto del proceso. 21 de abril de 2012 pg. 49 a
4.2. CONTEXTO
De esta ultima tabla, la de procesos, nos preocuparemos a continuacin. o El contexto, imagen o descriptor del proceso corresponde a todos los datos que el sistema operativo requiere para realizar la administracin del proceso. Este contendr diversa o a informacin referente al estado de ejecucin del proceso. o o O sea, ser una estructura de datos que representar al proceso, contiendo algunos datos a a como cuantos milisegundos de CPU ha usado el proceso en modo sistema o en modo usuario. Comando time entrega el tiempo en modo usuario (user )y modo sistema (sys). Las interrupciones que ocurren son contabilizadas en el tiempo del proceso que ocurren, las cuales no necesariamente son del proceso que se esta ejecutando.
4.2.1.
Atributos del proceso
A continuacin se listan algunos de los elementos que pueden ser encontrados dentro del o contexto de un proceso. Identicacin del proceso o Identicador del proceso. Identicador del proceso padre. Identicador del usuario. Informacin del estado del procesador o Registros visibles para el usuario: aquellos a los que puede hacerse referencia por medio del lenguaje de mquina. a Registros de control y estado: aquellos utilizados por el procesador para ejecutar el cdigo, ej: program counter. o Punteros de pila: apunta a la cima de la pila. 21 de abril de 2012 pg. 50 a
CAP ITULO 4. PROCESOS Informacin de control del proceso o
4.2. CONTEXTO
Informacin de planicacin y estado: estado, prioridad, sucesos u otros. o o Estructuracin de datos: enlace entre procesos, ejemplo colas por estar bloqueados. o Comunicacin entre procesos: indicadores, seales, mensajes. o n Privilegios: memoria, tipo de instrucciones, servicios o utilidades del sistema. Gestin de memoria: punteros hacia las direcciones de memoria asignadas. o Propiedad sobre recursos: recursos controlados por el proceso, ej archivos abiertos.
4.2.2.
Cambios de contexto
El cambio de contexto de un proceso ocurre cuando el proceso que se esta ejecutando sale de la CPU y entra uno nuevo. Lo anterior ya que cada proceso necesita su propio contexto para la ejecucin del mismo, por lo cual el que esta almacenado debe ser limpiado y cargado o el nuevo. Si un proceso hace entrada y salida, y sus datos no estn en buer debe bloquearse entrega a el control al sistema operativo y el scheduler toma el control escogiendo otro proceso, en ese momento ocurre un cambio de contexto entre los procesos. Lo mismo ocurre cuando se acaba el tiempo mediante la interrupcin del cronmetro regresivo. o o Suponga el siguiente escenario, tiene un proceso en ejecucin en la CPU al cual todav le o a queda tiempo del asignado, sin embargo el sistema operativo debe atender una interrupcin o que lleg para ese proceso, al ser una interrupcin el proceso en ejecucin ser interrumpido o o o a y se pasar a ejecutar la parte de cdigo en el area de sistema de dicho proceso, para luego de a o atender la interrupcin continuar con el proceso. Una interrupcin podr originar un cambio o o a de contexto, pero no necesariamente. 21 de abril de 2012 pg. 51 a
4.3. ESTADOS
Los cambios de contexto son caros ya que se debe limpiar la memoria donde se almacena el mismo, y esto al acceder al hardware es lento. Luego de limpiar se debe restaurar el contexto de inters. e Al realizar un cambio de contexto se debe: Resguardar los registros del proceso que sale. Contabilizar el uso de CPU. Cambiar de espacio de direcciones virtuales. Usualmente implica invalidar cach de e nivel 1, lo cual es lo ms costoso, esto es as en los procesos pesados y deben su nombre a justamente a esto. Resguardar los registros del proceso que entra.
4.3.
Estados
Durante la ejecucin de un proceso este puede encontrarse en diferentes estados, se debe o comprender que el proceso al iniciar su ejecucin no siempre se estar ejecutando, ya que o a deber compartir el tiempo de CPU con otros procesos en el sistema, e inclusive con el a mismo sistema operativo, el cual tambin es un proceso en ejecucin. Adicionalmente pueden e o ocurrir otras situaciones que lleven al proceso de un estado a otro. Los diferentes estados pueden ser vistos en la gura 4.2. A continuacin se describirn o a estos y los motivos que pueden llevar a pasar de uno a otro durante la vida del proceso. Cuando se lanza un proceso a ejecucin, el proceso comienza a ejecutarse inmediatamente, o sino que pasar por un estado de inicio, donde se debern realizar distintas operaciones que a a tienen que ver con la preparacin del entorno para la ejecucin del proceso. o o Una ves que se ha creado el entorno del proceso, y existe memoria para que este pueda comenzar, pasa a estado listo donde espera a ser planicado para entrar a la CPU y ejecutar su cdigo. o 21 de abril de 2012 pg. 52 a
4.3. ESTADOS
Inicio
Suspendido L.
Listo
Ejecucin o
Trmino e
Suspendido B.
Bloqueado
Figura 4.2: Estados de un proceso
21 de abril de 2012
pg. 53 a
4.3. ESTADOS
Al momento de ser elegido el proceso para su ingreso a la CPU pasa a estado de ejecucin. o Donde se encontrar, en una primera instancia, hasta que el tiempo asignado por el sistema a operativo expire. Una vez el tiempo expire el proceso volver a estado listo, donde volver a a a esperar para ser planicado. Si durante la ejecucin del proceso, este requiere algn recurso el proceso pasar a estado o u a bloqueado hasta que el sistema operativo le indique que el recurso que esta solicitando le fue asignado, como se vio anteriormente, esto podr ser por ejemplo una lectura de datos a desde el disco. Una vez ocurra esto el proceso pasar a estado listo nuevamente con el recurso a ya asignado para ser utilizado la prxima vez que entre a la CPU. o Una vez el proceso haya cumplido con la ejecucin de su programa, o haya ocurrido algn o u evento que lleve el proceso a su estado nal, se encontrar en estado de trmino o estado a e zombie, donde el proceso ya termino su ejecucin pero aun no se han liberado sus recursos. o Esto es utilizado por ejemplo, por un proceso padre que requiere datos una vez el proceso haya terminado, por lo cual ser la llamada a wait del proceso padre la que liberar nalmente a a los recursos del proceso zombie. Las razones de trmino de un proceso no solo se deben porque trmino con la ejecucin e e o de su cdigo, a continuacin se mencionan otras causas: o o L mite de ejecucin excedido. o L mite de espera excedido. No hay memoria disponible. Violacin de segmento (o l o mites). Error de proteccin. o Error aritmtico. e Error E/S. 21 de abril de 2012 pg. 54 a
CAP ITULO 4. PROCESOS Instruccin invlida. o a Instruccin privilegiada. o Mal uso de datos. Intervencin del SO. o Terminacin del padre. o Solicitud del padre.
4.3. ESTADOS
Ahora con los estados descritos hasta ahora un sistema podr funcionar, sin embargo a qu suceder si en un determinado momento tengo muchos procesos bloqueados y tengo e a otros nuevos esperando entrar a estado listo? Con el esquema descrito hasta ahora, si la RAM estuviese completamente ocupada nuevos procesos no podr ser recibidos. Considerando an esto es que aparecen dos estados adicionales, suspendido listo y suspendido bloqueado, los cuales se encargarn de mover a un almacenamiento secundario los procesos que por a alguna razn no puedan ser llevados a estado listo. Si un proceso se encuentra bloqueado o ser llevado a bloqueado suspendido para que espere sin consumir RAM por el recurso que a est solicitando, en cambio si un proceso es nuevo y no hay memoria RAM podr ser iniciado a a en un estado suspendido listo, donde ya tendr su contexto y solo le faltar memoria para a a poder ser candidato a planicacin. o El sacar un proceso de CPU y colocar otro implicar diversos pasos, los cuales se mena cionan a continuacin: o 1. Guardar el contexto del proceso. 2. Actualizar bloque de control del proceso. 3. Mover bloque de control a la cola adecuada (segn estado). u 4. Seleccionar otro proceso para ejecucin (planicacin). o o 21 de abril de 2012 pg. 55 a
4.4. CLASIFICACION DE PROCESOS
5. Actualizar el bloque de control del proceso seleccionado (cambiar a Ejecucin). o 6. Actualizar las estructuras de datos de gestin de memoria. o 7. Restaurar contexto del procesador a aquel que exist cuando el nuevo proceso dej el a o procesador. Nos preocuparemos especialmente de los algoritmos de planicacin ms adelante. o a
4.4.
Clasicacin de procesos o
Los procesos pueden clasicarse en dos grupos, como procesos pesados y como procesos livianos. Cada uno tendr sus caracter a sticas, ventajas y desventajas. En el cuadro 4.1 se pueden apreciar sus similitudes y diferencias. Pesado Implementacin o Memoria Archivos Procesador Requisitos de hardware Proteccin o Comunicaciones Costo cambio contexto fork propia compartidos propio (1) MMU si Liviano hebras compartida compartidos propio (varios) ninguno no
mensajes, sockets, pipes memoria compartida alto bajo alto
Cuadro 4.1: Comparativa entre procesos pesados y livianos Notar que la comparacin se hace pensando en la ejecucin de varios procesos pesados en o o paralelo en un sistema operativo, o bien la ejecucin de un unico proceso liviano con muchas o hebras ejecutndose de forma paralela. a 21 de abril de 2012 pg. 56 a
4.5. PARALELISMO
En sistemas operativos like Unix tradicionalmente se han utilizado procesos pesados. Si bien POSIX entrega una implementacin de hebras, esto es ms moderno, en los tiempos o a iniciales solo hab procesos pesados. an Sistemas operativos de juguete por lo general utilizan procesos livianos, ya que el sistema operativo en s corre sobre un proceso pesado de Unix.
4.4.1.
Procesos preemptive y non-preemptive
Adicionalmente a la clasicacin anterior el sistema operativo puede ofrecer, una de ests o a opciones, procesos de tipo preemptive y non-preemptive. Los procesos preemptive son aquellos donde el ncleo puede quitarle la CPU a un proceso u en cualquier momento, esto mediante interrupciones. Ejemplos de este tipo de sistema son sistemas like Unix y Windows NT y posteriores. En cambio en los procesos non-preemptive es el proceso quien decide invocar al ncleo y u devolver el control al sistema operativo. En estos casos debe haber una cooperacin entre las o aplicaciones y el sistema operativo para ofrecer paralelismo. Ejemplo de este tipo de sistema son Windows 3.11 y MacOS antes de la versin 6.X. Los sistemas operativos mencionados no o estaban diseados para la ejecucin simultnea de varias aplicaciones, siendo las aplicaciones n o a quienes deb implementar mecanismos de sincronizacin. an o
4.5.
Paralelismo
Un sistema con multiprocesador ser capaz de ejecutar procesos en paralelos, en este caso a se estn considerando varios chips. Otra alternativa corresponde a un sistema multincleo, a u donde existe un solo chip de procesador el cual posee varias CPU (ncleos). u En general, lo que har el sistema operativo ser emular el multiprocesamiento, ya que a a si bien yo puedo contar con un procesador con 2 o 4 ncleos, o ms, siempre querr tener u a e ms procesos en ejecucin que la cantidad de ncleos que la mquina me puede proveer. En a o u a 21 de abril de 2012 pg. 57 a
4.5. PARALELISMO
estos sistemas se entregarn tajadas de tiempo, donde cada proceso dispondr de un tiempo a a nito y determinado para ejecutar su cdigo, de no alcanzar deber intentarlo ms tarde o a a nuevamente. El concepto de concurrencia est relacionado con la ejecucin en paralelo de los procea o sos, si bien este paralelismo solo se podr lograr al disponer de un sistema con mltiples a u procesadores se debe recordar que los tiempos son tan pequeos que al ejecutarse todos los n procesos da la sensacin de que ocurre en paralelo. o La concurrencia aparecer al ejecutarse procesos en paralelo, donde dos o ms procesos a a querrn acceder al mismo tiempo a un determinado recurso. Originalmente la unica prograa macin con mltiples procesos era la del sistema operativo, ya que los lenguajes no entregaba o u soporte para concurrencia. Pero hoy en d como los lenguajes si ofrecen concurrencia como a, parte del lenguaje o biblioteca es importante conocer lo que esta implica. Independientemente de si estamos trabajando en un sistema multiprocesador, multincleo u o con emulacin del paralelismo existirn problemas relacionados a este paralelismo. Los o a cuales tendrn directa relacin con la forma en que se ejecutan los procesos. a o Se discutirn a continuacin los problemas que pueden ocurrir en un ambiente con mltia o u ples procesos en ejecucin, los cuales corresponden a data races, deadlocks y starvation. En o el cap tulo 5 se vern mtodos de sincronizacin que permitirn controlar estas situaciones. a e o a
4.5.1.
Data races
Los data races o condicin de carrera (race condition) ocurre en un proceso cuando o se obtiene un estado inconsistente del sistema, o bien cuando los datos que se obtienen se encuentran en un estado inconsistente. La idea de carrera se puede considerar como dos o ms procesos que compiten para producir cierto estado nal del sistema. a Considere el siguiente cdigo: o /* parte global (comn a todos los hilos) */ u int contador = 0; 21 de abril de 2012 pg. 58 a
CAP ITULO 4. PROCESOS /* cdigo principal de cada hilo en ejecucin */ o o void aumentar() { int aux = contador; /* instruccin 1 */ o contador = aux + 1; /* instruccin 2 */ o }
4.5. PARALELISMO
Suponga que la funcin aumentar() se esta ejecutando en forma paralela en dos hilos o (hebras o threads), qu problema se podr presentar?. Se debe considerar que las operae a ciones de la funcin no son atmicas, o sea pueden ser divididas, por lo tanto el sistema o o operativo puede interrumpir al proceso y detener su ejecucin en cualquier l o nea de ejecucin o del cdigo1 . Al existir la posibilidad que el sistema operativo interrumpa la ejecucin del o o cdigo en cualquier parte del cdigo puede ocurrir la siguiente situacin: o o o i. Hilo 1 ejecuta la funcin aumentar(), guarda el valor del contador y es interrumpido. o Entonces aux = 0. ii. Hilo 2 ejecuta la funcin aumentar(), guarda el valor del contador y es interrumpido. o Entonces aux = 0. iii. Hilo 1 hace la suma y guarda el valor. Entonces contador = 1. iv. Hilo 2 hace la suma y guarda el valor. Entonces contador = 1. Al nal de la operacin la variable contador tendr el valor 1, era el valor esperado? o a qu valor debiera tener la variable contador?. e El resultado esperado ser inconsistente ya que se esperaba que despus de la ejecucin a e o de los dos hilos el contador tuviese valor 2. Sin embargo a causa de la ejecucin en paralelo o y la no existencia de sincronizacin es que el valor resultante es incorrecto. Este problema o
1
Se ha forzado el cdigo a tener 2 l o neas, sin embargo debe considerar que aunque fuese una l nea la
operacin ser dividida en varias operaciones al ser pasada a cdigo de ms bajo nivel o a o a
21 de abril de 2012
pg. 59 a
4.5. PARALELISMO
tambin es conocido como el problema de exclusin mutua, ya que lo lgico que se esperar e o o a es que mientras un proceso modica una seccin cr o tica los otros no puedan hacerlo. Este es, de los problema de concurrencia que se vern, el peor de todos ya que son dif a ciles de detectar y son no determin sticos. Adicionalmente entregan un resultado al usuario, uno incorrecto, con lo cual l podr no darse cuenta si dicho resultado es o no el esperado. e a Agregar elementos a una pila o stack Pila p; int indice = 0; void agregar(Pila p, Objeto o) { put(p, o, indice++); } Sentarme en una silla int sillas[10]; /* arreglo inicializado en 0 */ void sentarme () { int i; for(i=0; i<10; ++i) { if(sillas[i]==0) { sillas[i] = 1; me_siento(i); break; } } } Se debe evitar pensar que el orden de las instrucciones puede ayudar con los problemas de data races, ya que el compilador puede reordenar el cdigo secuencial dejndolo de una o a 21 de abril de 2012 pg. 60 a
4.5. PARALELISMO
forma no deseada. La solucin correcta es el uso de alguna herramienta de sincronizacin, o o como semforos, para garantizar la exclusin mutua. a o
4.5.2.
Deadlock
Un deadlock o interbloqueo corresponde a una situacin donde un proceso requiere cierto o recurso que alguien ms tiene asignado, pero el otro proceso para continuar, y eventualmente a liberar el recurso, requiere el que tengo yo asignado. Esto se puede observar en la gura 4.3.
Recurso 1
asignado Proceso A pide
pide Proceso B
asignado
Recurso 2
Figura 4.3: Interbloqueo, espera circular entre proceso A y B Supongamos por un momento que tenemos una funcin que permite solicitar un recurso y o otra que permite liberar el recurso, ms adelante veremos que esto es posible hacerlo mediante a herramientas como los semforos. En este escenario se propone la siguiente situacin, donde a o Pa y Pb son dos procesos diferentes y que se estn ejecutando de forma paralela. a Pa solicitar(S); solicitar(Q); 21 de abril de 2012 Pb solicitar(Q); solicitar(S); pg. 61 a
4.5. PARALELISMO
Si el proceso A se esta ejecutando, solicita S, lo sacan de la CPU, entra el proceso B y solicita Q. Qu sucedera cuando entre nuevamente A y solicite Q?. Ambos procesos estarn e a esperando que el otro libere el recurso que necesitan. Pensando en un ejemplo ms concreto podr corresponder al problema: a a int tenedor = 1; int cuchillo = 1; function comer_asado() { solicitar(tenedor); solicitar(cuchillo); comer(); liberar(tenedor); liberar(cuchillo); } Para comer se requiere tanto el tenedor como el cuchillo y solo hay disponibles uno de cada uno. Qu podr ocurrir al haber dos personas tratando de comer? e a Otro ejemplo puede ser el del puente colgante, donde: Trco en una sola direccin. a o Cada seccin del puente ser un recurso. o a Si ocurre un deadlock, uno de los usuarios deber retroceder. a Puede ser que varios usuarios deban retroceder. Puede haber inanicin. o Para que ocurra interbloqueo se requieren las siguientes condiciones debe existir exclusin o mutua, los procesos deben mantener tomado el recurso y esperar por el siguiente, no debe 21 de abril de 2012 pg. 62 a
4.5. PARALELISMO
existir apropiacin por parte del sistema operativo (o sea que pueda quitarles el recurso) y o la espera debe ser circular. A continuacin se mencionan posibles casos con los que el sistema operativo podr eno a frentar un interbloqueo.. Ignorar el problema Hacer como si el problema no existiera. Fundamento: bloqueos pueden ocurrir muy pocas veces, donde las pol ticas para solucionarlo pueden llevar a mecanismos complejos y que degraden el rendimiento del sistema. Unix utiliza este mecanismo. Deteccin y recuperacin o o Permite que ocurran bloqueos. Cuando ocurren los detecta y lleva a cabo una accin para solucionarlo. o Deteccin: ejecutar algoritmo cada X tiempo que verique si existen interbloqueos. o Recuperacin: o Apropiacin: quitar el recurso y asignarlo al otro proceso. o Rollback: volver el sistema hacia un punto donde no hay bloqueo. Eliminacin del proceso: se eliminan procesos hasta romper el bloqueo. o Evitarlo dinmicamente a Se hace una simulacin de como quedar el sistema si se asigna un recurso solicitado o a por un proceso. 21 de abril de 2012 pg. 63 a
4.5. PARALELISMO
Se considera un estado seguro (todos satisfacen sus requerimientos) y uno inseguro (si uno o ms procesos no podrn verse satisfechos). a a Si el estado en que queda la simulacin es insegura, los recursos no sern asignados al o a proceso y deber esperar. a Algoritmo dif de implementar, ya que procesos no conocen sus necesidades de recurcil sos para un estado futuro. Evitar las cuatro condiciones Se busca que al menos una de las 4 condiciones necesarias para el bloqueo no se cumpla. Exclusin mutua: si los recursos no se asignarn de forma exclusiva a un proceso no o a habr problema de interbloqueos. a Retencin y espera: se debe evitar que procesos que ya tienen asignados recursos puedan o solicitar nuevos sin liberar los que ya tienen (al menos temporalmente). No apropiacin: quitar el recurso y asignarlo a otro (no siempre aplicable, ejemplo: o impresora). Espera circular: los procesos debern ordenarse para solicitar los recursos, no pudiendo a hacerlo todos al mismo tiempo.
4.5.3.
Starvation
Una situacin de starvation, hambruna o inanicin corresponde a la situacin donde o o o por alguna razn un proceso no obtiene nunca el recurso solicitado. Finalmente el proceso o termina por tiempo de espera excedido, o sea se muere de hambre. Un ejemplo de esta situacin: o Procesos A, B y C. 21 de abril de 2012 pg. 64 a
CAP ITULO 4. PROCESOS Recurso R. Planicador asigna recurso R a A y B, pero nunca a C.
4.5. PARALELISMO
C nunca adquiere el recurso para completar su objetivo y muere. Para manejar el problema de inanicin el sistema operativo puede asignar los recursos o mediante una cola FIFO o bien utilizar una prioridad para los procesos, penalizando a quienes han adquirido el recurso y favoreciendo a quienes no. Esto lo que busca es una asignacin o equitativa de los recursos, donde ninguno de los procesos debe quedar sin ser atendido.
21 de abril de 2012
pg. 65 a
4.5. PARALELISMO
21 de abril de 2012
pg. 66 a
Cap tulo 5 Sincronizacin o

A continuacin se discutirn diferentes conceptos de sincronizacin para solucionar los o a o problemas presentados en el cap tulo anterior. Se introducirn tres herramientas de sina cronizacin correspondientes a semforos, monitores y mensajes. o a
5.1.
Busy-waiting
Una solucin a los problemas de exclusin mutua es consultar reiteradamente si el recurso o o que se esta solicitando esta o no disponible. Son interesantes ya que permiten entender porque son incorrectas y que las hace inapropiadas para el problema de exclusin mutua. o Una de las posibles soluciones es utilizar una bandera para indicar si la seccin cr o tica esta (1) o no (0) siendo ocupada. int bandera = 0; int contador = 0; void aumentar() { while(bandera); bandera = 1; int aux = contador; 67
5.2. PROBLEMAS CLASICOS contador = aux + 1; bandera = 0; } a) Qu sucede con la variable global bandera? e
CAP ITULO 5. SINCRONIZACION
b) Que ocurre si dos procesos consultan en el while y la bandera es 0? Existen diversas soluciones para el problema de exclusin mutua utilizando busy-waiting, o sin embargo todas ellas tienen el mismo problema, espera activa. Se pueden revisar los algoritmos de Dekker y Peterson para ms soluciones de este tipo. a El gran problema con las soluciones de busy-waiting es que realizan una espera activa del recurso. Esto signica que utilizan CPU para consultar cada vez por el recurso. Lo que se ver en el resto del cap a tulo sern herramientas de sincronizacin con espera pasiva, donde a o el proceso consulta, y si el recurso esta ocupado se duerme.
5.2.
Problemas clsicos a
En la literatura relacionada con sistemas operativos siempre se mencionan tres problemas clsicos, los cuales se enunciarn a continuacin y sern utilizados durante los ejemplos de a a o a los diferentes mtodos de sincronizacin. e o
5.2.1.
Productor consumidor
En este problema uno o varios productores producen cierto elemento mientras que uno o varios consumidores consumen dicho elemento. Las operaciones put y get se realizan sobre una pila nita y deben entregarse en el mismo orden en que se depositaron. A continuacin se muestra una visin global del problema, posteriormente una solucin o o o incorrecta, ya que de estas es de donde ms se aprende y la solucin correcta al problema a o utilizando semforos. a 21 de abril de 2012 pg. 68 a
CAP ITULO 5. SINCRONIZACION Versin secuencial: o for (;;) { item it = produce(); consume(it); } Versin paralela: o /* productor */ for (;;) { item it = produce(); put(it); } /* consumidor */ for (;;) { item it = get(); consume(it); } Restricciones:
5.2. PROBLEMAS CLASICOS
get no puede entregar items que no fueron suministrados con put (bloqueo del consumidor). Con put se pueden recibir hasta N items sin que hayan sido extra dos con get (bloqueo del productor). Items tienen que entregarse en el mismo orden en que fueron puestos. Tiene que funcionar en paralelo. 21 de abril de 2012 pg. 69 a
Las funciones produce y consume son lentas y pueden correr en paralelo sin ningn probu lema, se deben sincronizar las operaciones put y get. Por lo cual la solucin deber considerar o a la implementacin sincronizada de estas dos funciones, asumiendo que lo ya dispuesto para o el resto de operaciones funcionar sin problemas. a P1 put P2 put get X X Figura 5.1: Interaccin entre productores y consumidores o C1 get C2
Solucin incorrecta o #define N 100 Item buffer[N]; int e = 0; int f = 0; int c = 0; void put (Item item) { while(c==N); buffer[e] = item; e = (e+1) % N; c++; } Item get () { Item item; while(c==0); item = buffer[f]; 21 de abril de 2012 pg. 70 a
CAP ITULO 5. SINCRONIZACION f = (f+1) % N; c--; return item; }
Por qu la solucin anterior es incorrecta? Al utilizar una variable global c para e o indicar la cantidad de elementos que hay en la pila, se incurre en el problema de exclusin o mutua, donde si no hay sincronizacin la variable c podr sufrir problemas de data races y o a quedar en un estado inconsistente durante algn punto de la ejecucin. Adicionalmente la u o solucin considera el uso de busy-waiting lo cual ya se discuti que no es aceptable. o o
5.2.2.
Cena de lsofos chinos o
Se ha invitado a una cena a cinco lsofos chinos a comer y pensar, y realizan solo una o de estas actividades al mismo tiempo. En la mesa donde se han de sentar existen 5 puestos y 5 palitos. Restricciones: Cada lsofo solo puede tomar palitos de su lado. o Requiere dos palitos para comer. Un palito no puede ser utilizado por dos lsofos. o Solucin incorrecta: data races o void filosofo(int i) { for(;;) { comer(i, (i+1)%5); pensar(); } 21 de abril de 2012 pg. 71 a
Figura 5.2: Problema lsofos chinos o } El problema en esta solucin es que al utilizar la funcin comer directamente con i e i + 1, o o dos lsofos podr tomar el mismo palito. o an
5.2.3.
Lector / escritor
Este problema utiliza la idea de un diccionario, se dispone de dos arreglos de tamao n jo que contienen las palabras y el otro sus deniciones. Se denirn operaciones para poder a agregar una nueva denicin al diccionario, para consultar por una denicin y para eliminar o o una. Restricciones: n lectores o escritores requieren acceso a una estructura de datos compartida. Los lectores solo consultan. 21 de abril de 2012 pg. 72 a
CAP ITULO 5. SINCRONIZACION Los escritores modican la estructura de datos.
Lectores y escritores debern utilizar herramientas de sincronizacin. a o Suponga la siguiente API: void newDef (char *k, char *d); char *query (char *k); void delDef (char *k); Un ejemplo del uso de la API se ilustra a continuacin: o newDef("a", "1"); /* palabra "a" con definicin "1" */ o printf("%s\n", query("a")); /* 1 */ delDef("a"); printf("%s\n", query("a")); /* NULL */ Implementacin de la API: o /* Definicin de arreglos globales para palabras y definiciones */ o #define MAX 100 char *keys[MAX], *defs[MAX];
/* Funcin que obtiene una casilla vaca */ o int getSlot() { int i; for(i=0; i<MAX; i++) if(keys[i]==NULL) return i; return -1; } 21 de abril de 2012 pg. 73 a
/* Funcin que crea una nueva definicin en el diccionario */ o o void newDef (char *k, char *d) { int i = getSlot(); if(i!=-1) { keys[i] = k; defs[i] = d; } }
/* Funcin que obtiene la posicin en la casilla a partir de una clave */ o o int getIdX (char *k) { int i; for(i=0; i<MAX; i++) if(keys[i]!=NULL && !strcmp(k, keys[i])) return i; return -1; }
/* Funcin que recupera una definicin */ o o char *query (char *k) { int i = getIdX(k); return i==-1 ? NULL : defs[i]; }
/* Funcin que elimina una definicin del diccionario */ o o void delDef (char *k) {
21 de abril de 2012
pg. 74 a
CAP ITULO 5. SINCRONIZACION int i = getIdX(k); if(i!=-1) { keys[i] = NULL; defs[i] = NULL; } }
El cdigo mostrado de forma secuencial funciona sin problemas, se pueden denir y cono sultar palabras e incluso eliminarlas. Sin embargo si realizamos una ejecucin en paralelo del o programa y tenemos mltiples consultas o deniciones al mismo tiempo podr presentarse u an problemas. Al analizar el cdigo se determinar que pueden ocurrir data races si se realizan al menos o a dos modicaciones en paralelo o si se realiza una modicacin con una consulta. No ocurrirn o a problemas si se realizan dos consultas en paralelo. Algunas de las situaciones se describen a continuacin, el lector deber ver que otros o a problemas pueden ocurrir. i. newDef con newDef : al realizar una nueva denicin se consulta por una casilla o libre, si justo en el momento despus de consultar si la casilla esta libre (instruccin e o if en getSlot), se saca al proceso de la CPU y entra otro proceso que hace la misma consulta se podr entregar la misma casilla a ambos procesos. a ii. query con delDef : al seleccionar una denicin se consulta mediante getIdX el o ndice dentro del arreglo, si justo despus de consultar por el e ndice se saca al proceso de la CPU y se llama a delDef eliminando la misma denicin consultada, cuando query retome la o CPU y use el ndice obtenido no habr lo esperado en la casilla. a iii. query con newDef : el resultado de query puede ser NULL si se ejecuta antes que newDef o distinto de NULL si se ejecuta despus. e 21 de abril de 2012 pg. 75 a
5.3. SEMAFOROS
5.3.
Semforos a
Los semforos corresponden a contadores, donde para utilizar una seccin cr a o tica se consulta por el valor del monitor si este es mayor a cero (o sea hay tickets) se usa la seccin, o si es igual a cero, se deber esperar. a El valor del semforo (o la cantidad de tickets), deber ser inicializada en la cantidad a a de procesos que pueden hacer uso al mismo tiempo de la seccin cr o tica. Adicionalmente las rutinas utilizadas deben ser atmicas, esto para garantizar que varios procesos puedan o consultar el valor del semforo sin que ocurran data races. a s=1; void proceso () { solicitar_ticket(s); // ejecucin de seccin crtica o o liberar_ticket(s); } Los procesos que no tengan acceso al semforo, por falta de tickets, debern esperar en a a una cola FIFO que se depositen tickets, en cuyo momento se despertar al proceso que estaba a primero en la cola para que obtenga el ticket y entre en la seccin cr o tica.
5.3.1.
API
/* Inicializa el semforo */ a nSem nMakeSem(int tickets);
/* Solicita el semforo */ a void nWaitSem(nSem s);
21 de abril de 2012
pg. 76 a
CAP ITULO 5. SINCRONIZACION /* Libera el semforo */ a void nSignalSem(nSem s);
5.3. SEMAFOROS
5.3.2.
Modo de operacin o
Un bosquejo de la implementacin de las funciones de la API que ayudar a comprender o a como operan los semforos es el siguiente: a void wait (s) { s--; if(s < 0) block(s); /* suspender proceso y agregarlo al final de la cola */ }
void signal (s) { s++; if (s <= 0) wakeup(s); /* despertar primer proceso en la cola */ } Qu signica que el valor del semforo sea -1?, signicar que ya hay un proceso e a a antes en la cola FIFO. Por lo cual al recibir un signal se despertar primero al otro proceso. a
5.3.3.
Problema productor consumidor
Solucin correcta o #define N 100 Item buffer[N]; int e = 0; 21 de abril de 2012 pg. 77 a
5.3. SEMAFOROS int f = 0; nSem empty; /* = nMakeSem(0) */ nSem full; /* = nMakeSem(N) */ void put (Item item) { nWaitSem(empty); buffer[e] = item; e = (e+1) % N; nSignalSem(full); } Item get () { Item item; nWaitSem(full); item = buffer[f]; f = (f+1) % N; nSignal(empty); return item; }
Esta solucin es vlida para un productor y un consumidor. Para n productos y m cono a sumidores se debe denir un semforo adicional para cubrir la seccin cr a o tica tanto de la funcin put como de la funcin get. Esto queda de tarea al lector. o o
5.3.4.
Problema lsofos chinos o
Solucin incorrecta: deadlock o nSem s[5]; /* for(i=0; i<5; i++) s[i] = nMakeSem(1); */ void filosofo(int i) { for(;;) { 21 de abril de 2012 pg. 78 a
CAP ITULO 5. SINCRONIZACION nWaitSem(s[i]); nWaitSem(s[(i+1)%5]); comer(i, (i+1)%5); nSignalSem(s[i]); nSignalSem(s[(i+1)%5]); pensar(); } }
5.3. SEMAFOROS
El problema en esta solucin es lo que suceder si todos los lsofos solicitaran el palito o a o i al mismo tiempo, cuando quieran solicitar el palito i + 1 ya alguien lo tendr tomado. a Solucin correcta espec o ca Se debe evitar que entren los 5 lsofos al mismo tiempo a la mesa, con esto se aseguo rar que al menos uno de ellos coma. En este caso la misma mesa se convierte en una seccin a o cr tica. nSem m; /* m = nMakeSem(4); */ nSem s[5]; /* for(i=0; i<5; i++) s[i] = nMakeSem(1); */ void filosofo(int i) { for(;;) { nWaitSem(m); nWaitSem(s[i]); nWaitSem(s[(i+1)%5]); comer(i, (i+1)%5); nSignalSem(s[i]); nSignalSem(s[(i+1)%5]); nSignalSem(m); 21 de abril de 2012 pg. 79 a
5.3. SEMAFOROS pensar(); } } Solucin correcta general o
Se deben solicitar los recursos siempre en el mismo orden, ya sea ascendente o descendente. Esto evitar el interbloqueo. a nSem s[5]; /* for(i=0; i<5; i++) s[i] = nMakeSem(1); */ void filosofo(int i) { int mini = min (i, (i+1)%5); int maxi = max (i, (i+1)%5); for(;;) { nWaitSem(s[mini]); nWaitSem(s[maxi]); comer(mini, maxi); nSignalSem(s[mini]); nSignalSem(s[maxi]); pensar(); } } Suponga que entra el lsofo 2, solicitar palito 2 y palito 3 y comer. Luego entra el o a a lsofo 1, solicita palito 1 (est disponible), pero al pedir el palito 2 (que esta ocupado por o a el lsofo 2) se bloquea a la espera que se desocupe. El problema aqu es que el lsofo 1 o o espera reteniendo el palito 1, entonces si llega un lsofo 0, que puede usar el palito 0, el o palito 1 no lo conseguir a pesar de que no est siendo utilizado para comer (solo est siendo a a a retenido por el lsofo 1). Eventualmente, cuando el lsofo 2 libere el palito 2, el lsofo 1 o o o 21 de abril de 2012 pg. 80 a
5.4. MONITORES
comer y eventualmente el 0 tambin lo har. Sin embargo podr haber comido el 2 y el 0 a e a a al mismo tiempo?, la respuesta es s . El problema de los semforos, en general, es que no se puede saber si el semforo est o a a a no ocupado antes de pedirlo. Esto trae como consecuencia una limitacin del paralelismo. o Sin embargo, si se considera que la operacin comer es mucho ms rpida que la de pensar, o a a por ejemplo asumiendo que comer es leer datos y pensar es procesarlos, esta limitacin de o paralelismo no es tan grave para ciertos problemas. Lo anterior se podr solucionar implementando algo que permita pedir dos semforos a a al mismo tiempo, pero que no los deje tomados si uno de ellos est ocupado. Esto entrea gar un mayor paralelismo, pero introducir el problema de hambruna, donde dos lsofos a a o (por ejemplo 0 y 2) podr estar pidiendo siempre los palitos que un tercero (1) quisiera an utilizar.
5.4.
Monitores
Los monitores son una herramienta de sincronizacin que ofrece ms paralelismo que o a los semforos, pero pueden provocar hambruna. Permitirn consultar al mismo tiempo por a a el valor de ms de una condicin, si alguno de los elementos de dicha condicin no se cumple a o o de la forma requerida el proceso se suspender. a Los monitores pueden ser vistos como semforos binarios, donde ticket del monitor es a la propiedad del mismo. Notar que la propiedad del monitor debe ser devuelta por el mismo proceso que solicit la propiedad. o void proceso () { solicitar_propiedad(m); // ejecucin de seccin crtica o o liberar_propiedad(m); } 21 de abril de 2012 pg. 81 a
5.4. MONITORES
5.4.1.
API
/* Crear un monitor */ nMonitor nMakeMonitor();
/* Destruir un monitor */ void nDestroyMonitor(nMonitor m);
/* Solicitar la propiedad sobre un monitor */ void nEnter(nMonitor m);
/* Devuelve la propiedad del monitor */ void nExit(nMonitor m);
/* Devuelve la propiedad y suspende el proceso hasta un nNotifyAll */ void nWait(nMonitor m);
/* Despierta las tareas suspendidas mediante nWait */ void nNotifyAll(nMonitor m);
Cuando se hace una llamada a nN otif yAll se despertar a todos los procesos suspendia dos por un nW ait del mismo monitor, el orden en que despiertan no esta garantizado, o sea no necesariamente es FIFO respecto a la ejecucin de nW ait. Adicionalmente una vez o despertadas deben esperar la propiedad del monitor y evaluar nuevamente sus condiciones, si nuevamente no se cumplen se suspendern liberando el monitor, as otro proceso despertado a con nN otif yAll podr obtener la propiedad y tambin evaluar sus condiciones nuevamente. a e Podr ocurrir tambin que con nN otif yAll los procesos al evaluar sus condiciones, ninguno a e pueda continuar, y todos se vuelvan a suspender. 21 de abril de 2012 pg. 82 a
5.5. MENSAJES
5.4.2.
Problema productor consumidor
Solucin incorrecta: deadlock o ...
Solucin correcta o ...
5.4.3.
Problema lsofos chinos o
5.4.4.
Problema lectores escritores
5.5.
Mensajes
Procesos conversan... 21 de abril de 2012 pg. 83 a
5.6. MONITORES DE HOARE
5.5.1.
Exclusin mutua con mensajes o
Implementacin o ...
5.5.2. 5.5.3.
Implementacin de semforos a partir de mensajes o a Problema lectores escritores
5.6.
Monitores de Hoare
21 de abril de 2012
pg. 84 a
Cap tulo 6 Planicacin en monoprocesadores o

Durante esta seccin se asumir que la mquina dispone de una unica CPU. Considerando o a a este escenario se analizarn diferentes mtodo mediante el cual el sistema operativo puede a e decidir que proceso ocupar el recurso CPU. a El scheduling o planicacin de procesos corresponde a la asignacin conveniente del o o recurso CPU a los procesos. Se debe elegir que proceso tomar la CPU y por cuanto tiempo. a La recuperacin de la CPU por parte del sistema operativo se hace mediante una interrupcin o o del cronmetro regresivo. El scheduler de procesos es la componente en el ncleo (por lo o u tanto en el area de sistema) que realiza el scheduling. Cada recurso deber tener su propio planicador, pero la idea siempre ser favorecer a a algn tipo de parmetro (como tiempo de espera, orden de llegada, etc). Por lo cual al ver u a la planicacin en en procesos es posible realizar una analog con lo que sucede en el resto o a de los dispositivos. FALTAN TODOS LOS ALGORITMOS!!
6.1.
Planicacin en Linux o
Se discutirn aspectos de la planicacin en Linux... a o
85
CAP 6.1. PLANIFICACION EN LINUX 6. PLANIFICACION EN MONOPROCESADORES ITULO
21 de abril de 2012
pg. 86 a
Cap tulo 7 Memoria principal
87
CAP ITULO 7. MEMORIA PRINCIPAL
21 de abril de 2012
pg. 88 a
Cap tulo 8 Memoria secundaria
89
CAP ITULO 8. MEMORIA SECUNDARIA
21 de abril de 2012
pg. 90 a
Cap tulo 9 Proteccin y seguridad o
91
CAP ITULO 9. PROTECCION Y SEGURIDAD
21 de abril de 2012
pg. 92 a
Cap tulo 10 Mdulos en Linux o
93
CAP ITULO 10. MODULOS EN LINUX
21 de abril de 2012
pg. 94 a
Anexo A Mquinas virtuales a

Una mquina virtual entrega una abstraccin del hardware de la mquina hacia el sistema a o a operativo, proporcionando una interfaz de hardware virtual similar a la de la mquina real. a Los discos duros son emulados, por ejemplo, mediante imgenes de discos. El sistema operaa tivo que corre sobre la mquina virtual desconoce tal condicin, o sea, no sabe que funciona a o sobre una mquina virtual y no una real. a Este tipo de sistemas permite correr mltiples sistemas operativos sobre una misma u mquina. Ejemplos de sistemas de virtualizacin son XEN, KVM y VirtualBox. a o El sistema operativo que corre sobre la mquina virtual tambin posee un modo de ejea e cucin usuario y de sistema, sin embargo estos son modos virtuales que corren sobre un o modo usuario real. Esto signica que si en el sistema operativo virtual hay una solicitud a una llamada del sistema a travs de un programa que corre en modo usuario virtual, esta e ser procesada por el sistema operativo en modo sistema virtual y se entregar a la mquina a a a virtual, la cual, en modo usuario real, atender la interrupcin mediante el hardware vira o tualizado y entregar la respuesta al sistema operativo. En caso que se requiera acceso al a hardware real, la mquina virtual deber hacer uso de la API del sistema operativo real para a a acceder al recurso solicitado. Es importante mencionar que los tiempos de respuesta en mquinas virtuales sern ms a a a 95
ANEXO A. MAQUINAS VIRTUALES lentos que en mquinas reales. Lo anterior debido a la emulacin que se debe realizar del a o hardware y por la posibilidad de que existan mltiples mquinas virtuales en ejecucin en u a o un mismo sistema real. Las principales ventajas de esta solucin es que permite realizar una proteccin por aiso o lamiento de los recursos del sistema, ya que el sistema virtualizado solo ver dispositivos a virtuales y en caso de cualquier problema solo podr afectar a la mquina virtual quedando a a la mquina real protegida. Adicionalmente son un medio ideal para la realizacin de pruebas a o de sistemas operativos, como la prueba de mdulos en desarrollo o la prueba de servicios que o se desean implementar en una mquina real. Tambin permiten aprovechar mejor el hardware a e disponible, entregando servicio en un mismo equipo a diferentes sistemas operativos que en conjunto comparte de forma eciente el hardware disponible.
21 de abril de 2012
pg. 96 a
Anexo B nSystem
nSystem (nano System) corresponde a un sistema operativo de juguete, desarrollado por el profesor Luis Mateu1 , de la Universidad de Chile, durante el ao 1993 como herramienta n para el curso de sistemas operativos que imparte desde esa misma fecha. En ese entonces exist uSystem (micro System), sin embargo a pesar de ser un sistema operativo pequeo a n era ms complejo, esta fue la razn por la que decidi programar su propia versin utilizando a o o o un cdigo ms reducido. o a Se hace uso de procesos livianos, llamados tareas, los cuales el sistema operativo los puedes tratar como procesos preemptive o non-preemptive, lo cual es congurable. Sin embargo en los ejemplos expuestos en este apunte se considera el uso de procesos preemptive, lo cual es por defecto as . El sistema operativo corre sobre un proceso pesado en Unix, y permite realizar una simulacin de un sistema operativo gracias a que cada proceso tiene su propio timer y existe o disponibilidad de seales en los procesos. Entonces, se multiplexa el tiempo virtual del proceso n pesado en tajadas para cada una de las tareas. Es importante mencionar que no existe verdadero paralelismo, aunque existan mltiples u CPUs en la mquina, ya que el proceso pesado utilizado corre sobre un unico ncleo (Unix a u
1
http://www.dcc.uchile.cl/~lmateu
97
B.1. API ve solo un proceso, independiente de las tareas que existan).
ANEXO B. NSYSTEM
B.1.
B.1.1.
/**
API
Creacin de tareas o
* Crear una nueva tarea * Solo recibe enteros o punteros * Solo retorna enteros */ nTask nEmitTask(int (*proc)(), ...);
/** * Esperar a que una tarea termine y entregue el resultado * Solo retorna enteros (proveniente de la tarea) * Por cada nEmitTask debe haber un y solo un nWaitTask asociado */ int nWaitTask(nTask task);
/** * Trmino anticipado de una tarea e * Recibe como parmetro el valor que se desea retornar a */ void nExitTask(int rc); Utilicemos el siguiente cdigo que calcula recursivamente los elementos de una serie de o Fibonacci: 21 de abril de 2012 pg. 98 a
ANEXO B. NSYSTEM int fib (int n) { if(n<=1) return n; else return fib(n-1) + fib(n-2); }
B.1. API
Cmo se pueden crear tareas para realizar el clculo de manera paralela o a en vez de recursiva? A continuacin se muestra una implementacin, usando tareas de o o nSystem, en que se crean dos tareas que ejecutarn en paralelo la funcin recursiva para a o realizar el clculo. a int pfib (int n) { if(n<=1) return n; else { nTask t1 = nEmitTask(fib, n-1); ntask t2 = nEmitTask(fib, n-2); int rc1 = nWaitTask(t1); int rc2 = nWaitTask(t2); return rc1 + rc2; } } Por qu se utiliza la funcin recursiva para las tareas en pb()? No es buena e o idea crear mucho paralelismo, ya que se podr obtener aplicaciones muy caras e inecientes. an Una alternativa, para conseguir ms paralelismo, es permitir la creacin de todas las tareas a o como hebras hasta un cierto l mite, luego de excedido el l mite empezar a usar la forma recursiva, o no paralela, esto se muestra a continuacin. o int pfib (int n, int p) { if(n<=1) 21 de abril de 2012 pg. 99 a
B.1. API return n; else if (p<=1) return fib(n); else { nTask t1 = nEmitTask(pfib, n-1, p/2); nTask t2 = nEmitTask(pfib, n-2, p-p/2); int rc1 = nWaitTask(t1); int rc2 = nWaitTask(t2); return rc1 + rc2; } }
ANEXO B. NSYSTEM
21 de abril de 2012
pg. 100 a

Apunte So

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apunte So

Uploaded by

Copyright:

Available Formats

Sistemas Operativos

Apuntes, Cdigos y Ejercicios o

Esteban De La Fuente Rubio esteban@delaf.cl 21 de abril de 2012

2.1.4. Sistemas con buering . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5. Sistemas de operacin online o . . . . . . . . . . . . . . . . . . . . . .

INDICE GENERAL 2.1.9. Computadores personales

3.4.4. Mdulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 3.5. Implementacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 21 de abril de 2012

INDICE GENERAL 4. Procesos

Cap tulo 1 Introduccin o

1.1. VISION GENERAL

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

1.1. VISION GENERAL

Figura 1.1: Visin global del Sistema Operativo o

1.1. VISION GENERAL

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

1.2. OBJETIVOS DEL SISTEMA OPERATIVO

Objetivos del sistema operativo

Objetivos del usuario

1.3. SERVICIOS OFRECIDOS

CAP ITULO 1. INTRODUCCION

Objetivos del sistema

CAP ITULO 1. INTRODUCCION

1.3. SERVICIOS OFRECIDOS

Gestin de memoria principal o

Gestin de memoria secundaria o

1.3. SERVICIOS OFRECIDOS

CAP ITULO 1. INTRODUCCION

Cap tulo 2 Historia

2.1. TIPOS DE SISTEMAS

CAP ITULO 2. HISTORIA

Sistemas por lotes

CAP ITULO 2. HISTORIA

2.1. TIPOS DE SISTEMAS

Sistemas de operacin oine o

2.1. TIPOS DE SISTEMAS

CAP ITULO 2. HISTORIA

CAP ITULO 2. HISTORIA

2.1. TIPOS DE SISTEMAS

Sistemas con buering

Sistemas de operacin online o

2.1. TIPOS DE SISTEMAS almacenaban las salidas de los mismos.

CAP ITULO 2. HISTORIA

CAP ITULO 2. HISTORIA

2.1. TIPOS DE SISTEMAS

Figura 2.2: Sistemas por lotes vs sistema multiprogramado

Mquinas o procesadores virtuales a

Sistemas de tiempo compartido

2.1. TIPOS DE SISTEMAS

CAP ITULO 2. HISTORIA

CAP ITULO 2. HISTORIA

2.1. TIPOS DE SISTEMAS

Redes de computadores personales

Sistemas en tiempo real

Sistemas distribu dos

2.2. TENDENCIAS ULTIMAS DOS DECADAS

CAP ITULO 2. HISTORIA

Tendencias ultimas dos dcadas e

CAP ITULO 2. HISTORIA

Free Software Foundation / http://www.gnu.org/licenses/gpl.html

CAP ITULO 2. HISTORIA

CAP ITULO 2. HISTORIA

Estructura del sistema