Contenido Sistemas Operativos

INSTITUTO TECNOLGICO DE VERACRUZ

SISTEMAS OPERATIVOS PLAN 2010 X COMPETENCIAS

Lic. Martha Martnez Moreno Depto. De Sistemas y Computacin

Unidad 1. Introduccin a los Sistemas Operativos 1.1 Definicin y Concepto Un Sistema Operativo (S.O.) es una coleccin organizada de rutinas o extensiones de software del hardware. Consiste en rutinas de control que hacen funcionar una computadora y proporcionan un entorno para la ejecucin de los programas. Existen otros programas que se apoyan en el S.O. para poder acceder a los recursos que necesitan. Esto se lleva a cabo a travs de llamadas sistema operativo. Tambin el S.O. debe brindar una forma de que el usuario se pueda comunicar con l a travs de una interfaz que le brinde una va de comunicacin con el hardware del sistema informtico. El objetivo principal del S.O. es lograr que el hardware de la computadora se emplee de modo eficiente, y su objetivo secundario es que se use de manera cmoda. El S.O. debe asegurar el correcto funcionamiento del sistema informtico. Para lograr esto el hardware debe brindar algn mecanismo apropiado que impida que los usuarios intervengan en el funcionamiento del sistema y as mismo el S.O. debe poder utilizar este recurso de hardware de modo que esto se cumpla. El S.O. debe ofrecer servicios a los programas y sus usuarios para facilitar la tarea de programacin. Las clases de sistemas operativos en la que nos basaremos sern los denominados multiusuarios y de multiprogramacin; es decir que varios usuarios podrn correr concurrentemente mltiples programas. Un S.O. es una parte importante de casi cualquier sistema informtico. Para entender mejor esto veremos que un sistema informtico puede separar en cuatro partes:

El hardware

El S.O.

Los programas de aplicacin

Los usuarios




Estas partes hacen de capas, cada una de las cuales acerca ms al usuario a utilizar los recursos del hardware. El hardware (CPU, memoria y dispositivos) proporciona los recursos de computacin bsicos sobre los que se agregaran estas capas sucesivas. Los programas de aplicacin como los compiladores, juegos, aplicaciones de negocios, etc. definen la forma en que estos recursos se emplearn para solucionar los problemas del usuario. Puede haber varias clases de usuarios usando el sistema, como ser personas, programas y otras computadoras, tratando de resolver diversos problemas. El S.O. controla y coordina el uso del hardware entre los diversos programas de aplicacin y los distintos usuarios, administrando todos los recursos como disco, memoria, impresoras, monitor, etc. El S.O. determina los tiempos en que un determinado programa utilizar un recurso. dado. Al comienzo de la era informtica, los sistemas no utilizaban S.O.'s. Estas computadoras de hace 40 aos ejecutaban un programa a la vez que era cargado por un programador. Este cargaba el programa y lo ejecutaba. Si exista algn error que hiciera que el programa se detuviera antes de lo esperado, se tena que comenzar de nuevo con todo el proceso. Recordemos que en esa poca no haba muchas computadoras en funcionamiento, as que el programador tena que esperar de varios das hasta tener nuevamente su turno enfrente de la computadora. Los S.O.'s existen porque son una solucin razonable al problema de crear un sistema informtico til. El objetivo fundamental de los sistemas informticos es ejecutar los programas de los usuarios y facilitar la resolucin de sus problemas. Todo esto se haca a travs de tarjetas perforadas que una persona encargada cargaba en la computadora y luego de algunas horas devolva la salida impresa al programador. Al avanzar la tecnologa informtica, muchos de estos programas se cargaban en una sola cinta, otro programa residente en la memoria de la computadora, cargaba y manipulaba los programas de esa cinta. Este es el ancestro de los S.O.'s de hoy en da. En la dcada del 60 la tecnologa de S.O.'s avanzo mucho y se podan tener mltiples programas al mismo tiempo en la memoria. As surgi el concepto de multiprogramacin. Si un programa necesitaba esperas a que ocurriera algn evento externo, como que una cinta se rebobinara, otro podra tener acceso. a la CPU para as poder utilizar el 100% del poder de procesamiento con que contaba la computadora. Esto ahorraba




mucho dinero ya que en aquel entonces todo en lo referente a cmputo (memoria, espacio en disco, etc.) costaba cientos de miles de dlares. A finales de los 60's, en 1969, naci UNIX, que es la base de muchos de los S.O.'s de hoy en da. Definir que forma parte de un S.O. y que no sera difcil, dada la gran variedad existente, pero una definicin para los S.O. que nos compete en estos momentos seria que el S.O. es el programa que ejecuta todo el tiempo en la computadora (conocido usualmente como kernel o ncleo), siendo los programas de aplicacin todo lo dems. En general un S.O. intenta incrementar la productividad de un recurso de proceso tal como el hardware de la computadora, o de los usuarios de los sistemas informticos.




1.2 Funciones y Caractersticas Funciones Bsicas de un Sistema Operativo Se tendr como punto de partida la mquina tal cual, es decir, el hardware bsico del computador, con una CPU, memoria central y perifricos. Sin ayuda del Software las operaciones de cargar y ejecutar un programa se debe realizar de forma manual, es decir totalmente bajo control humano. El operador debe llevar a cabo una secuencia de tareas:

Colocar el programa fuente almacenado en el dispositivo de entrada adecuado (cintas, tarjetas, discos...).

Desencadenar la ejecucin de un programa de lectura para el dispositivo elegido.

Desencadenar la ejecucin de un compilador que traduzca el programa fuente.

Colocar los datos de entrada en el dispositivo adecuado.

Ejecutar el programa objeto.

Sacar los resultados por impresora.

Un sistema operativo crea un entorno para la ejecucin de programas. Ofrece ciertos servicios a los programas y a los usuarios de estos programas. Dependen del tipo de Sistema Operativo, pero las funciones bsicas son: De cara al usuario:

Ejecucin de programas. El sistema debe ser capaz de cargar un programa en memoria y ejecutarlo.

Operacin de I/O. Un programa de usuario no puede ejecutar directamente operaciones de I/O. El sistema operativo debe facilitar medios para realizarla.

Manipulacin de ficheros: Lectura, escritura y borrado a partir del identificador de los mismos.

Deteccin de errores: Para cada tipo de error el sistema operativo debe adoptar la iniciativa apropiada que garantice una computacin correcta y consistente. No confundir esta deteccin de errores con la producida durante la compilacin de un programa. Esta deteccin se hace de cara a un funcionamiento eficiente.

De funcionamiento eficiente:

Asignacin de recursos.

Contabilidad: control del uso. de la computadora por cada usuario.

Proteccin: de datos, recursos, programacin, etc. Caractersticas de un Sistema Operativo 1.- Concurrencia. Consiste en la existencia de varias actividades simultneas o paralelas. Ejemplo de ello lo son la superposicin de las operaciones de I/O con el proceso de computacin, as como la coexistencia en memoria de varios programas. La concurrencia lleva asociado el problema de conmutar de una tarea a otra, as como proteger una determinada actividad de los efectos de las




otras, as como la sincronizacin de tareas que sean mutuamente dependientes.

2.- Utilizacin conjunta de recursos. Comparticin. Las razones para la comparticin son las siguientes: a) El coste: es absurdo disponer de suficientes recursos para cada usuario por separado. b) Aprovechamiento de los trabajos de otros. La utilidad es poder utilizar rutinas y programas desarrollados por otras personas. c) Posibilidad de compartir datos: Utilizacin de una misma base de datos para varios programas distintos, asociados posiblemente a distintos usuarios. d) Eliminacin de redundancias: poder disponer de una sola copia de un programa (por ejemplo un compilador) y compartirlo con otros.

3.- Permite que el usuario guarde sus datos o programas en el propio ordenador, y no tener que usar medios externos (portables). Los problemas que se plantean son de proteccin de la informacin frente a terceros y protegerlos frente a fallos del sistema. 4.- Un Sistema Operativo debe ser determinista en el sentido de que el mismo programa ejecutado con los mismos datos, en momentos diferentes, debe producir los mismos resultados. En cambio ser indeterminista porque en caso de variabilidad de las situaciones puede responder de un modo impredecible. Deben tomarse las medidas oportunas. Estas situaciones pueden ser debidas a peticin de recursos, errores de ejecucin en programas o bien interrupcin de perifricos. Caractersticas Deseables en un Sistema Operativo Eficiencia Se juzgar la eficiencia de un Sistema Operativo mediante los siguientes criterios:

1. Tiempo transcurrido entre tareas. 2. Tiempo no empleado del procesador central. 3. Tiempo de ejecucin empleado en las tareas batch. 4. Tiempo de respuesta (en los sistemas de acceso mltiple). 5. Utilizacin de recursos. 6. Rendimiento (tareas ejecutadas por hora).

Fiabilidad Estar libre de errores y ser capaz de resolver satisfactoriamente todas las contingencias que se pudieran presentar. Mantenibilidad Ser posible corregir un Sistema Operativo (mejorndolo, o bien subsanando errores) sin tener graves problemas. Estar bien documentado.




Tamao reducido El espacio ocupado por el Sistema Operativo no est disponible para su utilizacin productiva, por lo que debe ocupar lo menos posible. Para ello es preciso que el sistema operativo sea modular en su construccin. Disponer de interfaces claramente definidas en mdulos y estar bien documentado. Prestacin de Servicios Llamada al sistema: Los servicios de ms bajo nivel se obtienen mediante el uso de llamadas al sistema, Constituyen un interfaz entre el programa que se est ejecutando y el sistema operativo. Estas llamadas estn implementadas generalmente por instrucciones en lenguaje ensamblador. Se dividen en cuatro clases:

Control de procesos: Sirven para poder detener un programa normal o anormalmente. Tambin se utilizan para cargar y ejecutar otros procesos. Un ejemplo son los Lenguajes de Control de Trabajos.

Manipulacin de ficheros: Crean, abren, borran, cierran, leen, escriben y reposicionan ficheros. Obtienen y establecen atributos de ficheros.

Manipulacin de dispositivos: Solicitud y liberacin de dispositivos. Leen, escriben y reposicionan ficheros. Obtienen y establecen atributos de dispositivos.

Mantenimiento de la informacin: Obtener y establecer hora y fecha. Obtener y modificar datos del sistema. Obtener y establecer atributos de proceso, fichero o dispositivo.




1.3 Evolucin Histrica Primera generacin (1945-1955)

No existen Sistemas Operativos.

Un grupo reducido de gente diseaba, construa, programaba, mantena cada mquina.

Las instrucciones se codificaban a mano.

El programador insertaba su trabajo y esperaba su turno.

Exista un desaprovechamiento inadecuado del computador ("tiempos muertos de la CPU").

Disparidad de tiempos de ejecucin entre la CPU y los dispositivos de E/S.

En 1950 aparecen las tarjetas perforadas. Segunda generacin (1955-1965)

Aparicin de los transistores.

Se especializa el personal (diseadores, analistas, ...).

Se desarrollan los primeros sistemas operativos.

Se procesan los trabajos por lotes ("batch").

El S.O. se entiende como un programa de control que planifica los trabajos.

Tercera generacin (1965-1980)

Aparecen los circuitos integrados y la multiprogramacin.

Existen muchas computadoras diferentes con S.O. muy diferentes.

Se suministran una gran cantidad de programas de utilidad.

Los S.O. son complejos.

Se utilizan dispositivos virtuales como las tcnicas de SPOOL.

Multiprocesamiento (sistemas compuestos de varios procesadores).

Surgimiento de la Ingeniera del software.

Separacin entre la venta de hardware y software. Cuarta generacin (1980-2000)

Circuitos LSI (alta escala de integracin) y, posteriormente, VLSI.

Relanzamiento de los ordenadores personales.

Crecimiento del software para las computadoras personales.

Crecimiento de las redes de computadoras que ejecutan S.O. en red y distribuidos.

Quinta generacin (2000-...)

Aparicin de las computadoras de bolsillo (PDA, Personal Digital Assistant) como ampliacin de las agendas electrnicas.

Los S.O. se adaptan a estas nuevas computadoras y telfonos mviles (mucho ms pequeos que una computadora).




1.4 Clasificacin de los Sistemas Operativos Segn su entorno de funcionamiento: A. Nmero de usuarios que puede soportar:

S. O. monousuarios

S. O. multiusuarios B. Propsito para el que fueron diseados:

S. O. de propsito general

S. O. de propsito especfico

S. O. de tiempo real: proveen una respuesta dentro de unos intervalos de tiempo bien definidos a priori.

S. O. de tolerancia a fallos: capaces de detectar errores (hardware y software) y darles solucin.

S. O. virtuales: ejecutan a otros S. O. concurrentemente en la misma mquina.

C. Modo en el que se trabaja con ellos:

S. O. off-line (batch)

S. O. on-line (interactivo) D. Hardware del ordenador: 1. Nmero de procesadores

S. O. monoprocesador

S. O. multiprocesador 2. Situacin de la memoria principal:

S. O. centralizado

S. O. distribuido Tipos de Sistemas Operativos 1. Monoprogramacin Hasta que no finaliza la ejecucin de un programa de usuario no empieza a ejecutarse otro. Consecuencias:

Tiempos muertos de CPU, perifricos, ...

Desaprovechamiento de la Memoria Central (la no ocupada por el proceso).

Entre la finalizacin de un programa y el comienzo del siguiente transcurre un tiempo en el que el ncleo del sistema operativo tiene el control del procesador (CPU).

2. Sistemas por lotes o colas ("sistemas batch") Un sistema por lotes realiza una secuenciacin automtica de trabajos. En l van pasando a ejecucin de uno en uno los programas en espera. La planificacin es muy simple. Los trabajos se procesan, en general, en el orden de admisin (FIFO).




Un S.O. por lotes puede servir muy bien para programas que no requieran interaccin con el usuario y aquellos con tiempos de ejecucin largos, como los programas de nminas, de anlisis estadsticos, etc. Debido a los retardos en el tiempo total de ejecucin, el procesamiento por lotes no es muy conveniente para el desarrollo de programas. 3. S.O. de multiprogramacin Se cargan en memoria principal varios programas que se van ejecutando concurrentemente con lo cual, en un determinado tiempo se estarn ejecutando varios programas. Ventajas: Aprovechamiento de la memoria y mejora de los tiempos muertos del procesador. Un programa en ejecucin se conoce como proceso. El programa es, por tanto, un ente "pasivo" y el proceso un ente "activo". Un S.O. multiproceso o multitarea soporta dos o ms procesos activos simultneamente. Un S.O. de multiprogramacin soporta mltiples procesos concurrentes y, adems, permite que residan simultneamente en la memoria principal las instrucciones y datos procedentes de dos o ms procesos disjuntos. La multiprogramacin implica multiproceso pero el multiproceso no implica multiprogramacin. Tipos de multiprogramacin:

Clsica

Tratamiento paralelo

Tiempo compartido Multiprogramacin clsica El planificador del procesador da el turno a un programa determinado. Cuando ste tiene que realizar una operacin de E/S, le da el control del procesador a otro programa y as sucesivamente. Cuando un programa finaliza una operacin de E/S, el perifrico se lo comunica a la CPU (mediante una interrupcin) para cederle el control la prxima ocasin que le toque su turno. Problema: Monopolizacin de la CPU por parte de programas con mucho clculo y poca E/S. Tratamiento paralelo A cada uno de los programas en memoria se le asigna un intervalo de tiempo fijo o periodo T llamado "cuantum" (dcimas de segundo). Al finalizar el cuantum asignado a un programa, el control de la CPU pasa al siguiente programa y as sucesivamente. La cuenta del tiempo se realiza mediante un circuito contador activado por el reloj de la CPU (temporizador digital). Al transcurrir el periodo T se genera una interrupcin de la CPU. Tiempo compartido




Se asigna el control de la CPU a un nuevo programa interrumpiendo al anterior siempre que este ltimo agote su cuantum de tiempo o que entre en la ejecucin de una instruccin de E/S. La CPU trabaja el 100% en determinados intervalos segn el tipo de carga. 4. S.O. de secuencias mltiples o colas paralelas (multisecuencias) Permiten coexistir en memoria en ejecucin concurrente distintos tipos de trabajos (organizados en colas diferentes). Los trabajos se introducen en las distintas colas las cuales contienen distintas caractersticas (tiempo de CPU, prioridades, etc.) que deben reunir los trabajos. En ejecucin concurrente habr un trabajo por cada cola que exista. Pueden existir trabajos de tipo interactivo. 5. Sistemas de bases de datos Estos S.O. mantienen una gran cantidad de datos que pueden ser consultados en busca de una determinada informacin que debe suministrarse en un periodo razonable de tiempo. La B.D. puede ser frecuentemente modificada para mantener la informacin actualizada y se evitan las operaciones simultneas sobre los mismos datos. 6. Sistemas en tiempo real Un S.O. en tiempo real se caracteriza por el procesamiento de una actividad interrumpida, en la mayora de los casos, por sucesos externos aleatorios. El procesamiento de un suceso. particular viene acompaado por secuencias de tareas que se deben de realizar dentro de rgidas restricciones de tiempo. Un suceso puede ser: La recepcin de un dato (procedente, por ejemplo, de un sensor). La demanda de servicio de un dispositivo en lnea. Un sistema en tiempo real monitoriza y controla el sistema con mnima intervencin humana. Slo interviene en fallos del sistema o cuando se violan algunos lmites. El sistema est completamente dedicado a la aplicacin de control y debe estar configurado para garantizar respuestas rpidas en el tiempo incluso. con cargas pesadas. Los procesos suelen residir permanentemente en memoria principal para proporcionar tiempos de respuesta rpidos. El entorno es tal que la utilizacin del equipo es menos importante que la respuesta al entorno. Ejemplos: Lneas de produccin, semforos de trfico, equipamiento telefnico, control de vuelo, aplicaciones militares, etc. Es importante que el procesador pueda responder muy rpidamente a interrupciones externas y determinar intervalos de tiempo con una precisin muy alta. 7. Sistemas multiprocesador. Redes y sistemas distribuidos Una red interconecta varias computadoras ("hosts"), cada una de las cuales puede proporcionar servicios de computacin a los usuarios de la red. Las redes estn conectadas por subsistemas de comunicaciones y uno o varios




tipos de enlaces de comunicaciones como pueden ser las lneas telefnicas, canales de satlite, cables coaxiales y enlaces de microondas. Tipos de aplicaciones de procesamiento distribuido:

Redes de recursos compartidos: Los recursos de las diferentes computadoras se ponen a disposicin de las otras computadoras. La red proporciona los mecanismos para crear la ilusin de que los dispositivos remotos estn disponibles en el sistema local.

Redes de computacin distribuida: Realiza actividades de multitarea como pueden ser el control de procesos o de bases de datos, etc. Ej.: Planta de fabricacin de una compaa en todo un pas.

Redes de comunicacin remota: Proporcionan los medios para que los usuarios puedan acceder a instalaciones remotas de la forma ms econmica posible.

Un sistema operativo para red es una coleccin de software y protocolos asociados que permiten a varias computadoras autnomas que se encuentran interconectadas por una red de computadoras, ser utilizadas conjuntamente de una manera conveniente y econmica. Los S.O. para redes se clasifican en:

S.O. en red (NOS, Network Operating System)

S.O. distribuidos (DOS, Distributed Operating System) S.O. en red Cada uno de los hosts de la red utiliza su propio S.O. que no es de red. La red est controlada por los programas de usuario ejecutados en los diferentes hosts. Los usuarios conocen la existencia de mltiples computadoras y pueden conectarse a mquinas remotas y copiar archivos de una mquina a otra. Cada mquina tiene sus propios usuarios y ejecuta su S.O. S.O. distribuidos Los S.O. individuales de los hosts quedan descartados y se implementa un nico sistema operativo para toda la red. Aparece a los usuarios como un sistema uniprocesador aunque conste de muchos procesadores. Los usuarios no saben dnde se ejecutan sus programas ni dnde se localizan sus archivos. Por ello, la caracterstica principal de un DOS es la transparencia.




1.5 Estructuras (Niveles o Estratos de Diseo) Sistemas monolticos. Descripcin: sin estructura definida. Se componen de un conjunto de procedimientos, donde cada uno de ellos puede llamar a todos los dems. Proceso para requerir un servicio del S.O.: el programa de usuario coloca los parmetros necesarios en los lugares previamente definidos, y seguidamente ejecuta una llamada al supervisor (se cambia de modo usuario a modo supervisor), transfiriendo el control al S.O. que examina dichos parmetros y determina el procedimiento que debe invocar. Cuando se complete la llamada devuelve el control al programa de usuario. S.O. con una pequea estructura de niveles:

Sistemas en estratos. Descripcin: se organiza en una jerarqua de estratos, estando construido cada uno de ellos sobre el otro que tiene menor jerarqua que l. Ejemplos: A. THE (Dijkstra, 1968): sistema de procesamiento por lotes.




B. MULTICS: anillos concntricos alrededor del hardware, donde los internos son ms privilegiados que los externos.

Mquinas virtuales. Descripcin: crea ilusiones (mquinas virtuales) de la mquina real, permitiendo que en cada mquina virtual se ejecute un S.O. distinto. El programa de control es el que se ejecuta directamente sobre el propio hardware y ofrece al nivel inmediatamente superior varias mquinas virtuales.

Modelo Cliente-Servidor. Descripcin: su objetivo es minimizar el kernel desplazando el cdigo de todos sus servicios a estratos lo ms superiores posibles. Para ello, la mayora de sus funciones se implementan como procesos de usuario, denominados procesos servidores, de forma que cuando un proceso de usuario llamado proceso cliente, necesita un servicio del S.O. lo que hace es enviar un mensaje al proceso servidor correspondiente, que realiza el trabajo y devuelve la respuesta.




El kernel lo nico que hace es implementar la comunicacin entre clientes y servidores y entre servidores y el hardware

Estructura orientada al objeto. Descripcin: se basan en una coleccin de objetos, donde las funciones del sistema son un tipo de objeto (ficheros, dispositivos, etc.). La interaccin entre dichos objetos viene determinada por las capacidades que cada uno tenga para actuar con el otro. El kernel es el responsable del mantenimiento de las definiciones de los tipos de objetos soportados y del control de los privilegios de acceso a los mismos. Cuando un programa desee realizar una operacin sobre un objeto determinado, deber ejecutar una llamada al sistema, indicando qu derechos tiene para poder utilizarlo y qu operacin intenta llevar a cabo. Como resultado de dicha llamada, el sistema validar la peticin y, si puede ser aceptada, permitir la realizacin de dicha operacin.




1.6 Ncleo del Sistema Operativo Caractersticas del ncleo El kernel se ejecuta con las interrupciones desactivadas y es la parte del S. O. ms cercana al hardware, por ello suele estar codificado en ensamblador o lenguaje mquina, adems de estar residente en memoria principal. El resto del S. O. se suele programar en lenguajes de alto nivel. Funciones bsicas del kernel: a) Manipulacin de interrupciones; b) Inhabilitacin y habilitacin de interrupciones; c) Creacin y destruccin de procesos; d) Cambio de estado de un proceso; e) Despachar un proceso; f) Comunicacin entre procesos; g) Manipulacin de los Process Control Block (PCB); h) Soporte para servicios de ms alto nivel. Componentes del ncleo.

Administrador de procesos;

Controlador de interrupciones;

Manejador de la comunicacin entre procesos. 1.6.1 Administrador de Procesos (Dispatcher) Se encarga de asignar los procesadores a los diferentes procesos, por lo tanto debe actuar cuando se debe comprobar si es necesario cambiar el proceso que est activo, es decir en las siguientes situaciones:

Cuando el proceso. que esta activo se bloquea;

Cuando un proceso se desbloquea pasando a estado listo y debido al algoritmo de planificacin este puede desplazar al que esta activo;

Cuando un proceso debe pasar de activo a listo y por lo tanto otro pasara de listo a activo.




1.6.2 Controlador de Interrupciones Tipos de interrupciones:

Interrupciones internas: producidas por los propios procesos;

Interrupciones externas: producidas por elementos ajenos a los procesos.

Objetivos del controlador de interrupciones: 1. Determinar el origen de la interrupcin. Mtodos:

Ejecutando un trozo de cdigo formado por estructuras de decisin anidadas (cadena de saltos);

Que el hardware sea capaz de distinguir las diferentes fuentes de interrupcin y transferir el control a su correspondiente rutina de tratamiento;

Primero el hardware reconoce a que grupo pertenece la interrupcin y luego mediante una pequea cadena de salto asociada a ese grupo se identifica la interrupcin.

2. Dar servicio a la interrupcin. El controlador inicia el servicio de la interrupcin invocando a la rutina de tratamiento adecuada. Estas rutinas de tratamiento deben ser lo ms cortas posibles, por lo tanto, en general, llevan a cabo acciones mnimas. Es posible que una interrupcin vare el estado de un proceso, en cuyo caso ser la propia rutina de tratamiento la que cambie dicho estado accediendo al PCB del proceso. Mientras que acta el controlador de interrupciones estas estn inhabilitadas. Sin embargo, esto no se puede realizar en sistemas donde determinadas interrupciones requieren una respuesta rpida. Por ello, surge la nocin de prioridad entre las interrupciones, de forma que una interrupcin puede ser interrumpida si llega otra con una prioridad ms alta. En definitiva, solo se inhabilitan las interrupciones de igual o menor prioridad. 1.6.3 Primitivas de Comunicacin Esquemas de comunicacin: 1) Memoria compartida: - Los procesos se comunican a travs de variables compartidas. - El sistema operativo provee la memoria compartida. - El programador tiene la responsabilidad de proveer comunicacin. 2) Sistema de mensajes: - El sistema operativo tiene la responsabilidad de proveer comunicacin. - Operaciones: * SEND (enviar) * RECEIVE (recibir) Los mensajes pueden ser de tamao fijo o variable




Enlace de Comunicacin (Link) Debe existir entre dos procesos que deseen comunicarse. Estos pueden ser: A) Fsicos: - Memoria Compartida. - Bus de Hardware. - Red de Interconexin. B) Lgico: Deben definirse e implementarse. Tipos de Comunicacin. A- Directa: Proceso fuente y proceso destino. - Operaciones: SEND (P,Mensaje) RECEIVE (Q,Mensaje) - Simtrica: Comunicacin uno a uno. Propiedades Del Link En La Comunicacin Directa

Se establece automticamente entre cada par de procesos comunicantes.

Entre cada par de procesos que se comunican existe slo un "LINK".

Un Link est asociado exactamente con dos procesos.

El link es bidireccional. B. Indirecta: Los mensajes son enviados y recibidos a travs de buzones - Cada buzn tiene su propia identificacin. - Operaciones: SEND(A,mensaje) RECEIVE(A,mensaje) donde A es el buzn. - Asimtrica: Es de uno a varios. Propiedades del Link en la Comunicacin Indirecta.

Se establece entre dos procesos si tiene un buzn compartido.

Un Link puede estar asociado con ms de dos procesos.

Entre cada par de procesos que se comunican puede existir ms de un Link.

Puede ser unidireccional o bidireccional. Propietarios de un Buzn (Mailbox). - Un proceso P = Propietario -> P slo lee de A. Q = Usuario -> Q slo escribe en A




- El sistema Operativo ofrece mecanismos para:

Crear un nuevo buzn.

Enviar y recibir mensajes.

Destruir un buzn.

Pipes: Generalmente se usa entre un proceso productor y un proceso consumidor. Los mensajes son de tamao fijo. Buffering: Se refiere a la cantidad de mensajes que pueden residir temporalmente en un link. Esta propiedad puede verse como una "cola de mensajes que est relacionada (unida) al link. Formas (Colas)

Capacidad cero: - El link no puede tener ningn mensaje esperando en el.

Capacidad Limitada: A lo sumo n mensajes pueden residir en la cola del link.

Capacidad Ilimitada: La cola tiene potencialmente longitud infinita. ENTREGA DE EVIDENCIAS UNIDAD I

1. INVESTIGACION DOCUMENTAL PARA ELABORACION DE ENSAYO 2. VISITA A EMPRESA PARA CONOCER SUS SISTEMAS OPERATIVOS 3. REPORTE DE VISITA A EMPRESA 4. PRESENTACION DEL ENSAYO Y VISITA INDUSTRIAL 5. PRACTICAS UNIDAD I

Buzn P

Q

A




Unidad 2. Administracin de Procesos y del Procesador 2.1 Concepto de Proceso Un programa es una secuencia de instrucciones o acciones definidas a priori, que pueden ser ejecutadas por parte de un procesador. Un proceso es una secuencia de acciones derivadas de la ejecucin de una serie de instrucciones. Esto implica que:

Un proceso puede requerir la ejecucin de uno o varios programas; y

Que un programa puede formar parte de ms de un proceso. Un proceso se lleva a cabo por la accin de un agente (procesador) que ejecuta el programa asociado. Es decir, un procesador ejecuta un proceso, o un proceso se ejecuta sobre un procesador. El programa o programas asociados a un proceso no tienen porqu estar implementados en software. En la literatura, sobre todo en el mbito de sistemas operativos, existen tambin los conceptos de hilos (threads'') y de tareas (tasks'' o jobs'') que son parecidos al concepto de proceso, an que se distinguen en varios aspectos (por ejemplo, en el acceso a los recursos, en la vista de memoria, en la priorizacin etc.). En nuestro contexto no vamos a diferenciar mucho ms. Solo destacamos el concepto de hilo que se usa casi siempre en la programacin moderna. Un programa multi-hilo intercala varias secuencias de instrucciones que usan los mismos recursos (sobre todo aprovechan de una memoria comn) bajo el techo de un slo proceso en el sentido de unidad de control del sistema operativo, (que no se debe confundir con nuestro concepto abstracto de proceso). El cambio de contexto de un hilo al siguiente dentro del procesador se realiza rpidamente. Cmo se representan los Procesos? Se representan utilizando los conocidos como Bloques de control de proceso (PCB) (Bloque de contexto o descriptor de proceso), los cuales contienen la siguiente informacin sobre ese proceso:

Estado actual;

Identificacin;

Punteros para localizar la memoria que usa;

rea para preservar registros;

Punteros para asignar recursos.




2.2 Estados y Transiciones de los Procesos Durante su vida, un proceso puede pasar por una serie de estados discretos, algunos de ellos son:

En ejecucin: El proceso ocupa la CPU actualmente, es decir, se est ejecutando.

Listo o preparado: El proceso dispone de todos los recursos para su ejecucin, slo le falta la CPU.

Bloqueado: Al proceso le falta algn recurso para poder seguir ejecutndose, adems de la CPU. Por recurso se pueden entender un dispositivo, un dato, etc. El proceso necesita que ocurra algn evento que le permita poder proseguir su ejecucin.

Hay otros estados de los procesos, pero en el presente documento se tratarn estos tres. Por sencillez, se considera un sistema con una sola CPU, aunque no es difcil la extensin a mltiples procesadores. Solamente puede haber un proceso en ejecucin a la vez, pero pueden existir varios listos y varios pueden estar bloqueados. As pues, se forman una lista de procesos listos y otra de procesos bloqueados. La lista de procesos listos se ordena por prioridad, de manera que el siguiente proceso que reciba la CPU ser el primero de la lista. La lista de procesos bloqueados normalmente no est ordenada; los procesos no se desbloquean (es decir, no pasan a ser procesos listos) en orden de prioridad, sino que lo hacen en el orden de ocurrencia de los eventos que estn esperando. Como se ver ms adelante, hay situaciones en las cuales varios procesos pueden bloquearse esperando la ocurrencia del mismo evento; en tales casos es comn asignar prioridades a los procesos que esperan.




Operaciones Bsicas sobre Procesos 1. Crear un proceso: dar nombre al proceso, insertarlo en la lista de

procesos en estado listo, determinar su prioridad inicial, crear el PCB del proceso, y asignarle los recursos iniciales del proceso.

2. Destruir un proceso: devolver al sistema los recursos que tiene asignado, eliminarlo de todas las listas del sistema y borrar su PCB.

3. Cambiar la prioridad de un proceso. 4. Bloquear un proceso. 5. Despertar un proceso. 6. Despachar un proceso.




2.3 Procesos Ligeros (Hilos o Hebras) Uno de los problemas ms importantes en los ordenadores con un procesador es el de la ejecucin simultnea de varios programas (procesos). Este paralelismo no se puede realizar de forma completa dada la exclusividad del procesador y de las zonas de memoria que necesita cada programa. Un mtodo para lograr el paralelismo consiste en hacer que varios procesos cooperen y se sincronicen mediante memoria compartida. Otra alternativa es el empleo de mltiples hilos de ejecucin en un solo espacio de direcciones. Este es el objetivo principal de la utilizacin de los procesos ligeros. Un proceso ligero (thread o hebra) es un programa en ejecucin que comparte la imagen de la memoria y otras informaciones con otros procesos ligeros. Es un flujo de control perteneciente a un proceso (a veces se habla de tareas con threads).

La sobrecarga debida a su creacin y comunicacin es menor que en los procesos pesados. Cada hilo pertenece a un proceso pesado. Los procesos ligeros pueden, o no, compartir cierta informacin. Estas informaciones se enlistan a continuacin: Informacin compartida Espacio de memoria Variables globales Archivos abiertos Procesos hijos Temporizadores Seales y semforos Contabilidad Informacin No compartida Contador de programa Pila Registro Estado del proceso ligero




Un proceso ligero puede estar ejecutando, listo o bloqueado.

La ventaja de usar un grupo de hilos en vez de usar un programa secuencial normal es que muchas de las operaciones pueden ser llevadas a cabo en paralelo, y as estos eventos pueden ser manejados inmediatamente cuando llegan. La ventaja de usar un grupo de hilos en vez de usar un grupo de procesos es que el intercambio de contexto entre los hilos es mucho mas rpido que el intercambio de contexto entre procesos (el intercambio de contexto significa que el sistema intercambia de la ejecucin un hilo o proceso, a otro hilo o proceso). Tambin, la comunicacin entre dos hilos es a menudo ms rpida y ms fcil de implementar que la comunicacin entre dos procesos. Por otra parte, debido a que los todos los hilos en un grupo usan el mismo espacio de memoria, si uno de ellos corrompe el contenido de la memoria, los otros hilos podra sufrir lo mismo. Con los procesos, el sistema operativo normalmente protege los procesos de otros, y as, si uno corrompe su propio espacio de memoria, el resto de procesos no se perjudicarn. Otra ventaja del uso de procesos es que ellos corren en diferentes maquinas, mientras que los hilos tienen que correr en la misma maquina. Entre algunas de sus aplicaciones estn:

Utilizacin de los hilos en servidores. Los servidores pueden utilizar las ventajas del multihilo, creando un hilo gestor diferente para cada peticin entrante de un cliente.

Utilizacin de los hilos en interfaces de usuario. Se pueden obtener aumentos de rendimiento empleando un hilo para interactuar con un usuario, mientras se pasan las peticiones a otros hilos para su ejecucin.

Utilizacin de los hilos en el diseo de un kernel multihilo: para un sistema operativo distribuido, esto quiere decir que distribuya diferentes tareas entre los hilos.




2.4 Concurrencia y Secuenciabilidad Puede verse la concurrencia de procesos como la ejecucin simultnea de varios procesos. Si tenemos un multiprocesador o un sistema distribuido la concurrencia parece clara, en un momento dado cada procesador ejecuta un proceso. Se puede ampliar el concepto de concurrencia si entendemos por procesado concurrente (o procesado paralelo) la circunstancia en la que de tomar una instantnea del sistema en conjunto, varios procesos se vean en un estado intermedio entre su estado inicial y final. Esta ltima definicin incluye los sistemas multiprogramados de un nico procesador. Tipos de concurrencia:

Los distintos procesos dentro de un ordenador no actan de forma aislada. Por un lado, algunos procesos cooperan para lograr un objetivo comn. Por otro lado, los procesos compiten por el uso de unos recursos limitados, como el procesador, la memoria o los ficheros. Estas dos actividades de cooperacin y competicin llevan asociada la necesidad de algn tipo de comunicacin entre los procesos. La velocidad de un proceso con respecto a otro es impredecible ya que depende de la frecuencia de la interrupcin asociada a cada uno de ellos y cun a menudo y de por cunto tiempo tiene asignado cada proceso un procesador. Diremos, pues, que un proceso se ejecuta asncronamente con respecto a otro, es decir, sus ejecuciones son independientes. Sin embargo, hay ciertos instantes en lo que los procesos deben sincronizar sus actividades. Son estos puntos a partir de los cuales un proceso no puede progresar hasta que otro haya completado algn tipo de actividad. Competencia entre los procesos Los recursos de un sistema pueden clasificarse como compartibles, lo que significa que pueden ser utilizados por varios procesos de forma concurrente, o no compartibles, lo que equivale a que su uso se restrinja a un slo proceso a la vez. El hecho de que un recurso no sea compartible deriva de una de las dos razones siguientes:

La naturaleza fsica del recurso hace que sea imposible compartirlo. Un ejemplo lo constituye una impresora, si una impresora fuera utilizada por varios procesos simultneamente sus salidas se entremezclaran en el papel.




El recurso es tal que si es usado por varios procesos de forma concurrente la accin de uno de ellos puede interferir con la de otro. Un ejemplo comn lo constituye un fichero que contiene unos datos accesibles desde ms de un proceso, y modificables al menos por uno de ellos.

Dentro de la categora de recursos no compartibles se incluirn la mayora de los perifricos (los discos no), los ficheros de escritura y las zonas de memoria sujetas a modificacin. Los recursos compartibles incluirn la CPU, los ficheros de lectura, y las zonas de memoria que contengan rutinas puras o bien datos que no estn sujetos a modificacin. Los procesos concurrentes entran en conflicto cuando compiten por el uso del mismo recurso; dos o ms procesos necesitan acceder a un recurso durante su ejecucin. Cada proceso debe dejar tal y como est el estado del recurso que utilice. La ejecucin de un proceso puede influir en el comportamiento de los procesos que compiten. Por Ej. Si dos procesos desean acceder a un recurso, el sistema operativo le asignar el recurso a uno y el otro tendr que esperar. Cuando hay procesos en competencia, se deben solucionar tres problemas de control, siendo el primero de ellos la necesidad de exclusin mutua. Suponiendo que dos procesos quieren acceder a un recurso no compartible. A estos recursos se les llama "recursos crticos" y la parte del programa que los utiliza es la "seccin crtica del programa. Es importante que slo un programa pueda acceder a su seccin crtica en un momento dado. Hacer que se cumpla la exclusin mutua provoca un interbloqueo. Otro problema es la inanicin si tres procesos necesitan acceder a un recurso, P1 posee al recurso, luego lo abandona y le concede el acceso al siguiente proceso P2, P1 solicita acceso de nuevo y el sistema operativo concede el acceso a P1 YP2 alternativamente, se puede negar indefinidamente a P3 el acceso al recurso. El control de competencia involucra al sistema operativo, porque es el que asigna los recursos. 2.4.1 Exclusin Mutua de Secciones Crticas Exclusin Mutua es la comunicacin requerida entre dos o ms procesos que se estn ejecutando en paralelo y que necesitan a la vez el uso de un recurso no compartible. Consiste en asignar el recurso no compartible a slo uno de los procesos, mientras que los otros deben permanecer a la espera hasta que finalice la utilizacin de dicho recurso por el proceso al que se le asigno. Cuando este proceso termine, el recurso ser asignado a uno de los procesos en espera. Se asegura el correcto uso del recurso. Seccin crtica o regin crtica es el trozo de cdigo donde un proceso hace uso de un recurso no compartible, por lo tanto debe ejecutarse en exclusin




mutua. Las secciones crticas deben ser ejecutadas lo ms rpido posible y adems deben ser cuidadosamente codificadas. Idear soluciones que garanticen la exclusin mutua es uno de los problemas fundamentales de la programacin concurrente. Muchas son las alternativas y tipos de mecanismos que se pueden adoptar. La seleccin de las operaciones primitivas adecuadas para garantizar la exclusin mutua de las secciones crticas es una decisin primordial en el diseo de un sistema operativo. Al menos, una solucin apropiada debera cumplir las cuatro condiciones siguientes:

1. Que no haya en ningn momento dos procesos dentro de sus respectivas secciones crticas.

2. Que no hagan suposiciones a priori sobre las velocidades relativas de los procesos o el nmero de procesadores disponibles.

3. Que ningn proceso que est fuera de su seccin crtica pueda bloquear a otros.

4. Que ningn proceso tenga que esperar un intervalo de tiempo arbitrariamente grande para entrar en su seccin crtica.

2.4.2 Sincronizacin de Procesos en Secciones Crticas Sincronizacin es la comunicacin requerida entre dos o ms procesos con el fin de sincronizar sus actividades. Grficamente:

Un proceso es cooperativo si puede afectar o ser afectado por los otros procesos que se estn ejecutando en el sistema. La cooperacin entre procesos requiere: la ejecucin concurrente de los mismos, mecanismos de comunicacin y mecanismos de sincronizacin Al haber procesos concurrentes se deben emplear mecanismos para asegurar la consistencia de los datos. Como ejemplo, supongamos que tenemos 3 procesos concurrentes que quieren modificar un mismo archivo. Si los 3 acceden a este al mismo tiempo el archivo quedar con valores incorrectos. Para resolver problemas como este se




ide la seccin crtica (descrita anteriormente). Slo puede haber una seccin crtica en ejecucin por vez, as nos aseguramos que los datos quedan consistentes. El problema de la seccin crtica consiste en disear un protocolo que los procesos puedan usar para cooperar de esta forma. Cualquier solucin al problema de la seccin crtica deber satisfacer los tres requisitos siguiente:

Exclusin mutua.- Si el proceso Pi est ejecutndose en su seccin crtica, los dems procesos no pueden estar ejecutando sus secciones crticas.

Progreso.- Si ningn proceso est ejecutando su seccin crtica, y algunos procesos desean entrar en sus correspondientes secciones crticas, slo aquellos procesos que no estn ejecutando sus secciones restantes pueden participar en la decisin de cul ser el siguiente que entre en su seccin crtica, y esta seleccin no se puede posponer indefinidamente.

Espera limitada.- Existe un lmite en el nmero de veces que se permite que otros procesos entren en sus secciones crticas despus de que un proceso haya hecho una solicitud para entrar en su seccin crtica y antes de que la misma haya sido concedida.

Se usan dos mtodos generales para gestionar las secciones crticas en los sistemas operativos: 1. Kernels apropiativos.- Permite que un proceso sea desalojado mientras se est ejecutando en modo kernel. 2. Kernels no apropiativos.- No apropiativo no permite que un proceso que se est ejecutando en modo kernel sea desalojado. Hardware de Sincronizacin En sistemas de un procesador, el problema de las secciones crticas podra ser resuelto simplemente si pudiramos deshabilitar las interrupciones mientras una variable compartida est siendo actualizada. Esta solucin no es factible para un sistema con varios procesadores debido a la demora que implica el pasaje de mensajes. En muchos sistemas existen instrucciones de hardware que pueden ser usadas para resolver el problema de las secciones crticas. Estas instrucciones permiten ejecutar atmicamente las operaciones de: chequear y modificar el contenido de una palabra, o intercambiar el contenido de dos palabras




2.4.2.1 Mecanismos de Semforos Las soluciones por hardware presentadas no son fciles de generalizar a problemas ms complejos. Para solucionar problemas de procesos concurrentes, se diseo un S.O. como un conjunto de procesos secuenciales, eficientes y fiables para dar soporte a la cooperacin. Los procesos de usuario podran utilizar estos mecanismos si el procesador y el S.O. los hacan disponible. El principio fundamental es el siguiente, 20 procesos pueden cooperar por medio de simples seales, de manera que se pueda obligar a un proceso a detener en una posicin determinada hasta que reciba una seal especfica. Para la sealizacin se usan variables especiales llamadas semforos "S", los procesos ejecutan las primitivas wait(s) si la seal aun no se transmiti, el proceso se suspende hasta que tiene lugar la transmisin. A los semforos se los contemplan como variables que tienen un N entero sobre el que se definen las siguientes operaciones: un semforo puede iniciarse con un valor negativo la operacin wait disminuye el valor del semforo. Si el valor no es positivo el proceso que ejecuta wait se bloquea. Las operaciones signal incrementan el N del semforo. Si el valor es positivo se desbloquea el proceso bloqueado por una operacin wait. No hay forma de examinar o manipular los semforos aparte de estas tres operaciones. Las primitivas wait y signal se suponen atmicas, es decir no pueden ser interrumpidas y cada rutina puede considerarse como un peso indivisible. Un semforo solo puede tomar los valores 0 y 1. Son ms sencillos de implantar y pueden demostrarse que tienen la misma potencia de expresin que los semforos generales.




En ambos semforos se emplean una cola para mantener los procesos en espera, la cuestin reside en el orden en que se retiran los procesos de la cola. La poltica utilizada el la de FIFO; el proceso que estuvo bloqueado durante mas tiempo se libera de la cola, se denomina semforo robusto (incluye esta estrategia). Un semforo dbil no especifica el orden en que se retiran los procesos de la cola. Los semforos robustos garantizan la inexistencia de inanicin en el algoritmo de exclusin mutua, pero no as en los semforos dbiles, se supone que los semforos son siempre robustos ya que son los ms adecuados y porque son los tipos de semforos que ms incluyen los S.O. Implementacin de los semforos. Como se menciono anteriormente es impredecible que las operaciones wait y signal sean implementadas como primitivas atmicas. La esencia del problema del productor/consumidor, es la exclusin mutua: solo 1 proceso puede manipular un semforo a la vez, en una operacin wait o signal. Se pueden utilizar cualquier esquema de software con los algoritmos de Dekker o Peterson los que suponen una sobrecarga de procesos sustancial. Otra alternativa es usar uno de los esquemas de soporte del hardware p/la exclusin mutua. 2.4.2.2 Mecanismos de Monitoreo Son mecanismos de sincronizacin de nivel ms alto que semforos. La construccin se realiza a nivel de lenguaje de programacin que controla el acceso a datos compartidos. Un tipo monitor tiene un conjunto de operaciones definidas por el programador que gozan de la caracterstica de exclusin mutua dentro del monitor. Los monitores son estructuras de un lenguaje de programacin que ofrecen una funcionalidad equivalente a las de los semforos pero son ms fciles de controlar. La estructura de monitor se ha implementado en varios lenguajes de programacin como: Pascal concurrente, Modulo-2, Java, etc. En concreto, para una lista enlazada se puede necesitar un cierre que bloquee todas las listas enlazadas o bien un cierre por cada elemento de una lista. Monitores con Seales: (definicin de Hoare) Un monitor es un modulo de software que consta de uno o ms procedimientos, una secuencia de inicio y uno datos locales. Sus caractersticas son las siguientes:

Solo los procedimientos del monitor acceden a variables de datos locales.

Un proceso entra en el monitor invocando a uno de sus procedimientos.

En el monitor solo un proceso puede ser ejecutado en un momento dado; cualquier otro proceso quedara suspendido esperando la disponibilidad del monitor.




Al ser un proceso por vez, el monitor puede ofrecer un servicio de exclusin mutua fcilmente. As una estructura de datos puede protegerse situndola dentro de un monitor. Los monitores deben ofrecer herramientas de sincronizacin. Por ejemplo: si un proceso llama a un monitor y una vez dentro de l el proceso queda suspendido esperando alguna condicin, har falta un servicio que libere al monitor y lo deje disponible para el siguiente proceso. Mas tarde cuando la condicin se cumpla el proceso suspendido podr regresar al monitor y ejecutarse desde el momento de la suspensin. El monitor proporciona variables de condicin que son accesibles solo desde dentro del monitor. Hay dos funciones para operar variables de condicin:

cwait (c): suspende la ejecucin del proceso que llama bajo la condicin "c". El monitor est ahora disponible para otro proceso.

csignal (c): retorna la ejecucin de un proceso suspendido despus de un cwait, bajo la misma condicin. Si hay varios procesos elige uno de ellos.

Si un proceso de monitor ejecuta un csignal y no hay tareas esperando entonces el csignal de pierde. Aunque un proceso puede entrar al monitor llamando a cualquiera de sus procedimientos, se puede decir que el monitor tiene un solo punto de acceso, custodiado para que solo un proceso este en el monitor en un instante dado. Si existen otros procesos tratando de entrar al monitor, estos se colocan en una cola de procesos suspendidos esperando la disponibilidad del monitor. Un proceso dentro de un monitor puede suspenderse a s mismo, temporalmente, bajo la condicin X ejecutando cwait(x), entonces se coloca en una cola de procesos que esperan que cambie la condicin X entonces ejecuta un csignal(x) que avisa a la cola de condicin correspondiente de que la condicin a cambiado. En el cdigo se puede apreciar la solucin al problema de productor / consumidor usando monitores: El modulo monitor, buffers_acotado, controla el buffer para almacenar y retirar caracteres. El monitor incluye dos variables de condicin: No-lleno es verdadero su hay lugar para agregar al menos un carcter. No-vaci es verdadero si hay al menos un carcter en el buffer. Un productor solo puede agregar caracteres al buffer mediante el procedimiento aadir del monitor; el productor no tiene acceso directo al buffer. El procedimiento comprueba si hay espacio en el buffer, mediante la condicin no-lleno, si no lo hay el proceso queda suspendido y cualquier otro proceso




(consumidor o productor) puede entrar al monitor. Luego, cuando el buffer ya no esta lleno, el proceso se retira de la cola y es reactivado. Luego de aadir un carcter el proceso activa la condicin no-vaci. La estructura misma del monitor garantiza la exclusin mutua (solo un proceso por vez puede acceder al buffer). Sin embargo, el programador debe situar correctamente las primitivas cwait( ) y csignal( ) en el monitor para evitar que los procesos depositen elementos en un buffer lleno o los extraigan de uno vaci. Un proceso sale del monitor inmediatamente despus de ejecutar csignal( ). Si csignal( ) se ejecuta antes del final entonces ese proceso libera el monitor y esta colocado en una lista de procesos suspendidos. Un nuevo proceso puede entrar el monitor. Si no hay procesos esperando en la condicin X, la ejecucin de csignal (x) no tiene efecto. Es posible cometer errores en la sincronizacin de los monitores, por ejemplo, si se omite cualquiera de las funciones csignal() en el monitor buffer _ acotado los procesos que entran en la cola de condicin permanecen colgados permanentemente. Sin embargo la ventaja de los monitores es que todas las funciones de sincronizacin estn incluidas dentro del monitor, lo que permite una fcil deteccin y correccin de fallas de sincronizacin. Monitores con Notificacin y Difusin (definicin de Lampson y Redell) Son varios los inconvenientes que presenta la solucin de Hoare: -Si el proceso que ejecuta el csignal( ) no ha terminado en el monitor, se necesitaran dos cambios de procesos adicionales: uno para suspender el proceso y otro para reanudarlo. -La planificacin de procesos asociados con las seales debe ser muy fiable. Si un proceso ejecuta un csignal ( ), el proceso de la cola de condicin correspondiente debe activarse de inmediato, antes de que ingrese otro proceso del exterior o cambie la condicin bajo la que se activ el proceso. Otro caso seria que un proceso productor escribe un carcter en el buffer y falla antes de dar la seal, entonces la cola de condicin no-vaca se colgara para siempre. Lampson y Redell desarrollaron una definicin de monitores para el lenguaje MESA. La estructura de mesa reemplaza la primitiva csignal( ) por cnotify( ). Cuando un proceso ejecuta cnotify(x) enva una notificacin a la cola de condicin X, lo cual no significa que el proceso que esta ocupando el monitor vaya a detenerse, simplemente el cnotify(x) avisa al proceso de la cola de condicin correspondiente de que ser reanudado en un futuro cercano. Puesto que esta no garantiza que un proceso exterior entre al monitor, el proceso debe comprobar la condicin nuevamente.




En el cdigo, la sentencia IF se reemplaza por un bucle While, lo cual genera una evaluacin extra de la variable, pero sin embargo no hay cambios de procesos extra. Una modificacin til seria asociar un temporizador de guardia a cnotify( ) que permitira que un proceso que ha esperado durante el intervalo mximo sea situado en estado de listo, independientemente de s se ha notificado la condicin. Con la norma de notificar a los procesos en lugar de reactivarlos, es posible aadir una primitiva de difusin cbroadcast. La difusin provoca que todos los procesos que estn esperando por una condicin se coloquen en el estado de listo. Esto es til cuando un proceso no sabe cuantos procesos deben reactivarse. El mtodo Lampson/Redell es menos propenso a errores debido a que cada procedimiento comprueba la condicin luego de ser despertado, por medio de la instruccin while, un proceso puede realizar una seal o una difusin incorrectamente sin provocar un error en el programa que la recibe. Adems este modelo presta un mtodo mas modular de construccin de programas. Hay dos niveles de condicin que deben satisfacerse para los procesos secuenciales cooperantes.

1. Estructura de datos consistentes: significa que el monitor hace cumplir la exclusin mutua y concluye la operacin de entrada o salida antes de permitir cualquier otra operacin sobre el buffer.

2. La misma condicin del nivel 1 y, adems disponer de suficiente memoria para que este proceso pueda completar su solicitud de asignacin.

2.4.3 Interbloqueo (Deadlock) Un proceso esta interbloqueado si est esperando por un evento determinado que nunca va a ocurrir.




Postergacin indefinida (inanicin o Lockout): cuando un proceso espera por un evento que puede ocurrir pero no se sabe cuando. Condiciones necesarias para que se produzca interbloqueo Coffman, Elphick y Shoshani establecieron las cuatro condiciones necesarias para que se produzca interbloqueo: 1. Condicin de exclusin mutua: los procesos reclaman control exclusivo de los recursos que piden. 2. Condicin de esperar por: los procesos mantienen los recursos que ya les han sido asignados mientras esperan por recursos adicionales. 3. Condicin de no apropiatividad: los recursos no pueden ser extrados de los procesos que los tienen hasta su completa utilizacin. 4. Condicin de espera circular: existe una cadena circular de procesos en la cual cada uno de ellos mantiene a uno o ms recursos que son requeridos por el siguiente proceso de la cadena.

Puntos de estudio del interbloqueo A. Prevencin del interbloqueo: condiciona al sistema para que elimine toda posibilidad de que se produzca interbloqueo. Estrategias:

Negar la condicin de esperar por: cada proceso debe pedir todos los recursos que va a necesitar de golpe. Si el conjunto de todos ellos est disponible, se le asigna todos. Si no esta disponible todo el conjunto completo, no se le asigna ninguno al proceso y tendr que esperar hasta que estn todos disponibles.

Negar la condicin de no apropiatividad: cuando un proceso que tiene recursos le es negada una peticin de recursos adicionales, deber liberar sus recursos y, si es necesario, pedirlos de nuevo junto con los recursos adicionales.

Negar la condicin de espera circular: cuando se instala un recurso se le asigna un nmero exclusivo, de forma que los procesos deben de




solicitar los recursos en orden ascendente de acuerdo a los nmeros asignados a dichos recursos.

B. Evitacin del interbloqueo: condiciona al sistema para que esquive determinadas situaciones con posibilidad de interbloqueo. C. Deteccin del interbloqueo: determinan si existe o no un interbloqueo, e identifica cules son los procesos y recursos implicados en l. D. Recuperacin del interbloqueo: pretenden romper el interbloqueo retirando una o ms de las condiciones necesarias. Estrategias para Resolver Interbloqueos Los resultados de la investigacin sobre el bloqueo mutuo han sido satisfactorios en cuanto a que se han encontrado mtodos limpios y rpidos para manejar la mayora de los problemas ms comunes. Existen cuatro reas de inters relacionadas con los interbloqueos que pueden resumirse como prevencin, tcnicas para evitarlos, deteccin y recuperacin de los mismos. En la prevencin del interbloqueo interesa ajustar el sistema para eliminar toda posibilidad de que ocurra un bloqueo mutuo. La prevencin suele funcionar pero sus mtodos ocasionan, en general, un aprovechamiento pobre de los recursos. No obstante, estos mtodos se utilizan con frecuencia. Las tcnicas que tienen como objetivo evitar el interbloqueo imponen condiciones menos atractivas que en la prevencin, para tratar de obtener un aprovechamiento de los recursos. No elimina como las tcnicas de prevencin todas las posibilidades de que se produzca un bloqueo mutuo, pero se esquiva cuanto est a punto de suceder (algoritmo del banquero de Dijkstra). Los mtodos de deteccin del interbloqueo es utilizan en sistemas que permiten la ocurrencia de los mismos, ya sea de manera voluntaria o involuntaria. Su objetivo es determinar si ha ocurrido un bloqueo mutuo y saber exactamente cules son los procesos y recursos implicados en l. Los mtodos de recuperacin estn ntimamente ligados a los de deteccin. Sirven para eliminar los interbloqueos detectados en un sistema para poder seguir trabajando y para que los procesos implicados puedan terminar su ejecucin y liberen sus recursos. La recuperacin es un problema complejo, en el mejor de los casos, los sistemas se recuperan de un bloqueo mutuo eliminando completamente uno o varios de los procesos implicados. Despus, se inician de nuevo los procesos eliminados, perdindose la mayor parte o todo el trabajo previo realizado por el proceso. 1.- Desentenderse. El Algoritmo de la Avestruz La estrategia ms sencilla es el algoritmo del avestruz: esconder la cabeza bajo tierra y pretender que el problema no existe. La gente reacciona a esta estrategia de distintos modos segn su formacin. Los matemticos consideran que es inaceptable y argumentan que los interbloqueos se deben evitar a toda costa. Los ingenieros se interrogan sobre la frecuencia del problema, la




frecuencia con el que el sistema se para por otras causas y la importancia de los interbloqueos. Si stos se presentan de una vez cada cinco aos, y los sistemas se paran una vez al mes por errores en el hardware, en el compilador o en el sistema operativo, a casi ningn ingeniero le gustara tener que sufrir una degradacin seria de las prestaciones del sistema para garantizar la eliminacin de los interbloqueos. Por ejemplo, Unix pude sufrir interbloqueos que ni siquiera se detectan, y que, por supuesto, no se eliminan automticamente. El nmero total de procesos en el sistema viene determinado por el nmero de posiciones de la tabla de procesos, que, en definitiva, constituye un recurso limitado. Supongamos ahora que un sistema Unix con 100 posiciones en la tabla de procesos tiene ejecutndose diez programas, cada uno de los cuales ha de crear 12 subprocesos. Despus de que cada proceso haya creado otros 9, los 10 procesos originales y los 90 nuevos llenarn por completo la tabla. Los 10 procesos originales se encontrarn ahora en un bucle infinito intentando crear un nuevo proceso sin poder: se ha producido un interbloqueo. Otros ejemplos de recursos que suelen ser limitados son: el nmero mximo de ficheros que pueden estar abiertos est limitado, el rea en el disco para intercambio con memoria principal. En realidad, casi todas las tablas del sistema operativo representan recursos limitados, deberamos, por tanto, limitar estos recursos para no producir un interbloqueo? La estrategia UNIX es simplemente desentenderse del problema, suponiendo que la mayora de los usuarios preferirn un interbloqueo ocasional antes que la imposicin de que cada usuario pueda crear un solo proceso, abrir un solo fichero y usar slo una unidad de lo que sea. Veremos a continuacin que se puede adoptar alguna estrategia adecuada que nos permitir prevenir, evitar o detectar y recuperar situaciones de interbloqueo. 2.- Prevencin de Interbloqueos La estrategia empleada con ms frecuencia por los diseadores para tratar el bloqueo mutuo es la prevencin. En esta seccin se examinan los mtodos de prevencin, junto con los efectos que tienen sobre los usuarios y los sistemas, sobre todo desde la perspectiva del rendimiento. Havender (68) lleg a la conclusin de que si falta alguna de las cuatro condiciones necesarias no puede haber un interbloqueo. Este autor sugiere las siguientes estrategias para negar varias de esas condiciones:

Cada proceso deber pedir todos sus recursos al mismo tiempo y no podr seguir la ejecucin hasta haberlos recibido todos.

Si a un proceso que tiene recursos se le niegan los dems, ese proceso deber liberar sus recursos y, en caso necesario, pedirlos de nuevo junto con los recursos adicionales.

Se impondr un ordenamiento lineal de los tipos de recursos en todos los procesos; es decir, si a un proceso le han sido asignados recursos de un tipo especfico, en lo sucesivo slo podr pedir aquellos recursos que siguen en el ordenamiento.




Como vemos Havender presenta tres estrategias y no cuatro. Cada una de ellas, est diseada para negar una de las condiciones necesarias. La primera de estas condiciones, esto es, que los procesos exijan el uso exclusivo de los recursos que requieren, es una condicin que no es deseable impedir, porque especficamente queremos permitir la existencia de recursos no compartibles o dedicados. Negacin de la condicin de espera La primera de las estrategias requiere que los recursos que necesita un proceso sean pedidos de una sola vez. El sistema debe proporcionarlos segn el principio de todo o nada. Si est disponible el conjunto de los recursos que necesita un proceso, entonces el sistema puede asignarle todos los recursos y ste seguir su ejecucin. Si no est disponible alguno de ellos, el proceso debe esperar. Mientras espera no puede tener ningn recurso. Con esto se elimina la condicin de espera y no puede ocurrir un interbloqueo. Todo esto suena bien, pero puede llevar a un grave desperdicio de recursos. Supongamos que un proceso necesita diez unidades de un determinado recurso para su ejecucin. Como debe solicitarlas todas antes de comenzar, los mantendr en su poder durante toda su ejecucin. Pudiera suceder, que el programa nicamente utilice estos recursos al principio de su ejecucin, por tanto, los recursos estn ociosos el resto del tiempo. Dividir el programa en varios pasos que se ejecuten de manera relativamente independiente es una tcnica empleada con frecuencia para conseguir una mejor utilizacin de los recursos en estas circunstancias. La asignacin de recursos se controla por etapas. Esta solucin reduce el desperdicio pero implica mucho trabajo extra tanto en el diseo de las aplicaciones como en al ejecucin. Por otro lado, esta estrategia puede provocar un aplazamiento indefinido, pues los recursos requeridos pueden no estar disponibles todos al tiempo. El sistema podra, entonces, permitir que se fueran acumulando recursos hasta conseguir todos los que necesita un proceso. Pero mientras se acumulan no se pueden asignar a otros procesos y volvemos a infrautilizarlos. Negacin de la condicin de no apropiacin La segunda estrategia de Havender consiste en liberar los recursos que un proceso tiene asignados cuando se le niegan peticiones de recursos adicionales. De esta forma, se anula la condicin de no apropiacin. Los recursos se pueden quitar al proceso que los tiene antes de que termine su ejecucin. En este caso tambin existe un costo excesivo. Cuando un proceso libera recursos puede perder todo el trabajo realizado hasta ese momento. El costo puede parecer muy alto, pero la pregunta es: con qu frecuencia ha de pagarse ese precio? Si ocurre de tarde en tarde, entonces ste parece ser un buen mtodo para prevenir el interbloqueo. Si, por el contrario, es muy frecuente, entonces el costo es sustancial y sus efectos demasiado perjudiciales (por ejemplo, para procesos de alta prioridad o plazo fijo).




Esta estrategia tambin adolece de aplazamiento indefinido. Un proceso puede aplazarse continuamente mientras pide y libera muchas veces los mismos recursos. Si esto ocurre, el sistema puede verse obligado a eliminar el proceso para que otros puedan ejecutarse. Negacin de la condicin de espera circular La tercera estrategia de Havender anula la posibilidad de un espera circular. Como todos los recursos tienen una numeracin nica y como los procesos deben pedir los recursos en un orden lineal ascendente, es imposible que se presente una espera circular (la figura a continuacin). Esta estrategia presenta las siguientes dificultades:

Los recursos deben pedirse en un orden ascendente por nmero de recursos. El nmero de recurso es asignado por la instalacin y debe tener un tiempo de vida largo (meses o aos). Si se agregan nuevos tipos de recursos, puede ser necesario reescribir los programas y los sistemas.

Lgicamente, cuando se asignan los nmeros de recursos, stos deben reflejar el orden normal en que los usan la mayora de las tareas. Pero los procesos que necesiten los recursos en un orden diferente que el previsto por el sistema, los debern adquirir y conservar, quiz durante tiempo antes de utilizarlos realmente, lo que significa un desperdicio considerable.

Una de las metas ms importantes de los sistemas operativos actuales es crear ambientes amables con el usuario. Los usuarios deben ser capaces de desarrollar sus aplicaciones sin tener en cuenta molestas restricciones de hardware y software. El ordenamiento lineal impide al usuario escribir sus cdigos libremente.




2.5 Niveles, Objetivos y criterios de Planificacin. Definicin: La planificacin consiste en un conjunto de polticas y mecanismos incorporados al S. O. y por los que se rige el orden en que se completa el trabajo que hay que realizar. Su objetivo primordial es optimizar el rendimiento del sistema. Definicin: La planificacin del procesador es la asignacin de los procesadores fsicos a los procesos. La parte del S. O. encargada de tomar esta decisin se denomina planificador y el algoritmo que utiliza se llama algoritmo de planificacin o disciplina. La planificacin de la CPU, en el sentido de conmutarla entre los distintos procesos, es una de las funciones del sistema operativo. Este despacho es llevado a cabo por un pequeo programa llamado planificador a corto plazo o dispatcher (despachador). La misin del dispatcher consiste en asignar la CPU a uno de los procesos ejecutables del sistema, para ello sigue un determinado algoritmo. En secciones posteriores estudiaremos algunos algoritmos posibles. Para que el dispatcher conmute el procesador entre dos procesos es necesario realizar un cambio de proceso. Los acontecimientos que pueden provocar la llamada al dispatcher dependen del sistema (son un subconjunto de las interrupciones), pero son alguno de estos:

El proceso en ejecucin acaba su ejecucin o no puede seguir ejecutndose (por una E/S, operacin WAIT, etc.).

Un elemento del sistema operativo ordena el bloqueo del proceso en ejecucin (ver estados de un proceso).

El proceso en ejecucin agota su quantum o cuanto de estancia en la CPU.

Un proceso pasa a estado listo. Se puede definir el scheduling -algunas veces traducido como -planificacin- como el conjunto de polticas y mecanismos construidos dentro del sistema operativo que gobiernan la forma de conseguir que los procesos a ejecutar lleguen a ejecutarse. El scheduling est asociado a las cuestiones de:

Cundo introducir un nuevo proceso en el Sistema.

Determinar el orden de ejecucin de los procesos del sistema. El scheduling est muy relacionado con la gestin de los recursos. Existen tres niveles de scheduling, como se ilustra en la figura siguiente, estos niveles son:

Planificador de la CPU o a corto plazo.

Planificador a medio plazo.

Planificador a largo plazo.




Objetivos de la Planificacin a. Ser justo; b. Maximizar la capacidad de ejecucin; c. Maximizar el nmero de usuarios interactivos recibiendo unos tiempos de respuesta aceptables; d. Equilibrar el uso de recursos; e. Lograr un equilibrio entre respuesta y utilizacin; f. Evitar la postergacin indefinida; g. Asegurar las prioridades; h. Dar preferencia a los procesos que mantienen recursos no compartidos. Criterios para la Planificacin El principal objetivo de la planificacin a corto plazo es repartir el tiempo del procesador de forma que se optimicen algunos puntos del comportamiento del sistema. Generalmente se fija un conjunto de criterios con los que evaluar las diversas estrategias de planificacin. El criterio ms empleado establece dos clasificaciones. En primer lugar, se puede hacer una distincin entre los criterios orientados a los usuarios y los orientados al sistema. Los criterios orientados al usuario se refieren al comportamiento del sistema tal y como lo perciben los usuarios o los procesos. Uno de los parmetros es el tiempo de respuesta. El tiempo de respuesta es el periodo de tiempo transcurrido desde que se emite una solicitud hasta que la respuesta aparece en la salida. Sera conveniente disponer de una poltica de planificacin que ofrezca un buen servicio a diversos usuarios.




Otros criterios estn orientados al sistema, esto es, se centran en el uso efectivo y eficiente del procesador. Un ejemplo puede ser la productividad, es decir, el ritmo con el que los procesos terminan. La productividad es una medida muy vlida del rendimiento de un sistema y que sera deseable maximizar. Otra forma de clasificacin es considerar los criterios relativos al rendimiento del sistema y los que no lo son. Los criterios relativos al rendimiento son cuantitativos y, en general, pueden evaluarse o ser analizados fcilmente. Algunos ejemplos son el tiempo de respuesta y la productividad. Los criterios no relativos al rendimiento son, en cambio cualitativos y no pueden ser evaluados fcilmente. Un ejemplo de estos criterios es la previsibilidad. Sera conveniente que el servicio ofrecido a los usuarios tenga las mismas caractersticas en todo momento, independientemente de la existencia de otros trabajos ejecutados por el sistema. En particular, una disciplina de planificacin debe:

Ser equitativa: debe intentar hacer una planificacin justa, esto es, se debe tratar a todos los procesos de la misma forma y no aplazar indefinidamente ningn proceso. La mejor forma de evitarlo es emplear alguna tcnica de envejecimiento; es decir, mientras un proceso espera un recurso, su prioridad debe crecer.

Ser eficiente: debe maximizar el uso de los recursos tales como intentar que la ocupacin de la CPU sea mxima. Al mismo tiempo se debe intentar reducir el gasto extra por considerar que es trabajo no productivo. Normalmente el idear algoritmos eficientes supone invertir recursos en gestin del propio sistema.

Lograr un tiempo bueno de respuesta, es decir, que los usuarios interactivos reciban respuesta en tiempos aceptables.

Lograr un tiempo de proceso global predecible. Esto quiere decir que un proceso debe ejecutarse aproximadamente en el mismo tiempo y casi al mismo costo con independencia de la carga del sistema.

Elevar al mximo la productividad o el rendimiento, esto es, maximizar el nmero de trabajos procesados por unidad de tiempo. Eso supone, por un lado, dar preferencia a los procesos que ocupan recursos decisivos y, por otro, favorecer a los procesos que muestran un comportamiento deseable. En el primer caso conseguimos liberar el recurso cuanto antes para que est disponible para un proceso de mayor prioridad. Con el segundo criterio escogemos a los procesos que no consumen muchos recursos dejndole al sistema mayor capacidad de actuacin.

Estos criterios son dependientes entre s y es imposible optimizar todos de forma simultnea. Por ejemplo, obtener un buen tiempo de respuesta puede exigir un algoritmo de planificacin que alterne entre los procesos con




frecuencia, lo que incrementa la sobrecarga del sistema y reduce la productividad. Por tanto, en el diseo de una poltica de planificacin entran en juego compromisos entre requisitos opuestos; el peso relativo que reciben los distintos requisitos depender de la naturaleza y empleo del sistema. Planificacin apropiativa frente a no apropiativa. Planificacin no apropiativa: si una vez que se le ha asignado la CPU a un proceso, ya no se le puede retirar. Ventajas:

Es ms fcil predecir los tiempos de respuesta. Inconvenientes:

Los trabajos largos hacen esperar a los cortos. Planificacin apropiativa: si se le puede retirar la CPU a un proceso mientras est en ejecucin. Ventajas:

tiles en sistemas cuyos procesos de alta prioridad requieren atencin rpida;

Permiten obtener tiempos de respuesta aceptable. Inconvenientes:

Conllevan un coste debido al intercambio de contexto;

Requieren sobrecarga debido a la necesidad de mantener en memoria principal programas que no se estn ejecutando.




2.6 Tcnicas de Administracin de Planificacin Algoritmos de planificacin Mecanismos: A. Utilizacin de prioridades. Prioridad: calificador asignado a un proceso que determina la atencin que va a recibir del sistema. Segn el agente que asigna la prioridad:

Prioridades internas: asignadas automticamente por el S. O.;

Prioridades externas: asignadas desde el exterior. Segn los cambios que sufre la prioridad: Prioridades estticas: no cambian durante la ejecucin del proceso;

Prioridades dinmicas: varan durante la ejecucin del proceso. B. Utilizacin de un quantum de tiempo. Quantum: tiempo mximo que un proceso puede hacer uso del procesador. Puede ser fijo o variable y puede tener el mismo valor para todos los procesos o distinto. A. Que no usan quantum: 1. Planificacin por orden de llegada (FIFO, primero en entrar-primero en salir). La lista de procesos en estado listo esta ordenada segn el orden de llegada al sistema (creacin del proceso), siendo el ms antiguo el que esta en la cabecera de dicha lista. Es una disciplina no apropiativa, por lo tanto al proceso que esta activo no se le puede retirar la CPU hasta que l la abandone voluntariamente. Inconvenientes:

Bajos rendimientos, procesos largos hacen esperar a procesos cortos;

No es til en sistemas interactivos puesto que no garantiza buenos tiempos de respuesta.

Ventajas:

Permite predecir el orden de ejecucin de los procesos;

Es fcil de implementar.




2. Planificacin del trabajo ms corto primero (SJF). Es una disciplina no apropiativa. La lista de procesos en estado listo esta ordenada por la cantidad de tiempo de ejecucin estimada, de forma que el proceso ms corto es el primero en la cola. Para establecer este orden se necesita saber el periodo de tiempo de ejecucin de un proceso, y como esto raramente esta disponible, se confa en las estimaciones de los usuarios. Inconvenientes:

Con respecto al algoritmo FIFO, es menos predecible los tiempos de respuesta, sobre todo de los procesos largos;

Es poco til en sistemas interactivos puesto que no garantiza tiempos de respuesta razonables.

Ventajas:

Con respecto al algoritmo FIFO, reduce al mnimo el tiempo promedio de espera de los trabajos, ya que al favorecer los trabajos cortos sobre los largos reduce el nmero de trabajos en espera.

3. Planificacin del tiempo restante ms corto (SRT). Esta disciplina elige siempre al proceso que le queda menos tiempo de ejecucin estimado para completar su ejecucin; de esta forma aunque un proceso requiera mucho tiempo de ejecucin, a medida que se va ejecutando ira avanzando en la lista de procesos en estado listo hasta llegar a ser el primero. Para realizar esta eleccin, es necesario actualizar el PCB de los procesos a medida que se le asigna tiempo de servicio, lo que supone una mayor sobrecarga adicional. Es una disciplina apropiativa ya que a un proceso activo se le puede retirar la CPU si llega a la lista de procesos en estado listo otro con un tiempo restante de ejecucin estimado menor. B. Que usan quantum: 1. Planificacin de asignacin en rueda, por turnos (Round Robin (RR) Scheduling). La lista de procesos en estado listo es una cola circular, de forma que el proceso al que se le asigna la CPU pasar posteriormente a ser el ltimo de dicha cola circular. Si un proceso no agota su quantum debido a que pasa a estado bloqueado, entonces el siguiente proceso de la cola circular pasa a activo sin esperar que se termine el quantum del anterior. Esta disciplina apropiativa es efectiva en sistemas de tiempo compartido, puesto que garantiza tiempos de respuesta razonables. 2. Planificacin con colas de niveles mltiples. A cada proceso se le asigna una prioridad. La lista de procesos en estado listo esta formada por una serie de colas circulares, donde cada una de ellas contiene a todos aquellos procesos que




tienen una misma prioridad. La CPU se asigna siempre al proceso de la cola de mayor prioridad que no este vaca.

Problema: procesos de baja prioridad quedan postergados indefinidamente. Solucin: prioridad por envejecimiento. La prioridad aumenta gradualmente a medida que el proceso pasa cierto tiempo en el sistema, garantizando su terminacin en un tiempo finito. 3. Planificacin con colas de retroalimentacin de niveles mltiples. Su objetivo es tratar a los procesos de acuerdo a su comportamiento:

Si el proceso se suspende frecuentemente se le debe asignar bastantes veces el procesador con un quantum pequeo;

Si el proceso se suspende poco se le debe asignar el procesador menos veces pero con un quantum grande.

La lista de procesos en estado listo esta formada por varios niveles y cada uno de ellos con una cola circular. Cuando se inserta un nuevo proceso este se aade al final de la cola de mayor nivel gestionada de forma FIFO.




La CPU se asigna al proceso que se encuentra en la cabecera de la cola de mayor nivel que no este vaca. Cuando un proceso recibe la CPU puede ocurrir:

Que agote su quantum: entonces al pasar a estado listo se coloca al final de la cola del siguiente nivel inferior al que perteneca. Mientras que el proceso consuma totalmente su quantum en cada nivel, ir movindose haca el final de las colas de los niveles inferiores. La cola del nivel ms profundo se gestiona mediante asignacin de rueda.

Que no agote su quantum: entonces cuando pase de estado bloqueado a listo volver al final de la cola del nivel al que perteneca. Se supone que el comportamiento inmediato anterior de un proceso puede ser un buen indicador del comportamiento futuro cercano.

Normalmente, el quantum otorgado al proceso aumenta a medida que el proceso se mueve haca las colas de los niveles inferiores. En definitiva, este algoritmo trata a los procesos segn su comportamiento, y los separa por categoras segn sus n

Contenido Sistemas Operativos

Documents

Transcript of Contenido Sistemas Operativos