NDICE.

2.1 Concepto de Proceso. ..................................................................................................................... 3 2.2 Estados y Transiciones de los Procesos. .......................................................................................... 6 2.3 Procesos Ligeros (Hilos o Hebras). ................................................................................................... 9 2.4 Concurrencia y Secuenciabilidad. .................................................................................................... 12 2.4.1 Exclusin Mutua de Secciones Crticas. ............................................................................... 15 2.4.2 Sincronizacin de Procesos en S.C. ...................................................................................... 19 2.4.2.1 Mecanismo de Semforos. ...................................................................................... 23 2.4.2.2 Mecanismo de Monitores. ...................................................................................... 25 2.4.3 Interbloqueo (DeadLock). .................................................................................................... 30 2.4.3.1 Prevencin. .............................................................................................................. 32 2.4.3.2 Deteccin. ................................................................................................................ 33 2.4.3.3 Recuperacin. .......................................................................................................... 34 2.5 Niveles, Objetivos y Criterios de Planificacin................................................................................. 35 2.6 Tcnicas de Administracin del Planificador. .................................................................................. 40 2.6.1 FIFO. ..................................................................................................................................... 41 2.6.2 SJF. ....................................................................................................................................... 43 2.6.3 RR. ........................................................................................................................................ 45 2.6.4 Queves Multi-level. .............................................................................................................. 46 2.6.5 Multi-level Feedback Queves. ............................................................................................. 48

Introduccin.
Los sistemas operativos manejan muchsimos procesos, todos estos procesos se llevan a cabo con ayuda del procesador, En este trabajo se encuentra una informacin muy completa de la forma en que se realizan los procesos en el procesador, entre ellos se encuentra la forma de planificacin de los procesos, los tipos de interbloqueo y las tcnicas de administracin de procesos. En el desarrollo del trabajo presentamos las definiciones que cada tipo de planificacin utiliza, los objetivos que utilizan para ser la base de cada estructura de los procesos, presentamos algunas tcnicas de administracin en las que indicamos cual es la forma en que se deben de implementar para realizar operaciones con el procesador o para hacer funcionar mejor el procesador.

[2]

2.1 Concepto de Proceso.

Un proceso no es ms que un programa en ejecucin e incluye los valores actuales del contador de programa, los registros y las variables. Conceptualmente, cada uno de estos procesos tiene su propia CPU virtual. Desd luego en la realidad la verdadera CPU conmuta de un proceso a otro pero para entender el sistema es mucho ms fcil de seguir la pista a la forma en la que la CPU conmuta de un programa a otro. Esta rpida conmutacin se denomina multiprogramacin. Con la CPU conmutado entre los procesos, la rapidez con que un proceso realiza sus clculos no es uniforme y probablemente ni siquiera reproducible si los mismos procesos se ejecutan otra vez. por tanto, los procesos no deben programarse basndose en supuestos acerca de los tiempos. Considere, por ejemplo, un proceso de e/s que inicia una cinta continua para restaurar archivos respaldados, ejecuta un ciclo vaco 10000 veces para permitir que la cinta alcance la velocidad de trabajo y luego emite un comando para leer el primer registro. Si la CPU decide conmutar a otro proceso durante el ciclo vaco, es posible que los procesos de cinta no se ejecuten otra vez sino hasta despus de que el primer registro haya pasado por la cabeza de lectura. Cuando un proceso tiene requisitos de tiempo real crticos como este, es decir, cuando ciertos eventos deben ocurrir en cierto nmero de milisegundos, se deben tomar medidas especiales para asegurar que as ocurran. Normalmente, empero, los procesos no resultan afectados por la multiprogramacin subyacente de la CPU ni las velocidades relativas de los diferentes procesos. La diferencia entre un programa y un proceso es sutil, pero crucial. Tal vez una analoga ayude a aclarar este punto. Consideremos un computologo con inclinaciones gastronmicas que est preparando un pastel de cumpleaos para su hija. l cuenta con una receta para pastel de cumpleaos y una cocina bien abastecida de las entradas necesarias: harina, huevos, azcar, extracto de vainilla, etc. en esta analoga, la receta es el programa (es decir un algoritmo expresado en alguna flotacin apropiada), el computologo es el procesador (CPU) y los ingredientes del pastel son los datos de entrada. el proceso es la actividad de nuestro pastelero consistente en leer la receta, obtener los ingredientes y hornear el pastel.

[3]

Imaginemos ahora que el hijo del computologo llega corriendo y llorando, diciendo que le pico una abeja. El computologo registra el punto en que estaba en la receta (guarda el estado del proceso actual), saca un libro de primeros auxilios, y comienza a seguir las instrucciones que contiene. Aqu vemos como el procesador se conmuta de un proceso (hornear) a un proceso de ms alta prioridad (administrar cuidados mdicos), cada uno con un programa diferente (receta vs primeros auxilios). Una vez que se ha atendido la picadura de abeja, el computologo regresa a su pastel, continuando en el punto donde haba interrumpido. la idea clave aqu es que un proceso es una actividad de algn tipo: tiene programa, entrada, salida y un estado. Se puede compartir un procesador entre varios procesos, usando algn algoritmo de planificacin para determinar cundo debe de trabajar en un proceso para atender a uno distinto. Informalmente, un proceso es un programa en ejecucin. La ejecucin de un proceso debe proceder de manera secuencial. Es decir, en cualquier instante, cuando ms una instruccin se estar ejecutando nombre del proceso. un proceso es ms que el cdigo del programa (tambin conocido como seccin de texto); tambien incluye la actividad actual, representada por el valor del contador de programa y el contenido de los registros del procesador. Generalmente, un proceso tambin incluye la pila (stack) del proceso, que contiene datos temporales (como los parmetros de subrutinas, direcciones de retorno y variables temporales), y una seccin de datos que contiene variables globales. Hacemos hincapi en que un programa por s solo no es un proceso; un programa es una entidad pasiva, como el contenido de un archivo guardado en disco, mientras que un proceso es una entidad activa, con el contador de programa especificando la siguiente instruccin que se ejecutara, y un conjunto de recursos asociados. Aunque podra haber dos procesos asociados al mismo programa, de todas maneras se consideran como dos secuencias de ejecucin distintas. Por ejemplo, varios usuarios podran estar ejecutando copias del programa editor. Cada una de estas es un proceso aparte, y aunque las secciones de texto sean equivalentes, las secciones de datos variaran. Tambin es comn tener un proceso que engendra muchos procesos durante su ejecucin. [4]

Jerarqua de procesos.
Los sistemas operativos que manejan el concepto de proceso deben contar con algn mecanismo para crear todos los procesos necesarios. En los sistemas muy sencillos, o en los diseados para ejecutar solo una aplicacin (por ejemplo, controlar un dispositivo en tiempo real), es posible que, cuando el sistema de inicia, todos los procesos que puedan necesitarse estn presentes. Sin embargo, en la mayor parte de los sistemas se necesita algn mecanismo para crear y destruir procesos segn sea necesario durante la operacin. En minix, los procesos se crean con la llamada del sistema fork (bifurcar), que crea una copia idntica del proceso invocador. El proceso hijo tambin puede ejecutar fork, as que es posible tener un rbol de procesos. En otros sistemas operativos existen llamadas al sistema para crear un proceso, cargar su memoria y ponerlo a ejecutar. Sea cual sea la naturaleza exacta de la llamada al sistema, los procesos necesitan poder crear otros procesos. Obsrvese que cada proceso tiene un padre, pero cero, uno, dos, o ms hijos. Como ejemplo sencillo del uso de los rboles de procesos, veamos la forma en que minix se inicializa a si mismo cuando se pone en marcha. Un proceso especial, llamado mit, est presente en la imagen de arranque. Cuando este proceso comienza a ejecutarse, lee un archivo que le indica cuantas terminales hay, y luego bifurca un proceso nuevo por terminal. Estos procesos esperan a que alguien inicie sesin. Si un inicio de sesin ( login ) tiene xito, el proceso de inicio de sesin ejecuta un shell para aceptar comandos . Estos comandos pueden iniciar ms procesos, y as sucesivamente. Por tanto, todos los procesos del sistema pertenecen a un mismo rbol, que tiene a mit en si raz. (El cdigo de mit no se alista en este libro, y tampoco el del shell. Haba que poner un lmite en algn lado).

[5]

2.2 Estados y Transiciones de los Procesos.

A medida que un proceso se ejecuta, cambia de estado. El estado de un proceso est definido en parte por la actividad actual de ese proceso. Cada proceso puede estar en uno de los siguientes estados:
PROCESO - NUEVO (NEW). - EN EJECUCION (RUNNING). - EN ESPERA (WAITING). ACTIVIDAD EL PROCESO SE ESTA CREANDO. SE ESTAN EJECUTANDO. El PROCESO ESTA ESPERANDO QUE OCURRA ALGUN SUCESO (COMO LA TERMINACION DE UNA OPERACIN DE E/S O LA RECEPCION DE UNA SEAL). EL PROCESO ESTA ESPERANDO QUE SE LE ASIGNE A UN PROCESADOR. EL PROCESO TERMINO SU EJECUCION.

LISTO (READY). TERMINADO (TERMINATED).

Estos nombres son arbitrarios, y varan de un sistema operativo a otro; sin embargo, los estados que representan se encuentran en todos los sistemas. Ciertos sistemas operativos hacen distinciones todava ms sutiles entre estados de los procesos. Es importante tener presente que solo un proceso puede estar ejecutndose en cualquier procesador en un instante dado, pero muchos procesos pueden estar listos y esperando. Un proceso sale de un sistema en dos pasos. Primero, el proceso termina cuando liega al punto normal de terminacin, cuando se abandona debido a un error irrecuperable o cuando otro proceso con la debida autoridad hace que el proceso abandone, la terminacin pasa el proceso al estado terminado. En este punto, el proceso ya no se elige ms para la ejecucin. Sin embargo, las tablas y otra informacin asociada con el trabajo son conservadas temporalmente por el sistema operativo. Esto le da tiempo a otros programas auxiliares o de soporte para extraer la informacin necesaria. Por ejemplo, puede ser que un programa de contabilidad necesite registrar el tiempo de procesador y otros recursos usados por el proceso con fines de facturacin. Un programa de utilidades puede tener [6]

que extraer informacin sobre la historia del proceso con fines relativos a un anlisis de uso o de rendimiento. Una vez que estos programas han extrado la informacin necesaria, el sistema operativo ya no necesita mantener ms datos relativos al proceso y estos se borran del sistema. Nulo nuevo: se crea un nuevo proceso para ejecutar un programa.

Nuevo listo: el sistema operativo pasara a un proceso del estado nuevo al estado listo cuando est preparado para aceptar un proceso ms. La mayora de los sistemas ponen un lmite en funcin del nmero de procesos existentes o en la cantidad de memoria virtual dedicada a los procesos existentes. El motivo de este lmite es asegurar que no haya tantos procesos activos como para degradar el rendimiento.

Listo ejecucin: cuando es hora de seleccionar un nuevo proceso para ejecutar, el sistema operativo elige a uno de los procesos del estado listo. Ejecucin terminada: el proceso que se est ejecutando es finalizado por el sistema operativo si indica que termino 0 si se abandona. Ejecucin listo: la razn ms comn de esta transicin es que el proceso que est en ejecucin ha alcanzado el tiempo mximo permitido de ejecucin interrumpida; casi todos los sistemas operativos con multiprogramacin imponen este tipo de norma de tiempo. Hay otras causas alternativas para esta transicin que no estn implementadas en todos los sistemas operativos. Por ejemplo, si el sistema operativo asigna diferentes niveles de prioridad a los diferentes procesos. Supngase que un proceso a esta ejecutndose con un cierto nivel de prioridad y que el proceso b, con un nivel de prioridad mayor, est bloqueado. Si el sistema operativo se entera de que el suceso que b estaba esperando se ha producido, pasando as b ha estado listo, entonces puede interrumpir al proceso a y expandir a b. Por ltimo, otro caso es que un proceso ceda voluntariamente el control del procesador. Ejecucin bloqueada: un proceso se pone en el estado bloqueado sus e solicita algo por lo que debe esperar. Las solicitudes al sistema operativo suelen ser en forma de llamadas a [7]

servicios del sistema, es decir , llamadas desde el programa que esta ejecutndose a un procedimiento que forma parte del cdigo del sistema operativo. Bloqueado listo: un proceso que est en el estado bloqueado pasara al estado listo cuando se produzca el suceso que estaba esperando. Listo terminado: en algunos sistemas, un padre puede terminar con un proceso hijo en cualquier momento. Adems, si el padre termina, todos los hijos asociados con l pueden ser finalizados. Bloqueado terminado: se aplica el mismo comentario que en el caso anterior.

[8]

2.3 Procesos Ligeros (Hilos o Hebras).

Es un proceso tradicional hay un solo hilo de control y un solo contador de programa en cada proceso. Sin embargo. Algunos sistemas operativos modernos manejan mltiples hilos de control dentro de un proceso. Estos hilos de control se llaman solo hilos, ocasionalmente, procesos ligeros. Recordemos que un proceso se define por los recursos que usa y por el lugar donde se ejecuta. Sin embargo, hay muchos casos en los que sera til compartir los recursos y acceder a ellos de forma concurrente. Esta situacin es similar al caso en que se hace una llamada al sistema bifurcar (folk) con un nuevo contador de programa, o hilo de control ejecutndose dentro del mismo espacio de direcciones. Este concepto es tan til que varios sistemas operativos nuevos incluyen un mecanismo para apoyarlo mediante hilos. Un hilo, tambin llamado proceso ligero (lwp,lightweight procesos), es una unidad bsica de utilizacin de la CPU, y consiste en un contador de un programa, un juego de registros y un espacio de pila. El hilo comparte con sus hilos pares la seccin de cdigo, seccin de datos y recursos del sistema operativo como archivos abiertos y seales, lo que se denomina colectivamente una tarea. Un proceso tradicional o pesado es igual a una tarea con un solo hilo. Una tarea no hace nada si no hay hilos en ella, y un hilo debe estar en una y solo una tarea. El extenso compartir hace que la conmutacin de la CPU entre hilos pares, y la creacin de hilos, sea econmica en comparacin con las conmutaciones de contexto entre procesos pesados. Aunque una conmutacin de contexto de hilos tambin requiere un cambio de conjunto de registros, no hay que realizar operaciones relacionadas con la gestin de memoria. Al igual que en cualquier entorno de procesamiento paralelo, el multicitado de un proceso puede introducir problemas de control de concurrencia que requieren el uso de secciones crticas o cerraduras. Adems, en algunos sistemas implementan hilos en el nivel de usuario en bibliotecas en el nivel de usuario, no por medio de llamadas al sistema, as que la conmutacin de hilos no necesita invocar el sistema operativo ni causar una interrupcin para pasar al ncleo. La conmutacin entre hilos en el nivel de usuario puede hacerse con independencia del sistema operativo y, por tanto muy rpidamente. As, bloquear un hilo conmutar a otro es una solucin razonable al problema de cmo un [9]

Servidor puede manejar muchas solicitudes de forma eficiente. Los hilos en el nivel de usuario que ejecute una llamada al sistema harn que toda la tarea espere hasta que la llamada regrese.

Los hilos operan en muchos sentidos, de la misma forma que los procesos. Los hilos pueden estar en uno de varios estados: listo, bloquead, en ejecucin o terminado. Al igual que los procesos, los hilos comparten la CPU, y solo hay un hilo activo (en ejecucin) en un instante dado. Un hilo dentro de un proceso se ejecuta secuencialmente, y cada hilo tiene su propia pila y contador de programa. los hilos pueden crear hilos hijos, y se pueden bloquear en espera a que termine la ejecucin de llamadas al sistema; si un hilo se bloquea, otro puede ejecutarse. Por otro lado, a diferencia de los procesos, los hilos no son independientes entre s. Dado que todos los hilos pueden acceder a todas las direcciones de la tarea, un hilo puede leer la pila de cualquier otro hilo o escribir sobre ella. Esta estructura no ofrece proteccin entre hilos. Los hilos ofrecen un mecanismo que permite a procesos secuenciales hacer llamadas al sistema bloqueadoras y al mismo tiempo lograr paralelismo. La popularidad de los hilos est creciendo por que tienen algunas de las caractersticas de los procesos pesados pero se pueden ejecutar con mayor eficiencia. Hay muchas aplicaciones en las que esta combinacin es til. Por ejemplo, algunas implementaciones del ncleo de Unix son mono tareas: solo una tarea puede estar ejecutando cdigo del ncleo en un momento dado con esto se evitan muchos problemas, como la sincronizacin del acceso a datos (poniendo cerraduras a las estructuras de datos mientras se estn modificando), porque solo permite a un proceso efectuar la modificacin. Mach, en cambio, es multicitado y permite al ncleo atender muchas solicitudes simultneamente.

[10]

En algunos sistemas del sistema operativo no est consciente de la existencia de los hilos. En otras palabras, los hilos se manejan totalmente en el espacio de usuario. Por ejemplo, cuando un hilo est a punto de bloquearse, escoge e inicia a su sucesor antes de detenerse. Hay varios paquetes de hilos a nivel de usuario, incluidos los paquetes de hilos p de posix e hilos c de mach. En otros sistemas, el sistema operativo esta consiente de la existencia de mltiples hilos por proceso, as que, cuando un hilo se bloquea, el sistema operativo escoge el que se ejecutara a continuacin, ya sea del mismo proceso o de uno distinto. Para realizar la planificacin, el kernel debe tener una tabla de hilos que liste todos los hilos del sistema anloga a la tabla de procesos. Aunque estas dos alternativas pueden parecer equivalentes, su rendimiento es muy distinto. La conmutacin de hilos es mucho ms rpida cuando la administracin de hilos se efecta en el espacio de usuario que cuando necesita una llamada al kernel. Este hecho es un argumento convincente para realizar la administracin en el espacio de usuario y uno se bloquea.

[11]

2.4 Concurrencia Y Secuensiabilidad.

La concurrencia es el punto clave y fundamental para el diseo de sistemas operativos. La concurrencia comprende un gran nmero de cuestiones de diseo, incluyendo la comunicacin entre procesos, comparticin y competencia por los recursos, sincronizacin de la ejecucin de varios procesos y asignacin del tiempo de procesador a los procesos. Se ver que estas cuestiones no solo surgen en entornos de multiprocesadores y proceso distribuido, sino incluso en sistemas multiprogramados con un solo procesador. Es tambin un sistema multiprogramado con un nico procesador, los procesos se intercalan en el tiempo para dar la apariencia simultnea. Aunque no se consigue un proceso paralelo real y aunque se produce una cierta sobrecarga en los intercambios de procesos de un sitio a otro, la ejecucin intercalada produce beneficios importantes en la eficiencia del procesamiento y en la estructuracin de los programas. La concurrencia comprende un gran nmero de cuestiones de diseo incluyendo la comunicacin entre procesos, comparticin y competencia por los recursos, sincronizacin de la ejecucin de varios procesos y asignacin de tiempo del procesador a los procesos. La concurrencia puede presentarse en tres contextos diferentes: Varias aplicaciones: la multiprogramacin se cre para permitir que el tiempo de procesador de la maquina fuese compartido dinmicamente entre varios trabajos o aplicaciones activas.

Aplicaciones estructuradas: como aplicacin de los principios del diseo modular y la programacin estructurada, algunas aplicaciones pueden implementarse eficazmente como un conjunto de procesos concurrentes. Estructura del sistema operativo: las mismas ventajas de estructuracin son aplicables a los programadores de sistemas y se ha comprobado que algunos sistemas operativos estn implementados como un conjunto de procesos.

[12]

Cuando dos o ms procesos llegan al mismo tiempo a ejecutarse, se dice que se ha presentado una concurrencia de procesos. Es importante mencionar que para que dos o ms procesos sean concurrentes, es necesario que tengan alguna relacin entre ellos como puede la cooperacin para un determinado trabajo o el uso de informacin o recursos compartidos, por ejemplo: en un sistema de un procesador , la multiprogramacin es una condicin necesaria pero no suficiente para que exista concurrencia ya que los procesos pueden ejecutarse de forma totalmente independiente. Por otro lado en un sistema de varios procesos se puede presentar la concurrencia siempre y cuando las actividades necesiten actuar entre si ya sea para utilizar informacin en comn o para cualquier otra cosa.

BENEFICIOS DE LA CONCURRENCIA : Trata de evitar los tiempos muertos de la UCP. Comparte y optimiza el uso de recursos. Permite la modularidad en las diferentes etapas del proceso. Acelera los clculos. Da mayor comodidad.

DESVENTAJAS DE LA CONCURRENCIA: Inanicin e interrupcin de procesos Ocurrencia de bloqueos Que dos o ms procesos requieran el mismo recurso (no apropiativo).

Tipos de computadora en los que puede haber concurrencia: multiprogramacin con un CPU: el sistema operativo se encarga de repartir el CPU entre los procesos, intercalando su ejecucin para dar una apariencia de ejecucin simultnea. Multiprocesador: maquina formada por ms de un CPU que comparten memoria principal. Los procesos no solo intercalan su ejecucin sino tambin la superponer. [13]

 Multicomputadora: es una mquina de memoria distribuida formada por una serie de computadoras, es posible la ejecucin simultanea de los proceso en los diferentes cups. La concurrencia ser aparente siempre que el nmero de procesos sea mayor que el de procesadores disponibles y ser real cuando haya un proceso por procesador (paralelismo).

[14]

2.4.1 Exclusin Mutua Secciones Criticas.

El mtodo ms sencillo de comunicacin entre los procesos de un programa concurrente es el uso comn de unas variables de datos. El problema de este sistema es que la accin de un proceso interfiere en las acciones de otro de una forma no adecuada. Para evitar este tipo de errores se pueden identificar aquellas regiones de los procesos que acceden a variables compartidas y dotarlas de la posibilidad de ejecucin como si fueran una nica instruccin. Se denomina seccin crtica a aquellas partes de los procesos concurrentes que no pueden ejecutarse de forma concurrente o, que desde otro proceso se ven como si fueran una nica instruccin. Esto quiere decir que si un proceso entra a ejecutar una seccin crtica en la que accede a unas variables compartidas, entonces otro proceso no puede entrar a ejecutar una regin crtica en la que se modifique las variables compartidas con el anterior. Las secciones crticas se pueden agrupar en clases, siendo mutuamente exclusivas las secciones crticas de cada una. Para conseguir dicha exclusin se deben implementar protocolos software que impidan o bloqueen el acceso a una seccin crtica mientras est siendo utilizada por un proceso. Los algoritmos de exclusin mutua (comnmente abreviada como mutex por mutual exclusin) se usan en programacin concurrente para evitar que fragmentos de cdigo conocidos como secciones crticas accedan al mismo tiempo a recursos que no deben ser compartidos. La mayor parte de estos recursos son las seales, contadores, colas y otros datos que se emplean en la comunicacin entre el cdigo que se ejecuta cuando se da servicio a una interrupcin y el cdigo que se ejecuta el resto del tiempo. Se trata de un problema de vital importancia porque, si no se toman las precauciones debidas, una interrupcin puede ocurrir entre dos instrucciones cualesquiera del cdigo normal y esto puede provocar graves fallos. La tcnica que se emplea por lo comn para conseguir la exclusin mutua es inhabilitar las interrupciones durante el conjunto de instrucciones ms pequeo que impedir la corrupcin de la estructura compartida (la seccin crtica). Esto impide que el cdigo de la interrupcin se ejecute en mitad de la seccin crtica.

[15]

En un sistema multiprocesador de memoria compartida, se usa la operacin indivisible test-and-set sobre una bandera, para esperar hasta que el otro procesador la despeje. La operacin test-and-set realiza ambas operaciones sin liberar el bus de memoria a otro procesador. As, cuando el cdigo deja la seccin crtica, se despeja la bandera. Esto se conoce como espera activa. Algunos sistemas tienen instrucciones multi-operacin indivisibles similares a las anteriormente descritas para manipular las listas enlazadas que se utilizan para las colas de eventos y otras estructuras de datos que los sistemas operativos usan comnmente. La mayora de los mtodos de exclusin mutua clsicos intentan reducir la latencia y espera activa mediante las colas y cambios de contexto. Algunos investigadores afirman que las pruebas indican que estos algoritmos especiales pierden ms tiempo del que ahorran. A pesar de todo lo dicho, muchas tcnicas de exclusin mutua tienen efectos colaterales. Por ejemplo, los semforos permiten interbloqueos (deadlocks) en los que un proceso obtiene un semforo, otro proceso obtiene el semforo y ambos se quedan a la espera de que el otro proceso libere el semforo. Otros efectos comunes incluyen la inanicin, en el cual un proceso esencial no se ejecuta durante el tiempo deseado, y la inversin de prioridades, en el que una tarea de prioridad elevada espera por otra tarea de menor prioridad, as como la latencia alta en la que la respuesta a las interrupciones no es inmediata. La mayor parte de la investigacin actual en este campo, pretende eliminar los efectos anteriormente descritos. Si bien no hay un esquema perfecto conocido, hay un interesante esquema no clsico de envo de mensajes entre fragmentos de cdigo que, aunque permite inversiones de prioridad y produce una mayor latencia, impide los interbloqueos. Algunos ejemplos de algoritmos clsicos de exclusin mutua son: El algoritmo de Dekker.

El algoritmo de Peterson.

[16]

Los puntos de entrada de un recurso indican la cantidad de procesos que pueden utilizar simultneamente al mismo. Si un recurso tiene slo un punto de entrada, se lo denomina recurso crtico o recurso no compartible. Regin crtica de un proceso es la fase o etapa en la vida de ese proceso concurrente en la cual accede a un recurso crtico para modificarlo o alterarlo. El uso adecuado de la concurrencia entre procesos exige la capacidad de definir secciones crticas y hacer cumplir la exclusin mutua. Cualquier servicio o capacidad que d soporte para la exclusin mutua debe cumplir con un protocolo de sincronizacin, que tiene los requisitos siguientes: Debe cumplirse la exclusin mutua: slo un proceso de entre todos los que poseen secciones crticas por el mismo recurso u objeto compartido, debe tener permiso para entrar en ella en un instante dado.

Un proceso que se interrumpe en una seccin no crtica debe hacerlo sin estorbar a los otros. Es decir que si se cuelga un proceso que est usando un recurso, los dems procesos que esperan deben poder acceder al recurso de todas formas (el S.O. mata al proceso que se colg y as libera al recurso).

No se puede demorar indefinidamente la entrada de un proceso a un cierto recurso; no debe permitirse el interbloqueo y la inanicin. Todos los procesos deben poder acceder al recurso que solicitan, sino se van a morir sin usarlo y no es justo.

Cuando ningn proceso est en su seccin crtica, cualquier proceso que solicite entrar en la suya debe poder hacerlo sin dilatacin. Es decir, si nadie est usando un cierto recurso, entonces se le otorga al primer proceso que lo solicite.

No se pueden hacer suposiciones sobre la velocidad relativa de los procesos o su nmero (cantidad de procesadores). Nunca se puede saber a priori si a un proceso le falta mucho o poco para terminar.

[17]

 Un proceso permanece en su seccin crtica slo por un tiempo finito. Esto sirve para evitar que un proceso se quede con un recurso por mucho tiempo y para que un recurso no se quede trabado sin sentido.

[18]

2.4.2 Sincronizacin de Procesos en S.C.

(Segn Deitel, 1993) Uno de los objetivos del sistema operativo es la representacin de los procesos y el soporte de los cambios de contexto entre procesos, que posibilitan la comparticin del recurso CPU. El acceso a otros recursos compartidos y comunicacin entre procesos relacionados (por ejemplo, de una misma aplicacin) hacen necesaria la utilizacin de mecanismos de sincronizacin dentro del sistema operativo. Tpicamente, un proceso requiere la CPU durante un periodo de tiempo, realiza alguna operacin de E/S, y vuelve a requerir la CPU, repitindose este ciclo hasta la finalizacin del programa. El proceso pasa por diversos estados entre los que se definen transiciones, como representa, en su forma ms sencilla, el grafo de la Figura siguiente. (Segn Deitel, 1993) Cada vez que un proceso pasa al estado preparado, est compitiendo por el recurso CPU. Un segundo objetivo del sistema operativo multiprogramado es la planificacin del uso del (de los) recurso(s) de proceso. Los criterios que se siguen para la planificacin y las polticas que se usan se estudiarn ms adelante en el desarrollo de la presente investigacin. Para representar los procesos, un sistema operativo multiprogramado debe almacenar informacin en base a la cual: Identificar cada proceso. Se utiliza un identificador del proceso, que suele ser un entero.

Representar el estado de cada proceso para mantener el grafo de transicin de estados. Normalmente los estados se representan mediante colas de procesos. Planificar el siguiente proceso que entre en la CPU (scheduling). Se requiere informacin que permita aplicar los criterios de planificacin (prioridad, quantum, etc). Contabilizar el uso de recursos por el proceso (tiempo consumido de CPU, tiempo de ejecucin del proceso, tiempos mximos asignados, identificador de usuario). Parte de esta informacin puede ser til para la planificacin.

[19]

 Gestionar el contexto de los procesos. Por cada proceso hay que almacenar el estado del procesador, de la pila y de los otros recursos (memoria y entrada/salida). En un cambio de contexto hay que guardar el contexto del proceso que abandona la ejecucin y restaurar el contexto del proceso planificado. Gestionar la memoria. Punteros a tablas de pginas y otra informacin de la que hablaremos en su momento. Soportar la entrada/salida. Peticiones pendientes, dispositivos asignados, tabla de canales, etc.

Esta informacin no tiene por qu estar concentrada en una estructura de datos nica para cada proceso. Cmo se almacene depender de la estructura del sistema operativo. Por ejemplo, en los sistemas por capas, la informacin de un proceso estar segmentada a travs de las capas. Sin embargo, conceptualmente podemos suponer una estructura, que denominaremos Bloque de Control del Proceso o PCB (Process Control Block), que almacena la informacin del proceso. Los PCBs se enlazan para formar listas encadenadas (Figura B), por lo que el PCB incluye uno o ms apuntadores. La disciplina de acceso a los PCBs puede ser diversa (FCFS, en base a la prioridad, etc.). As, la gestin de procesos en el sistema operativo se puede representar mediante un conjunto de colas de PCBs. Habr una cola para los procesos que estn en estado preparado para ejecucin, una cola para cada condicin de bloqueo, e incluso, para generalizar, se puede considerar una cola de procesos en ejecucin (por cada CPU).

[20]

De esta forma, podemos definir el sistema operativo como un modelo de procesos que se representa mediante un sistema de colas, segn se muestra a continuacin.

En programacin concurrente, se define como a la porcin de cdigo de un programa de computador el cual accede a un recurso compartido (estructura de datos dispositivo) que no debe de ser accedido por ms de un hilo en ejecucin (thread). La seccin crtica por lo general termina en un tiempo determinado y el hilo, proceso tarea solo tendr que esperar un perodo determinado de tiempo para entrar. Se necesita de un mecanismo de sincronizacin en la entrada y salida de la seccin crtica para asegurar la utilizacin exclusiva del recurso, por ejemplo un semforo. El acceso concurrente se controla teniendo cuidado de las variables que se modifican dentro y fuera de la seccin crtica. La seccin crtica se utiliza por lo general cuando un programa multihilo actualiza mltiples variables sin un hilo de ejecucin separado que lleve los cambios conflictivos a esos datos. Una situacin similar, la seccin crtica puede ser utilizada para asegurarse de que un recurso compartido, por ejemplo, una impresora, puede ser accedida por un solo proceso a la vez. La manera en cmo se implementan las secciones puede variar dependiendo de los diversos sistemas operativos. Slo un proceso puede estar en una seccin crtica a la vez. Propiedades del acceso exclusivo a secciones crticas: Como criterios de validez de un mecanismo de sincronizacin nos referiremos al cumplimiento de las siguientes condiciones enunciadas por Dijkstra para el acceso exclusivo a una seccin crtica. Exclusin mutua. No puede haber ms de un proceso simultneamente en la SC.

No interbloqueo. Ningn proceso fuera de la SC puede impedir que otro entre a la SC. [21]

 No inanicin. Un proceso no puede esperar por tiempo indefinido para entrar a la SC. Independencia del hardware. No se pueden hacer suposiciones acerca del nmero de procesadores o de la velocidad relativa de los procesos.

[22]

2.4.2.1 Mecanismo de Semforos.

(Segn William Stallings, 2002) Los semforos son mecanismos que permiten sincronizar procesos para prevenir colisiones cuando uno o ms procesos solicitan simultneamente un recurso. Un mecanismo semforo consta bsicamente de dos operaciones primitivas seal (Signal) y espera (Wait) (Originalmente definidas como P y V por Disjkstra), que operan sobre un tipo especial de variable semforo, s. La variable semforo puede tomar valores enteros y, excepto posiblemente en su inicializacin, solo puede ser accedida y manipulada por medio de las operaciones SIGNAL y WAIT. Ambas primitivas llevan un argumento cada una, la variable semforo, y pueden definirse del modo siguiente: SIGNAL (S): Incrementa el valor de su argumento semforo, s, en una operacin indivisible. WAIT (S): Decrementa el valor de su argumento semforo, s , en tanto el resultado no sea negativo. La conclusin de la operacin WAIT, una vez tomada la decisin de decrementar su argumento semforo, debe ser individual.

Propiedades. (Segn William Stallings, 2002) Los semforos son un mecanismo relativamente sencillo pero poderoso de asegurar la exclusin mutua entre procesos concurrentes para acceder a un recurso compartido. En vez de que lo usuarios inventen sus propios protocolos de sincronizacin (tarea difcil y traicionera) los semforos son una herramienta proporcionada por el diseador de sistemas. Los usuarios solo necesitan contribuir a controlar el acceso a los recursos compartidos obedeciendo un protocolo estndar y sencillo. Disciplina de Servicio de los Semforos. (Segun William Stallings, 2002) La definicin de semforo con espera activa no impone la aplicacin de ninguna ordenacin a los procesos que esperan, existe, por tanto, una posibilidad de que un proceso [23]

pueda quedar bloqueado debido a la competencia con otros. Esta situacin, en la cual algunos procesos progresan hacia su terminacin pero uno o ms procesos permanecen bloqueados fuera del recurso, se denomina Aplazamiento Indefinido. Este fenmeno tambin es conocido como Bloqueo Activo, y los procesos afectados se dicen que son Postergados. Para evitar bloqueos activos algunas implementaciones de semforos obligan a aplicar una disciplina de servicio entre los procesos en espera. La eleccin de una disciplina de servicio es muy importante ya que una disciplina sesgada puede posibilitar que un grupo de procesos conspire contra otros y usurpe permanentemente el recurso. La postergacin de procesos puede evitarse aadiendo el siguiente requisito a la implementacin de semforo ..: Una peticin para entrar a la seccin critica debe ser concedida en tiempo finito. Dada la suposicin de que cada proceso tarda un tiempo finito en ejecutar la seccin critica, este requisito puede sastifacerse utilizando la disciplina FIFO (First Input First Output - Primero en entrar... Primero en Salir) para elegir entre los procesos en espera. Este mtodo garantiza la entrada a la seccin crtica en tiempo finito, como tambin es conocido como Implementacin Estricta de Semforos. Implementacin de Semforos con Colas. (Segun William Stallings, 2002) La implementacin de los semforos con espera activa tienen dos importantes desventajas .: el potencial aplazamiento indefinido y la baja eficiencia debido al consumo de ciclos de procesador por parte de procesos bloqueados. Aunque un proceso bloqueado no experimenta ningn proceso real, no obstante continua consumiendo recursos del sistema a causa de la espera activa. Tanto el bloqueo activo como la ineficaz espera activa pueden verse aliviados por la implementacin de semforos con cola. Un proceso suspendido no consume ciclos de procesador, de modo que este mtodo es potencialmente ms eficiente que el de la espera activa.

[24]

2.4.2.2 Mecanismos de Monitores.

(Como comenta F. Vallejo, 2001) Los monitores son estructuras de datos utilizadas en lenguajes de programacin para sincronizar dos o ms procesos o hilos de ejecucin que usan recursos compartidos. En el estudio y uso de los semforos se puede ver que las llamadas a las funciones necesarias para utilizarlos quedan repartidas en el cdigo del programa, haciendo difcil corregir errores y asegurar el buen funcionamiento de los algoritmos. Para evitar estos inconvenientes se desarrollaron los monitores. El concepto de monitor fue definido por primera vez por Charles Antony Richard en un artculo del ao 1974. La estructura de los monitores se ha implementado en varios lenguajes de programacin, incluido Pascal concurrente, Modula-2, Modula-3 y Java, y como biblioteca de programas. Componentes : Un monitor tiene cuatro componentes: inicializacin, datos privados, procedimientos del monitor y cola de entrada. Inicializacin: contiene el cdigo a ser ejecutado cuando el monitor es creado

Datos privados: contiene los procedimientos privados, que slo pueden ser usados desde dentro del monitor y no son visibles desde fuera

Procedimientos del monitor: son los procedimientos que pueden ser llamados desde fuera del monitor.

Cola de entrada: contiene a los threads que han llamado a algn procedimiento del monitor pero no han podido adquirir permiso para ejecutarlos an.

Exclusin mutua en un monitor. (Como comenta F. Vallejo, 2001) Los monitores estn pensados para ser usados en entornos multiproceso o multihilo, y por lo tanto muchos procesos o threads pueden llamar a la vez a un [25]

procedimiento del monitor. Los monitores garantizan que en cualquier momento, a lo sumo un thread puede estar ejecutando dentro de un monitor. Ejecutar dentro de un monitor significa que slo un thread estar en estado de ejecucin mientras dura la llamada a un procedimiento del monitor. El problema de que dos threads ejecuten un mismo procedimiento dentro del monitor es que se pueden dar condiciones de carrera, perjudicando el resultado de los clculos. Para evitar esto y garantizar la integridad de los datos privados, el monitor hace cumplir la exclusin mutua implcitamente, de modo que slo un procedimiento est siendo ejecutado a la vez. De esta forma, si un thread llama a un procedimiento mientras otro thread est dentro del monitor, se bloquear y esperar en la cola de entrada hasta que el monitor quede nuevamente libre. Aunque se la llama cola de entrada, no debera suponerse ninguna poltica de encolado. Tipos de monitores. Antes se dijo que una llamada a la funcin cond_signal con una variable de condicin haca que un proceso que estaba esperando por esa condicin reanudara su ejecucin. Ntese que el thread que reanuda su ejecucin necesitar obtener nuevamente el lock del monitor. Cualquier solucin debe garantizar la exclusin mutua. Segn quin contina con la ejecucin, se diferencian dos tipos de monitores: Hoare y Mesa. Tipo Hoare.

En la definicin original de Hoare, el thread que ejecuta cond_signal le cede el monitor al thread que esperaba. El monitor toma entonces el lock y se lo entrega al thread durmiente, que reanuda la ejecucin. Ms tarde cuando el monitor quede libre nuevamente el thread que cedi el lock volver a ejecutar.

[26]

Aqu tenemos ventajas y desventajas del hoare. VENTAJAS DESVENTAJAS

El thread que reanuda la ejecucin puede Si el proceso que ejecuta cond_signal no hacerlo inmediatamente sin fijarse si la termin con su ejecucin se necesitarn dos condicin se cumple, porque desde que se cambios de contexto para que vuelva a tomar ejecut cond_signal hasta que lleg su turno el lock del monitor. Al despertar a un thread de ejecutar ningn proceso puede cambiarla. que espera en una variable de condicin, se El thread despertado ya estaba esperando debe asegurar que reanude su ejecucin desde antes, por lo que podra suponerse que inmediatamente. De otra forma, algn otro es ms urgente ejecutarlo a seguir con el thread podra cambiar la condicin. Esto proceso despertante. implica que la planificacin debe ser muy fiable, y dificulta la implementacin.

Tipo mesa: Butler W. Lampson y David D. Redell en 1980 desarrollaron una definicin diferente de monitores para el lenguaje Mesa que lidia con las desventajas de los monitores de tipo Hoare y aade algunas caractersticas. En los monitores de Lampson y Redell el thread que ejecuta cond_signal sobre una variable de condicin contina con su ejecucin dentro del monitor. Si hay otro thread esperando en esa variable de condicin, se lo despierta y deja como listo. Podr intentar entrar el monitor cuando ste quede libre, aunque puede suceder que otro thread logre entrar antes. Este nuevo thread puede cambiar la condicin por la cual el primer thread estaba durmiendo. Cuando reanude la ejecucin el durmiente, [27]

debera verificar que la condicin efectivamente es la que necesita para seguir ejecutando. En el proceso que durmi, por lo tanto, es necesario cambiar la instruccin if por while, para que al despertar compruebe nuevamente la condicin, y de no ser cierta vuelva a llamar a cond_wait. Adems de las dos primitivas cond_wait(c) y cond_signal(c), los monitores de Lampson y Redell poseen la funcin cond_broadcast(c), que notifica a los threads que estn esperando en la variable de condicin c y los pone en estado listo. Al entrar al monitor, cada thread verificar la condicin por la que estaban detenidos, al igual que antes. Los monitores del tipo Mesa son menos propensos a errores, ya que un thread podra hacer una llamada incorrecta a cond_signal o a cond_broadcast sin afectar al thread en espera, que verificar la condicin y seguir durmiendo si no fuera la esperada. Tipos De Monitores. Monitor tipo monitor. Este monitor fue implementado en Pascal

Concurrente, lenguaje desarrollado por Per Brinch Hansen. Es el monitor ms simple de todos pues solo tiene tres estados y las funciones internas son muy sencillas. Una caracterstica distintiva de este monitor es que el proceso que reinicia a otros debe salir del monitor, es decir abandona el estado activo. Monitor tipo manager. Este monitor es muy similar al monitor tipo monitor, la diferencia esencial es que un proceso que es reiniciado debe abandonar el monitor, es decir no se le permite que entre al estado activo.

[28]

Monitor tipo mediador Este monitor fue propuesto por C.A.R. Hoare, tiene la caracterstica de compensar las desventajas de los monitores tipo monitor y tipo managEer. Un proceso que reinicia a otros puede permanecer dentro del monitor y un proceso reiniciado tambin puede permanecer dentro del monitor.

Monitor tipo gladiador. Este monitor propuesto por Cavers y Brown tiene la caracterstica fundamental de solo tener un punto de consistencia interno (un punto de consistencia interno ocurre cuando el proceso que est activo abandona este estado y sigue dentro del monitor).

[29]

2.4.3 Interbloqueo DeadLock.

El interbloqueo puede definirse formalmente como sigue: Un conjunto de procesos est en interbloqueo si cada proceso del conjunto est esperando un evento que slo otro proceso del conjunto puede causar. Puesto que todos los procesos estn esperando, ninguno de ellos puede causar ninguno de los eventos que podran despertar a cualquiera de los dems miembros del conjunto, y todos los procesos continan esperando indefinidamente. Tipos de recursos Reutilizables: Un recurso reutilizable es aqul que puede ser usado con seguridad por un proceso y no se agota con el uso. Los procesos obtienen unidades de recursos que liberan posteriormente para que otros procesos las reutilicen. Como ejemplos de recursos reutilizables se tienen los procesadores, canales de E/S, memoria principal y secundaria, dispositivos y estructuras de datos tales como archivos, bases de datos y semforos. Consumibles: Un recurso consumible es aqul que puede ser creado (producido) y destruido (consumido).

Coffman (1971) demostr que deben cumplirse cuatro condiciones para que haya un bloqueo mutuo: Condicin de exclusin mutua. Cada recurso est asignado nicamente a un solo proceso o est disponible.

Condicin de retener y esperar. Los procesos que actualmente tienen recursos que les fueron otorgados previamente pueden solicitar nuevos recursos. Condicin de no expropiacin. No es posible quitarle por la fuerza a un proceso los recursos que le fueron otorgados previamente. El proceso que los tiene debe liberarlos explcitamente. Condicin de espera circular. Debe haber una cadena circular de dos o ms procesos, cada uno de los cuales est esperando un recurso retenido por el siguiente miembro de la cadena.

[30]

Deben estar presentes estas cuatro condiciones para que ocurra un bloqueo mutuo. Si una o ms de estas condiciones estn ausentes, no puede haber bloqueo mutuo. Prevencin La estrategia de prevencin del interbloqueo consiste, a grandes rasgos, en disear un sistema de manera que est excluida, a priori, la posibilidad de interbloqueo. Los mtodos para prevenir el interbloqueo son de dos tipos. Los mtodos indirectos consisten en impedir la aparicin de alguna de las tres condiciones necesarias, antes mencionadas (condiciones 1 a 3). Los mtodos directos consisten en evitar la aparicin del crculo vicioso de espera (condicin 4). Retencin y Espera. La condicin de retencin y espera puede prevenirse exigiendo que todos los procesos soliciten todos los recursos que necesiten a un mismo tiempo y bloqueando el proceso hasta que todos los recursos puedan concederse simultneamente. Esta solucin resulta ineficiente por dos factores. En primer lugar, un proceso puede estar suspendido durante mucho tiempo, esperando que se concedan todas sus solicitudes de recursos, cuando de hecho podra haber avanzado con slo algunos de los recursos.

[31]

2.4.3.1 Prevencin Interbloqueo DeadLock.

Los bloqueos mutuos pueden ser evitados si se sabe cierta informacin sobre los procesos antes de la asignacin de recursos. Para cada peticin de recursos, el sistema controla si satisfaciendo el pedido entra en un estado inseguro, donde puede producirse un bloqueo mutuo. Existen varios algoritmos para evitar bloqueos mutuos: Algoritmo del banquero, introducido por Dijkstra. Algoritmo de grafo de asignacin de recursos Algoritmo de Seguridad. Algoritmo de solicitud de recursos. Prevencin Los bloqueos mutuos pueden prevenirse asegurando que no suceda alguna de las condiciones necesarias vistas anteriormente. Eliminando la exclusin mutua: ningn proceso puede tener acceso exclusivo a un recurso. Esto es imposible para procesos que no pueden ser encolados (puestos en un spool), e incluso con colas tambin pueden ocurrir interbloqueos. La condicin de retencin y espera puede ser eliminada haciendo que los procesos pidan todos los recursos que van a necesitar antes de empezar. Este conocimiento por adelantado muchas veces es imposible nuevamente. Otra forma es requerir a los procesos liberar todos sus recursos antes de pedir todos los recursos que necesitan.

[32]

2.4.3.2 Deteccin Interbloqueo DeadLock.

Las estrategias de prevencin del interbloqueo son muy conservadoras; solucionan el problema del interbloqueo limitando el acceso a los recursos e imponiendo restricciones a los procesos. En el lado opuesto, las estrategias de deteccin del interbloqueo no limitan el acceso a los recursos ni restringen las acciones de los procesos. Una vez detectado el interbloqueo, hace falta alguna estrategia de recuperacin. Las tcnicas siguientes son posibles enfoques, enumeradas en orden creciente de sofisticacin: Abandonar todos los procesos bloqueados. Esta es, se crea o no, una de las soluciones ms comunes, si no la ms comn, de las adoptadas en un sistema operativo.

Retroceder cada proceso interbloqueado hasta algn punto de control definido previamente y volver a ejecutar todos los procesos. Es necesario que haya disponibles unos mecanismos de retroceso y reinicio en el sistema. El riesgo de esta solucin radica en que puede repetirse el interbloqueo original. Abandonar sucesivamente los procesos bloqueados hasta que deje de haber interbloqueo. El orden en el que se seleccionan los procesos a abandonar seguir un criterio de mnimo costo. Apropiarse de recursos sucesivamente hasta que deje de haber interbloqueo. Para los puntos 3 y 4, el criterio de seleccin podra ser uno de los siguientes, consistentes en escoger el proceso con: Algunas de estas cantidades son ms fciles de medir que otras. El tiempo restante estimado deja lugar a dudas, especialmente. Adems, aparte de las medidas de prioridad, no existe otra indicacin del coste para el usuario frente al coste para el sistema en conjunto.

[33]

2.4.3.3 Recuperacin Interbloqueo DeadLock.

Una vez que se ha detectado el interbloqueo se debe romper para que los recursos puedan finalizar su ejecucin y liberar as los recursos. Para ruptura de la espera se pueden realizar varias opciones. Las idnea sera suspendiendo algunos de los procesos bloqueados para tomar sus recursos y reanudar sus ejecucin una vez que se hubiera deshecho el interbloqueo. Esta solucin solo puede resultar factible en casos muy particulares; no se podra suspender a un proceso de escribir de escribir en una impresora para pasarla a otro proceso y reanudar despus la impresin, como tampoco se podra suspender indefinidamente un proceso de tiempo real. Para aplicar la primera de las opciones se deben tener en cuenta una serie de factores con el fin de elegir aquellos procesos cuya reiniciacin resulte menos traumtica. Entre los factores a tener en cuenta en cada proceso se tienen: La prioridad del proceso.

El tiempo de procesamiento utilizado y el que le resta. El tipoy nmero de recursos que posee. El nmero de recursos que necesita para finalizar. El procedimiento de la segunda opcin consiste en ir expropiando recursos de algunos procesos de forma sucesiva hasta que se consiga salir del interbloqueo. La eleccin de los recursos que se expropian se basa en criterios similares a los expuestos en la reiniciacin de los procesos.

[34]

2.5 Niveles, Objetivos y Criterios de Planificacin.

En pocas pasadas de los sistemas de procesamiento por lotes, con una entrada en forma de imgenes de tarjetas en una cinta magntica, el algoritmo de planificacin era sencillo: solo haba que ejecutar el siguiente trabajo en la cinta. En los sistemas de multiusuario de tiempo compartido, que se combinaban con un fondo de trabajos procesados en lote, el algoritmo era ms complejo. En forma invariable, existan varios usuarios en espera de servicio y podan existir tambin otros trabajos para ser procesados en lote. Incluso en los sistemas puros de tiempo compartido existen con frecuencia los trabajos colaterales, como el sistema de correo electrnico, que a menudo se ejecuta todo el tiempo para enviar o recibir correo o noticias.

Cuando ms de un proceso es ejecutable, el Sistema Operativo debe decidir cul de ellos deber ejecutarse primero. Hay que tener una planificacin de los procesos que quieren ejecutarse en el sistema. La planificacin es una funcin primordial del Sistema Operativo. La mayora de los recursos, si no es que todos, se planifican antes de que se utilicen. La asignacin de procesadores fsicos a los procesos hace posible que estos realicen su trabajo, y tal asignacin es un problema complejo manejado por el Sistema Operativo.

Concepto de Planificacin.
La planificacin hace referencia a un conjunto de polticas y mecanismos incorporados al sistema operativo que gobiernan el orden en que se ejecutan los trabajos que deben ser cumplimentados por el sistema informtico.

[35]

Objetivo de la Planificacin.
El objetivo principal de la planificacin es optimizar el rendimiento del sistema y proporcionar un buen servicio a todos los procesos que se encuentren en l. En general, la planificacin trata de cubrir los siguientes objetivos: Justicia. La planificacin debe ser lo ms justa posible con todos los procesos, sin favorecer a unos y perjudicar a otros. Mxima capacidad de ejecucin. Debe dar un servicio eficiente para que todos los trabajos se realicen lo ms rpidamente posible. Esto se puede lograr disminuyendo el nmero de cambios de proceso. Mximo nmero de usuarios interactivos. En los sistemas de tiempo compartido se tratara de que puedan estar trabajando el mayor nmero de usuarios al mismo tiempo. Predecibilidad. La planificacin debe realizarse de tal forma que en todo momento pueda saberse como ser su ejecucin. Minimizacin de la sobrecarga. La computadora debe tener poca sobrecarga ya que esta afecta directamente al rendimiento final del sistema: a menor sobrecarga mayor velocidad de proceso. Equilibrio en el uso de recursos. Para obtener un mayor rendimiento en el uso de los recursos y que estos estn ocupados equitativamente el mayor tiempo posible. Seguridad de las prioridades. Si un proceso tiene mayor prioridad que otro, este debe ejecutarse ms rpidamente. Evitar la postergacin indefinida. Esto se logra aumentando la prioridad de un proceso mientras espere por un recurso. La prioridad llegara a ser tan alta que al proceso le ser asignado el recurso que pidi. [36]

Criterios de planificacin.
Para realizar los objetivos de la planificacin, un mecanismo de planificacin debe considerar lo siguiente:

La limitacin de un proceso a las operaciones de Entrada / Salida: Cuando un proceso consigue la CPU, ?la utiliza solo brevemente antes de generar una peticin de Entrada / Salida? La limitacin de un proceso a la CPU: Cuando un proceso obtiene la CPU, ?tiende a usarla hasta que expira su tiempo? Si un proceso es por lote (batch) o interactivo: los usuarios interactivos deben recibir inmediato servicio para garantizar buenos tiempos de respuesta. Qu urgencia tiene una respuesta rpida?: Por ejemplo, un proceso de tiempo real de un sistema de control que supervise una refinera de combustible requiere una respuesta rpida, ms rpida que la respuesta requerida por un proceso en lotes (batch) que deber entregarse al dia siguiente. La prioridad de un proceso: A mayor prioridad mejor tratamiento. Frecuentemente un proceso genera fallos (carencias) de pgina: Probablemente los procesos que generan pocos fallos de pgina hayan acumulado sus conjuntos de trabajo en el almacenamiento principal. Los procesos que experimentan gran cantidad de fallos de pgina an no han establecido sus conjuntos de trabajo.

[37]

Un criterio indica favorecer a los procesos que han establecido sus conjuntos de trabajo. Otro criterio indica favorecer a los procesos con una tasa alta de fallos de pgina ya que rpidamente generaran una peticin de Entrada / Salida. Frecuentemente un proceso ha sido apropiado por otro de ms alta prioridad, lo cual significa lo siguiente: A menudo los procesos apropiados deben recibir un tratamiento menos favorable.

Cada vez que el Sistema Operativo asume la sobrecarga para hacer ejecutar este proceso, el corto tiempo de ejecucin antes de la apropiacin no justifica la sobrecarga de hacer ejecutar al proceso en primer lugar. Cuanto tiempo de ejecucin real ha recibido el proceso?: Un criterio considera que debe ser favorecido un proceso que ha recibido muy poco tiempo de CPU. Cunto tiempo adicional va a necesitar el proceso para terminar?: Los tiempos promedio de espera pueden reducirse priorizando los procesos que requieren de un tiempo de ejecucin mnimo para su terminacin, pero pocas veces es posible conocer la cantidad de tiempo adicional que cada proceso necesita para terminar. En pocas pasadas de los sistemas de procesamiento por lotes, con una entrada planificacin era sencillo: solo haba que ejecutar el siguiente trabajo en la cinta. En los sistemas de multiusuario de tiempo compartido, que se combinaban con un fondo de trabajos procesados en lote, el algoritmo era ms complejo. En forma invariable, existan varios usuarios en espera de servicio y podan existir tambin otros trabajos para ser procesados en lote. Incluso en los sistemas puros de tiempo compartido existen con frecuencia los trabajos colaterales, como el sistema de correo electrnico, que a menudo se ejecuta todo el tiempo para enviar o recibir correo o noticias. Cuando ms de un proceso es ejecutable, el Sistema Operativo debe decidir cul de ellos deber ejecutarse primero. Hay que tener una planificacin de los procesos que quieren ejecutarse en el sistema. La planificacin es una funcin primordial del Sistema Operativo. La mayora de los recursos, si [38]

no es que todos, se planifican antes de que se utilicen. La asignacin de procesadores fsicos a los procesos hace posible que estos realicen su trabajo, y tal asignacin es un problema complejo manejado por el Sistema Operativo. En forma de imgenes de tarjetas en una cinta magntica.

[39]

2.6 Tcnicas de Administracin del Planificador.

Se denomina planificador al software del sistema operativo encargado de asignar los recursos de un sistema entre los procesos que los solicitan. Siempre que haya tomar una decisin, el planificador debe decidir cul de los procesos que compiten por la posesin de un determinado recursos lo recibir. El planificador es un componente funcional muy importante de los sistemas operativos multitarea y multiproceso y es esencial en los sistemas operativos de tiempo real. Su funcin consiste en repartir el tiempo disponible de un microprocesador entre todos los procesos para su ejecucin. Todo sistema operativo gestiona los programas mediante el concepto de proceso. En un instante dado, en el ordenador pueden existir diversos procesos listos para ser ejecutados. Sin embargo, solamente uno de ellos puede ser ejecutado (en cada microprocesador). De ah la necesidad de que una parte del sistema operativo gestione, de una manera equitativa, qu proceso debe ejecutarse en cada momento. La planificacin (scheduling) es la base para lograrla multiprogramacin. Un sistema multiprogramado tendr varios procesos que requerirn el recurso procesador a la vez. Esto sucede cuando los procesos estn en estado ready (pronto). Si existe un procesador disponible y existen procesos en estado ready, se debe elegir el que ser asignado al recurso para ejecutar. El componente del sistema operativo que realiza la eleccin del proceso es llamada planificador (scheduler).

[40]

2.6.1 FIFO.
FIFO: First In First Out Mecanismo de scheduling en el cual los procesos se ordenan en una fila, en la cual se ejecutan cada uno de los procesos hasta su finalizacion secuencialmente. Es tremendamente ineficiente. Cuando se tiene que elegir a qu proceso asignar la CPU se escoge al que llevara ms tiempo listo. El proceso se mantiene en la CPU hasta que se bloquea voluntariamente. Para implementar el algoritmo slo se necesita mantener una cola con los procesos listos ordenada por tiempo de llegada. Cuando un proceso pasa de bloqueado a listo se sita el ltimo de la cola. Algoritmo de planificacin de FIFO. Tal vez la disciplina ms simple de planificacin sea la de primeras entradas, primeras salidas (PEPS). Los procesos se despachan de acuerdo con su tiempo de llegada a la cola de procesos listos. Cuando un proceso tiene la CPU, se ejecuta hasta terminar. Es junto en el sentido formal, pero algo injusta en cuanto a que los trabajos largos hacen esperar a los cortos y los trabajos sin importancia hacen esperar a los importantes. FIFO ofrece variaciones relativamente pequeas en los tiempos de respuesta y por lo tanto es ms predecible que los otros esquemas. No es til en la planificacin para los usuarios interactivos porque no puede garantizar buenos tiempos de respuesta. El esquema FIFO rara vez se usa como esquema principal en los sistemas actuales, pero a menudo est incorporado en otros sistemas. Por ejemplo, muchos esquemas de planificacin despachan los procesos de acuerdo con la prioridad, pero los procesos con la misma prioridad se despachan de acuerdo con el esquema FIFO. Este es un algoritmo que no usa apropiacin, y que consiste en atender a los procesos por estricto orden de llegada a la lista de procesos listos. Cada proceso se ejecuta hasta que termina, o hasta que hace una llamada bloqueante (de E/S). Se trata de una poltica muy simple y sencilla de llevar a la prctica, pero muy pobre en cuanto a su comportamiento. Las caractersticas principales de este algoritmo son las siguientes: No es apropiativa. [41]

 Es justa, aunque los procesos largos hacen esperar mucho a los cortos. Es una poltica predecible. El tiempo promedio de servicio es muy variable ya que est en funcin del nmero de procesos y la duracin promedio que tenga.

[42]

2.6.2 Planificacin SJF.

Shortest-job-First (Trabajo ms corto Primero), este algoritmo asocia con cada proceso la duracin de la siguiente rfaga de CPU del proceso. Cuando el CPU est disponible, se asigna al proceso que tiene la siguiente rfaga de CPU ms corta. Cuando las siguientes rfagas de CPU de dos procesos son iguales, se usa la planificacin FCFS para romper el empate. Un trmino ms apropiado sera el de algoritmo de la siguiente rfaga de CPU ms corta, ya que la planificacin depende de la duracin de la siguiente rfaga de CPU, en lugar de depender de la duracin total. Como ejemplo de planificacin SFJ, tenemos el siguiente conjunto de procesos, estando especificada la duracin de la rfaga de CPU en milisegundos:

Usando la planificacin SJF, planificaramos estos procesos de acuerdo al siguiente diagrama de Gantt:

El tiempo de espera es de 3 milisegundos para el proceso P1, de 16 milisegundos para el proceso P2, de 9 milisegundos para el proceso P3 y de 0 milisegundos para el proceso P4. Por tanto, el tiempo medio de espera es de (3+16+9+0)/4 = 7 milisegundos. Por comparacin, si estuviramos usando el esquema de planificacin FCFS, el tiempo de espera seria de 10.25 milisegundos El algoritmo de planificacin SJF es probablemente ptimo, ya que proporciona el tiempo medio de espera mnimo para un conjunto de procesos. Al anteponer un proceso corto a uno largo disminuye el tiempo de espera del proceso corto en mayor medida de lo que incrementa el tiempo de espera del proceso largo. Por esto, el tiempo medio de espera disminuye. La dificultad del algoritmo SJF es conocer la duracin de la siguiente solicitud de CPU. En una planificacin a largo plazo en un sistema de procesamiento por lotes, podemos usar una duracin el

[43]

lmite del tiempo del proceso que el usuario especifique en el momento de enviar el trabajo. La planificacin SJF se usa frecuentemente como mecanismo de planificacin a largo plazo. Aunque el algoritmo SJF es optimo, no se puede implementar en el nivel de planificacin del CPU a corto plazo, ya que no hay forma de conocer la duracin de la siguiente rfaga de CPU. Un mtodo consiste en intentar aproximar la planificacin SJF: podemos no conocer la duracin de la siguiente rfaga de CPU, pero podemos predecir su valor, por el procedimiento de confiar en que la siguiente rfaga de CPU sea similar en duracin a las anteriores. De esta manera, calculando una aproximacin de la duracin de la siguiente rfaga de CPU, podemos tomar el proceso que tenga la rfaga de CPU predicha ms corta. La siguiente rfaga de CPU se predice como una media exponencial de las duraciones medias anteriores. Sea tn la duracin de la n-sima rfaga de CPU y sea n+1 el valor predicho rapa la siguiente rfaga de CPU. Entonces, para , 01, se define: n+1 = tn + (1 - )tn Esta frmula define un promedio exponencial. El valor de tn contiene la informacin ms reciente; n almacena el historial pasado. El parmetro controla el peso relativo del historial reciente y pasado de nuestra prediccin. Si =0, entonces n+1 = n, y el historial reciente no tiene ningn efecto; si =1, entonces n+1 = n y solo la rfaga de CPU mas reciente importa. Frecuentemente, =1/2, el historial reciente y pasado tienen el mismo peso. El valor inicial 0 puede definirse como una constante o como un promedio global para todo el sistema. La siguiente figura muestra el promedio exponencial como =1/2 y 0 = 10.

[44]

2.6.3 RR.
Cada proceso tiene asignado un intervalo de tiempo de ejecucin, llamado cuantum o cuanto. Si el proceso agota su cuantum de tiempo, se elige a otro proceso para ocupar la CPU. Si el proceso se bloquea o termina antes de agotar su cuantum tambin se alterna el uso de la CPU. El round robin es muy fcil de implementar. Todo lo que necesita el planificador es mantener una lista de los procesos listos.

[45]

2.6.4 Queves Multi-level.

Otra clase de algoritmos de planificacin es la que se ha desarrollado para aquellas situaciones en las que los procesos pueden clasificarse fcilmente en grupos diferentes. Por ejemplo, una clasificacin habitual consiste en diferenciar entre procesos de primer plano (interactivos) y procesos de segundo plano (por lotes). Estos dos tipos de procesos tienen requisitos diferentes de tiempo de respuesta y, por tanto, pueden tener distintas necesidades de planificacin. Adems, los procesos de primer plano pueden tener prioridad (definida externamente) sobre los procesos de segundo plano. Un algoritmo de planificacin mediante colas multinivel divide la cola de procesos preparados en varias colas distintas. Los procesos se asignan permanentemente a una cola, generalmente en funcin de alguna propiedad del proceso, como por ejemplo el tamao memoria, la prioridad del proceso o el tipo de proceso. Cada cola tiene su propio algoritmo de planificacin. Por ejemplo, pueden emplearse colas distintas para los procesos de primer plano y de segundo plano. La cola de primer plano puede planificarse mediante un algoritmo por turnos, mientras que para la cola de segundo plano puede emplearse un algoritmo FCFS. Adems, debe definirse una planificacin entre las colas, la cual suele implementarse como una planificacin apropiada y prioridad fija. Por ejemplo, la cola de procesos de primer plano puede tener velocidad absoluta sobre la cola de procesos de segundo plano. Veamos un ejemplo de algoritmo de planificacin mediante colas multinivel con las cinco colas que se enumeran a continuacin, segn su orden de prioridad: Procesos del sistema. Procesos interactivos. Procesos de edicin interactivos. Procesos por lotes. Procesos de estudiantes. Cada cola tiene prioridad absoluta sobre las colas de prioridad ms baja. Por ejemplo, ningn proceso de la cola por lotes podr ejecutarse hasta que se hayan vaciado completamente las colas de los procesos del sistema, los procesos interactivos y los procesos de edicin interactivos. Si un proceso de [46]

edicin interactivo llega a la cola de procesos preparados mientras se est ejecutando un proceso por lotes, el proceso por lotes ser desalojado. Otra posibilidad consiste en repartir el tiempo entre las colas. En este caso, cada cola obtiene una cierta porcin del tiempo de CPU, con la que puede entonces planificar sus distintos procesos Por ejemplo, en el caso de la colas de procesos de primer plano y segundo plano, la cola de primer plano puede disponer del 80 por ciento del tiempo de CPU para planificar por turnos sus procesos, mientras que la cola de procesos de segundo plano recibe el 20 por ciento del tiempo de CPU para gestionar sus procesos mediante el mtodo FCFS.

[47]

2.6.5 Multi-level Feedback Queves.

Normalmente, cuando se usa el algoritmo de planificacin mediante colas multinivel, los procesos se asignan de forma permanente a una cola cuando entran en el sistema. Por ejemplo, si hay colas diferentes para los procesos de primer y segundo plano, los procesos no se mueven de una cola a otra, dado que no pueden cambiar su naturaleza de proceso de primer o segundo plano. Esta configuracin presenta la ventaja de una baja carga de trabajo de planificacin, pero resulta poco flexible. Por el contrario, el algoritmo de planificacin mediante colas multinivel realimentadas permite mover un proceso de una cola a otra. La idea es separar los procesos en funcin de las caractersticas de sus rfagas de CPU. Si un proceso utiliza demasiado tiempo de CPU, se pasa a una a d prioridad ms baja. Este esquema deja los procesos limitados por E/S y los procesos interactivos en las colas de prioridad ms alta. Adems, un proceso que est esperando demasiado tiempo en una cola de baja prioridad puede pasarse a una cola de prioridad ms alta. Este mecanismo de envejecimiento evita el bloqueo indefinido. Por ejemplo, considere un planificador de colas multinivel realimentadas con tres colas, numeradas de 0 a 2 (Figura 5.7). En primer lugar, el planificador ejecuta todos los procesos de la cola 0. Solo cuando la cola 0 este vaca ejecutara procesos de la cola 1. De forma similar, los procesos de la cola 2 solo se ejecutaran si las colas 0 y 1 estn vacas. Un proceso que llegue a la cola 1 desalojara a un proceso de la cola 2 y ese proceso de la cola 1 ser, a su vez, desalojado por un proceso que llegue a la cola 0. Un proceso que entre en la cola de procesos preparados se coloca en la cola 0 y a cada uno de los procesos de esa cola se le proporciona un cuanto de tiempo de 8 milisegundos. Si el proceso no termina en ese tiempo, se pasa al final de la cola 1. Si la cola 0 esta vaca, al proceso que se encuentra al principio de la cola 1 se le asigna un cuanto de 16 milisegundos. Si no se completa en ese tiempo, se lo desaloja y se lo incluye en la cola 2. Los procesos de la cola 2 se ejecutan basndose en una planificacin FCFS, pero solo cuando las colas 0 y 1 estn vacas. Este algoritmo de planificacin proporciona la prioridad ms alta a todo proceso que tenga una rfaga de CPU de 8 milisegundos o menos. Tales procesos acceden rpidamente a la CPU, concluyen su rfaga de CPU y pasan a su siguiente rfaga de E/S. Los procesos que necesitan ms de 8 milisegundos y menos de 24 milisegundos tambin son servidor rpidamente, aunque con una prioridad ms baja que [48]

los procesos ms cortos. Los procesos largos terminan yendo automticamente a la cola 2 y se sirven, siguiendo el orden FCFS, con los ciclos de CPU no utilizados por las colas 0 y 1. En general, un planificador mediante colas multinivel realimentadas se define mediante los parmetros siguientes: El nmero de colas. El algoritmo de planificacin de cada cola. El mtodo usado para determinar cundo pasar un proceso a una cola de prioridad ms alta. El mtodo usado para determinar cundo pasar un proceso a una cola de prioridad ms baja. El mtodo usado para determinar en qu cola se introducir un proceso cuando haya que darle servicio. La definicin del planificador mediante colas multinivel realimentadas le convierte en el algoritmo de planificacin de la CPU ms general. Puede configurarse este algoritmo para adaptarlo a cualquier sistema especfico que se quiera disear. Lamentablemente, tambin es el algoritmo ms complejo, puesto que definir el mejor planificador requiere disponer de algn mecanismo para seleccionar los valores de todos los parmetros.

[49]

Conclusin.
Con esto llegamos al final del desarrollo de investigacin de esta unidad, los conocimientos obtenidos nos estn ayudando a comprender ms a fondo la funcionabilidad del sistema operativo. Estamos comprendiendo tambin algunas funciones especficas de los procesos y la forma en que estas se presentan, en cada uno de los diferentes comportamientos de la mquina. Al igual hemos aprendido que gran parte de las funciones del sistema operativo se llevan a cabo a travs de las comunicaciones y estas comunicaciones a travs de procesos. La importancia jerarqua que los procesos le otorgan a las diferentes actividades y la forma en que esta las administra para que se lleven a cabo las tareas. Y con esto llegamos al final de la investigacin de esta unidad esperamos ampliar ms nuestro conocimientos en el transcurso de las siguientes unidades.

[50]

Bibliografa.

http://administraciondeprocesos-naranjo.blogspot.mx/2008/10/241-exclusin-mutua-de-seccionescrticas.html sistemasoperativos.angelfire.com/html/2.4.3.html sistemasoperativos.angelfire.com/html/2.4.3.html http://administraciondeprocesos-barrueta.blogspot.mx/2008/10/2432-deteccin-deinterbloqueos.html http://administraciondeprocesos-barrueta.blogspot.mx/2008/10/2433-recuperacin-deinterbloqueo.html Sistemas Operativo, 2 Ed, Prentice Hall, Madrid, 1997. Sistemas operativos, diseo e implementacin 2da edicin - Andrew S. Tanenbaum & Albert S. Wood Hull. Sistemas operativos - 5ta edicin - Abraham Silbers chatz & Peter Baer Galvin.

[51]