Asesoría Didáctica 1

SISTEMAS OPERATIVOS I
ASESORIA DIDACTICA 1
Contenido
FUNDAMENTOS DE SISTEMAS OPERATIVOS ............................................................. 3 INTRODUCCION.................................................................................................. 3 SOFTWARE DEL SISTEMA OPERATIVO ................................................................... 4 HARDWARE DE LA MAQUINA ................................................................................ 7 TIPOS DE SISTEMAS OPERATIVOS ........................................................................ 9 HISTORIA BREVE DEL DESARROLLO DE LOS SISTEMAS OPERATIVOS ..................... 10 ADMINISTRADOR DEL PROCESADOR ..................................................................... 16 PLANIFICACIN DE TRABAJOS EN COMPARACIN CON PLANIFICACIN DE PROCESOS ...................................................................................................................... 17 PLANIFICADOR DE PROCESOS ............................................................................ 18 ESTADO DE LOS TRABAJOS Y DE LOS PROCESOS ................................................. 19 Bloques de control de procesos ........................................................................ 21 Bloques de control de procesos y colas ............................................................. 22 POLITICAS DE PLANIFICACION DE PROCESOS ..................................................... 23 ALGORITMOS DE PLANIFICACION DE PROCESOS .................................................. 24 PRIMERO DE ENTRAR, PRIMERO DE SERVIRSE .................................................. 24 SIGUE EL TRABAJO MS CORTO ...................................................................... 25 PLANIFICACIN CON PRIORIDAD ..................................................................... 26 TIEMPO RESTANTE MS BREVE ....................................................................... 27 ROUND ROBIN ............................................................................................... 29 COLAS DE MULTIPLES NIVELES ....................................................................... 31 MEMORIA CACHE ........................................................................................... 33 UNA PALABRA SOBRE INTERRUPCIONES ........................................................... 33 ADMINISTRACIN DE LOS PROCESOS ................................................................. 36 BLOQUEO MUTUO ............................................................................................. 37 Siete casos de bloqueo mutuo ......................................................................... 37 CONDICIONES PARA EL BLOQUEO MUTUO ........................................................ 43
MODELADO DE BLOQUEOS MUTUOS ................................................................ 44 Estrategias para el manejo de bloqueos ............................................................ 47 INANICIN ...................................................................................................... 53 PROCESOS CONCURRENTES ................................................................................. 56 QU ES PROCESAMIENTO PARALELO? ................................................................ 56 CONFIGURACIONES TPICAS DE MULTIPROCESAMIENTO ...................................... 57 Configuracin maestro/esclavo ........................................................................ 57 Configuracin dbilmente acoplada .................................................................. 58 Configuracin simtrica .................................................................................. 59 SOFTWARE DE SINCRONIZACIN DE PROCESOS .................................................. 59 PROBAR Y ESTABLECER .................................................................................. 61 WAIT y SIGNAL ............................................................................................. 61 Semforos .................................................................................................... 61 COOPERACIN DE PROCESOS ............................................................................ 63 Productores y consumidores ............................................................................ 64 Lectores y escritores ...................................................................................... 65 PROGRAMACIN CONCURRENTE ........................................................................ 66 Aplicaciones de la programacin concurrente ..................................................... 66
FUNDAMENTOS DE SISTEMAS OPERATIVOS
Comprender el sistema operativo es entender el funcionamiento de todo el sistema de computo porque dicho sistema de computo, porque dicho sistema administra toda y cada una de las piezas del hardware y el software. En este texto exploraremos lo que son los sistemas operativos, como funcionan, que hacen y porque. Este captulo describe de manera breve cmo funcionan los sistemas operativos y cmo han evolucionado en trminos generales. Los captulos siguientes exploran con mayor profundidad cada uno de los componentes y muestran como se relaciona su funcin con las dems partes del sistema operativo. En otra palabras sin problemas. Nota: como ya se menciono; en todo el libro el tipo en negritas indica trminos que quedan definidos en el glosario.
INTRODUCCION
Empecemos con una definicin: qu es un sistema operativo? En los trminos ms simples, es el gerente ejecutivo, la parte del sistema de computo que administra el hardware y el software.
Ing. Romel Alds
Para ser especficos, controla los archivos, dispositivos, sectores de la memoria principal y cada nanosegundo del tiempo de procesamiento; asimismo controla quien puede controlar el sistema y de qu manera. En breve, es el patrn. Por otro lado, cuando el usuario enva un comando el sistema operativo debe asegurarse que se ejecute, o si esto no ocurre, deber arreglrselas de manera que el usuario reciba un mensaje explicando el error. Esto no significa necesariamente que el sistema operativo ejecute el comando o envi el mensaje de error; pero si controla las partes o componentes del sistema que lo hacen.
SOFTWARE DEL SISTEMA OPERATIVO

La pirmide que se muestra en la figura 1.1 y en el forro interior de la pantalla es una representacin abstracta de un sistema operativo y muestra las interrelaciones de sus componentes principales. La base de la pirmide muestra los cuatro administradores esenciales de todo sistema operativo: el administrador de memoria, el administrador del procesador, el administrador de dispositivos y el administrador de archivos. De hecho, estos administradores son la base de todos los sistemas operativos y cada uno se analiza en detalle a lo largo de esta primera parte. Cada administrador trabaja de cerca con los dems y desempea su papel, sea cual sea su sistema operativo analizado las funciones de red no siempre fueron una parte integral de los sistema operativos y por lo general se montaban en sistemas operativos existentes. Por lo tanto, no hemos trazado una esquina por separado en la pirmide, pero en los captulos relacionados hemos incorporado estas funciones bajo el encabezado sistemas operativos. Por otra parte, la interfaz de comandos de usuario, desde la cual los usuarios emiten los comandos al sistema operativo es un componente especfico en cada sistema operativo y muy distinto de un sistema a las siguiente-algunas veces incluso entre distintas versiones de sistema operativo-. (Para su conveniencia la figura 1.1 repite en la primera de forros y muestra los captulos en los cuales se analiza cada uno de los componentes.)
Ing. Romel Alds
Sin importar el tamao o configuracin del sistema, cada uno de los administradores de subsistemas que se ilustra en la figura 1.2 deben llevar a cabo estas tareas. 1. Monitorear continuamente sus recursos 2. Obligar al cumplimiento de la polticas que determinan quien obtiene que cuando y cuanto. 3. Asignar los recursos cuando es apropiado. 4. Liberar el recurso-recuperarlo-cuando es conveniente. Por ejemplo, el administrador de memoria est a cargo de la memoria principal o RAM. Comprueba la validez de cada solicitud de espacio de memoria y, si se trata de una solicitud legal le asigna una porcin que todava no est en uso. En un entorno multiusuario, el administrador de la memoria establece una tabla para llevar el control de quien est usando que seccin de la memoria. Para finalizar, cuando llega el momento de recuperar la memoria el administrador la libera. Una de las principales funciones del administrador de memoria es proteger el espacio en la memoria principal que ocupa el sistema operativo no puede permitir que parte alguna de este espacio sea alterada de manera accidental o propositiva. El administrador del procesador decide como asignar la unidad de procesamiento central (CPU). Una funcin importante de este administrador es controlar el estado de cada proceso (un proceso que aqu se define como una instancia de ejecucin de un programa): Este administrador monitorea si el CPU est ejecutando un proceso o espera que termine la ejecucin de un comando de LECTURA o ESCRITURA. Dado que maneja las transacciones de procesos de un estado de ejecucin a otro, se puede comparar con un controlador de trfico. El administrador asigna al procesador y establece los registros y tablas necesarias ms tarde, cuando la tarea ha terminado o expirado el tiempo mximo lo recupera. De una manera conceptual, el administrador del procesador del procesador tiene dos niveles de funcin: uno es manejar las tareas conforme entran en el sistema; el otro es administrar cada proceso de estas tareas. El planificador de tareas manejar la primera parte. Es la porcin de alto nivel del administrador que acepta o rechaza las tareas que llegan. El planificador de procesos maneja la segunda parte. Se trata de la porcin de
Ing. Romel Alds
bajo nivel del administrador del procesador; su trabajo es decidir qu proceso obtiene el CPU y durante cunto tiempo. El administrador de dispositivos vigila todos los dispositivos, canales y unidades de control. Su tarea es escoger la manera ms eficiente de asignar los dispositivos del sistema (impresoras, terminales, unidades de disco, etc.), con base en una poltica de programacin escogida por los diseadores del sistema. Este administrador asigna este dispositivo, inicia su operacin y lo libera. En cuarto el administrador de archivos, lleva el control de todo archivo en el sistema, incluyendo archivos de datos, ensambladores, compiladores y programas de aplicacin. Mediante el uso de polticas de acceso predeterminadas, obliga a cada archivo a cumplir las restricciones de acceso. (Cuando se crea se estipula quien lo acceder solo el sistema solo el usuario, solo un grupo o de acceso general. Una funcin crucial del sistema operativo es hacer que se cumplan estas restricciones). Los administrados de archivos tambin controlan la flexibilidad de acceso que tiene cada usuario con los diversos tipos de archivo (como solo de lectura, de lectura y escritura o la posibilidad de crear registros). Tambin asigna el recurso al abrir el archivo y lo libera al cerrarlo. Sin embargo, no basta que cada uno de estos administradores lleve a cabo sus tareas individuales. Tambin deben ser capaces de trabajar en armona con los otros administradores. A continuacin veremos un ejemplo simplificado digamos que alguien escribe un comando para ejecutar un programa. Los siguientes pasos principales deben darse en secuencia. 1. El administrador de dispositivos recibe los impulsos elctricos del teclado, codifica el tecleo para formar el comando y enva el comando a la interfaz de comando del usuario, donde el administrador del procesador lo valida. 2. Luego, el administrador del procesador manda un mensaje de reconocimiento, para que aparezca en el monitor de video, de manera que quien escribi sepa que se envi el comando. 3. Cuando el administrador del procesador recibe el comando, determina si hay que traer el programa correspondiente de donde este almacenado o si ya est en la memoria, despus de lo cual notifica al administrador apropiado. 4. Si el programa est almacenado, el administrador de archivos debe calcular su localizacin exacta en el disco y pasar la informacin al administrador de dispositivos. Este recupera y enva el programa al administrador de la memoria, el cual debe encontrar espacio para el mismo y registrar su ubicacin exacta en la memoria. 5. Una vez que el programa se arla en la memoria, el administrador de esta debe controlar su localizacin y progreso conforme lo ejecuta el administrador del procesador. 6. Cuando termina la ejecucin del programa, este manda un mensaje de terminado de regreso al administrador del procesador. 7. Por ltimo, el administrador del procesador manda un mensaje de terminado de vuelta al administrador de dispositivos, que lo muestra en el monitor para que lo vea el usuario. Aunque esta es una demostracin sobre simplificada de una operacin complicada, ilustra la increble precisin requerida por el sistema operativo. Recuerde, ningn administrador por si solo puede llevar a cabo sus tareas si la cooperacin activa de las dems partes.
Ing. Romel Alds
Los sistemas operativos con capacidad de red tienen un quinto administrador esencial conocido como administrador de red, que proporciona una forma conveniente para los usuarios de compartir recursos y, al mismo tiempo, controlar su acceso a los mismos estos recursos incluyen hardware (CPU reas de memoria, impresora, unidades de cinta, modem y unidades de disco) y software (compiladores, programas de aplicacin y archivo de datos). Al aadir el quinto administrador para crear un sistema operativo de red creamos una pirmide de cinco lados. La base de la pirmide aparece en la figura 1.3 y se describe en detalle en el captulo 9.
HARDWARE DE LA MAQUINA
Para apreciar la funcin del sistema operativo, necesitamos definir los aspectos esenciales del hardware del sistema de la computadora la maquina fsica y sus componentes electrnico incluyendo los chips de memoria, los dispositivos de entrada /salida, los dispositivos de almacenamiento y la unidad de procesamiento central. El hardware se diferencia del software, el cual se refiere a programas escrito para el sistema de cmputo. La memoria principal es donde se debe recibir los datos y las instrucciones para ser procesados. Los dispositivos de entrada / salida o dispositivo E/S incluyen toda unidad perifrica del sistema como impresoras, unidades de disco, unidad del CD, dispositivos de cinta magntica, teclado, reproductores de DVD, modem, etctera. El CPU o unidad de procesamiento central es el cerebro que, apoyado en circuitera (a veces conocida como chips) controla la interpretacin y ejecucin, de las instrucciones. En esencia, controla la operacin de la totalidad del sistema de cmputo, como ilustra en la figura 1.4. Esta unidad inicia o realiza todas las referencia de almacenamiento, manipulables de datos y operaciones de entrada / salida. Hasta 1975, las computadoras se clasificaban segn su capacidad y precio. Una mainframe o macrocomputadoras era una maquina grande, tanto fsicamente como por su funcin o capacidad interna de memoria. La IBM 360, introducida en 1964, en un ejemplo clsico de una de las primeras macrocomputadoras. La IBM 360 modelo 30 la
Ing. Romel Alds
ms pequea de la familia 360 (Prasad, 1989), necesitaba de un cuarto con aire acondicionado de unos 18 pies de lado para albergar el CPU, la consola del operador, una impresora, un lector de tarjetas y una mquina perforadora. El CPU tena 5 pies de altura y 6 de ancho, con una memoria interna de 64k (considerada grande para la poca) y un precio de 200000 dlares, en dlares de 1964. Debido a su tamao y precio del momento, sus aplicaciones se limitaban a grandes centros de cmputo, propiedad del gobierno federal, universidades y negocios muy grandes. Un ejemplo de un sistema operativo para macrocomputadoras es el OS/390 de IBM. La minicomputadora fue desarrollada para satisfacer las necesidades de instituciones ms pequeas, con unas cuantas docenas de usuarios. Digital Equipment Corporation (DEC) puso en el mercado una de las primeras minicomputadoras para cubrir las necesidades de grandes escuelas y pequeas universidades, que empezaron a ofrecer cursos de computacin a principio de os 70. (El precio de su PDP-8, Periphral Device Processor-8, era inferior a 18 000 dlares.) Las minicomputadoras eran ms pequeas en tamao y capacidad de memoria que una microcomputadora, as como ms econmicas. Un ejemplo de un sistema operativo para microcomputadora fue el VAX/VMS, que desde entonces ha evolucionado hacia el sistema operativo Open VMS Alpha. La supercomputadora apareci en 1976, principalmente para cubrir aplicaciones gubernamentales que necesitaban capacidad masiva y rpida de manipulacin de cifras para llevar a cabo operaciones militares y de pronstico del tiempo. Los negocios y la industria se interesaron en la tecnologa cuando las computadoras masivas se hicieron ms rpidas y menos costosas. Una supercomputadora Cray T3E-1200ETM es un ejemplo tpico, con 6 a 2048 procesadores que realizan hasta 2.4 billones de operaciones de un punto flotante por segundo (taeraflopc). Hoy da, se realizan supercomputadoras para una amplia gama de tareas, desde la investigacin cientfica hasta el apoyo a clientes y desarrollo de productos. Incluso se realizan para efectuar clculos complicados utilizados para la creacin de pelculas animadas. As mismo ayudan a las empresas petroleras en su bsqueda de hidrocarburos mediante el anlisis de cantidades masivas de datos (Stair, 1999). Los ejemplos de sistemas operativos para supercomputadoras son los derivados de UNIX de alto nivel como UNICOSR e IRIXR La microcomputadora fue desarrollada para los usuarios individuales a fines de los 70. Tandy Corporation y Apple Computer, Inc, fueron los primeros en ofrecer microcomputadoras para la venta al pblico en general. El primero se diriga al mercado de pequeos negocios, y el ltimo al mercado de la educacin elemental. Estos primeros modelos tenan muy poca memoria segn los estndares de hoy dia-64k era la capacidad mxima -. Su tamao fsico era menor que de la minicomputadoras de dicha poca, aunque mayor que el de las microcomputadoras de hoy da. Para finalizar las pocas de las microcomputadoras crecieron a fin de aceptar el software con mayor capacidad y velocidad. La caracterstica distintiva de una microcomputadora es su estatus de uso individual. Un ejemplo de un sistema operativo para estas maquinas es el MS-DOS. Las microcomputadoras ms potentes, utilizadas para empresas comerciales , educativas y gubernamentales se conocen como estaciones de trabajo por lo general se encuentran en red i se utilizan para dar apoyo a usuarios de ingeniera y tcnicos que llevan a cavo calcules matemticos masivos, diseo asistido por computadoras (CAD) u otras aplicaciones que para cumplir sus necesidades requiere unidades centrales de procesamiento muy poderosas, as como grandes cantidades de memoria principal y presentaciones graficas de resolucin extremadamente alta. Un ejemplo de sistema operativo para estacin de trabajo es UNIX. Desde mediados de los 70 los rpidos avances de la tecnologa de la computacin han obscurecido de caractersticas distintivas de las primeras maquinas: tamao fsico, costo y capacidad de memoria. Las microcomputadoras ms poderosas de hoy da tienen mltiples procesadores coordinadas por el administrador del procesador las macrocomputadoras simples siguen teniendo una memoria principal grande, pero ahora estn disponibles en un gabinete de tamao de un escritorio. Las minicomputadoras se parecen a los microcomputadoras y las ms pequeas pueden llevar a cabo tareas
Ing. Romel Alds
reservadas a las microcomputadoras; as mismo, la capacidad de red ha sido integrada a casi todos los sistemas. Hubo un tiempo en que las computadoras se clasificaron con base en su capacidad de memoria. Ahora se distinguen por la capacidad del procesador. Debemos subrayar que se trata de categoras relativas y lo que hoy es grande se convertir en mediano y despus en pequeo en el futuro cercano. En 1965, Gordon Moore, ejecutivo de Intel, sealo que cada nuevo chip procesador contena alrededor del doble de capacidad de su predecesor y cada chip sala al mercado en un plazo de 18 a 24 meses despus del anterior. Concluyo que la tendencia aria que la potencia de cmputo se elevara en sentido exponencial a lo largo de periodos relativamente breves. Conocida como la ley de Moore, la tendencia a continuado y sigue siendo muy precisa por lo que forma la base de los pronsticos industriales el chip Intel 4004 en 1971 tena 2300 transistores, en tanto que veinte aos despus el chip Pentium II llego a 7.5 millones.
TIPOS DE SISTEMAS OPERATIVOS

Los sistemas operativos para las computadoras grandes y pequeas se ubican en cuatro clases, que se distinguen por su tiempo de respuesta y la forma en que se introducen los datos en el sistema. Son los sistemas por lote, interactivo, en tiempo real hbrido.
Los sistemas por lotes o batch existen desde las primeras computadoras que se apoyan en tarjetas perforadas o en cintas para la entrada cuando se introduca una tarea mediante la agrupacin de las tarjetas en un paquete y se corra todo el paquete atreves de un lector de tarjetas como un grupo: Un lote los sistemas por lotes de hoy no estn
Ing. Romel Alds
limitados o tarjetas o cintas, pero los trabajos todava se procesan en serie, sin interaccin del usuario. La eficiencia del sistema se media en produccin-esto es, la cantidad de tareas completadas en una cantidad dada de tiempo (por ejemplo, 30 tareas por hora)-y el tiempo total se media en horas, a veces en das. En la actualidad no es comn encontrar un sistema que este limitado en programas por lotes. Los sistemas interactivos (tambin conocidos como sistemas tiempo compartido) dan un tiempo de retorno ms rpido que los dems por lotes, pero son ms lentos que los sistemas de tiempo real, de los cuales hablaremos ms adelante. Se introdujeron para satisfacer las demandas de usuarios que necesitaban un tiempo de retorno rpido al eliminar los errores de sus programas. El sistema operativo requera el desarrollo del software de tiempo compartido, lo que permitira a cada usuario interactuar directamente con el sistema de computo vi comandos introducidos a partir de una terminal de tipo mquina de escribir. El sistema operativo proporciona una retroalimentacin inmediata al usuario y el tiempo de respuesta se puede medir en minutos o segundo, segn la cantidad de usuarios activos. Los sistemas de tiempo real son los ms rpidos de los cuatro y se utilizan en entornos de tiempo critico, donde los datos se deben procesaron la suma rapidez porque la salida afecta decisiones inmediatas. Los sistemas de tiempo real se utilizan para vuelos especiales, control de trfico en aeropuertos, aeronaves de alta velocidad, procesos industriales, equipo mdico complicado, distribucin de electricidad y conmutacin telefnica. Un sistema a tiempo real debe ser 100 por ciento de las veces. El tiempo de respuesta se mide en fracciones de segundo aunque esto en la prctica es un ideal que no se logra a menudo. Se bien en teora es posible convertir un sistema operativo de tiempo general en un sistema de tiempo real, en la prctica de carga general de los sistemas de tipo general es tan grande que no se logran desempeos a tiempo real. Por tanto, la mayor parte de los trabajos en tiempo real requieren sistemas operativos diseados para llenar necesidades a tiempo real. Los sistemas hbridos, son una combinacin en sistemas en lotes e interactivos. Parecen interactivos porque los usuarios individuales pueden tener acceso al sistema mediante terminales y obtener una respuesta rpida; pero cuando la carga interactiva es ligera este tipo de sistemas acepta y opera programas en lotes en un segundo plano. Un sistema hibrido aprovecha el tiempo libre entre demandad de procesamiento para ejecutar programas que no necesitan ayuda cientfica del operador. Muchos sistemas de cmputo grande son hbridos.
HISTORIA BREVE OPERATIVOS
DEL
DESARROLLO
DE
LOS
SISTEMAS
La evolucin de los sistemas operativos es paralela a la evolucin de las computadoras para las que fueron diseados a fin de controlarlas. A continuacin ofrecemos un breve panorama general del proceso. DCADA DE LOS 40 La primera generacin de computadoras (1949-1955) se dio en una poca de tecnologa de tubos al vacio (bulbos) y de computadoras del tamao de salones de clase. Cada mquina era nica en estructura y propsito. Haba poca necesidad de un software estndar de sistema operativo, ya que el uso de cada computadora estaba restringido a unos cuantos profesionales, que trabajaban en aplicaciones matemticas, cientficas o militares, todos familiarizados con la idiosincrasia de su hardware. Un programa tpico inclua todas las instrucciones que la computadora necesitaba para llevar a cabo las tareas solicitadas daba instrucciones explicitas al lector de tarjetas
Ing. Romel Alds
10
(cuando empezar, como imprimir el producto terminado, como dar formato a la pagina y cuando terminar). Los programadores operaban las maquinas desde la consola principal era un proceso en que ellos debieran hacer todo para eliminar los errores de un programa el programador tenia al procesador, lea el contenido de cada registro, efectuaba las correcciones en las localizaciones de memoria y reanudaba la operacin. Para ejecutar programas los programadores tenan que reservar la maquina el tiempo que estimaban que esta tardara en ejecutar el programa. Como resultado, la maquina se utilizaba en una memoria diferente. El CPU procesaba datos y efectuaba clculos durante solo una fraccin de tiempo disponible y, de hecho, la totalidad del sistema esperaba ocioso entre las reservaciones. Con el paso del tiempo el hardware y software de cmputo se hicieron mas estndares y la ejecucin de un programa requera menos pasos y conocimientos de los mecanismos internos de la computadora se desarrollaron compiladores y ensambladores para traducir a cdigo binario los comandos de los lenguajes de alto nivel que se estaba desarrollado. Los sistemas operativos rudimentarios empezaron a tomar forma con la creacin de macros, programas de videoteca, subritinas estndares y programas de utilera. Adems incluan subrutinas de unidades de dispositivos programas prescritos que estandarizaban la forma en que se utilizaban los dispositivos de entrada y salida. Estos primeros programas tenan una desventaja importante, ya que estaban diseados para utilizar sus recursos de manera conservadora, a costa de la comprensin. Esto significaba que muchas instrucciones utilizaban una lgica complicada, solo comprensible para el programador original, por lo que era casi importante que cualquier otra persona eliminara errores o cambiara el programa ms tarde. DCADA DE LOS 50 Las computadoras de segunda generacin (1955-1965) fueron desarrolladas para llenar las necesidades de un nuevo mercado, los negocios. El entorno empresarial daba mucha importancia a la efectividad en costo del sistema. Las computadoras seguan siendo muy costosas en especial al compararlas con otro equipo de oficina (la IBM 7094 tena un precio de 200000 dlares). Por lo tanto, se deba maximizar la produccin para hacer que este tipo de inversin fuera rentable para uso empresarial lo que significaba incrementar de manera dramtica el uso del sistema. Dos mejoras hallaron una amplia difusin: se contrataron operadores de computadoras para facilitar la operacin de cada mquina y se instituyo la programacin de las tareas dicha programacin es un esquema de mejora de la productividad que rene programas con requerimientos similares. Mientras el compilador FORTRAN estuviera en la memoria, se ejecutara varios programas FORTRAN a todas las tareas que utilizaban lector de tarjetas como entrada se correran puntos y los que utilizaban la unidad de cinta se ejecutaran despus. Operadores llegaron a la conclusin que la combinacin ms eficientes eran la mezcla de requerimiento de dispositivos de entrada y salida; esto es, al mezclar programa de entrada por cinta con programa de entrada por tarjeta, se podra montar o rebobinar las cintas mientras el lector de tarjetas estaba ocupado La programacin de tareas introdujo la necesidad de tarjetas de control que definan la naturaleza exacta de cada programa y sus requerimientos. Esto fue uno de los primeros usos de un leguaje de control de tareas (JCL, por sus siglas en ingles) que ayudo al sistema operativo a coordinar y administrar los recursos del sistema, al identificar los usuarios y sus tareas, y al especificar los recursos requeridos para ejecutar cada tarea. Pero incluso con tcnicas por lotes, las computadoras ms rpidas de segunda generacin aceptaban costosos retrasos de tiempo entre el CPU y los dispositivos de entrada/salida. Por ejemplo, una tarea que significa leer mil seiscientos tarjetas, poda representar 79 segundos en el lector de tarjetas y solo 5 segundos de uso del CPU para ensamblar compilar. Esto significa que el CPU estaba ocioso 94% del tiempo y solo procesaban 6% de tiempo dedicado a dicha tarea.
Ing. Romel Alds
11
Varios factores terminadores por ayudar a mejorar el desempeo o rendimiento del CPU. Primero, la velocidad de los dispositivos de entrada/salida como unidades de cinta, discos y tambores que fue haciendo ms rpida. Segundo, para utilizar ms el rea de almacenamiento disponible en estos dispositivos, los registros se bloqueaban antes de su recuperacin o almacenamiento (Bloquear significa que varios registros lgicos se agrupan en un registro fsico.) cuando se recuperaban los registros haba que desbloquearlos antes de que un programa pudiera utilizarlos. Para ayudar a los programadores de estas funciones de bloqueo y desbloqueo, se desarrollaron mtodos de acceso y se agregaron al cdigo objeto por medio del editor de enlace. Tercero, para reducir la diferencia de velocidad entre entradas y salidas del CPU, se coloco una interfaz conocida como unidad de control entre ellas para ejecutar la funcin de almacenamiento temporal en el buffer. Un buffer es un rea temporal de almacenamiento que funciona como sigue: conforme al dispositivo de entrada lento lee un registro, la unidad de control coloca cada uno de los caracteres del registro en el buffer. Cuando este se llena, todos los registros se transmiten rpidamente al CPU el proceso es justo lo opuesto para dispositivos de salida: el CPU coloca en el buffer todo el registro, mismo que pasa por la unidad de control a la velocidad ms lenta, requerida por el dispositivo de salida. Si la unidad de control tiene ms de un buffer el proceso de entrada y salida puede hacerse con ms rapidez si la unidad de control tiene dos buffer, el segundo se puede cargar mientras el primero est transmitiendo su contenido al CPU. En trminos ideales, cuando el primero ha transmitido su contenido, el segundo estar listo para empezar, y as sucesivamente. De esta manera, el tiempo de entrada se reduce a la mitad. Adems el uso del buffer, se desarrolla en forma primitiva de efectuar operaciones perifricas simultneas, realizando operaciones de lectura, impresin y perforacin de tarjetas fuera de lnea. Hoy da esta forma de operar se le forma SPOOL. Que son las siglas en ingle de operacin perifrica simultanea en lnea (Simultaneous Peripheral Operations On Line). Por ejemplo, los trabajos de entrada serian transferidos fuera de lnea de los paquetes de tarjeta a la cinta, con lo que su lectura llega al CPU desde la cinta de mayor velocidad que la del lector de tarjetas. El modo spool funciona de la misma manera que el buffer pero, en este ejemplo, es un dispositivo perifrico que no est directamente conectado al CPU en tanto que el buffer forma parte de hardware de la computadora. Tambin durante la segunda generacin se desarrollaron tcnicas para administrar bibliotecas de programas crear y mantener archivos e ndices de datos, para elegir al azar las direcciones de acceso directas, y crear y revisar etiquetas de archivo se desarrollaron varias tcnicas estndares de organizacin de archivos, como el acceso secuencial, el secuencial indizado y el acceso directo con estas tcnicas instaladas mini programas estandarizados, conocidos como macros eliminaban la necesidad que tenan los programadores de escribir rutinas personalizadas de apertura y cierre para cada programa. Se desarrollaron los interruptores de tiempo para proteger al CPU de ciclos infinitos en programas que por error tena instrucciones de ejecutar una sola serie de comandos para siempre y a fin de permitir el trabajo compartido. Se asigno una cantidad fija de tiempo de ejecucin a cada programa al entrara al sistema, lapso vigilado por el sistema operativo. Si cualquier programa segua operando al expirar este plazo, se les daba por terminando y el usuario era notificado utilizando un mensaje de error. Durante la segunda generacin, los programas seguan siendo operados en modo de lotes seriales-uno por uno. El siguiente paso hacia un mejor uso de los recursos del sistema fue pasar el procesamiento compartido. DCADA DE LOS 60
Ing. Romel Alds
12
Las computadoras de la tercera generacin provienen de mediados del decenio de los 60 fueron diseadas con CPU ms rpidas pero du velocidad causo problemas cuando interactuaba con dispositivos de entrada/salida relativamente lentos. La solucin fue la multiprogramacin, que introdujo la idea de cargar muchos programas de una vez y compartir la tensin de un CPU. Los primeros sistemas de multiprogramacin permitan que se diera servicio a cada programa por turno uno despus de otro. El mecanismo ms comn para implementar la multiprogramacin fue introducir el concepto de interrupcin, que es cuando se notifica al CPU cuales sucesos necesitan los servicios de los sistemas operativos. Por ejemplo, cuando un programa emite un comando de entrada /salida, genera una interrupcin que solicita los servicios del procesador de entrada y salida y se libera al CPU para que inicie la ejecucin de la tarea siguiente. Esto se conoci como multiprogramacin pasiva ya que el sistema operativo no controlaba las interrupciones sino que esperaba a que cada tarea terminaba una secuencia de ejecucin era menos que ideal, porque si una tarea estaba acotada por el CPU (esto es que ejecutaba una gran cantidad de procesami ento sin detenerse, antes de emitir una interrupcin) ocupaba el CPU durante largos periodos y el resto de las tareas tena que empezar. A fin de compensar este efecto, pronto se dio una funcin ms activa al sistema operativo multiprogramacin activa, que permita que cada programa mas usara una tarjeta preestablecida del tiempo del CPU. Cuando expiraba el plazo, la tarea se interrumpa y se iniciaba otra tarea. La tarea interrumpida tena que empezar su turno hasta que se le permitiera reanudar la ejecucin mas tarde. La idea de dividir el tiempo se hiso comn en muchos sistemas de tiempo compartido. La planificacin de programas que se haba iniciado con los sistemas de segunda generacin, continuaba en ese momento pero se complicaba porque la memoria principal estaba ocupada con muchos trabajos la resolucin fue clasificar los trabajos en grupo y cargar los programas de acuerdo con una rotacin preestablecida. Los grupos por lo general se determinaban en funcin de la prioridad de los requerimientos de memoriacualquiera de los cuales daba un uso ms eficiente de los recursos. Adems de planificar los trabajos de manejar las interrupciones y asignar la memoria, los sistemas operativos tenan que resolver conflictos cuando dos tareas solicitaban el mismo dispositivo al mismo tiempo. Durante este periodo se efectuaron pocos avances de importancia en la administracin de los datos. Las funciones de biblioteca y los mtodos de acceso eran los mismos de los ltimos aos de la segunda generacin. El sistema operativo de las maquinas de tercera generacin consista en muchos mdulos entre los cuales poda seleccionar el usuario, por lo que todo el sistema operativo se personalizaba para adecuarse a necesidades parciales los mdulos de mayor uso se hacan resistentes en el ncleo y los menos utilizados residan en un almacenamiento secundario de donde eran llamados solo cuando hacan falta. DCADAS DE LOS 70 Despus de la tercera generacin, a fines de los 70 las computadoras tenan CPU ms rpidos, lo que aumento la disparidad entre su velocidad de procesamiento y el tiempo de acceso ms lento de las entradas y salidas. Los esquemas de multiprogramacin para incrementar el uso del CPU estaban limitados por la capacidad fsica de la memoria principal, un recurso limitado y costoso. Una solucin a esta limitacin fsica fue el desarrollo de la memoria virtual, que aprovecho el hecho de que el CPU solo poda procesar una instruccin a la vez con la memoria virtual, no era necesario que todo programa residiera en memoria antes que se iniciara la ejecucin. Un sistema con memoria virtual dividira los programas en segmentos los mantendra en almacenamiento secundaria y traera cada segmento a la memoria conforme fuera necesario. (Los programadores de computadoras de segunda generacin haban utilizado esta idea con el mtodo de programacin roll in/roll out,
Ing. Romel Alds
13
que hoy se conoce como sper posicin para ejecutar programas que excedan la memoria fsica de esas computadoras). En este tiempo tambin exista una creciente atencin a la necesidad de conservar los recursos de datos el software de administracin de base de datos se convirti en una herramienta popular, ya que organizaba los datos de una manera integral, minimizaba la redundancia y simplificaba la actualizacin y el acceso de los datos. Se introdujo cierta cantidad de sistemas de consulta que permita que incluso un usuario novato recuperar piezas especificas de la base de datos. Estas consultas solan efectuarse por medio de una terminal lo que obligo a un crecimiento en la necesidad de apoyarse en terminales y en software de comunicaciones de datos. Los programadores pronto se distanciaros mas de las complicaciones de la computadora y los programas de aplicacin empezaron a utilizar palabras de tipo ingles, estructuras modulares y operaciones estndares, esta tendencia hacia uso de estndares mejoro la administracin de los programas, ya que el mantenimiento de los mismos se hiso ms rpido y fcil. DCADA DE LOS 80 El desarrollo en este decenio mejoro de una manera dramtica le relacin costo/rendimiento de los componentes de la computadoras. El hardware era ms flexible con funciones lgicas incorporadas en tarjetas de fcil remplazo. Tambin era menos costoso por lo que ms funciones del sistema operativo se hicieron parte del hardware esto dio lugar a un nuevo concepto , el firmware, trmino utilizado para indicar que un programa est contenido de manera permanente en ROM (memoria de lectura solamente) en contraposicin a los que permanecen en almacenamiento secundario la tarea del programador segn se haba definido en aos anteriores, cambio de manera espectacular porque el software del sistema desempeaba muchas funciones de programacin esto simplifico la rea del programador . Este simplifico la tarea del programador y la hizo menos dependiente del hardware. La industria acabo pasando al multiprocesamiento y se disearon lenguaje ms elaboradorados para coordinar las actividades los diversos procesadores que daban servicio a una tarea. Como resultado, se pudieron ejecutar programas en paralelo y llego a ser habitual dar por hecho que los sistemas operativos de computadoras de cualquier tamao aceptaran el multiprocesamiento. La evolucin de la computadora personales y de las comunicaciones de alta velocidad origino el cambio al procesamiento distribuido y los sistemas en red, que permite que usuarios en ubicaciones remotas compartan recursos de hardware y de software. En trminos generales, con los sistemas operativos de red los usuarios reconocieron la existencia de muchos recursos en red y pudieron registrarse en localizaciones remotas y manipular archivos en red muy lejanas. Estos sistemas operativos eran similares a los utilizados en un procesador en cuanto a que cada maquina corran sus sistemas operativo local y tena sus usuarios. La diferencia estaba en la adicin de un controlador de interfaz de red con software de bajo nivel para manejar el sistema operativo local, as como programas que permita el registro a distancia y acceso de archivos remotos. Por otra parte, con el sistema operativo distribuidos, los usuarios podan pensar que estaba trabajando con un sistema uniprocesador tpico, cuando en realidad estaban conectados a una red formada por muchos procesadores que trabajan en intima relacin. Con estos sistemas los usuarios no necesitaban que procesador ejecutara sus aplicaciones ni cual dispositivos almacenaba sus archivos. El sistema operativo manejaba estos detalles de manera transparente, situacin que requera ms que agregar unas cuantas lneas de cdigo a un sistema operativo de un procesador. La desventaja de un sistema operativo de este tipo era la necesidad de algoritmos ms complicados de programacin de procesadores. Adems, los retardos de comunicacin dentro de la red significaba que algunas veces los algoritmos de programacin tenan que operar con informacin incompleta o desactualizada.
Ing. Romel Alds
14
DCADA DE LOS 90 A mediados de los 90 la demanda generalizada de capacidades internet origino la proliferacin de capacidades de red. Hoy, las accesibilidad a web y es intercambio de correo electrnicos son caractersticas comunes en casi todo sistema operativo. Sin embargo, el crecimiento de la red tambin ha creado mayor demanda de seguridad, a fin de proteger el hardware y el software. Durante el decenio tambin proliferaron las aplicaciones de multimedios que demandaban potencia, flexibilidad y compatibilidad de dispositivos adicionales para la mayor parte de sistemas operativos. Una computadora tpica multimedia contiene dispositivos para correr audio, video, creacin grafica y edicin. Esto puede requerir muchos dispositivos especializados como un micrfono un piano digital una o interfaz digital de instrumento musical, una cmara digital, una unidad de disco de video digital unidades de disco compacto CD altavoces, monitoreas adicionales, dispositivos de proyeccin, impresoras de color, conexin internet de alta velocidad, etc. Tambin precisa hardware especializado controladores, tarjetas, buces entre otros as como software para hacer que trabajen juntos correctamente. Los multimedios necesitan una gran capacidad de almacenamiento, misma que el sistema operativo debe administrar con gracia. Por ejemplo cada segundo de un video de pantalla completa de 30 figuras por minuto requiere 27 megabytes de almacenamiento. Esto significa que unos 24 segundo de video caven en un disco compacto estndar. Por lo que un programa de televisin de 20 minutos requerira alrededor de 50 discos de almacenamiento, a menos que se compriman los datos de alguna manera. Para satisfacer la demanda de video comprimido, las compaas de hardware han desarrollado chips y tarjetas de video de uso especial. Un estndar es el video digital interactivo, comprime las imgenes en una relacin de 150:1, por lo que una hora de proyeccin se puede almacenar en menos de un gigabyte. Cul ser el efecto de estos avances tecnolgicos en el sistema operativo, cada avance requiere un avance paralelo en las capacidades de administracin del software. Los sistemas operativos que no puedan mantenerse al da con la demanda se harn obsoletos con rapidez.
Ing. Romel Alds
15
ADMINISTRADOR DEL PR OCESADOR
En los sistemas de un solo usuario, el procesador slo est ocupado el usuario ejecuta una tarea, en todos los dems momentos est ocioso. La administracin del procesador en este entorno es simple. Sin embargo, cuando existen muchas usurarios con muchas tareas en el sistema (esto se conoce como un entorno de multiprogramacin) hay que asignar el procesador a cada tarea de una manera justa y eficiente, lo que puede ser algo complicado, como veremos en este captulo. Antes de empezar, definamos con claridad algunos de los trminos que utilizaremos en las pginas siguientes. Un programa es una unidad inactiva, como un archivo almacenado en un disco. Un programa no es un proceso. Para un sistema operativo, un programa o un trabajo es una unidad de trabajo enviada por el usuario. El trmino trabajo por lo general se asocia con sistema por lotes. Por otra parte, un proceso es una entidad activa, que requiere un conjunto de recursos para llevar a cabo su funcin, entre ellos un procesador y registro especiales. Un proceso, tambin conocido como tarea, es una instancia de un programa ejecutable. Una hebra de control es una porcin de un proceso que se puede ejecutar de manera independiente. Por ejemplo, si su sistema permite que los procesos tengan una sola hebra de control y usted desea una serie de imgenes en el sitio Web de un amigo, puede instruir al navegador (Browser) para que establezca una conexin entre ambos sitios y descargar una imagen a la vez. Sin embargo, si su sistema permite que sus procesos tengan mltiples hebras de control, puede solicitar varias imgenes al mismo tiempo y el navegador o explorador establecer mltiples conexiones y descargar varias imgenes a la vez. El procesador, tambin conocido como CPU (siglas en ingls de unidad de procesamiento central), es la parte de la mquina que lleva a cabo los clculos y ejecuta los programas. La multiprogramacin requiere que el procesador se asigne a cada tarea o proceso durante un periodo y se desasigne en el momento apropiado. Si el procesad or se desasigna durante la ejecucin de un programa, esto debe ocurrir de manera que se pueda reiniciar despus con toda la facilidad posible. Es un procedimiento delicado. Como demostracin, veamos un ejemplo cotidiano. Aqu est usted, confiando en que puede armar un juguete, a pesar de la advertencia que requiere algo de ensamble. Armado con las instrucciones y mucha paciencia, cada paso, uno a la vez, y llegar al producto terminado. El primer paso es unir la parte A con la parte B, utilizando un tornillo de 2 pulgadas y conforme usted lo completa, marca el paso uno como ejecutado. Inspirado por su
Ing. Romel Alds
16
xito, pasa al paso 2 y despus al 3; acaba de completarlo cuando un vecino se lesiona al trabajar con un herramienta elctrica y grita pidiendo ayuda. Rpidamente marca el paso 3 en las instrucciones, de manera que sepa dnde se qued, hace a un lado sus herramientas y corre al lado de su vecino. Despus de todo, tiene mayor importancia la necesidad inmediata de alguien que su xito final con el de un libro de primeros auxilios y utiliza vendajas y antisptico. Luego de tratar con xito la lesin, regresa a su tarea. Conforme recoge sus herramientas, hace referencia a las instrucciones y ve que debe empezar a partir del paso 4. Contina con su proyecto hasta concluirlo. En terminologa de sistemas operativo, usted ejecut el papel de CP U o procesador. Existan dos programas o tareas: una era ensamblar el juguete; la segunda, vendar la lesin. Cuando estaba ensamblando el juguete (tarea A) cada uno de los pasos que llev a cabo era proceso. La llamada de auxilio fue una interrupcin y cuando dej el juguete para ayudar a su amigo herido, pas a un programa de una prioridad superior. Cuando usted fue interrumpido, llev a cabo un cambio de contexto al marcar el paso tres como la ltima instruccin terminada y dej de lado sus herramientas. En cuidado de la lesin de su vecino se convirti terminada y dej de lado sus herramientas. El cuidado de la lesin de su vecino se convirti en la tarea B. Mientras usted ejecutaba las instrucciones de primeros auxilios, cada uno de los pasos que pona en prctica resultaba de nuevo un proceso. Y, naturalmente, cuando cada una de las dos tareas se completan, el procesamiento termina. El administrador del procesador identificara la serie de hechos como sigue:
Obtencin de entrada para la tarea A Identificacin de los recursos Ejecucin del proceso Interrupcin Cambio de contexto a tarea B Obtencin de entrada para la tarea B Identificacin de recursos Ejecucin del proceso Terminacin de la tarea B Cambio de contexto a tarea A Reanuda la ejecucin del proceso Interrumpido Terminacin de la tarea A (localizacin de las instrucciones en la caja) (acopio de las herramientas necesarias) (seguimiento de cada uno de los pasos en turno) (llamada del vecino) (usted marca el sitio donde se qued en las instrucciones) (encuentra el libro de primeros auxilios) (rene los suministros mdicos) (sigue cada paso sealado en el libro de primeros auxilios) (regresa a casa) (se prepara para reanudar el ensamble) (ejecuta los pasos pendientes por turno) (juguete terminado)
Como hemos visto, varias tareas o procesos pueden compartir un procesador. Ahora bien, esto es posible slo si el sistema operativo tiene una poltica de planificacin y un algoritmo de planificacin para determinar cundo dejar de trabajar en una tarea y asumir otra. En este ejemplo, el algoritmo de planificacin se basaba en la prioridad: usted trabajaba en los procesos correspondientes a la tarea A hasta que se present una tarea de prioridad ms elevada. Aunque en este caso se trataba de un buen algoritmo, un algoritmo de planificacin basado en la prioridad no siempre es el mejor, como veremos en este captulo.
PLANIFICACIN DE TRABAJOS PLANIFICACIN DE PROCESOS
EN
COMPARACIN
CON
El administrador del procesador est compuesto por dos sub-administradores, encargados de la planificacin de trabajos y de la planificacin de procesos,
Ing. Romel Alds
17
respectivamente. Se conoce como el planificador de trabajo y el procesos.
planificador de
Tpicamente, un usuario concibe un trabajo como una serie de pasos de tarea globales complicacin, carga y ejecucin- o como un paso completo: ejecucin. Sin embargo, por lo general la mayor parte de los sistemas operativos maneja la planificacin de los trabajos en dos niveles. Si regresamos al ejemplo anterior, podemos observar que existe una jerarqua entre el planificador de trabajos y el de procesos. La planificacin de los dos trabajos, ensamblar el juguete y vendar la lesin, se bas en los conceptos primero en entrar, primero en servirse, y prioridad. El planificador de tareas las inicia con base en ciertos criterios. Una vez seleccionado el trabajo para su ejecucin, el planificador de procesos establece cundo se ejecuta cada paso o conjunto de pasos una decisin que tambin se base en ciertas criterios-. Cuando usted inici el ensamble del juguete, el planificador de procesos habra seleccionado para su ejecucin cada paso en las instrucciones de ensamble. Por lo tanto, cada trabajo (o programa) pasa a travs de una jerarqua de administradores. Dado que el primero que encuentra es el planificador de trabajos, tambin se conoce como planificador de alto nivel. Este subadministrador slo se ocupa de elegir los trabajos de una cola de trabajos que llegan y colocarlas en la cola de procesos, ya sea en lotes o de manera interactiva, con base en las caractersticas de cada uno. Su meta es ubicar las tareas en una secuencia que utilice tanto como sea posible los recursos del sistema. Es una funcin importante. Por ejemplo, si el planificador de trabajos escoge varios para ejecutarlos de manera consecutiva y cada uno tiene muchas E/S (entrada/salida), los dispositivos E/S se mantendrn muy ocupados y el CPU tendra que hacerse cargo de las E/S en caso de que no se utilizara un controlador de E/S- por lo que se ejecutara muy poca computacin. Por otra parte, si el planificador de trabajos selecciona varios trabajos consecutivos con gran cantidad de computacin, el CPU estara muy ocupado, perol os dispositivos de E/S estaran ociosos, en espera de solicitudes E/S. Por lo tanto, un planificador de trabajos busca una mezcla equilibrada de trabajos que requieren grandes cantidades de interaccin E/S y de otros que precisan grandes cantidades de computacin. Su meta es mantener ocupada la mayor parte de los componentes de sistema de la computadora la mayor parte del tiempo.
PLANIFICADOR DE PROCESOS
La mayor parte de este captulo est dedicado al planificador de procesos, porque despus que el panificador de trabajos pone un trabajo en la cola de LISTO, el planificador de procesos se hace a cargo. Define qu trabajos tendrn derecho al CPU, cundo y cunto tiempo. Tambin decide cundo debe interrumpirse el procesamiento, determina a qu colas se debe pasar el trabajo durante su ejecucin y reconoce cundo ha concluido un trabajo y ya no hay necesidad de seguir procesndolo. Este subadministrador en un planificador de bajo nivel que asigna el CPU para ejecutar los procesos de los trabajos que el planificador de trabajos ha colocado en la cola de LISTO. Cuando hay que orquestar el procesamiento de varios trabajos, se convierte en una funcin vital- de la misma manera que cuando usted deja su ensamble y se apresura a ayudar a su vecino. Para planificar el CPU, el planificador de procesos aprovecha un rasgo comn en la mayora de los programas de cmputo: la alternancia entre ciclos CPU y de E/S. Observe que el trabajo que sigue tiene un ciclo de CPU relativamente largo y dos ciclos de E/S muy breves.
Ing. Romel Alds
18
Aunque la duracin y frecuencia de los ciclos del CPU varan de un programa a otro, existen varias tendencias generales que se pueden explotar al seleccionar un algoritmo de planificacin. Por ejemplo, las trabajos limitados por E/S (como la impresin de una serie de documentos) tienen ciclos CPU muy breves y largos ciclos de entras y salidas, en tanto que los trabajos limitados por CPU (como la determinacin de los trescientos primeros nmeros primos) tienen largos ciclos CPU y ciclos de entradas y salidas ms cortos. El efecto total de los ciclos CPU tanto de los trabajos limitados por E/S como de los restringidos por CPU- se aproxima a una curva de distribucin de Poisson (Fig. 4.1.)
En un entorno muy interactivo existe un tercer nivel del administrador del procesador, conocido como planificador de nivel medio. En algunos casos, en especial cuando el sistema est sobrecargo, el planificador de nivel medio encuentra ventajoso retirar trabajos activos de la memoria para reducir el grado de multiprogramacin, y por lo tanto, permitir que los trabajos se completen ms aprisa. Este subadministrador controla los trabajos que se intercambian hacia afuera y de regreso. En un entorno monousuario, no existe distincin entre planificacin de trabajos y de procesos porque en cualquier momento slo un trabajo est activo en el sistema, por lo que el CPU y otros recursos estn dedicados a l hasta que se completa.
ESTADO DE LOS TRABAJOS Y DE LOS PROCESOS

A medida que un trabajo se mueve por el sistema, siempre estar en uno de tres a cinco estados, conforme cambia de ACEPTADO a LISTO a EJECUCIN a BLOQUEADO y por ltimo a TERMINADO (Fig. 4.2.). stos se conocen como estados del trabajo o estados del proceso.
Ing. Romel Alds
19
He aqu cmo cambia el estado de un trabajo cuando un usuario enva un trabajo al sistema por lotes o en forma interactivo. Cuando el sistema lo acepta lo pone en ACEPTADO en una cola. En algunos sistemas el manejador spool del trabajo (o controlador del disco) genera una tabla con las caractersticas dcada trabajo de la cola y advierte las bsicas, como estimacin del tiempo de uso del CPU, prioridad, dispositivos especiales de E/S requeridos y el mximo de memoria necesaria. El planificador de trabajos usa esta tabla para decidir cul ser el siguiente trabajo que se va a ejecutar. Desde ACEPTADO, el trabajo pasa a LISTO cuando est listo para ser ejecutado pero est en espera de CPU. En algunos sistemas, el trabajo (o proceso) se puede colocar directamente en la lista de LISTOS. En EJECUCIN significa que el trabajo est siendo procesado. En sistemas que tienen un solo procesador solamente un trabajo o proceso puede estar en estado EJECUCIN. En BLOQUEADO quiere decir que el trabajo no puede continuar hasta que no se le asigne un recurso especfico o se termina una operacin de E/S. Al completarse, el trabajo est TERMINADO y se devuelve al usuario. El planificador de trabajos o de procesos inicia la transicin de un estado a otro: El planificador de trabajo empieza la transicin de ACEPTADO a LISTO de acuerdo con alguna poltica predefinida. En este momento se verifican la disponibilidad de suficiente memoria principal y cualquier dispositivo requerido. El planificador de procesos maneja la transicin de LISTO a EJECUCIN con base en algn algoritmo predefinido (por ejemplo, FCFS, SJN, planificacin por prioridad, SRT o round robin, todos los cuales se analizarn en breve). El planificador de procesos maneje a la transicin de EJECUCIN a regreso a LISTO, de acuerdo con algn lmite de tiempo predefinido o cualquier otro criterio por ejemplo, una interrupcin de prioridad. El planificador de procesos maneja la transicin de EJECUCIN a BLOQUEADO. Mediante una instruccin en la tarea, como un comando de leer, escribir, cualquier otra solicitud de E/S o alguna que requiera la obtencin de una pgina. El planificador de procesos maneja la transicin de BLOQUEADO a LISTO. Mediante una seal de la administrador de dispositivos de E/S, la cual indica que se ha satisfecho la solicitud de E/S y que la tarea puede continuar. En el caso de una obtencin de agina, el manejador de interrupciones de pgina sealar que sta se encuentra en la memoria y el proceso puede colocarse en la cola de LISTO. Por ltimo, el planificador de procesos o de trabajos inicia la transicin de EJECUCIN a TERMINADO cuando 1) el trabajo se ha completado con xito y termina su ejecucin o 2) el sistema operativo indica que ha ocurrido un error y la tarea se da por terminada de manera prematura.
Ing. Romel Alds
20
Bloques de control de procesos

Cada proceso en el sistema est representado por una estructura de datos, conocida bloque de control de procesos (PCB). Dicha estructura tiene la misma funcin que el pasaporte de un viajero. El PCB (Fig. 4.3.) contiene la informacin bsica sobe la tarea, incluyendo lo que es, dnde va, cunto de su procesamiento se ha completado, dnde est almacenada y cunto ha gastado en recursos.
IDENTIFICACIN DEL PROCESO Cada trabajo es reconocido por la identificacin del usuario y un puntero que lo conecta a su descriptor (suministrado por el planificador de trabajos cuando el trabajo entra en el sistema y es colocado en ACEPTADO).
ESTADO DEL PROCESO Indica el estado actual del trabajo ACEPTADO, LISTO, EN EJECUCIN o BLOQUEADO- y los recursos a cargo de dicho estado. CONDICIN DEL PROCESO condicin actual de la tarea, como: Contiene la informacin necesaria para indicar la
Palabra del estado del proceso. Es el contenido presente del contador y registro de instrucciones cuando no se est ejecutando el trabajo, per se halla en ACEPTADO, LISTO o BLOQUEADO. Si el trabajo est en EJECUCIN, esta informacin se deja sin definir. Contenido del registro. Seala si el trabajo se ha interrumpido y est esperando par a reanudar el procesamiento. Memoria principal. Informacin pertinente, que incluye la direccin donde est almacenado el trabajo y, en el caso de memoria virtual, el mapeo entre localidades virtuales y fsicas de la memoria. Recursos. Informacin de todo lo asignado a este trabajo. Cada recurso tiene un campo de identificacin que lista su tipo y un campo que describe los detalles de su asignacin, como la direccin del sector en un disco. Estos recursos pueden ser unidades de hardware (unidades de disco o impresoras, por ejemplo) o archivos. Prioridad del proceso. Lo usan los sistemas que utilizan un algoritmo de programacin por prioridad para seleccionar el trabajo que se ejecutar a continuacin.
CONTABILIDAD Contiene informacin utilizada principalmente para efectos de facturacin y medicin del rendimiento. Indica qu tipo de recursos utiliz el trabajo y durante cunto tiempo. Los cargos tpicos incluyen:
Cantidad de tiempo del CPU utilizada del principio al final de su ejecucin.

21
Ing. Romel Alds
Tiempo total que el trabajo estuvo en el sistema hasta que sali. Ocupacin en almacenamiento principal, el tiempo en que el trabajo estuvo en memoria hasta que termin la ejecucin. Suele ser una combinacin del tiempo y del espacio utilizado; por ejemplo, en un sistema de paginacin puede registrarse en unidades de pginas por segundo. Almacenamiento secundario utilizando durante la ejecucin. Esto tambin se registra como una combinacin de tiempo y espacio utilizados. Programas utilizados del sistema, como compiladores y editores o utileras. Nmero y tipo de operaciones de E/S, incluyendo el tiempo de transmisin de E/S, lo que abarca utilizacin de canales, unidades de control y dispositivos. Tiempo utilizando en espera de la terminacin de entradas y salidas. Nmero de registros de entrada ledos (en concreto, los que se introdujeron en lnea o que provienen de rastreadores pticos, lecturas de tarjeta u otros dispositivos de entrada) y nmero de registros de salida escritos (en forma especfica, los que se enviaron a la impresora de lneas). Este ltimo distingue entre dispositivos de almacenamiento secundario y dispositivos de entrada y salida tpicos.
Bloques de control de procesos y colas El bloque de control de procesos (PCB) de un trabajo se crea cuando el planificador de trabajos lo acepta y se actualiza conforme ste avanza desde el principio hasta el final de su ejecucin. Las colas utilizan los PCB para llevar el control de los trabajos de la misma manera que los funcionarios de aduanas usan los pasaportes para llevar el control de los visitante internacionales. El PCB contiene los datos del trabajo necesarios para que el sistema operativo administre el procesamiento de ste. Conforme el trabajo se mueve a travs del sistema, su avance se anota en el PCB. Los PCB, no los trabajos, estn vinculados para formar las colas (Fig. 4.4.). Aunque cada PCB no est dibujado con detalle, imagine cada cola como una lista enlazada de PCB. Los bloques de control de procesos par cada trabajo se relacionan en la cola de LISTOS, y todos los PCB con trabajos que acaban de entrar al sistema, en la cola de ACEPTADOS. Ahora bien, las tareas que se encuentran en BLOQUEADO estn vinculadas por razn de la espera, por lo que los PCB de los trabajos de esta categora estn vinculados en varias colas. Por ejemplo, los PCB para trabajos que esperan entradas y salidas de una unidad de disco estn vinculados, en tanto que los que esperan a la impresora en lnea lo estn en una cola diferente. Hay necesidad de administrar estas colas de una manera ordenada, y esto queda determinado por las polticas y algoritmos de planificacin del proceso.
Ing. Romel Alds
22
POLITICAS DE PLANIFICACION DE PROCESOS

En el entorno de multiprogramacin existen por lo general ms trabajos por ejecutar de los que se pueden correr en un momento dado. Antes de que el sistema operativo pueda planificarlos, necesita resolver tres limitaciones de sistema: 1) existe un numero finito de recursos (como unidades de disco, impresoras y unidades de cinta); 2) algunos recursos, una vez asignados, no pueden recibir otro trabajo (como las impresoras), y 3) algunos recursos requieren la intervencin del operador esto es, no se pueden reasignar de manera automtica de un trabajo a otro( como las unidades de cinta). Cul es una buena poltica de planificacin de procesos? Se presentan a la mente varias opciones, pero no te que en la lista siguiente algunas se contradicen. Maximizar la produccin ejecutando tantos trabajos como sea posible en un tiempo dado. Esto es fcil si se ejecutan trabajos breves o sin interrupciones. Minimizar el tiempo de respuesta contestando rpidamente solicitudes interactivas. Esto sera factible ejecutando nada ms trabajos interactivos y dejando que los trabajos por lotes esperen hasta que la carga interactiva desaparezca. Minimizar el tiempo de retorno introduciendo y sacando con rapidez trabajos completos del sistema. Para esto se corren primero los trabajos por lotes (porque estos se pueden agrupar para ejecutarse con mayor eficiencia que los trabajos interactivos). Minimizar el tiempo de espera sacando los trabajos de la cola de LISTOS tan rpido como sea posible. Esto es posible reduciendo el nmero de usuarios permitidos en el sistema, de manera que el CPU est disponible cada que un trabajo entre en la cola de LISTOS. Maximizar la eficiencia del CPU manteniendo el CPU ocupando al 100 por ciento del tiempo. Esto solo es viable ejecutando trabajos limitados por el CPU (no por entradas y salidas). Asegurar la justicia para todos los trabajos dando a todos una cantidad igual de tiempo de CPU y de E/S. Esto es posible sin dar tratamiento especial alguno a los trabajos, sean cual sean sus caractersticas de procesamiento o prioridad. Como todos podemos ver, si el sistema da preferencia a un tipo de usuario, perjudica a otro y no utiliza sus recursos con eficiencia. La decisin final es del diseador del sistema, que debe definir qu criterios son de mayor importancia para dicho sistema. Por ejemplo, si usted podra decidir maximizar la utilizacin del CPU, minimizar el tiempo de respuesta y equilibrar el uso de los componentes de sistema a travs de una mezcla de trabajos limitados por entradas y salidas y CPU. Por lo tanto, seleccionara la poltica de planificacin que satisfaga con mayor precisin sus criterios. Aunque el planificador de trabajos elige trabajos para asegurarse que las colas de LISTOS y de E/S se mantienen equilibradas , hay casos que en un trabajo reclama al CPU durante un tiempo muy largo, antes de emitir una solicitud de entrada y salida. Si las solicitudes de entrada y salida se estn cubriendo ( para lo cual se usa un controlador de entradas y salidas, tema que se analiza ms tarde), este uso intensivo del CPU har que se acumule la cola de LISTOS y al mismo tiempo se vacen las colas de entrad y salida, lo que crea un desequilibrio inaceptable en el sistema. Para resolver este problema el planificador de procesos a menudo utiliza un mecanismo de tiempo y peridicamente, cuando ha expirado un lapso predeterminado interrumpe los procedimientos de ejecucin. Cuando esto ocurre, el planificador suspende toda la actividad de la tarea de ejecucin, la vuelve a reprogramar en la cola de LISTOS y continua su proceso ms tarde. El CPU se asigna a otro trabajo que se ejecuta hasta que ocurra una de estas tres cosa: transcurrido el lapso predeterminado, el trabajo emite un comendo de E/S o se termina. Entonces se lo traslada a la cola de LISTOS, de BLOQUEADOS o de TERMINADOS, respectivamente. Una solicitud de E/S se conoce como espera natural en entornos de multiprogramacin (permite la asignacin del procesador a otros trabajos).
Ing. Romel Alds
23
Una estrategia de planificacin que interrumpe el procesamiento de un trabajo y transfiere al CPU a otro se conoce como poltica de planificacin apropiativa y es muy utilizada en ambientes de tiempo compartido. La alternativa naturalmente es una poltica de planificacin no apropiada, que funciona sin interrupciones externas (interrupciones externas de trabajo). Por lo tanto, una vez que un trabajo captura el procesador e inicia la ejecucin, se mantiene en el estado de ejecucin hasta que se emite una solicitud de E/S (espera natural) o hasta que termina (excepto los ciclos infinitos, que se interrumpen tanto por polticas apropiativas como por no apropiativas).
ALGORITMOS DE PLANIFICACION DE PROCESOS

El planificador de procesos se apoya en un algoritmo de planificacin de procesos, basado en una poltica especfica para asignar el CPU y mover los trabajos por el sistema. Los primeros sistemas operativos utilizan polticas no apropiadas, diseadas para mover los trabajos por lotes a travs del sistema con tanta eficiencia como era posible. La mayor parte de los sistemas actuales, con un nfasis en el uso interactivo de tiempo de respuesta, utiliza un algoritmo que se ocupa de las solicitudes inmediatas de usuarios interactivos. Aqu presentamos seis algoritmos de planificacin de procesos de uso muy difundido.
PRIMERO DE ENTRAR, PRIMERO DE SERVIRSE

Primero de entrar, primero de servirse (FCFS) es un logaritmo de planificacin no apropiativa que maneja los trabajos de acuerdo con su tiempo de arribo: conforme entran son servidos. Es un logaritmo muy simple de implementar, porque utiliza un tipo de cola FIFO, este logaritmo est bien para la mayor parte de los sistemas por lotes, pero es inaceptable para los sistemas interactivos por los usuarios interactivos deben tener tiempos cortos de respuesta. Con los FCFS, conforme un nuevo trabajo entra en el sistema su PCB queda vinculado con el final de la cola de LISTOS y es eliminado de la parte delantera de la cola cuando el procesador queda disponible esto es, despus que ha procesado todos los trabajos que exista en la cola. En un sistema FCFS ciento por ciento, no existen colas de BLOQUEADO (cada trabajo se ejecuta hasta su terminacin), aunque pueden haber sistemas en que el control (contexto) pasa a una espera natural (solicitud de E/S), luego de lo cual el trabajo se reanuda al terminar la operacin de E/S. Los ejemplos que siguen suponen un entorno FCFS por completo (sin multiprogramacin). El tiempo de retorno es impresendible con la poltica FCFS; considere las siguientes tres tareas: El trabajo A tiene un ciclo de CPU de 15 milisegundos B tiene un ciclo de CPU de 2 milisegundos C posee un ciclo de CPU de 1 milisegundo Para cada trabajo, el ciclo CPU contiene tanto el uso real del CPU como las solicitudes de E/S: el tiempo de ejecucin total. La lnea de tiempo (diagrama de Gantt) ilustrada en la figura 4.5 usa un algoritmo FCFS con la secuencia de llegadas A, B, C.
Ing. Romel Alds
24
Si los tres trabajos llegan prcticamente de manera simultnea, podemos calcular que el tiempo de retorno para el trabajo A es 15, para el trabajo B, 17, y para C, 18. Por lo que el tiempo de retorno promedio es: =16,67 Sin embargo, si los trabajos llegasen en un orden diferente, digamos C, B, A, los resultados serian segn se muestra en la figura 4.6, en caso de usar el mismo algoritmo FCFS.
En este ejemplo el tiempo de retorno para el trabajo A es 18, para B es 3, y para C, 1. El tiempo promedio total es: =7.3 Esto es una verdadera mejora sobre la primera secuencia. Por desgracia, estos dos ejemplos ilustran la desventaja principal del uso de concepto FCFS: los tiempos promedio de retorno varan de una manera muy amplia y rara vez se minimizan. De hecho, cuando hay tres trabajos en la cola de LISTOS, el sistema solo tiene una oportunidad en seis de ejecutar los trabajos en la secuencia ms ventajosa (C,B,A)> con cuatro trabajos las oportunidades pasan a una en 24 y as sucesivamente. Si un trabajo monopoliza el sistema, la repercusin de este efecto general en el rendimiento del sistema, la repercusin de este efecto general en el rendimiento del sistema depende de la poltica de planificacin y de si el trabajo est limitado por el CPU o por las entradas o salidas. Cuando un trabajo con un ciclo CPU largo ( en este ejemplo el trabajo A0 utiliza el CPU mientras las otras esperan el momento de entrar al procesamiento o de terminar sus solicitudes de entradas y salidas( si se utiliza un controlador de entradas y salidas rpidamente se colmaran y el CPU quedara ocioso( si es un controlador de entradas y salidas). Esta situacin se resuelve cuando un trabajo limitado por entradas y salidas termina su ciclo de entradas y salidas, las colas empiezan a moverse de nuevo y el sistema se puede recuperar del cuello de botella. En un algoritmo FCFS puro, ninguna de estas situaciones ocurre. Sin embargo, el tiempo de retorno es variable (impredecible). Por esta razn, FCFS es un algoritmo menos atractivo que uno que diera servicio al trabajo ms corto primero, como el siguiente , incluso en un entorno que no fuera de multiprogramacin
SIGUE EL TRABAJO MS CORTO

Sigue el trabajo ms corto(SJN) es un algoritmo de planificacin no apropiativa ( tambin conocido como trabajo ms corto o SJF) que maneja los trabajos con base en la duracin de su ciclo de CPU. Es muy fcil de implementar en entornos por lotes, donde cada usuario da por adelantado el tiempo estimado de CPU requerido para ejecutar el trabajo al inicio del mismo. Sin embargo, no funciona en sistemas interactivos, porque los usuarios no prevn el tiempo de CPU requerido para ejecutar sus trabajos . Por ejemplo, a continuacin hay cuatro trabajos por lotes, todos en la cola de LISTOS, para la cual el ciclo de CPU, o tiempo de ejecucin, se estima como sigue: Trabajo: Ciclo CPU: A 5 B 2 C 6 D 4
Ing. Romel Alds
25
EL algoritmo SJN revisara los cuatro trabajos y los programara para procesamiento en este orden: B, D, A, C. La lnea de tiempo aparece en la figura 4.7.
El tiempo de retorno promedio es: =9.0 Tommonos un minuto para ver por qu este logaritmo puede demostrar ser optimo y dar el tiempo de retorno promedio mnimo. Usaremos el ejemplo de arriba para deducir una formula de tipo general. En la figura 4.7 podemos ver que el trabajo B termina en su tiempo dado (2), el trabajo D acaba en su tiempo dado, mas el tiempo que tuvo que esperar para que se ejecutara B (4+2), el trabajo A finaliza en su tiempo dado ms los tiempos de D mas B (5+4+2) y el trabajo C termina en su tiempo dado ms los de los tres anteriores (6+5+4+2) por lo que al calcular el promedio tenemos:
Como puede ver, el tiempo para el primer trabajo aparece en la ecuacin cuatro vecesuna para cada trabajo-. En forma similar, el tiempo para el segundo trabajo aparece tres veces ( numero de trabajo menos 1); en tiempo del tercero, dos ( trabajos menos 2), y el tiempo del cuarto, una( cantidad de trabajos menos 3). As pues, la ecuacin anterior se puede volver a escribir de la forma:
Dado que el tiempo para e primer trabajo aparece cuatro veces en la ecuacin, tiene cuatro veces ms efecto sobre el tiempo promedio que la duracin del cuarto trabajo, que solo figura una vez. As pues, si el primer trabajo requiere el tiempo de clculo ms breve, seguido en orden por los dems trabajos, ordenadas desde el lapso ms corto hasta el ms largo, el resultado ser el promedio ms pequeo posible. La frmula para el promedio es:
Cuando n es el nmero de trabajos en la cola y para cada uno de los trabajos.
es la longitud del ciclo CPU
Sin embargo, el algoritmo SJN solo es ptimo cuando todos los trabajos estn disponibles al mismo tiempo y las estimaciones de CPU estn al acceso y son precisas.
PLANIFICACIN CON PRIORIDAD

La planificacin con prioridad es un algoritmo no apropiativo y uno de los algoritmos de planificacin ms comunes en sistemas por lotes, aun cuando para algunos usuarios puede dar un tiempo de retorno ms lento. Este algoritmo e tratamiento preferencial a los trabajos importantes. Permite procesar primero y en forma ininterrumpida los programas con la prioridad ms elevada hasta que sus ciclos CPU (tiempos de ejecucin) se hayan completado o hasta que ocurra una espera natural. Si hay dos o ms trabajos
Ing. Romel Alds
26
con prioridad igual en la cola de LISTOS, el procesador se asigna al que llego primero (primero en entrar , primero en servirse dentro de la prioridad). Las prioridades se pueden asignar con un administrador del sistema utilizando las caractersticas extrnsecas de los trabajos; por ejemplo, con base en la posicin del usuario (investigaciones primero, estudiantes primero) o en entornos comerciales, se pueden poner a la venta y el usuario que desee la prioridad ms elevada para garantizar el procesamiento ms rpido posible de sus trabajos, pagara mas. Con un algoritmo por prioridad, los trabajos suelen vincularse a una de varias colas de LISTOS mediante el planificador de trabajos con bases a sus prioridades, por lo que el planificador de procesos administra varias colas de LISTOS en vez de una sola. Ms adelante en este captulo se presentan detalles sobre colas mltiples. El administrador del procesador tambin puede determinar prioridades con base en caractersticas intrnsecas de los trabajos como: Requerimientos de memoria. Es posible asignar prioridades inferiores a los trabajos que requieren grandes cantidades de memoria que a los que solicitan pequeas cantidades de memoria o viceversa. Nmero y tipo de dispositivos perifricos. Se asignara prioridades inferiores a los trabajos que precisan muchos dispositivos perifricos que a los que requieren menos dispositivos. Tiempo total de CPU. Se podra dar menor prioridad a los trabajos con un ciclo de CPU, o tiempo de ejecucin estimado largo, que a los que tiene el tiempo de ejecucin estimado breve. Cantidad de tiempo en el sistema. Es el tiempo total transcurrido desde que se acepto el trabajo para su procesamiento. Algunos sistemas incrementan la prioridad de los trabajos que ya han estado en el sistema por un tiempo extraordinariamente largo, a fin de expeditar su salida. Esto se conoce como envejecer. Estos criterios se utilizan para establecer las prioridades predeterminadas de muchos sistemas. Estas se pueden obviar en funcin de prioridades especficas solicitadas por los usuarios. Existen tambin esquemas de prioridades apropiadas, mismas que se analizan en la seccin de colas mltiples de este captulo.
TIEMPO RESTANTE MS BREVE

El tiempo restante ms breve (SRT) es la versin apropiada del algoritmo SJN. El procesador se asigna al trabajo que este por terminar- pero incluso este trabajo se puede hacer a un lado si un trabajo ms reciente en la cola de LISTOS tiene un tiempo de terminacin mas breve. Este algoritmo no es implementarle en un sistema interactivo, porque requiere saber por adelantado cuanto tiempo del CPU representa la terminacin de cada trabajo. A menudo se utiliza en entornos por lotes, cuando es deseable dar preferencia a trabajos breves, aun cuando el SRT supone ms carga general que el SJN, porque el sistema operativo tiene que vigilar con frecuencia el tiempo del CPU de todos los trabajos en la cola de LISTOS y debe efectuar cambios de contexto para los trabajos que estn intercambiando (conmutando) en el momento de la aprobacin (no necesariamente hacia el disco, aunque esto tambin puede ocurrir). Un ejemplo de la figura 4.8 muestra la forma en que funciona el algoritmo SRT con cuatro trabajos que han llegado en rpida sucesin (con una diferencia de un ciclo de CPU). Tiempo de llegada: Trabajo: Ciclo de CPU: 0 A 6 1 B 3 2 C 1 3 D 4
Ing. Romel Alds
27
En este caso el tiempo de retorno es el tiempo de terminacin de cada trabajo, menos su tiempo de llegada: Trabajo: Tiempo de retorno: A 14 B 4 C 1 D 6
Por lo que el tiempo promedio es: =6.25 Cmo se compara lo anterior con el problema que utiliza la poltica SJN no apropiativa? La figura 4.9 utiliza la misma situacin con SJN.
En este caso el tiempo de retorno es: Trabajo: Tiempo de retorno: A 6 B 9 C 5 D 11
Por lo que el tiempo de retorno es: =7.75 Note que en la figura 4.9 que inicialmente A es el nico trabajo en la cola de LISTOS, por lo que se ejecuta primero y continua hasta que est terminado porque SJN es un algoritmo no apropiativo. El siguiente trabajo que se va a ejecutar es C, porque cuando termina (en el tiempo 6 ) han llegado los dems trabajos (B,C Y D).De estos tres, C tiene el ciclo del CPU ms breve, por lo que es el siguiente que se atiende, despus B y por ultimo D. Por lo tanto, con este ejemplo, SRT en 6.25 es ms rpido que SJN en 7.75. Sin embargo, no incluimos el tiempo requerido por el logaritmo SRT para efectuar el cambio de contexto, el cual se requiere en todos los algoritmos preferentes. Cuando se opta por el trabajo A, toda su informacin de procesamiento se debe guardar en su PCB para uso posterior, cuando prosiga su ejecucin y el contenido del PCB del trabajo B se cargue en los registros apropiados de manera que pueda volver a ejecutarse; esto es un cambio de contexto; esta vez la informacin del trabajo desplazado se almacena en su PCB y el contenido del PCB del trabajo A se carga en los registros apropiados. 28
Ing. Romel Alds
La forma en que se lleva a cabo el cambio de contexto depende de la arquitectura del CPU; en muchos sistemas existen instrucciones especiales que proporcionan un rpido guardado y restauracin de la informacin. La conmutacin esta diseada para que se d con eficiencia; pero sea cual sea su rapidez, aun consume un tiempo valioso del CPU. Por tanto, aunque el SRT aparecera como mas rpido, en un entorno real de operacin sus ventajas se ven disminuidas por el tiempo que se utiliza en los cambios de contexto. Una comparacin precisa del SRT del SJN tendra que incluir el tiempo requerido para efectuar el cambio de contexto.
ROUND ROBIN
Round Robin es un algoritmo de planificacin de procesos apropiadamente muy difundido en sistemas interactivos, ya que es fcil de implementar y no se basa en las caractersticas del trabajo sino en una fraccin predeterminada de tiempo que se da a cada trabajo, para asegurar que los procesos activos compartan por igual el CPU y que ningn trabajo lo monopolice Esta fraccin de tiempo se conoce como quantum de tiempo y su tamao es vital para el desempeo del sistema. Por lo general varia de 100 milisegundos a 1 0 2 segundos (Pinkert & Wear, 1989). Los trabajos se colocan en la cola de LISTOS utilizando el esquema de primero en entrar, primero en servirse, y el planificador de procesos selecciona el primero en la parte delantera de la cola, pone en marcha el reloj en el quantum de tiempo y asigna el CPU a este trabajo. Si el procesamiento no ha terminado cuando expira el tiempo, se retira el trabajo, se coloca al final de la cola de LISTOS y su informacin e guarda en su PCB. En caso que el ciclo de CPU del trabajo sea ms breve que el quantum de tiempo, ocurrir una de dos situaciones:1) si se trata del ltimo ciclo CPU del trabajo y este ha terminado, todos los recursos asignados al mismo se liberan y el trabajo ha completado se devuelve al usuario; 2) si una solicitud de E/S ha interrumpido del ciclo de CPU el trabajo, la informacin de la tarea se guarda en su PCB y queda vinculada al final de la cola apropiada de entradas y salidas. Luego, una vez satisfecha la solicitud de E/S, se devuelve al final de la cola de LISTOS para esperar asignacin de CPU. El ejemplo de la figura 4.10 ilustra un algoritmo de round robin con una fraccin de tiempo de 4 milisegundos ( se ignora las solicitudes de E/S) Tiempo llegada: Trabajo: Ciclo de CPU: de 0 A 8 1 B 4 2 C 9 3 D 5
El tiempo de retorno es el lapso en que se termina, menos el tiempo de llegada: Trabajo Tiempo retorno de A 20 B 7 C 24 D 22
Ing. Romel Alds
29
Por lo que el tiempo promedio de retorno es:
Note que en la figura 4.10 el trabajo A se hizo de lado una vez porque necesitaba 8 milisegundos para completar su ciclo de CPU, en tanto que el trabajo B termin en un tiempo de quantum. El trabajo C se retir dos veces porque necesitaba 9 milisegundos para completar su ciclo de CPU y el trabajo D se retir una vez porque requera 5 milisegundos. En su ltima ejecucin o intercambio en la memoria, los trabajos D y C utilizaron el CPU durante un milisegundo y terminaron antes que expirara su tiempo de quantum, con lo que liberaron el CPU ms aprisa. La eficiencia de round robin depende del tamao de quantum en relacin con el ciclo promedio del CPU. Si dicho quantum es demasiado grande esto es, mayor que la generalidad de los ciclos del CPU -, el algoritmo se reduce a un sistema FCFS. Si es demasiado pequeo, la cantidad de cambios de contexto disminuyen la velocidad de ejecucin de los trabajos y la carga general se incrementa en forma gramtica, como demuestran los tres ejemplos de la figura 4.11. el trabaja A tiene un ciclo de CPU de 8 milisegundos. La cantidad de cambios de contexto se incrementa conforme se reduce de tamao el tiempo de quantum. En la figura 4.11 el primer caso a) tiene un tiempo de quantum de 10 milisegundos y no hay cambio de contextos (sin carga general). El ciclo del CPU termina antes que expire el tiempo de quantum y el trabajo se ejecuta hasta terminarse. Para ese trabajo con este quantum no hay diferencia entre los algoritmos de round robin y de FCFS. En el segundo caso b), con un tiempo de quantum de 5 milisegundos, existe un cambio de contexto. El trabajo se retira una vez cuando el quantum expira, por lo que existe algo de carga general por cambio de contexto, y abra un tiempo de retorno retrasado con base en la cantidad de otros trabajos en el sistema. En el tercer caso c), con un tiempo de cambio de 1 milisegundo, hay siete cambios de contexto por que el trabajo se retira cada que expira el tiempo de quantum, la carga general se vuelve costosa y, por consiguiente, el tiempo de retorno sufre. Cul es el tamao ms adecuando de tiempo de quantum? La respuesta debe ser predecible en este momento: depende del sistema. Si se trata de un entorno interactivo, se espera que el sistema responda con rapidez a sus usuarios, en especial cuando hacen solicitudes simples. Si se trata de un sistema por lotes, el tiempo de respuesta no es un factor (el tiempo de retorno lo es) y la carga general adquiere importancia. Existen dos reglas practicas generales para seleccionar el quantum correcto: 1) debe ser lo bastante largo para permitir que 80% de los ciclos CPU se ejecuten hasta su terminacin, 2)debe ser por lo menos 100 veces ms largo que el tiempo requerido para llevar a cabo un cambio de contexto. Estas reglas se utilizan en algunos sistemas, pero no son inflexibles (Finkel, 1986).
Ing. Romel Alds
30
COLAS DE MULTIPLES NIVELES

Las colas de mltiples niveles no son en realidad un algoritmo de planificacin por separado, pero funcionan junto con varios de los esquemas ya analizados y se encuentran en sistemas con trabajos que se pueden agrupar de acuerdo con una caracterstica comn. Ya hemos presentado por lo menos un tipo de cola de mltiples niveles: la de un sistema basado en prioridades con diferentes colas por cada nivel de importancia. Otro tipo de sistema puede reunir los trabajos limitados por CPU en una cola y los trabajos restringidos por entradas y salidas en otra. Luego el planificador de procesos seleccionara de manera alterna trabajos de cada cola, para mantener el sistema equilibrado. Un tercer ejemplo comn es el utilizado en un entorno hibrido, que acepta trabajos por lotes he interactivos. Los primeros se ponen en una cola llamada cola de segundo plano en tanto que los segundos se ubican en una cola de primer plano y se tratan mas favorablemente que los correspondientes a las colas de segundo plano. Todos estos ejemplos tiene algo en comn: la poltica de planificacin se basa en algn esquema predeterminado, que da un tratamiento especial a los trabajos de cada cola. En cada cola, los trabajos se asignan de manera FCFS. Las colas de mltiples niveles plantean algunas preguntas interesantes. El procesador queda asignado a los trabajos de la primera cola hasta que se vaca, antes de pasar a la siguiente cola, o se mueve de una co la a otra, hasta servir el ltimo trabajo de la ltima y regresa para servir el primer trabajo de la primera cola, o algo intermedio? Es justa para los que han ganado o pagado por una prioridad ms elevada? Es justa para las que se encuentran en una cola de baja prioridad? Si el procesador se asigna a los trabajos de la primera cola y nunca se vaca, Cundo se atendern los trabajos de las ltimas colas? Los trabajos de las ltimas colas pueden obtener algn premio por buen comportamiento y terminar pasando a colas mejore? Las respuestas dependen de la poltica utilizada por el sistema para atender las colas. Existen cuatro mtodos principales para el movimiento: no permitir desplazamiento alguno entre colas, mover trabajos de una a otra cola, pasarlas de una cola a otra cola e incrementar los quanta de tiempo para colas inferiores y dar un tratamiento especial a
Ing. Romel Alds
31
los trabajos que han estado en el sistema durante largo tiempo. Esto ltimo se conoce como envejecimiento. Los siguientes ejemplos de casos se derivan de Yourdon (1972). CASO 1, NINGUN MOVIMIENTO ENTRE COLAS. La falta de movimiento entre colas es una poltica muy simple, que premia a las que tienen trabajos de alta prioridad. El procesador se asigna de manera FCFS a los trabajos en la cola de alta prioridad y solo cuando estas se han vaciado se ocupa de los trabajos en las colas de baja prioridad. Esta poltica se puede justificar si existen pocos usuarios de trabajos de alta prioridad por lo que las colas superiores se vacan con rapidez y permiten que el procesador utiliza una cantidad razonable de tiempo en la ejecucin de trabajos de baja prioridad. CASO 2, MOVIMIENTO ENTRE COLAS. El desplazamiento entre colas es una poltica que ajusta las prioridades asignadas a cada trabajo: una vez que los de alta prioridad estn en el sistema, se tratan como todos los dems (su prioridad inicial puede ser favorable). Cuando ocurre una interrupcin de quantum de tiempo, el trabajo se retira y se mueve al final de la siguiente cola inferior. Tambin cabe incrementar la prioridad de un trabajo por ejemplo, cuando emite una solicitud de entrada y salida antes que acabe su quantum de tiempo. Esta poltica es la ms justa en un sistema en que los trabajos se manejan de acuerdo con sus caractersticas del ciclo de computo: limitados por CPU o por entradas y salidas. Esto supone que un trabajo que excede su quantum de tiempo est restringido por el CPU y puede requerir mas asignacin de este que aquel que solicita entradas y salidas antes que expire el quantum de tiempo. Por lo tanto, los trabajos limitados por CPU se colocan al final de la siguiente cola inferior cuando se han quitado debido a la expiracin del quantum, en tanto que una vez que termina su solicitud de entrada salida, los trabajos restringidos por entradas y salida se devuelven al final de la siguiente cola de nivel alto. Esto facilita los trabajos limitados por entradas y salidas (y es bueno en sistemas interactivos). CASO 3, QUANTUM DE TIEMPO VARIABLE POR COLA. El quantum de tiempo variable por cola es una variable del movimiento entre colas y permite un tiempo de retorno ms rpido de los trabajos limitados por CPU. En el esquema, a cada cola se da un quantum de tiempo dos veces ms largo que la cola anterior. La cola ms elevada puede tener un quantum de 100 milisegundos, por lo que la segunda cola tendr un quantum de 200 milisegundos, la tercera de 400 milisegundos, etc. Si hay suficientes colas, las ms baja pudiera tener un quantum de tiempo relativamente largo, de 3 segundos o ms. Si un trabajo no termina su ciclo de CPU en el primer quantum de tiempo, es movido al final de la siguiente cola de nivel inferior; luego cuando se le vuelve a asignar procesador, su ejecucin ocupa dos veces ms que antes. Con este esquema, un trabajo limitado por CPU puede ejecutarse durante perodos mas y mas largos, mejorando as sus oportunidades de terminar mas a prisa. CASO 4, ENVEJECIMIENTO. Se utiliza para asegurar que los trabajos en las colas de nivel inferior completaran su ejecucin. El sistema operativo controla el tiempo de espera de cada trabajo y cuando uno se hace demasiado antiguo esto es, cuando alcanza cierto tiempo - , se cambia a la siguiente cola ms alta, y as sucesivamente, hasta que llega a la cola superior. Una poltica de envejecimiento ms drstica mueve el trabajo viejo desde la cola ms baja hasta el extremo de la cola ms alta. Sin importar su implementacin real, una poltica de envejecimiento protege contra posposicin indefinida de trabajos muy grandes. Como usted poda espera la posposicin indefinida significa que la ejecucin de un trabajo se retrasa de manera indefinida, porque una y otra vez se retira para procesar otros trabajos (todos conocemos ejemplos de un trabajo desagradable que ha sido pospuesto de manera indefinida para dar tiempo a un pasatiempo ms atractivo). Por ltimo, la situacin podra llevar a la inanicin del
Ing. Romel Alds
32
trabajo envejecida. La posposicin indefinida es un problema importante al asignar recursos y se analizara a detalle en el captulo 5.
MEMORIA CACHE
La memoria cache es una versin de rpido acceso, diseada para resolver las diferencias de velocidad entre un CPU muy rpido y una memoria principal ms lenta. Lo hace almacenando una copia de los datos de uso frecuente en una memoria de fcil acceso en vez de la memoria principal, cuyo acceso es ms lento. Un tamao de cache razonablemente pequeo puede general mejoras significativas en el rendimiento (Stallings, 1998). Dado que la memoria cache es un pequeo espacio que contiene relativamente pocos datos, el procesador tiene acceso a sus datos e instrucciones con mucha mayor rapidez que si tuviera que recuperarlos de la memoria principal (Stair, 1999). La memoria cache se localiza entre el procesador y la memoria principal (figura 4.12). La memoria cache aprovecha el principio de localidad de referencia, que se describi en los captulos de la administracin de la memoria. Otro ejemplo del mismo principio es un archivo de marca libros en un navegador de web que almacena direcciones de uso frecuente; esto es, el archivo marca libros solo almacena un porcentaje pequeo de las direcciones validas de web, pero las posibilidades son relativamente elevadas de que usted las visite.
Un controlador de cache determina la frecuencia con que se utilizan los datos, transfiere los que se usan a menudo a la memoria cache y los elimina cuando identifica datos de uso aun ms constante (para una explicacin detallada de los controladores lea el captulo 7). Los datos en la memoria cache se deben considerar como temporales. En caso de una falla de energa, se pierden y no se pueden recuperar a diferencia de los datos escritos en el almacenamiento secundario.
UNA PALABRA SOBRE INTERRUPCIONES

Las interrupciones o fallas se producen cuando el administrador de la memoria emite interrupciones de pgina para dar entrada a solicitudes de tarea. Existe otro tipo de interrupcin, que ocurre cuando el quantum de tiempo expira y el procesador es desasignado del trabajo en ejecucin y asignado a otro. Existen otras interrupciones causadas por hechos internos al proceso. Las interrupciones de entrada y salida se emiten cuando se manda un comando de READ ODEWRITE (los explicaremos en detalle en el captulo siguiente). Las interrupciones internas, o
Ing. Romel Alds
33
interrupciones sincrnicas, tambin ocurren como resultado directo de la operacin aritmtica o instruccin de trabajo en proceso. Las operaciones aritmticas y legales, como las que se dan a continuacin, pueden general interrupciones: Intentos de dividir entre cero. Operaciones de punto flotante que generen un sobre flujo (o desbordamiento) o un sub flujo. La suma o la sustraccin de punto fijo que cause un sobre flujo aritmtico.
Las instrucciones ilegales de trabajos como las que siguen tambin pueden generar interrupciones: Intento de tener acceso a localidades de almacenamiento protegidas o inexistentes. Intentos de utilizar un cdigo de operacin no definido. Operacin sobre datos invlidos. Intentos de efectuar cambios al sistema, como tratar de modificar el tamao del quantum de tiempo.
El programa de control que maneja la secuencia de interrupcin de los hechos se conoce como manejador de interrupciones. Cuando el sistema operativo detecta un error no recuperable, el manejador de interrupciones sigue esta secuencia: 1. Se describe y se almacena el tipo de interrupcin para enviarlo al usuario como mensaje de error . 2. Se guarda el estado del proceso interrumpido, incluyendo el valor del contador del programa, la especificacin del modo y los contenidos de los registros. 3. Se procesa la interrupcin: el mensaje de error y el estado del proceso interrumpido se envan al usuario; la ejecucin del programa se detiene, cualquier recurso asignado al trabajo se libera y el trabajo sale del sistema. 4. El procesador reanuda una operacin normal. Si estamos tratando con interrupciones internas nicamente, que no son recuperables, el trabajo termina en el paso 3, sin embargo, cuando el manejador de instrucciones trabaja con una interrupcin de E/S, un quantum de tiempo u otra interrupcin recuperable, el paso 3 detiene el trabajo y lo mueve a la cola apropiada de dispositivos de entrada y salida o a la cola de LISTOS (fuera de tiempo). Ms tarde, cuando acaba la solicitud de entrada y salida, el trabajo es devuelto a la cola de LISTOS. Si se trata de un tiempo fuera (interrupcin de quantum) el trabajo (o proceso) ya est en la cola de LISTOS.
Ing. Romel Alds
34
Ing. Romel Alds
35
ADMINISTRACIN DE LOS PROCESOS
Ya hemos visto dos aspectos de compartir recursos, la administracin de la memoria y compartir el procesador. En este captulo encararemos los problemas que se presentan cuando muchos procesos compiten por relativamente pocos recursos y el sistema no es capaz de dar servicio a todos los procesos en el sistema. Una carencia de sincronizacin de los procesos puede dar como resultado dos condiciones extremas: el bloqueo mutuo o la inanicin. En los primeros sistemas operativos, el bloqueo mutuo se conoca con la frase ms descriptiva de abrazo mortal. Es un enredo a nivel del sistema de solicitudes de recursos que se inicia cuando dos o ms trabajos se ponen en espera, cada uno aguardando que quede disponible un recurso vital. El problema se genera cuando otros trabajos ocupan los recursos que necesitan los primeros y no pueden liberarlos y seguir corriendo porque tambin aguardan otros recursos que no estn disponibles. Todos los trabajos se detienen. El bloqueo mutuo es completo si el resto del sistema tambin llega a un paro total. Por lo general el sistema operativo es incapaz de resolver la situacin y requiere intervencin exterior, ya sea de los operadores o usuarios, que deben tomar acciones drsticas, como retirar o terminar a mano un trabajo. Es ms fcil describir un bloqueo mutuo con un ejemplo: una escalera angosta en un edificio (regresaremos a este ejemplo a lo largo del captulo). La escalera se construy como salida en caso de incendio, pero las personas que trabajan en el edificio a menudo la utilizan en vez de esperar los elevadores, que son lentos. El trfico en ella se mueve bien, a menos que necesiten pasar dos personas que se desplazan en direcciones opuestas, que que solo hay sitio para una en cada escaln. En este ejemplo, la escalera es el sistema y los descansos son los recursos. Existe un descanso entre cada piso y tiene la suficiente amplitud para que lo compartan varias personas; pero las escaleras no lo son y solo se pueden asignar a un usuario a la vez. Ocurren problemas cuando alguien que sube se encuentra con alguien que baja y ninguno acepta regresar a un lugar ms amplio. Esto crea un bloqueo mutuo, que el objeto de gran parte de nuestro anlisis sobre la sincronizacin de los procesos. Por otra parte, si unas cuantas personas pacientes esperan en el descanso a que se aclare el trfico en sentido contrario, y dicha situacin no ocurre nunca, pueden esperar ah para siempre. Esto es la inanicin, un caso extremo de posposicin indefinida, y se analizar cerca del final de este captulo.
Ing. Romel Alds
36
BLOQUEO MUTUO
El bloqueo mutuo es ms serio que la posposicin indefinida o inanicin porque afecta ms de un trabajo. Dado que los recursos estn en uso, la totalidad del sistema (no unos cuantos programas) queda afectado. El ejemplo que ms se utiliza para ilustrar este caso es un congestionamiento de trfico. Como se muestra en la figura 5.1, no existe una solucin simple e inmediata para el bloqueo mutuo: nadie puede avanzar mientras alguien no se quite del camino, pero nadie se puede quitar del camino en tanto alguien no avance o la parte trasera de una lnea retroceda. Es obvio que se requiere la intervencin exterior para eliminar uno de los cuatro vehculos de una interseccin o hacer que una lnea retroceda; solo entonces se puede resolver el bloqueo mutuo. Los bloqueos mutuos eran pocos frecuentes en los primeros sistemas por lotes porque los usuarios incluan en las tarjetas de control de los trabajos que precedan al trabajo una lista completa de los recursos del sistema (unidades de cinta, discos, impresoras, etc) requeridos para ejecutarlo. El sistema operativo se aseguraba que todos los recursos solicitados estuvieran disponibles y asignados a dicho trabajo, antes de pasar el trabajo a la cola de LISTOS y no los liberaba mientras el trabajo no estuviera completo. El trabajo no pasaba a la cola de LISTOS mientras los recursos no estuvieran disponibles. Los bloqueos mutuos se volvieron ms frecuentes con el uso creciente de los sistemas interactivos, porque stos son ms flexibles que los entornos por lotes. Por lo general, dichos sistemas mejoran el uso de los recursos al compartirlos en forma dinmica; ms esta capacidad de compartir recursos tambin incrementa la posibilidad de los bloqueos mutuos.
Siete casos de bloqueo mutuo

Un bloqueo mutuo por lo general ocurre cuando recursos insustituibles que no se pueden compartir como archivos, impresoras o unidades de cinta- se asignan a trabajos que terminarn por requerir otros recursos incompartibles e insustituibles esto es, recursos bloqueados por otros trabajos-. Sin embargo, los bloqueos mutuos no se limitan a archivos, impresoras y unidades de cinta; tambin pueden ocurrir en recursos compartibles, como discos y bases de datos, segn veremos en los ejemplos que siguen.
Ing. Romel Alds
37
CASO 1: BLOQUEOS MUTUOS EN SOLICITUDES DE ARCHIVO Si se permite que las tareas soliciten y conserven archivos durante la duracin de su ejecucin, puede ocurrir un bloqueo mutuo. La figura 5.2 muestra el bloqueo mutuo mediante una representacin modificada de grficas dirigidas, que se analiza en mayor detalle en la seccin relativa a los modelos de bloqueo mutuo. Por ejemplo, considere el caso de una empresa de construccin de casas habitacin con dos programas de aplicacin, compras (P1) y ventas (P2), activos al mismo tiempo. Para actualizar transacciones cotidianas cada uno necesita tener acceso a dos archivos, inventarios (F1) y proveedores (F2). Un da el sistema se bloquea mutuamente cuando ocurre la siguiente secuencia de circunstancias.
1. Compras (P1) accede el archivo de proveedores (F2) para colocar un pedido para ms madera.
Ing. Romel Alds
38
2. Ventas (P2) accede el archivo de inventarios (F1) para reservar los componentes que se requerirn a fin de construir la casa habitacin pedida ese da. 3. Compras (P1) no libera el archivo de proveedores (F2), pero solicita el archivo de inventarios (F1) para comprobar la cantidad de madera a mano, antes de colocar su pedido por ms, pero P1 est bloqueado porque P2 tiene a F1. 4. Mientras tanto, ventas (P2) no libera el archivo de inventarios (F1), pero solicita el archivo de proveedores (F2) para verificar el programa de un subcontratista. Al llegar a este punto P2 tambin queda bloqueado porque F2 est en manos de P1. Cualesquiera otros programas que requieran F1 o F2 se pondrn en espera por el tiempo que esta situacin contine. Este bloqueo se mantendr hasta que se retire o quite a la fuerza uno de los dos programas y su archivo quede liberado. Solo entonces el otro programa podr continuar y el sistema regresar a la normalidad. CASO 2: BLOQUEOS MUTUOS EN BASES DE DATOS Tambin puede ocurrir bloqueo mutuo si dos procesos acceden y bloquean registros de una base de datos. un
Para apreciar el escenario que sigue es necesario recordar que las consultas y transacciones de las bases de datos suelen ser procesos relativamente breves que buscan o modifican partes de una base de datos. Por lo general las solicitudes llegan al azar y pueden estar entrelazadas de manera arbitraria. El bloqueo es una tcnica utilizada para garantizar la integridad de los datos, a travs de la cual el usuario bloqueo a los dems usuarios mientras est trabajando con la base de datos. El bloqueo puede efectuarse en tres niveles: en toda la base de datos durante la duracin de la solicitud, en una subseccin de la misma o en el registro individual hasta que el proceso termine, si se bloquea la base de datos ( la solucin ms extrema y de mayor xito) se impide que ocurran los bloqueos mutuos, pero el acceso a la base de datos queda restringido a un usuario a la vez y, en un entorno multiusuario, los tiempos de respuesta de reducen de manera significativa; por tanto, esto no suele ser una solucin aceptable, cuando solo se bloquea parte de la base de datos, el tiempo de acceso mejora, pero s incrementa la posibilidad de un bloqueo mutuo porque diferentes procesos a veces necesitan trabajar con varias porciones de las bases de datos al mismo tiempo. A continuacin presentamos un sistema que bloquea cada registro cuando es accedido hasta que el proceso se completa. Existen dos procesos (P1 y P2), cada uno necesita actualizar dos registros (R1 y R2) y la secuencia que sigue nos lleva a un bloqueo mutuo: 1. 2. 3. 4. P1 P2 P1 P2 accede a R1 y lo bloquea. usa a R2 y lo bloquea. solicita a R2, que est bloqueado por P2. pide R1, que est bloqueado por P1.
Una alternativa es no utilizar bloqueo; pero esto no lleva a otras dificultades. Si no se utilizan bloqueos para preservar la integridad, los registros actualizados en la base de datos pueden incluir solo parte de los datos y su contenido dependera del orden en que cada proceso termina su ejecucin. Esto se conoce como carrera entre procesos y se ilustra en el ejemplo que sigue en la figura 5.3.
Ing. Romel Alds
39
Digamos que usted es un estudiante veterano, que sabe que la universidad conserva la mayor parte de sus archivos en una base de datos que se puede acceder mediante varios programas, incluyendo uno para calificaciones y otro que lista direcciones personales. Digamos que usted es un estudiante que cambia de domicilio, por lo que le enva su nueva direccin a la universidad a final del semestre de otoo, poco tiempo despus que las calificaciones han sido emitidas. Un da fatal, ambos programas corren para tener acceso a su registro en la base de datos. 1. El proceso de notas o calificaciones (P1) es el primero en tener acceso y copia el registro (R1) en su rea de trabajo. 2. El proceso de direcciones (P2) entra a su registro (R1) y lo copia a su rea de trabajo. 3. P1 modifica a R1 introduciendo sus notas para el otoo y calculando su nuevo promedio. 4. P2 cambia a R1 actualizando el campo de la direccin. 5. P1 termina su trabajo primero y vuelve a escribir su versin de su registro de regreso en la base de datos. Sus calificaciones o notas han sido modificadas, pero no su direccin. 6. P2 termina y vuelve a escribir su registro actualizado de regreso a la base de datos. Su direccin ha sido modificada, pero no sus notas. De acuerdo con la base de datos, usted no asisti a la escuela durante ese semestre. Si invertimos el orden y decimos que P2 gan la carrera, sus notas estarn actualizadas, pero no su direccin. Segn su xito en el aula, usted puede preferir un mal al otro, pero desde el punto de vista del sistema operativo, cualquiera de las alternativas es inaceptable, porque permite que datos incorrectos contaminen la base de datos. El sistema no puede permitir que la integridad de la base de datos dependa de una secuencia aleatoria de circunstancias. CASO 3: BLOQUEOS MUTUOS EN LA ASIGNACIN DE DISPOSITIVOS DEDICADOS El uso de un grupo de dispositivos dedicados puede bloquear el sistema. Digamos que dos usuarios del consejo local de educacin estn ejecutando sendos programas (P1 y P2) y ambos terminarn por requerir dos unidades de cinta para copiar los archivos de una cinta a otra. El sistema es pequeo y cuando los dos programas se han iniciado, solo estn disponibles dos unidades de cinta, asignadas con base en segn se solicite. Pronto ocurre la secuencia que sigue: 40
Ing. Romel Alds
1. 2. 3. 4.
P1 P2 P1 P2
solicita la unidad de cinta 1 y la obtiene. pide la unidad de cinta 2 y la obtiene. solicita la unidad de cinta 2 pero est bloqueada. pide la unidad de cinta 1 ms est bloqueada.
Ninguno de los trabajos puede continuar porque estn esperando que termine el otro y que libere su unidad de cinta, un hecho que jams ocurrir. Una serie similar de circunstancias puede bloquear mutuamente cualquier grupo de dispositivos dedicados. CASO 4: BLOQUEOS EN LA ASIGNACIN MLTIPLE DE DISPOSITIVOS Los bloqueos no ocurren nada ms procesos que compiten por el mismo tipo de dispositivo; pueden presentarse cuando varios procesos solicitan y se quedan con dispositivos dedicados, en tanto que otros procesos actan de manera similar a la mostrada en la figura 5.4.
Considere el caso de una empresa de diseo de ingeniera con tres programas (P1, P2 y P3) y tres dispositivos dedicados: unidad de cinta, impresora y graficador. La siguiente secuencia de circunstancias resultar en un bloqueo mutuo: 1. 2. 3. 4. 5. 6. P1 P2 P3 P1 P2 P3 solicita y obtiene la unidad de cinta. pide y obtiene la impresora. solicita y obtiene el graficador. pide la impresora pero se encuentra bloqueada. solicita el graficador pero est bloqueado. pide la unidad de cinta pero se encuentra bloqueada.
Igual que en los ejemplos anteriores, ninguno de los trabajos puede continuar porque cada uno espera un recurso ocupado por otro. CASO 5: BLOQUEOS MUTUOS EN OPERACIONES PERIFRICAS SIMULTNEAS EN LNEAAunque en el ejemplo anterior la impresora era un dispositivo dedicado, la mayor parte de los sistemas han transformado la impresora en un dispositivo compartible ( tambin conocido como dispositivo virtual) al instalar un dispositivo de alta velocidad, un disco, entre ella y el CPU. El disco acepta las salidas de varios usuarios y acta como un rea de almacenamiento temporal para todas las salidas, hasta que la impresora puede aceptarlas. Este proceso se conoce como operaciones perifricas simultneas en lnea (spooling). Si antes de empezar a imprimir la impresora necesita todas las salidas de una tarea, pero el sistema de spool llena un espacio disponible de disco con una salida parcialmente completada, puede ocurrir un bloqueo mutuo. Esto sucede como sigue. Digamos que falta una hora antes de que se necesite el gran proyecto para la clase de computacin. Veintisis programadores acelerados teclean sus cambios finales y, con
Ing. Romel Alds
41
unos cuantos minutos disponibles, emiten comandos de impresin. El manejador de spool recibe las pginas de cada estudiante una por una, pero le llegan por separado, varias pginas uno, dos, etc. La impresora est lista para imprimir el primer programa completo que obtiene, pero conforme el manejador de spool (esto es, el operador perifrico simultneo en lnea) recorre sus archivos, obtiene la primer pgina de muchos programas, pero no tiene la ltima de ninguno. Por desgracia, el spool est lleno de salidas semicompletadas, por lo que no puede aceptar otra pgina; pero ninguno de los trabajos se puede imprimir ( lo que liberara su espacio en disco) porque la impresora solo acepta archivos de salida completos. Una situacin desafortunada. Este escenario no se limita a impresoras. Cualquier parte del sistema que se base en spooling, como el que maneja los trabajos de entrada o transfiere archivos en una red, es vulnerable ante un bloqueo mutuo. CASO 6: BLOQUEOS AL COMPARTIR DISCOS Los discos estn diseados para ser compartidos, por lo que no es raro que dos procesos usen reas diferentes del mismo disco. Sin controles para regular el uso de la unidad de disco, los procesos en competencia podran enviar comandos conflictivos y bloquear el sistema, como se ve en al figura 5.5. Por ejemplo, en una empresa de seguros el sistema lleva a cabo muchas transacciones cotidianas. Una de las siguientes series de circunstancias bloqueo el sistema:
1. El proceso P1 desea mostrar un pago, por lo que emite un comando para leer el saldo, que est almacenado en el cilindro 20 de un paquete de discos. 2. Mientras la unidad de control est moviendo el brazo hacia el cilindro 20, P1 se pone en espera y el canal de entradas/salidas queda libre para procesar la siguiente solicitud de entrada/salida. 3. P2 obtiene el control del canal de entradas/salidas y emite un comando para escribir el pago de otra persona en un registro almacenado en el cilindro 310. Si el comando no est bloqueado P2 quedar en espera, mientras la unidad de control mueve el brazo hasta el cilindro 310. 4. Puesto que P2 est en espera el canal est libre y P1 puede capturarlo de nuevo, lo que vuelve a confirmar su comando de leer del cilindro 20. 5. Dado que el ltimo comando de P2 ha obligado al mecanismo del brazo hasta el cilindro 310, la unidad de control de disco empieza a reubicarlo para el cilindro 20 a fin de satisfacer a P1. El canal de entradas/salidas ser liberado, porque P1 ha quedado de nuevo en espera, por lo que P2 puede capturarlo. Este emite un comando WRITE y descubre que hay necesidad de reubicar el mecanismo del brazo. Como resultado, el brazo est en un estado continuo de movimiento, pasando de un lado a otro entre el cilindro 20 y el cilindro 310 conforme responde a los dos comandos en competencia, sin poder satisfacerlos.
Ing. Romel Alds
42
CASO 7: BLOQUEOS MUTUOS EN UNA RED Una red congestionada o que ha llenado un porcentaje grande de su buffer de entrada/salida- se puede bloquear totalmente si no tiene protocolos para controlar el flujo de mensajes a travs de la red (Fig.5.6). Por ejemplo, un centro de procesamiento de palabras de tamao medio tiene siete computadoras en red, cada una con nodos diferentes. C1 recibe mensajes de los nodos C2, C6 y C7 y solo enva mensajes a uno: C2. C2 recibe los mensajes de los nodos C1, C3 y C4 y nada ms manda mensajes a C1 y a C3. La direccin de las flechas de la figura 5.6 seala el flujo de los mensajes. Los mensajes recibidos por C1 desde C6 y C7 y destinados a C2 se almacenan en una cola de salida. Los mensajes recibidos por C2 de C3 y de C4 destinados a C1 se almacenan en una cola de salida. Conforme se incrementa el trfico, aumenta la longitud de cada cola de salida, hasta que se llena el espacio disponible para las colas. En este punto C1 ya no puede aceptar ms mensajes (de C2 o de cualquier otra computadora) porque no existe ms espacio disponible para almacenarlas. Por lo misma razn, C2 no puede aceptar ms mensajes de C1 para ninguna otra computadora, ni siquiera una solicitud para enviar. La trayectoria de comunicacin entre C1 y C2 se bloquea y en vista de que C1 solo puede recibir mensajes de C6 y C7, estos caminos tambin se han bloqueado. C1 no puede enviar palabras hasta C2 respecto al problema, por lo que el bloqueo mutuo no se puede resolver sin intervencin del exterior.
CONDICIONES PARA EL BLOQUEO MUTUO

En cada uno de estos siete casos, el bloqueo comprendi la interaccin de varios procesos y recursos, pero la ocurrencia simultnea de cuatro condiciones precedi cada 43
Ing. Romel Alds
bloqueo mutuo, condiciones que el sistema operativo u otro sistema podra haber reconocido: exclusin mutua, retencin de recursos, no apropiatividad y espera circular. Para ilustrarnos, revisemos el ejemplo de la escalera del principio del captulo e identifiquemos las cuatro condiciones para un bloqueo mutuo. Cuando dos personas se encuentran entre descansos no pueden pasar, ya que en los escalones slo cabe una a la vez. Exclusin mutua, el acto de permitir que slo una persona (o proceso) tenga acceso a un escaln (un recurso dedicado), es la primera condicin del bloqueo mutuo. Cuando dos personas se encuentran en las escaleras y cada una se empea en no retirarse y espera a que lo haga lo otra, esto es un ejemplo de retencin de recursos (en contraste con compartir recursos), la segunda condicin para el bloqueo mutuo. En este ejemplo, cada escaln est dedicado al que sube (o al que baja); queda asignado al que lo ocupe tanto tiempo como sea necesario. Esto se conoce como no apropiatividad, la carencia de una reasignacin temporal de los recursos, y es la tercera condicin para el bloque mutuo. Estos tres llevan a la cuarta condicin o espera circular, en que cada persona (o proceso) inmerso en la espera de que la otra libere el escaln (o recurso), por lo que por lo menos una ser capaz de continuar y llegar a destino. Se requieren las cuatro condiciones para que ocurra el bloqueo mutuo y siempre que las cuatro estn presentes, ste continuar; pero si se puede eliminar una, el bloqueo mutuo se resolver. De hecho, es posible prevenir que las cuatro condiciones se den al mismo tiempo, con lo cual se evitaran los bloqueos mutuos; pero aunque esta idea es obvia no es fcil de implementar.
MODELADO DE BLOQUEOS MUTUOS

Holt (1972) demostr la forma en que las cuatro condiciones se pueden modelar utilizando grficas dirigidas (las usamos con modificaciones en las figuras 5.2 y 5.4). stas utilizan dos tipos de smbolos: procesos, representados por crculos y recursos, denotados por cuadrados. Una lnea slida de un recurso hacia un proceso significa que el proceso retiene dicho recurso; una lnea slida de un proceso a un recurso, que un proceso espera dicho recurso. La direccin de la flecha indica el flujo. Si hay un ciclo en la grfica, entonces existe un bloqueo mutuo que abarca los procesos y los recursos del ciclo, segn se observa en la figura 5.7c).
El sistema que tiene tres procesos: P1, P2 y P3, y tiene tres recursos: R1, R2 Y R3, cada uno diferente: impresora, unidad de cinta y graficador. Dado que no hay un orden especfico en el cual se manejan las solicitudes, tenemos tres escenarios posibles, as que utilizaremos grficas para ayudarnos a detectar cualquier bloque mutuo. ESCENARIO 1 La secuencia de circunstancias del primer escenario aparece en la tabal 5.1. La grfica dirigida se encuentra en la figura 5.8. Note en la grfica dirigida que no existen ciclos. Por lo tanto, podemos concluir con seguridad que no es factible un bloqueo, aun cuando cada proceso solicite todos los recursos, si los recursos se liberan antes que los solicite el siguiente proceso. 44
Ing. Romel Alds
ESCENARIO 2 Ahora, consideremos un segundo escenario de secuencia de circunstancias como la mostrada en la tabla 5.2. La grfica dirigida aparece en la figura 5.9.
En la grfica dirigida hay un bloque mutuo porque todos los procesos esperan un recurso que est detenido por otro proceso, pero ninguno quedar liberado sin la intervencin del operador. ESCENARIO 3 El tercer escenario se muestra en la tabla 5.3. Segn se puede ver en la figura 5.10, los recursos se liberan antes que ocurra el bloqueo mutuo.
Ing. Romel Alds
45
OTRO EJEMPLO En los ejemplos presentados hasta ahora hemos examinado casos en que uno o ms recursos de diferentes tipos se asignaron a un proceso. Sin embargo, se pueden expandir las grficas para incluir varios recursos del mismo tipo, como unidades de cinta, que se pueden asignar de manera individual o en grupos al mismo proceso. Estas grficas agrupan los dispositivos del mismo tipo en una entidad en la figura 5.11 se usa un rectngulo y las flechas muestran los vnculos entre el nico recurso y los procesos que lo utilizan.
Ing. Romel Alds
46
La figura 5.11 de un ejemplo de un agrupamiento con tres recursos del mismo tipo, como tres unidades de disco, cada uno asignado a tres procesos. Aunque la figura 5.11 a) parece ser estable ( no puede ocurrir bloqueo mutuo), no es el caso, porque si los tres procesos solicitan un recurso ms, sin liberar el que estn utilizando, el bloqueo mutuo ocurrir, como se muestra en la figura 5.11 b).
Estrategias para el manejo de bloqueos

Como hacen ver estos ejemplos, las solicitudes y liberaciones se reciben en un orden impredecible, lo que hace muy difcil disear una poltica preventiva a toda prueba. En general, los sistemas operativos utilizan una de tres estrategias para manejar bloqueos mutuos: Impedir que ocurra alguna de las cuatro condiciones. Evitar el bloqueo si se hace probable. Detectarlo cuando ocurre y recuperarse del mismo con gracia. PREVENCIN Para impedir un bloqueo mutuo, el sistema operativo debe eliminar una de las cuatro condiciones necesarias, tarea complicada porque no es posible suprimir la misma condicin de todos los recursos. La exclusin mutua es necesaria en cualquier sistema de cmputo, porque algunos recursos como la memoria, el CPU o los dispositivos dedicados, deben quedar asignados exclusivamente a un usuario a la vez. En el caso de dispositivos de entrada/salida como las impresoras, la exclusin mutua puede obviarse mediante el uso de spool, de manera que la salidas de muchas tareas se pueda almacenar al mismo tiempo en archivos temporales en el uso de spool separados; luego, cada archivo de salida completo se manda imprimir cuando el dispositivo est listo. Sin embargo, quizs estemos sustituyendo un tipo de bloqueo mutuo (caso 3): bloqueos mutuos de asignacin de dispositivos dedicados) por otro (caso 5: bloqueos mutuos en operaciones perifricas simultneas en lnea). La retencin de recursos, es decir, cuando una tarea conserva un recurso mientras espera otro que no est disponible podra evitarse obligando a cada trabajo a solicitar, en el momento de la creacin, todos los recursos que necesitar. Por ejemplo, si se da tanta memoria como necesita cada trabajo en un sistema por lotes, el nmero de taras activas quedar regido por cuantas quepan en la memoria. Es una poltica que reducir de manera significativa el grado de multiprogramacin. Adems, los dispositivos
Ing. Romel Alds
47
perifricos quedaran ociosos porque se asignaran a un trabajo aunque no se utilizarn todos el tiempo. Como hemos dicho, esto funcionaba en entornos por lotes, aunque reduca el uso efectivo de los recursos y restringa la cantidad de multiprogramacin. Pero no es tan adecuado en sistemas interactivos. La no apropiatiavidad podra soslayarse permitiendo que el sistema operativo desasigne recursos de los trabajos. Esto se puede efectuar si el estado del trabajo se guarda y restaura con facilidad cuando, por ejemplo, se retira un trabajo en un entorno round robin o se intercambia la pgina a un almacenamiento secundario en un sistema de memoria virtual. Por otra parte, el retiro o sustitucin de un dispositivo de entra/salida dedicado (impresora, graficador o unidades de cinta, etc.) o de los archivos durante el proceso de modificacin puede requerir algunas tareas de recuperacin muy desagradables. La espera circular se puede obviar si el sistema operativo impide la formacin de un crculo. Havender (1968) propuso una solucin de este tipo, la cual se basa en un sistema de numeracin para los recursos: impresora= 1, disco = 2, cinta = 3, graficador = 4, etc. El sistema obliga a que cada trabajo solicite sus recursos en orden ascendente: cualquier dispositivo nmero uno requerido por el trabajo ser solicitado primero; todo dispositivo nmero dos ser pedido despus, y as sucesivamente. Si un t rabajo necesitaba una impresora y despus una graficadora, lo solicitara en este orden: impresora (#1) y despus graficadora (#4). Si el trabajo necesitaba la graficadora primero y despus la impresora, an as pedira primero la impresora (que es un # 1) aunque no la utilizar de inmediato. Un trabajo podra solicitar una impresora (#1), un disco (#2) y despus una cinta (#3), pero si ms tarde en su procesamiento necesitaba otra impresora (#1), tendra que anticipar dicha necesidad cuando la solicit por primera vez y antes de pedir el disco. Este esquema de ordenamiento jerrquico elimina la posibilidad de una espera circular, por lo que garantiza la eliminacin de los bloqueos mutuos. No requiere que los trabajos establezcan con anticipacin sus necesidades mximas, pero s precisa que anticipen el orden en que solicitarn los recursos. Desde la perspectiva de un diseador de sistemas, una de las dificultades de este esquema es descubrir el mejor orden para los recursos, de manera que las necesidades de la mayora de los usuarios queden satisfechas. Otra dificultad es que en la asignacin de una clasificacin jerrquica a recursos no fsicoscomo archivos o registros cerrados de bases de datos-no existe base alguna para asignar un nmero ms elevado a uno en relacin con el otro. EVITAR BLOQUEOS MUTUOS Incluso si el sistema operativo no puede eliminar una de las condiciones de un bloqueo mutuo, puede evitar uno, si conoce por anticipado la secuencia de las solicitudes asociadas con cada proceso activo. Como se ilustr en las grficas de las figuras 5.7 a 5.11, existe por lo menos una secuencia de asignacin de recursos que permitir que las tareas continen sin bloquearse mutuamente. Dijkstra (1965) propuso uno de esos algoritmos para regular la asignacin de recursos a fin de evitar bloqueos. Este algoritmo, conocido como algoritmo del banquero, se basa en un banco con una cantidad fija de capital que opera segn los principios siguientes: A ninguno de los clientes se conceder un prstamo que exceda el capital total del banco. A todos los clientes se dar el lmite de crdito mximo al abrir una cuenta. A ningn cliente se permitir que pida prestado ms all de su lmite. La suma de todos los prstamos no exceder el capital total del banco.
Con estas condiciones, no se requiere que el banco tenga a la mano el total de las cuotas mximas de prstamos antes de abrir sus puertas (suponemos que la institucin tendr siempre el mismo total fijo y pasaremos por alto el inters que se carga sobre prstamos). Para nuestro ejemplo, el banco tiene un fondo de capital total de 10 000 dlares y tres clientes, Cl, C2 y C3, cuyos lmites mximos de crdito son 4000, 5000 y 8000 dlares, respectivamente. La tabla 5.4 ilustra el estado de negocios del banco, desIng. Romel Alds
48
pus que se han concedido algunos prstamos a C2 y C3. Este se conoce como estado seguro, porque la institucin tiene todava suficiente dinero disponible para satisfacer las solicitudes mximas de Cl, C2 y C3.
Es un estado inseguro porque con 1000 dlares disponibles el banco no puede satisfacer la solicitud mxima de ninguno de los clientes y si presta los 1000 dlares a cualquiera de ellos, se quedara bloqueado totalmente (no puede efectuar un prstamo). Un estado inseguro no necesariamente lleva al bloqueo mutuo, pero s indica que el sistema es un candidato excelente para uno. Despus de todo, no se requiere que ninguno de los clientes solicite el mximo, pero el banco no sabe la cantidad exacta que pedirn. En tanto el capital de la institucin sea menor que la cantidad mxima disponible para los prstamos individuales, no puede garantizar que tendr capacidad de cubrir las solicitudes de prstamo. Si en vez de clientes y dlares tenemos trabajos y dispositivos dedicados, podemos aplicar los principios de la banca a un sistema operativo. En este ejemplo, el sistema cuenta con diez dispositivos. La tabla 5.6 muestra nuestro sistema en un estado seguro, y la tabla 5.7, en un estado inseguro. Corno antes, en un estado seguro es posible terminar por lo menos un trabajo, ya que existen suficientes recursos disponibles para satisfacer sus necesidades mximas. Luego, utilizando los recursos liberados por el trabajo terminado, se pueden llenar las necesidades mximas de otro trabajo, el cual se puede terminar, y as sucesivamente, hasta que se ejecuten todos los trabajos.
Ing. Romel Alds
49
El sistema operativo debe estar seguro de nunca satisfacer una solicitud que convierta un estado seguro en inseguro. Por lo tanto, conforme cubre las solicitudes de los usuarios, el sistema operativo debe identificar el trabajo con el nmero ms pequeo de recursos restantes y asegurarse que el nmero de recursos disponibles sea siempre igual o incluso mayor al nmero necesario para que ese trabajo se ejecute hasta su terminacin. El sistema operativo debe bloquear las solicitudes que pondran en riesgo el estado seguro, hasta que se puedan aceptar con seguridad. Si el sistema se conserva en un estado seguro, las solicitudes sern satisfechas y se evitar el bloqueo. Si esta solucin elegante se ampla para trabajar con diferentes clases de recursos, el sistema establece una tabla de "asignacin de recursos" para cada tipo de recurso y lleva el control de cada una a fin de mantener el sistema en un estado seguro. Aunque el algoritmo del banquero se ha utilizado para evitar bloqueos mutuos en sistemas con pocos recursos, no siempre resulta prctico para la mayor parte de los sistemas, por varias razones. 1. Conforme los trabajos entran al sistema, deben enunciar por adelantado el nmero mximo de los recursos necesarios. Como hemos dicho, esto no resulta prctico en sistemas interactivos. 2. El total de recursos para cada clase debe mantenerse constante. Si un dispositivo se rompe y sbitamente deja de estar disponible, el algoritmo no funcionar (el sistema puede quedar en un estado inseguro). 3. El nmero de trabajos debe mantenerse fijo, algo que no es posible en los sistemas interactivos, donde la cantidad de trabajos activos cambia en forma constante. 4. El costo por carga general incurrida al ejecutar el algoritmo para evitar bloqueos mutuos puede resultar bastante elevado cuando hay muchos trabajos activos y dispositivos, ya que se debe correr con cada solicitud. 5. Los recursos no se utilizan bien porque el algoritmo supone el caso peor y, como resultado, conserva recursos vitales no disponibles como proteccin contra estados inseguros. 6. La planificacin sufre como resultado de la mala utilizacin y los trabajos se que dan esperando la asignacin de recursos: un flujo uniforme de trabajos que solicitan unos cuantos recursos puede causar una posposicin indefinida de un trabajo ms complejo, que requiere muchos recursos. 50
Ing. Romel Alds
DETECCIN Las grficas dirigidas que se presentaron antes mostraban la forma en que la existencia de una espera circular indica un bloqueo mutuo, por lo que es razonable concluir que los bloqueos mutuos se pueden detectar, elaborando grficas de recursos dirigidos y buscando ciclos. A diferencia del algoritmo para evitar bloqueos mutuos, que se debe ejecutar cada que existe una solicitud, el algoritmo utilizado para detectar circularidad se puede correr siempre que sea apropiado: cada hora, una vez al da, cuando el operador note que produccin se ha deteriorado o cuando se queje un usuario. Dicho algoritmo se puede explicar utilizando las grficas de recursos dirigidos y "reducindolas". Los pasos para reducir una grfica son los que: 1. Encuentre un proceso que est utilizando un recurso y que no est en espera de uno. Este proceso se puede eliminar de la grfica (desconectando el vnculo que une el recurso al proceso) y los recursos se pueden devolver a la "lista disponible". Esto es posible porque el proceso terminar y devolver el recurso. 2. Encuentre un proceso que nada ms espere clases de recursos que no estn asignados por completo. Este proceso no contribuye al bloqueo mutuo, ya que terminar por obtener el recurso que espera, terminar su trabajo y devolver el recurso a la "lista disponible". 3. Vuelva al paso 1 y contine la iteracin, hasta eliminar todas las lneas que conecten recursos con procesos. Si quedan lneas, esto indicar que la solicitud del proceso en cuestin no puede satisfacerse y que existe un bloqueo mutuo. La figura 5.12 ilustra un sistema en el cual tres procesos P1, P2 y P3 y tres recursos R1, R2 y R3 no estn bloqueados mutuamente. La figura 5.12 muestra las etapas de una reduccin de grfica desde a), el estado original, b) El vnculo entre P3 y R3 se puede eliminar porque P3 no espera algn otro recurso para terminar, por lo que R3 se libera y se asigna a P2 (paso 1). c) Los vnculos entre P2 y R3 y entre P2 y R2 se pueden suprimir porque P2 tiene todos los recursos solicitados y puede ejecutarse hasta su terminacin, con lo que R2 se puede asignar a Pl. Por ltimo, en d) los vnculos entre P1 y R2 y entre P1 y R1 se pueden eliminar porque P1 tiene todos sus recursos solicitados y puede finalizar con xito. Por tanto, la grfica est resuelta por completo. En la figura 5.13, el mismo sistema est bloqueado mutuamente.
Ing. Romel Alds
51
El sistema bloqueado totalmente de la figura 5.13 no se puede reducir, a) El vnculo entre P3 y R3 se puede eliminar porque P3 no espera otro recurso, por lo que R3 se libera y se asigna a P2. Pero b) P2 slo tiene dos de los tres recursos que necesita para terminar y espera R1. Pero P1 no lo puede liberar porque espera a R2, que est en manos de P2; adems, P1 no puede acabar porque espera que P2 termine (y libere R2) y ste no puede finalizar porque aguarda a R1. Se trata de una espera circular. RECUPERACIN Una vez que se detecta un bloqueo mutuo hay que desarmarlo y devolver el sistema a lo normal con tanta rapidez como sea posible. Existen varios algoritmos de recuperacin, pero todos tienen una caracterstica en comn: requieren por lo menos una vctima, un trabajo consumible, mismo que, al ser eliminada del bloqueo mutuo, liberar al sistema. Por desgracia, para eliminar la vctima generalmente hay que reiniciar el trabajo desde el principio o a partir de un punto medio conveniente. El primer mtodo y ms simple de recuperacin, y el ms drstico, es terminar los trabajos que estn activos en el sistema y volver a arrancarlos desde el principio. El segundo mtodo es terminar slo los trabajos incluidos en el bloqueo mutuo y solicitar a sus usuarios que los vuelvan a enviar. El tercero es identificar qu trabajos intervienen en el bloqueo mutuo y terminarlos uno por uno y comprobar la desaparicin del bloqueo mutuo despus de cada eliminacin hasta resolverlo. Una vez liberado el sistema, se deja que los trabajos restantes terminen su procesamiento; luego, los trabajos detenidos se inician de nuevo desde el principio. El cuarto procedimiento se puede poner en efecto slo si el trabajo mantiene un registro, una instantnea de su progreso, de manera que se pueda interrumpir y despus continuar sin tener que reiniciar desde el principio. La instantnea es como el
Ing. Romel Alds
52
descanso del ejemplo de la escalera: en vez de obligar a los que suben a volver a la parte inferior de la misma, slo necesitan retirarse al descanso ms cercano, esperar a que pasen los dems y reanudar la subida. En general, este mtodo es el preferido para trabajos de ejecucin larga, a fin de ayudarlos a tener una recuperacin rpida. Hasta ahora hemos ofrecido soluciones que comprenden los trabajos que se encuentran en el bloqueo mutuo. Los dos mtodos siguientes se concentran en trabajos que no estn en el bloqueo mutuo y los recursos que conservan. Uno de ellos, el quinto mtodo de nuestra lista, selecciona un trabajo no bloqueado, retira los recursos que contiene y los asigna a procesos bloqueados, de manera que pueda reanudarse la ejecucin esto deshace el bloqueo mutuo. El sexto mtodo detiene los trabajos nuevos e impide que entren al sistema, lo que permite que los que no estn bloqueados sigan hasta su terminacin y liberen sus recursos. Por ltimo, con menos trabajos en el sistema, la competencia por los recursos se reduce, de suerte que los procesos bloqueados obtienen los recursos que necesitan para ejecutarse hasta su terminacin. Este mtodo es el nico aqu listado que no necesita una vctima. No se garantiza que funcione, a menos que el nmero de recursos disponibles exceda los necesarios en por lo menos uno de los trabajos bloqueados para ejecutar (esto es posible con recursos mltiples). Deben considerarse varios factores al elegir la vctima para que tenga el efecto menos negativo sobre el sistema. Los ms comunes son: 1. La prioridad del trabajo en consideracin por lo general no se tocan los trabajos de alta prioridad. 2. El tiempo de CPU utilizado por el trabajo no suelen tocarse los trabajos que estn a punto de terminar. 3. La cantidad de tareas en que repercutira la eleccin de la vctima. Adems, los programas que trabajan con bases de datos tambin merecen un trato especial. Los trabajos que estn modificando datos no se deben elegir para su terminacin, ya que la consistencia y validez de la base de datos se pondra en peligro. Afortunadamente, los diseadores de muchos sistemas de bases de datos han incluido mecanismos complejos de recuperacin, por lo que se minimiza el dao a la base de datos si se interrumpe una transaccin o se termina antes de completarse.
INANICIN
Hasta ahora nos hemos concentrado en bloqueos mutuos, el resultado de la asignacin liberal de los recursos. En el otro extremo est la inanicin, el resultado de la asignacin conservadora de recursos, donde una tarea no puede ejecutarse porque permanece en espera de recursos que nunca quedan disponibles. Para ilustrar lo anterior, Dijkstra (1968) introdujo el caso de la "cena de los filsofos" . Cinco filsofos estn sentados en una mesa redonda, cada uno medita profundamente, y en el centro hay un recipiente de espagueti accesible a todos. Hay un tenedor entre cada comensal (Fig. 5.14). La costumbre local exige que cada filsofo utilice dos tenedores, los que estn a ambos lados del plato, para comer el espagueti, pero slo hay cinco no los diez que se requeriran para que los cinco pensadores comieran al mismo tiempo y esto es desafortunado para el filsofo 2. Cuando se sientan para cenar, el filsofo 1 (F1) es el primero que toma los dos tenedores (TI y T5) a ambos lados del plato y empieza a comer. Inspirado por su colega, el filsofo 3 (F3) hace lo mismo y toma T2 y T3. Ahora el filsofo 2 (F2) decide empezar la comida, pero no puede porque no estn disponibles tenedores: TI ha sido asignado a F1 y T2 a F3; slo F4 o F5 puede usar el nico tenedor disponible, as que el filsofo 2 debe esperar.
Ing. Romel Alds
53
Pronto, F3 termina de comer, deja sobre la mesa sus dos tenedores y vuelve a su meditacin. Hay que asignar el tenedor que est a su lado (T2), ahora libre, al filsofo hambriento (F2)? Aunque es tentador, tal cosa resultara ser un mal precedente, porque si se permite que los filsofos utilicen todos los recursos con la esperanza de que el recurso requerido quede disponible, la cena puede pasar con facilidad a un estado inseguro; sera cuestin de tiempo, antes que cada filsofo se hiciera de un tenedor y nadie podra cenar. As pues, los recursos se asignan a los filsofos slo cuando ambos tenedores estn disponibles al mismo tiempo. El estado del "sistema" se ilustra en la figura 5.15. F4 y F5 estn meditando tranquilamente y F1 sigue comiendo, cuando F3 (que debe estar lleno) decide comer algo ms y, dado que los recursos estn libres, tiene la posibilidad de tomar T2 y T3 de nuevo. Poco despus, F1 termina y libera TI y T5, pero F2 sigue sin poder comer, porque T2 est asignado. Este escenario podra continuar de manera indefinida, y siempre que F1 y F3 alternaran su uso de los recursos disponibles, F2 deber esperar. F1 y F3 pueden comer en cualquier momento, en tanto que F2 se muere de hambre a slo pulgadas del alimento. En un entorno de cmputo, los recursos son como los tenedores y los procesos competitivos son como los comensales. Si el administrador de los recursos no vigila los procesos y los trabajos que se estn quedando sin alimento y planea su terminacin en algn momento, se podran quedar en el sistema esperando para siempre la combinacin correcta de recursos.
Ing. Romel Alds
54
Al fin de encarar este problema, se puede implementar un algoritmo diseado para detectar trabajos con inanicin, que controla el tiempo que cada trabajo permanece en espera de recursos (esto es lo mismo que el envejecimiento descrito en el captulo 4). Una vez detectada la inanicin, el sistema puede bloquear nuevos trabajos hasta que los trabajos hambrientos queden satisfechos. Este algoritmo se debe supervisar de cerca: si se efecta demasiado a menudo, los nuevos trabajos quedan bloqueados constantemente y la produccin disminuye. Si no se lleva a cabo con la frecuencia suficiente, quedarn en el sistema trabajos con inanicin durante un periodo inaceptablemente largo.
Ing. Romel Alds
55
PROCESOS CONCURRENTE S
En los captulos 2 y 3 describimos sistemas que utilizan solamente un CPU, En este veremos sistemas de multiprocesamiento; eso es, con ms de un CPU. Analizaremos Las razones de su desarrollo, ventajas y problemas. Como veremos aqu, la clave para el multiprocesamiento ha sido objeto de amplia investigacin. Examinaremos varias configuraciones de procesadores y revisaremos los problemas clsicos de procesos concurrentes, como "productores y consumidores", "lectores y escritores", y "cliente en la espera faltante". Aunque los problemas ocurren en los sistemas de un solo procesador, se presentan aqu porque se aplican a los multiprocesos en general, independientemente de que se refieran a un solo procesador (con dos o ms procesos) o a ms de un procesador (por lo tanto multiprocesos).
QU ES PROCESAMIENTO PARALELO?
El procesamiento paralelo, tambin llamado multiprocesamiento, es una situacin en la cual dos o ms procesadores operan al unsono. Esto quiere decir que dos o ms CPU ejecutan instrucciones de manera simultnea. Por lo tanto, con ms de un proceso activo a la vez, cada CPU puede tener al mismo tiempo un proceso en estado de EJECUCIN. Para los sistemas de multiprocesamiento, el administrador del procesador tiene que coordinar la actividad de cada procesador, as como sincronizar la interaccin entre los CPU. La complejidad de la tarea del administrador del procesador cuando se ocupa de varios procesadores o de mltiples procesos se ilustra con un ejemplo: usted est atrasado para una cita a principios de la tarde y corre el riesgo de no poder almorzar, por lo que se integra a la cola de servicio en el auto de un restorn de comida rpida. Cuando hace su pedido, el empleado confirma su solicitud, le indica el precio y le pide que maneje hasta la ventanilla de entrega, donde un cajero le cobra y le da su pedido. Todo est bien y de nuevo est conduciendo y contento. Acaba de ser testigo de un sistema de multiprocesamiento bien sincronizado. Aunque usted entr en contacto con dos procesadores, el empleado de pedidos y el cajero, existan por lo menos dos procesadores ms tras bambalinas, que cooperaron para que el sistema funcionara, el cocinero y el empacador. El restaurante de comida rpida es similar a un sistema de recuperacin de informacin, en el cual el procesador 1 (el empleado de pedidos) acepta la consulta, ve que no existan errores y pasa la solicitud al procesador 2 (el empacador). ste busca en la base de datos la informacin requerida (la hamburguesa). El procesador 3 (el cocinero) recupera los datos de la base de datos (la carne para preparar la hamburguesa) si es que est fuera de lnea, en algn almacenamiento secundario. Una vez reunidos los datos (la hamburguesa cocinada) se coloca donde el procesador 2 pueda tomarla (la charola de hamburguesas). El procesador 2 (el empacador) se la pasa al procesador 4 (el cajero). ste encamina la respuesta (su pedido) de regreso al originador de la misma: usted.
Ing. Romel Alds
56
La sincronizacin es la clave del xito del sistema, porque en un sistema de multiprocesamiento muchas cosas pueden salir mal. Por ejemplo, qu pasa si el sistema de comunicacin dejara de funcionar y usted no pudiera hablar con el empleado de pedidos? Qu sucede si el cocinero produjera hamburguesas a toda velocidad todo el da, incluso durante los periodos lentos? Qu pasara a las hamburguesas adicionales? Qu ocurre si el cocinero se quema gravemente y ya no puede cocinar? Qu hara el empacador si no hubiera hamburguesas? Qu pasara si el cajero decidiera tomar su dinero, pero no darle alimento alguno? Obviamente, el sistema no puede trabajar en forma correcta, a menos que cada uno de los procesadores se comunique y coopere con los dems procesadores. Los multiprocesadores fueron desarrollados para modelos de mainframe de alta velocidad de IBM y computadoras VAX, donde el sistema operativo trataba a los CPU adicionales como recursos adicionales que se programaban para su trabajo. Estos sistemas, algunos con slo dos CPU, han estado en uso durante muchos arios (Lane & Mooney, 1988). A partir de mediados de los 80, cuando los costos del hardware empezaron a bajar, los sistemas de multiprocesador con decenas de CPU han encontrado uso en entornos empresariales. Lo que es ms, sistemas con decenas de miles de CPU (sistemas que en el pasado slo estaban disponibles para la investigacin) se pueden encontrar ahora en entornos de produccin. Hoy da, los sistemas de multiprocesador estn disponibles en sistemas de todos los tamaos. Existen dos fuerzas principales tras el desarrollo del multiprocesamiento, mejorar la produccin e incrementar la potencia de cmputo, y dos beneficios principales, mayor confiabilidad y un procesamiento ms rpido. La confiabilidad se deriva de la disponibilidad de ms de un CPU: si falla un procesador, los dems pueden continuar operando y absorber la carga. Esto no es de ejecucin sencilla: el sistema debe estar diseado con sumo cuidado de manera que, primero, el procesador que est fallando pueda informar a los dems procesadores para que se hagan cargo y, segundo, que el sistema operativo pueda reestructurar sus estrategias de asignacin de recursos, a fin de que el sistema que queda no se sobrecargue. La mayor velocidad de procesamiento se logra porque las instrucciones se pueden procesar en paralelo, dos o ms a la vez, y esto se efecta en una de varias maneras. Algunos sistemas asignan un CPU a cada programa o trabajo. Otros asignan uno a cada conjunto de trabajo o a partes del mismo. Otros subdividen las instrucciones individuales de manera que cada subdivisin se pueda procesar al mismo tiempo (lo cual se conoce como "programacin concurrente" y se analiza con detalle a la conclusin de este captulo). La mayor flexibilidad significa mayor complejidad; sin embargo, quedan dos retos de importancia: cmo conectar los procesadores en configuraciones y cmo orquestar su interaccin. Este ltimo problema, la orquestacin de la interaccin, se aplica tambin a procesos mltiples que interactan (pudiera ayudarle si piensa en cada proceso como si corriera en un procesador por separado, aunque en realidad, slo exista uno que realiza todo el trabajo).
CONFIGURACIONES TPICAS DE MULTIPROCESAMIENTO

Mucho depende de cmo se configuran los procesadores mltiples en el sistema. Las configuraciones tpicas son maestro/ esclavo, dbilmente acoplado y simtrica.
Configuracin maestro/esclavo
El sistema de multiprocesamiento maestro/esclavo es una configuracin asimtrica. En trminos conceptuales, es un sistema de un procesador con procesadores "esclavos" adicionales, cada uno de los cuales est administrado por el procesador primario "maestro", segn se puede observar en la figura 6.1.
Ing. Romel Alds
57
El procesador maestro administra el sistema: todos los archivos, dispositivos, memoria y procesadores. Por tanto, mantiene el estado de los procesadores en el sistema, efecta actividades de administracin de almacenamiento, planifica el trabajo de los dems procesadores y ejecuta los programas de control. Esta configuracin es adecuada para entornos de cmputo en que el tiempo de procesamiento se divide entre procesadores frontales y posteriores; en estos casos el procesador frontal se ocupa de los usuarios interactivos y de los trabajos rpidos, y el procesador posterior, de los trabajos largos mediante el modo de lotes. La ventaja principal de esta configuracin es su simplicidad. Sin embargo, tiene tres desventajas serias: 1. Su confiabilidad no es ms elevada que la de un sistema de un procesador porque si el procesador principal falla, tambin el sistema. 2. Puede llevar a un mal uso de los recursos porque si un procesador esclavo queda liberado mientras el procesador maestro est ocupado, el esclavo debe esperar hasta que el maestro se libere y le pueda asignar ms trabajo. 3. Incrementa el nmero de interrupciones porque todos los procesadores esclavos deben interrumpir al procesador maestro cada que necesitan la intervencin del sistema operativo, como las solicitudes de entrada /salida. Esto crea largas colas al nivel de procesador maestro cuando existen muchos procesadores e interrupciones.
Configuracin dbilmente acoplada

La configuracin dbilmente acoplada tiene varios sistemas de cmputo completos, cada uno con memoria propia, dispositivos de entrada/salida, CPU y sistema operativo (Fig. 6.2). Se conoce como dbilmente acoplado porque cada procesador controla sus propios recursos sus archivos y dispositivos de entrada/salida. Esto significa que cada procesador mantiene sus tablas de comandos y de administracin de entrada /salida. La nica diferencia entre un sistema de multiprocesamiento dbilmente acoplado y un conjunto de sistemas de procesamiento individuales independientes es que cada procesador se puede comunicar y cooperar con los dems.
Ing. Romel Alds
58
Cuando un trabajo llega por primera vez, se asigna a un procesador. Una vez asignado, el trabajo se quedar con ese procesador hasta que se termina. Por lo tanto, cada procesador debe tener tablas "globales" que indiquen a cul procesador se ha asignado cada trabajo. Para mantener el sistema equilibrado y asegurar el mejor uso de los recursos, la planificacin de los trabajos se basa en varios requisitos y polticas. Por ejemplo, los nuevos trabajos pueden asignarse al procesador con la carga ms ligera o con la combinacin disponible de dispositivos de salida. Este sistema no est sujeto a fallas catastrficas de sistema, porque incluso cuando falla un procesador los dems pueden continuar el trabajo de manera independiente. Sin embargo, puede resultar difcil detectar cundo ha fallado un procesador.
Configuracin simtrica
La configuracin simtrica se implementa mejor si todos los procesadores son del mismo tipo. Tiene cuatro ventajas sobre la de dbilmente acoplada: 1. 2. 3. 4. es ms confiable, se utilizan los recursos con efectividad, puede equilibrar las cargas y se puede degradar con elegancia en caso de una falla (Forinash, 1987).
Sin embargo, es la ms difcil de implementar porque los procesos deben estar bien sincronizados para evitar los problemas de carreras y bloqueos analizados en el captulo 5. En una configuracin simtrica, la programacin del procesador est descentralizada (Fig. 6.3).
Una sola copia del sistema operativo y una tabla global que lista cada proceso y su estado estn almacenadas en un rea comn de la memoria, por lo que todos los procesadores tienen acceso a la misma. Cada procesador utiliza el mismo algoritmo de planificacin para seleccionar el proceso que se ejecutar a continuacin. Siempre que se interrumpe un proceso, ya sea que se deba a una solicitud de entrada o salida o a cualquier otro tipo de interrupcin, su procesador actualiza la entrada correspondiente en la lista de procesos y encuentra otro proceso para ejecutar. Esto significa que los procesadores se mantienen bastante ocupados y tambin que varios procesadores pueden ejecutar cualquier tarea o trabajo durante su tiempo de ejecucin. Debido a que cada procesador tiene acceso a todos los dispositivos de entrada/ salida y puede hacer referencia a cualquier unidad de almacenamiento, existen ms. Conflictos conforme varios procesadores intentan tener acceso al mismo recurso al mismo tiempo. Esto presenta la necesidad obvia de algoritmos para resolver conflictos entre procesadores esto es, la "sincronizacin de los procesos".
SOFTWARE DE SINCRONIZACIN DE PROCESOS

El xito de la sincronizacin de los procesos se basa en la capacidad del sistema operativo para poner un recurso fuera del alcance de otros procesos mientras uno de ellos lo
Ing. Romel Alds
59
est usando. Estos "recursos" pueden incluir dispositivos de entrada/salida, una localidad en el almacenamiento o un archivo de datos. En esencia, el recurso utilizado debe quedar bloqueado, alejado de otros procesos, hasta que queda liberado. Slo cuando est libre se permite que un proceso en espera lo utilice. Aqu es donde la sincronizacin es vital. Un error pudiera dejar un trabajo o una tarea esperando de manera indefinida. Es lo mismo que ocurre en una nevera llena de gente. Los clientes toman un nmero para recibir atencin. Los empleados actualizan los nmeros en la pared jalando una cadena conforme atienden a cada cliente. Pero qu ocurrira sin una sincronizacin entre el servicio a los clientes y el cambio del nmero? El caos. ste es el caso del "cliente en espera faltante". Digamos que usted tiene el nmero 75. El empleado 1 atiende al cliente 73 y el empleado 2 al 74. La seal en la pared dice "ahora se est atendiendo al nmero 74" y usted est listo con su pedido. El empleado 2 termina con el 74 y tira de la cadena, por lo que la serial dice "ahora se est atendiendo al nmero 75". Pero justo en ese momento, el empleado recibe una llamada telefnica, deja el edificio y no regresa (una interrupcin). Mientras tanto, el empleado 1 tira de la cadena, se ocupa del nmero 76 y usted ha perdido su turno. Si habla a tiempo, puede corregir el error de manera graciosa; pero cuando ocurre en un sistema de cmputo, el resultado no se remedia con tanta facilidad. Considere el escenario en el cual los procesadores 1 y 2 terminan sus trabajos al mismo tiempo. Para ejecutar el siguiente trabajo, cada procesador: 1. 2. 3. 4. Consulta la lista de trabajos para ver cul debe ejecutar a continuacin Recupera el trabajo para su ejecucin Incrementa la lista de LISTOS para el trabajo siguiente Lo ejecuta
Van a la lista de LISTOS para seleccionar un trabajo. El procesador 1 ve que el 74 es el siguiente y va a recuperarlo. Un momento despus, el procesador 2 tambin lo escoge y va por l. Poco despus, el procesador 1, luego de recuperar el trabajo 74, regresa a la lista de L I STOS y la incrementa, pasando el trabajo 75 a la parte superior. Un momento ms tarde, regresa al procesador 2; tambin ha recuperado el trabajo 74 y est listo para procesarlo, por lo que incrementa la lista de LISTOS y ahora se mueve el trabajo 76 a la parte superior y se convierte en el siguiente trabajo en lnea para su procesamiento. El trabajo 75 se ha convertido en el "cliente en espera faltante" y jamas ser procesado: un estado de cosas inaceptable. Existen varios sitios donde puede ocurrir este problema: memoria y tablas de asignacin de pginas, tablas de entradas/salida, bases de datos de aplicacin y cualquier otro recurso compartido. Obviamente, esta situacin requiere sincronizacin. Estn disponibles varios mecanismos de sincronizacin para obtener cooperacin y comunicacin entre los procesos. El elemento comn de todos los esquemas de sincronizacin es permitir que un proceso termine el trabajo en una regin crtica del programa, antes que otros procesos tengan acceso al mismo. Esto es aplicable tanto a multiprocesadores como a dos o ms procesos en un sistema de procesamiento de un procesador (tiempo compartido). Se conoce como regin crtica porque su ejecucin se debe manejar como una unidad. Segn hemos visto, los procesos de una regin crtica no se pueden entrelazar sin poner en peligro la integridad de la operacin. La sincronizacin a veces se implementa como un arreglo de "cerradura y llave": antes que un proceso pueda funcionar en una regin crtica, es necesario que obtenga la "llave". Una vez que la tiene, los dems procesos se quedan "encerrados afuera" hasta que termina; entonces libera la entrada a la regin crtica y devuelve la llave a otro proceso que puede tenerla y empezar el trabajo. Esta secuencia est formada por dos acciones: 1) el proceso primero debe ver si la llave est disponible y 2) si est disponible, el proceso debe tomarla y ponerla en la cerradura, para que no est al acceso de los dems procesos. Para que este esquema funcione, hay que ejecutar ambas funciones en un ciclo de la mquina; de lo contrario, cabe que mientras el primer proceso est listo
Ing. Romel Alds
60
para tomar la llave, cualquier otro la encuentre disponible y se disponga a tomarla y cada uno podra bloquear al otro y evitar su avance. Se han desarrollado varios mecanismos de bloqueo, incluyendo el de probar y establecer, WAIT y SIGNA L, y los semforos.
PROBAR Y ESTABLECER
Probar y establecer es una instruccin indivisible de mquina, conocida simplemente como "TS"(por las siglas en ingls de Test and Set), introducida por IBM para su sistema de multiprocesamiento 360/370. En un ciclo de mquina revisa si la llave est disponible y de ser as la establece como "no disponible". La llave real es un solo bit en una localidad de almacenamiento que puede contener un cero (est libre) o un uno (est ocupada). Podemos considerar el TS como un subprograma de funcin que tiene un parmetro (localidad de almacenamiento) y que devuelve un valor (el cdigo de estado: ocupado/libre), con la excepcin que slo toma un ciclo de mquina. Por lo tanto, el proceso P1 puede probar el cdigo de estado con la instruccin TS antes de entrar a una regin crtica. Si ningn otro proceso est en dicha regin, se permite que P1 siga adelante y el cdigo de condicin cambia de cero a uno. Luego, cuando P1 sale de la regin crtica, se restablece el cdigo de condicin a cero, de manera que otro proceso pueda entrar. Por otra parte, si P1 encuentra un cdigo de condicin ocupado, se coloca en una "iteracin de espera" donde contina efectuando la prueba del cdigo de condicin y aguarda hasta que est libre (Calingaert, 1982). Aunque se trata de un procedimiento simple en su implementacin, y funciona bien en un nmero pequeo de procesos, tiene dos grandes inconvenientes. Primero, cuando muchos procesos esperan entrar a una regin crtica, podra ocurrir la carencia de recursos o inanicin porque los procesos obtienen el acceso de manera arbitraria. Aunque se estableciera una poltica de primeras llegadas primeros servicios, algunos procesos pudieran quedar favorecidos respecto a otros. El segundo es que los procesos en espera se conservan en iteraciones de espera no productivas, pero que consumen recursos. Esto se conoce como espera activa. sta no slo consume tiempo valioso del procesador, sino tambin se apoya en procesos competitivos para probar la llave, algo que maneja mejor el sistema operativo o el hardware.
WAIT y SIGNAL
WAIT y SIGNAL es una modificacin de probar y establecer diseada para eliminar la espera activa. Dos nuevas operaciones, mutuamente excluyentes, forman parte del juego de operaciones del planificador del proceso: WAIT y SIGNAL. WAIT se activa cuando el proceso encuentra un cdigo de condicin ocupado; establece el bloque de control del proceso (PCB, por sus siglas en ingls) en el estado bloqueado y lo vincula con la cola de procesos que esperan la entrada a esta regin crtica particular. El planificador del proceso selecciona otro proceso para su ejecucin. SIGNAL queda activado cuando un proceso sale de la regin crtica y el cdigo de condicin se establece como "libre". Comprueba la cola de los procesos que esperan entrar a la regin crtica, selecciona uno y lo coloca en el estado de LISTO. Por ltimo, el planificador de procesos lo escoge para su ejecucin. La adicin de las operaciones de WAIT y S IGNAL libera a los procesos del dilema de la "espera activa" y devuelve el control al sistema operativo, mismo que entonces puede ejecutar otras tareas, mientras los procesos en espera estn ociosos.
Semforos
Un semforo es una variable entera no negativa, que se utiliza como bandera. Los semforos mejor conocidos son los dispositivos de sealizacin tipo bandera que se usan en los ferrocarriles para indicar si una seccin de los rieles est libre. Cuando se
Ing. Romel Alds
61
eleva el brazo del semforo, los rieles estn libres y el tren puede seguir. Cuando el brazo est bajado, los rieles estn ocupados y el tren debe esperar (Fig. 6.4).
En un sistema operativo, un semforo efecta una funcin similar: seala si un recurso est libre y lo puede utilizar un proceso. Dijkstra (1965) introdujo dos operaciones para manejar el semforo a fin de resolver el problema de sincronizacin del proceso que hemos analizado. Dijkstra los llam P y V y as se conocen hoy da. La P representa la palabra holandesa proberen (probar) y la V significa verhogen (incrementar). Las operaciones P y V efectan eso: prueban e incrementan. He aqu cmo funcionan. Si suponemos que s es una variable de semforo, la operacin V sobre s es incrementar s en uno. La accin se puede enunciar de la siguiente manera: V(s): s: = s + 1 Esto a su vez requiere una secuencia de recuperacin, incremento y almacenamiento. Igual que con el esquema probar y establecer, para evitar bloqueos mutuos hay que ejecutar la operacin V como una accin indivisible. Esto significa que ningn otro proceso tiene acceso a s durante dicha operacin. La operacin P sobre s es probar el valor de sta y, en caso de no ser cero, reducirlo en uno. La accin se puede enunciar de la siguiente manera: P(s): si s > O entonces s: = s - 1 Esto comprende una secuencia de probar, recuperar, decrementar y almacenar. De nuevo, esta secuencia se debe ejecutar como una accin indivisible en un ciclo de mquina u organizar que el proceso no realice accin alguna hasta que termine la operacin (P o V). El sistema operativo ejecuta las operaciones P y V en respuesta a llamadas emitidas por cualquier proceso que use un semforo como parmetro (esto evita que el proceso tenga control). Si s = O, el proceso que llama sobre la operacin P debe esperar hasta que la operacin pueda correr, y esto no ocurre sino hasta s > O. Como se aprecia en la tabla 6.1, P3 se coloca en el estado WA I T (para el semforo) en el estado 4. Como tambin se ve en dicha tabla, para los estados 6 y 8, cuando el proceso sale de la regin crtica, el valor de s se restablece a 1. Esto a su vez dispara el despertar de uno de los procesos bloqueados, su entrada en la regin crtica y el restablecimiento de s a cero. En el estado 7, P1 y P2 no intentan efectuar procesamientos en la regin crtica y P4 sigue bloqueado.
Ing. Romel Alds
62
Despus del estado 5 de la tabla 6.1, el proceso de espera ms larga P3 fue elegido para entrar en la regin crtica, pero esto no es necesariamente el caso, a menos que el sistema utilice una poltica de seleccin de primeras entradas primeras salidas. De hecho, la eleccin de la tarea que se procesar depende del algoritmo que use esta porcin del planificador de procesos. Como puede observar en la tabla 6.1, las operaciones P y V en un semforo s obligan al concepto de la exclusin mutua, necesaria para evitar que dos operaciones intenten ejecutarse al mismo tiempo. El nombre tradicionalmente dado a este semforo en la literatura es mutex, y significa MUTual EXclusion. Por lo que las operaciones se convierten en: P(mutex): si mutex > O entonces mutex: = mutex - 1 V(mutex): mutex: = mutex + 1 En el captulo 5 hablamos del requisito de la exclusin mutua cuando varios trabajos intentan tener acceso a los mismos recursos fsicos compartidos. El concepto es el mismo aqu, pero tenemos varios procesos que intentan tener acceso a la misma regin crtica compartida. El procedimiento se puede generalizar a semforos con valores superiores a cero y uno. Hasta ahora hemos visto el problema de la exclusin mutua presentado por procesos paralelos que interactan utilizando los mismos datos compartidos a tasas diferentes de ejecucin. Esto puede ser aplicable a varios procesos en ms de un procesador o a procesos interactivos (codependientes) de un procesador. En este caso, el concepto de la "regin crtica" se hace necesario porque asegura que los procesos paralelos modificarn los datos compartidos slo mientras estn en la regin crtica. En los clculos secuenciales la exclusin mutua se logra de manera automtica, porque cada operacin se maneja en orden, una a la vez. Sin embargo, en computaciones en paralelo, el orden de ejecucin puede cambiar, por lo que hay que establecer y conservar de manera explcita la exclusin mutua. De hecho, todo el principio de los procesos en paralelo se apoya en que todas las operaciones sobre variables comunes se excluyen a lo largo del tiempo.
COOPERACIN DE PROCESOS
En ocasiones varios procesos trabajan juntos para completar una tarea comn. Los ejemplos famosos son los problemas de "productores y consumidores" y "lectores y escritores". Cada caso requiere la exclusin mutua y la sincronizacin, y se implementan utilizando semforos.
Ing. Romel Alds
63
Productores y consumidores
En el problema clsico de productores y consumidores, un proceso produce algunos datos que otro proceso consume despus. A pesar de que describiremos el caso con un productor y un consumidor, se puede expandir a varios pares de productores y consumidores. Volvamos por un momento al ejemplo de la comida rpida al principio del captulo, porque la sincronizacin entre dos de los procesadores (el cocinero y el empacador) representa un problema significativo en los sistemas operativos. El cocinero produce hamburguesas consumidas por el empacador. Ambos procesadores tienen acceso a un rea comn, la charola de hamburguesas, que contiene un nmero finito de hamburguesas (esto se conoce como rea de memoria intermedia). La charola es un rea necesaria de almacenamiento, porque la velocidad a la cual se producen las hamburguesas es independiente de la velocidad a la cual se consumen. Se presentan problemas en dos extremos: cuando el productor intenta agregar algo a una charola llena (como cuando el cocinero trata de colocar una hamburguesa de ms en una charola llena) o cuando el consumidor intenta retirar algo de una charola vaca (como cuando el empacador intenta coger una hamburguesa que todava no se prepara). En la vida real, las personas observan la charola, advierten si est vaca o demasiado llena y el problema se resuelve con rapidez. Sin embargo, en un sistema de cmputo dicha resolucin no es tan fcil. Considere el caso del CPU prolfico: el CPU puede generar datos de salida mucho ms aprisa de lo que puede imprimir una impresora de lnea. Por lo tanto, como esto comprende a un productor y a un consumidor con dos velocidades diferentes, es necesario una memoria intermedia, donde el productor pueda almacenar temporalmente datos que pueda recuperar el consumidor a una velocidad ms apropiada. La figura 6.5 muestra tres estados tpicos de memoria intermedia (buffer).
Dado que la memoria intermedia slo puede contener una cantidad finita de datos, el proceso de sincronizacin debe retrasar al productor, para que genere menos datos cuando la memoria intermedia est llena. Tambin debe estar preparado para retrasar la recuperacin de datos por parte del consumidor cuando la memoria intermedia est vaca. Esta tarea se puede implementar mediante dos semforos de conteo: uno para indicar el nmero de posiciones llenas en la memoria intermedia y en el otro para indicar el nmero de posiciones vacas en dicha memoria. Un tercer semforo, mutex, asegura la exclusin mutua entre los procesos. A continuacin presentamos las definiciones de los procesos de productor y de consumidor:
PRODUCTOR produce datos P(vaco) P(mutex) escribe datos en la memoria intermedia V(mutex) V(lleno) CONSUMIDOR P(lleno) P(mutex) lee datos de la memoria intermedia V(mutex) V(vaco) consume datos
Ing. Romel Alds
64
La siguiente lista da las definiciones de las variables y de las funciones utilizadas en el algoritmo de productores y consumidores.
Dados: n: V (x): P (x): mutex I Lleno, vaco, mutex, definidos como semforos Nmero mximo de posiciones en la memoria intermedia x: = x + 1 (x es cualquier variable definida como semforo) Si x> O entonces x: = x 1 Significa que se permite que el proceso entre en la regin crtica
A continuacin est el algoritmo que implementa la interaccin entre el productor y el consumidor. COBEGIN y COEND son delimitadores que se utilizan para indicar secciones de cdigo que se van a efectuar al mismo tiempo. ALGORITMO DE PRODUCTORES Y CONSUMIDORES
Vaco: = n Lleno: = 0 mutex: = I COBEGIN repetir hasta que no haya ms datos del PRODUCTOR Repetir hasta que la memoria intermedia est vaca CONSUMIDOR COEND
Los procesos (productor y consumidor) se ejecutan como se describi. Usted puede intentar con el cdigo con n = 3 o con un orden alterno de ejecucin para ver si funciona. El concepto de productor/consumidor se puede extender a la memoria intermedia que contiene registros u otros datos, as como a otras situaciones en que se requiere la comunicacin directa de los mensajes de proceso a proceso.
Lectores y escritores
En 1971 se formul por primera vez el problema de lectores y escritores y se presenta cuando dos tipos de procesos necesitan tener acceso a un recurso compartido como un archivo o una base de datos. Llamaron a estos procesos "lectores" y "escritores". Un buen ejemplo es un sistema de reservaciones de una aerolnea. Los lectores son los que desean informacin sobre los vuelos. Son lectores porque slo leen los datos existentes, no los modifican. Como no hay nadie que modifique la base de datos, el sistema puede permitir muchos lectores activos al mismo tiempo, no hay necesidad de la exclusin mutua entre ellos. Los escritores efectan las reservaciones sobre un vuelo en particular. Los escritores se deben organizar con cuidado, porque modifican datos existentes en la base de datos. El sistema no puede permitir que cualquiera escriba mientras alguna otra persona lee (o escribe). Por lo tanto, debe obligar a la exclusin mutua si existen grupos de lectores y un escritor o si existen varios escritores en el sistema. El sistema debe ser justo cuando obligue a esta poltica, para evitar una posposicin indefinida de lectores o escritores. En el trabajo original, Courtois, Heymans y Parnas ofrecieron dos soluciones, utilizando operaciones P y V. La primera da prioridad a los lectores sobre los escritores, por lo que slo se quedan esperando si un escritor est modificando datos en ese momento. Sin embargo, esta poltica da como resultado inanicin de escritores si existe una corriente continua de lectores. La segunda poltica da prioridad a los escritores. En este caso, tan pronto como llega un escritor, se permite que termine su procesamiento cualquier lector que est activo en ese momento, pero se dejan pendientes los lectores adicionales, hasta que termine el escritor. Esto da como resultado la inanicin de lectores si existe una corriente continua de escritores. Cualquiera de estos escenarios es inaceptable.
Ing. Romel Alds
65
Para evitar cualquier tipo de inanicin, Hoare (1974) propuso la siguiente poltica de combinacin de prioridades. Cuando ha terminado un escritor, se permite que lean todos los lectores que estn esperando o "pendientes". Luego, cuando ese grupo de lectores ha terminado, el escritor que est "pendiente" puede iniciar y se evita el acceso a todo lector nuevo que llegue en el nterin mientras no acabe el escritor. El estado del sistema se puede resumir con cuatro contadores inicializados a cero: 1. Nmero de lectores que han solicitado un recurso y todava no lo han liberado (L1 =0); 2. Lectores que estn usando un recurso y an no lo liberan (L2=0); 3. Nmero de escritores que han solicitado un recurso y que no lo han liberado (E1 =0); 4. Cantidad de escritores que estn usando un recurso y todava no lo liberan (E2=0). Esto se puede implementar utilizando dos semforos para asegurar la exclusin mutua entre lectores y escritores. Un recurso se puede dar a todos los lectores (L1 = L2) siempre y cuando no haya escritores procesando (E2=0). Un recurso se puede proporcionar a un escritor, siempre y cuando no haya lectores leyendo (L2=0) ni escritores escribiendo (E2=0). Los lectores siempre deben solicitar dos procedimientos: el primero verifica si los recursos se pueden conceder de inmediato para la lectura; luego, cuando se libera el recurso, el segundo revisa que ningn escritor est en espera. Lo mismo es cierto para los escritores. El primer procedimiento debe determinar si el recurso se puede conceder de inmediato para escribir y, al liberarlo, el segundo procedimiento averiguar si hay lectores en espera.
PROGRAMACIN CONCURRENTE
Hasta ahora hemos visto el multiprocesamiento como varios trabajos que se ejecutan al mismo tiempo en un procesador (que interactan con procesadores de entrada /salida, por ejemplo) o sobre multiprocesadores. El multiprocesamiento tambin puede referirse a un trabajo que utiliza varios procesadores para ejecutar conjuntos de instrucciones en paralelo. El concepto no es nuevo, pero requiere un lenguaje de programacin y un sistema de cmputo que pueda apoyar ese tipo de construccin. Este tipo de sistemas se conoce como sistema de procesamiento concurrente.
Aplicaciones de la programacin concurrente

La mayor parte de los lenguajes de monoprogramacin son de naturaleza serial: las instrucciones se ejecutan una por una. Por lo tanto, para resolver una expresin aritmtica, todas las operaciones se efectan en secuencia, siguiendo el orden prescrito por el programador y el compilador (tabla 6.2).
Ing. Romel Alds
66
Para muchos propsitos de cmputo, el procesamiento serial es conveniente; es fcil de implementar y lo suficientemente rpido para la mayor parte de los usuarios. Sin embargo, las expresiones aritmticas se pueden procesar de manera diferente si utilizamos un lenguaje que permita el procesamiento concurrente. Definamos dos trminos, COBEG I N y CO E N D, que indicarn al compilador qu instrucciones se pueden procesar de manera concurrente. A continuacin escribiremos de nuevo nuestra expresin, para aprovechar un compilador de procesamiento concurrente. Como se observa en la tabla 6.3, para resolver A = 3 * B * C + 4 / (D+E)**(F G), las tres primeras operaciones se pueden efectuar al mismo tiempo, si nuestro sistema de cmputo tiene por lo menos tres procesadores. Las siguientes dos operaciones se efectan al mismo tiempo y la ultima expresin se lleva a cabo de manera serial, utilizando los resultados de los dos primeros pasos. Con este sistema hemos incrementado la velocidad de cmputo, as como la complejidad del lenguaje de programacin y el hardware (tanto la maquinaria como la comunicacin entre mquinas). De hecho, tambin hemos colocado una carga grande sobre el programador: enunciar de manera explcita qu instrucciones se pueden ejecutar en paralelo. Esto es paralelismo explcito.
Los primeros programas de procesamiento concurrente se apoyaban en el programador para escribir las instrucciones en paralelo; pero se presentaban problemas: la codificacin era lenta y llevaba a perder oportunidades de procesamiento en paralelo. Tambin conduca a errores, donde el procesamiento en paralelo se indicaba de manera equivocada. Desde el punto de vista de mantenimiento, los programas eran difciles de modificar. La solucin fue la deteccin automtica hecha por el compilador de instrucciones que se puedan ejecutar en paralelo. Esto se conoce como paralelismo implcito. Con un sistema de procesamiento verdaderamente concurrente, el ejemplo presentado en las tablas 6.2 y 6.3 se codifica como una expresin. El compilador traduce la expresin algebraica en instrucciones por separado y decide cules se realizarn en paralelo y cules en serie.
Ing. Romel Alds
67
Por ejemplo, el compilador puede reorganizar la ecuacin Y=A+B*C+D en la forma A + D + B * C, de manera que las dos operaciones A+D y B*C se pueden efectuar en paralelo, dejando la suma final para calcularla al ltimo Como se muestra en los cuatro casos que se dan a continuacin, el procesamiento concurrente tambin puede reducir dramticamente la complejidad de trabajar con operaciones matriciales dentro de ciclos, de llevar a cabo la multiplicacin matricial, de conducir bsquedas en paralelo en bases de datos y de ordenar o combinar archivos. Algunos de estos sistemas utilizan procesadores en paralelo que ejecutan el mismo tipo de tareas (Ben-Ari, 1982). CASO 1, OPERACIONES DE MATRICES Para llevar a cabo una operacin de matriz dentro de un ciclo, las instrucciones pudieran decir: DO 1=1,3 A(I) = B(I)+C(I) ENDDO Si utilizamos tres procesadores, la instruccin se puede llevar a cabo en un paso como sigue:
Procesador #1 ejecuta: A(1) = B(1)+C(1) Procesador #2 ejecuta: A(2) = B(2)+C(2) Procesador #3 ejecuta: A(3) = B(3)+C(3)
Varios elementos de la primera hilera de la matriz A se podran multiplicar por los elementos correspondientes de la primera columna de la matriz B. Este proceso se puede repetir hasta poder calcular todos los productos para el primer elemento de la matriz C y obtener el resultado sumando los productos. El nmero real de productos que se puede calcular al mismo tiempo depende del nmero de procesadores disponibles. En serie, puede calcularse en 45 pasos. Con tres procesadores, al efectuar multiplicaciones en paralelo, bastan 27 pasos. CASO 3, BSQUEDA DE BASES DE DATOS La bsqueda es una aplicacin no matemtica comn de procesamiento concurrente. Cada procesador busca una seccin diferente de la base de datos o del archivo. Es una manera muy rpida de encontrar trminos en un diccionario, autores en una base de datos bibliogrfica o trminos en archivos invertidos (los archivos invertidos se generan partir de bases de datos de documentos completos. Cada registro en un archivo invertido contiene un trmino de tema y los nmeros de documentos donde el tema se encuentre). CASO 4, ORDENAMIENTO O COMBINACIN DE ARCHIVOS La divisin de un archivo grande en secciones, cada uno con su procesador, permite ordenar cada seccin al mismo tiempo. Luego es factible combinar pares de secciones hasta que el archivo entero est completo de nuevo y ordenado.
Ing. Romel Alds
68

Asesoría Didáctica 1

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Asesoría Didáctica 1

Enviado por

Direitos autorais:

Formatos disponíveis

SISTEMAS OPERATIVOS I

FUNDAMENTOS DE SISTEMAS OPERATIVOS

Ing. Romel Alds

SOFTWARE DEL SISTEMA OPERATIVO

Ing. Romel Alds

Ing. Romel Alds

Ing. Romel Alds

TIPOS DE SISTEMAS OPERATIVOS

HISTORIA BREVE OPERATIVOS

Ing. Romel Alds

Ing. Romel Alds

Ing. Romel Alds

Ing. Romel Alds

ADMINISTRADOR DEL PR OCESADOR

Ing. Romel Alds

PLANIFICACIN DE TRABAJOS PLANIFICACIN DE PROCESOS

Ing. Romel Alds

respectivamente. Se conoce como el planificador de trabajo y el procesos.

Ing. Romel Alds

ESTADO DE LOS TRABAJOS Y DE LOS PROCESOS

Ing. Romel Alds

Ing. Romel Alds

Bloques de control de procesos

Cantidad de tiempo del CPU utilizada del principio al final de su ejecucin.

Ing. Romel Alds

Ing. Romel Alds

POLITICAS DE PLANIFICACION DE PROCESOS

Ing. Romel Alds

ALGORITMOS DE PLANIFICACION DE PROCESOS

PRIMERO DE ENTRAR, PRIMERO DE SERVIRSE

Ing. Romel Alds

SIGUE EL TRABAJO MS CORTO

Ing. Romel Alds

Cuando n es el nmero de trabajos en la cola y para cada uno de los trabajos.

es la longitud del ciclo CPU

PLANIFICACIN CON PRIORIDAD

Ing. Romel Alds

TIEMPO RESTANTE MS BREVE

Ing. Romel Alds

En este caso el tiempo de retorno es: Trabajo: Tiempo de retorno: A 6 B 9 C 5 D 11

Ing. Romel Alds

Ing. Romel Alds

Por lo que el tiempo promedio de retorno es:

Ing. Romel Alds

COLAS DE MULTIPLES NIVELES

Ing. Romel Alds

UNA PALABRA SOBRE INTERRUPCIONES

Ing. Romel Alds

Ing. Romel Alds

Ing. Romel Alds

ADMINISTRACIN DE LOS PROCESOS

Ing. Romel Alds

Siete casos de bloqueo mutuo

Ing. Romel Alds

Ing. Romel Alds

Ing. Romel Alds

Ing. Romel Alds

Ing. Romel Alds

CONDICIONES PARA EL BLOQUEO MUTUO

Ing. Romel Alds

MODELADO DE BLOQUEOS MUTUOS

Ing. Romel Alds

Ing. Romel Alds