2.1.- CONCEPTO DE PROCESO.

Un proceso no es mas que un programa en ejecucin, e incluye los valores actuales del contador de programa, los registros y las variables. Conceptualmente cada unos de estos procesos tiene su propia CPU virtual. Desde luego, en la realidad la verdadera CPU conmuta de un proceso a otro. Un proceso es un concepto manejado por el sistema operativo que consiste en el conjunto formado por: Las instrucciones de un programa destinadas a ser ejecutadas por el microprocesador. Su estado de ejecucin en un momento dado, esto es, los valores de los registros de la CPU para dicho programa. Su memoria de trabajo, es decir, la memoria que ha reservado y sus contenidos. Otra informacin que permite al sistema operativo su planificacin. Esta definicin vara ligeramente en el caso de sistemas operativos multihilo, donde un proceso consta de uno o ms hilos, la memoria de trabajo (compartida por todos los hilos) y la informacin de planificacin. Cada hilo consta de instrucciones y estado de ejecucin. Los procesos son creados y destruidos por el sistema operativo, as como tambin este se debe hacer cargo de la comunicacin entre procesos, pero lo hace a peticin de otros procesos. El mecanismo por el cual un proceso crea otro proceso se denomina bifurcacin (fork). Los nuevos procesos pueden ser independientes y no compartir el espacio de memoria con el proceso que los ha creado o ser creados en el mismo espacio de memoria. En los sistemas operativos multihilo es posible crear tanto hilos como procesos. La diferencia estriba en que un proceso solamente puede crear hilos para s mismo y en que dichos hilos comparten toda la memoria reservada para el proceso. En este modelo: todo software ejecutable de la computadora, lo que a menudo incluye al sistema operativo, esta organizado en una serie del proceso secuenciales, o simplemente procesos. la idea clava 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 cuando debe de trabajar en un proceso para atender a uno distinto. Jerarquas 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. En otros sistemas operativos existen llamadas al sistema para crear un proceso, cargar su memoria y ponerlo en ejecutar. Sea cual sea la naturaleza exacta de la llamada al sistema. Los procesos necesitan poder crear otros procesos. En MINIX, los procesos se crean con la llamada al 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 proceso.

2.2.- ESTADOS Y TRANSICIONES DE LOS PROCESOS.

El principal trabajo del procesador es ejecutar las instrucciones de mquina que se encuentran en memoria principal. Estas instrucciones se encuentran en forma de programas. Para que un programa pueda ser ejecutado, el sistema operativo crea un nuevo proceso, y el procesador ejecuta una tras otra las instrucciones del mismo. En un entorno de multiprogramacin, el procesador intercalar la ejecucin de instrucciones de varios programas que se encuentran en memoria. El sistema operativo es el responsable de determinar las pautas de intercalado y asignacin de recursos a cada proceso. Aunque cada proceso se una entidad independiente, con su propio contador de programa y estado interno, los procesos a menudo necesitan interactuar con otros procesos. Un proceso podra generar ciertas salidas que otro proceso utilizan como entradas, en el comando de Shell. Cuando un proceso se bloquea, lo que hace porque le es imposible continuar lgicamente, casi siempre porque esta separando entradas que todava no estn disponibles, tambin puede ser que un programa que conceptualmente esta listo y en condiciones de ejecutarse sea detenido porque el sistema operativo ha decidido asignar la CPU a otro proceso durante un tiempo. Estas dos condiciones son totalmente distintas, en el primer caso, la suspensin es inherente al problema (no es posible procesar la lnea de comandos del usuarios antes de que este la teclee). En el segundo caso, se trata de un tecnicismo del sistema (no hay suficiente: CPU para darle a cada proceso su propio procesador privado).

1.- Ejecutndose (usando realmente la CPU en este instante).

2.- Listo (se puede ejecutar, pero se suspendi temporalmente para dejar que otro proceso se ejecute).

3.- Bloqueo (no puede ejecutarse en tanto no ocurra algn evento externo).

Puede haber cuanto transiciones entre estos tres estados, como se muestra.

La transaccin 1 ocurre cuando un proceso descubre que no puede continuar. En algunos sistemas el proceso debe ejecutar una llamada al sistema, block, para pasar al estado bloqueado. En otros sistemas, incluido MINIX, cuando un proceso lee de un conducto o de un archivo especial, (p.ej., una terminal) y no hay entradas disponibles, se bloquea automticamente. Las transiciones 2 y 3 son causadas por el planificador de procesos, un parte del sistema operativo , sin que el proceso se entere siquiera de ellas.

La transicin 2 ocurre cuando el planificador decide que el proceso en ejecucin ya se ejecuto durante suficiente tiempo y es ahora de dejar que otros procesos tengan algo de tiempo de CPU.

La transaccin 3 ocurre cuando todos los dems procesos han disfrutado de una porcin justa y es hora de que el primer proceso reciba otra vez la CPU para ejecutarse.

La transaccin 4 ocurre cuando acontece el suceso externo que un proceso estaba esperando (como la llegada de entrada). Sin ningn otro proceso se esta ejecutando en ese instante, se dispara de inmediato la transaccin 3 y el proceso comienza a ejecutarse.

En caso contrario, el proceso tal vez tenga que esperar en el estado listo durante cierto tiempo hasta que la CPU este disponible. Usando el modelo de procesos, es mucho mas fcil visualizar lo que esta sucediendo dentro del sistema. [1]

2.3 PROCESOS LIGEROS (HILOS O HEBRAS)

El concepto de proceso engloba dos conceptos separados y potencialmente independientes: uno relativo a la propiedad de recursos y otro que hace referencia a la ejecucin. Unidad que posee recursos: A un proceso se le asigna un espacio de memoria y, de tanto en tanto, se le puede asignar otros recursos como dispositivos de E/S o ficheros. Unidad a la que se le asigna el procesador: Un proceso es un flujo de ejecucin (una traza) a travs de uno o ms programas. Esta ejecucin se entremezcla con la de otros procesos. De tal forma, que un proceso tiene un estado (en ejecucin, listo, etc) y una prioridad de expedicin u origen. La unidad planificada y expedida por el sistema operativo es el proceso. En la mayora de los sistemas operativos, estas dos caractersticas son, de hecho, la esencia de un proceso. Sin embargo, son independientes, y pueden ser tratadas como tales por el sistema operativo. Esta distincin ha conducido en los sistemas operativos actuales a desarrollar la construccin conocida como thread, cuyas traducciones ms frecuentes son hilo, hebra y proceso ligero. Si se tiene esta divisin de caractersticas, la unidad de asignacin de la CPU se conoce como hilo, mientras que a la unidad que posee recursos se le llama proceso. Dentro de un proceso puede haber uno o ms hilos de control cada uno con: Un estado de ejecucin (en ejecucin, listo, bloqueado). Un contexto de procesador, que se salva cuando no est ejecutndose. Una pila de ejecucin. Algn almacenamiento esttico para variables locales. Acceso a la memoria y a los recursos de ese trabajo que comparte con los otros hilos. Los beneficios clave de los hilos se derivan de las implicaciones del rendimiento: se tarda menos tiempo en crear un nuevo hilo de un proceso que ya existe, en terminarlo, y en hacer un cambio de contexto entre hilos de un mismo proceso.

Al someter a un mismo proceso a varios flujos de ejecucin se mantiene una nica copia en memoria del cdigo, y no varias. Un ejemplo de aplicacin que podra hacer uso de los hilos es un servidor de ficheros de una red de rea local. Cada vez que llega una solicitud de una operacin sobre un fichero, se puede generar un nuevo hilo para su gestin. El servidor gestiona multitud de solicitudes, por tanto, se pueden crear y destruir muchos hilos en poco tiempo para dar servicio a estas peticiones. Si el servidor es un multiprocesador, se pueden ejecutar varios hilos de un mismo proceso simultneamente y en diferentes procesadores.[1]

Un proceso ligero (thread o hebra) es un programa en ejecucin que comparte la imagen de la memoria y otras informaciones con otros procesos ligeros.

Figura 1 Procesos ligeros

Es una unidad bsica de utilizacin de la CPU consistente en un juego de registros y un espacio de pila. Comparte el cdigo, los datos y los recursos con sus hebras pares

Una tarea (o proceso pesado) est formada ahora por una o ms hebras

Una hebra slo puede pertenecer a una tarea

Figura 2 Tareas con una y varias hebras

CARACTERISTICAS

Se comparten recursos. La comparticin de la memoria permite a las hebras pares comunicarse sin usar ningn mecanismo de comunicacin inter-proceso del SO.

La conmutacin de contexto es ms rpida gracias al extenso compartir de recursos

No hay proteccin entre las hebras. Una hebra puede escribir en la pila de otra hebra del mismo proceso

Estado de los procesos ligeros

Un proceso ligero puede estar ejecutando, listo o bloqueado. Figura 3 Estados de los Procesos ligeros

Paralelismo Los procesos ligeros permiten paralelizar una aplicacin.[2]

Figura 4 Paralelismo

2.4 CONCURRENCIA Y SECUENCIABILIDAD.

La concurrencia comprende un gran nmero de cuestiones de diseo, incluyendo la comunicacin entre procesos, comparicin y competencia por los recursos, sincronizacin de la ejecucin de varios procesos y asignacin del tiempo de procesador a los procesos y es fundamental para que existan diseos como Multiprogramacin, Multiproceso y Proceso distribuido Los procesos son concurrentes si existen simultneamente. 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 La concurrencia puede presentarse en tres contextos diferentes: Varias aplicaciones: La multiprogramacin se cre para permitir que el tiempo de procesador de la mquina fuese compartido dinmicamente entre varios trabajos o aplicaciones activas.

 Aplicaciones estructuradas: Como ampliacin 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. Existen tres modelos de computadora en los que se pueden ejecutar procesos concurrentes: Multiprogramacin con un nico procesador. El sistema operativo se encarga de ir repartiendo el tiempo del procesador entre los distintos procesos, intercalando la ejecucin de los mismos para dar as una apariencia de ejecucin simultnea. Multiprocesador. Es una maquina formada por un conjunto de procesadores que comparten memoria principal. En este tipo de arquitecturas, los procesos concurrentes no slo pueden intercalar su ejecucin sino tambin superponerla. Multicomputadora. Es una maquina de memoria distribuida, que est formada por una serie de computadoras. En este tipo de arquitecturas tambin es posible la ejecucin simultnea de los procesos sobre los diferentes procesadores. En general, la concurrencia ser aparente siempre que el nmero de procesos sea mayor que el de procesadores disponibles, es decir, cuando haya ms de un proceso por procesador. La concurrencia ser real cuando haya un proceso por procesador. Aunque puede parecer que la intercalacin y la superposicin de la ejecucin de procesos presentan formas de ejecucin distintas, se ver que ambas pueden contemplase como ejemplos de procesos concurrentes Existen diversas razones que motivan la ejecucin de procesos concurrentes en un sistema: Facilita la programacin de aplicaciones al permitir que stas se estructuren como un conjunto de procesos que cooperan entre s para alcanzar un objetivo comn. Acelera los clculos. Si se quiere que una tarea se ejecute con mayor rapidez, lo que se puede hacer es dividirla en procesos, cada uno de los cuales se ejecuta en paralelo con los dems. Posibilita el uso interactivo a mltiples usuarios que trabajan de forma simultnea. Permite un mejor aprovechamiento de los recursos, en especial de la CPU, ya que pueden aprovechar las fases de entrada-salida de unos procesos para realizar las fases de procesamiento de otros.

As como existen las razones que motivan la ejecucin de procesos concurrentes, tambin existen sus contras: Inanicin e interrupcin de procesos Ocurrencia de bloqueos Que dos o ms procesos requieran el mismo recurso (No apropiativo) Tipos de procesos concurrentes. Los procesos que ejecutan de forma concurrente en un sistema se pueden clasificar como: Proceso independiente: Es aquel que ejecuta sin requerir la ayuda o cooperacin de otros procesos. Un claro ejemplo de procesos independientes son los diferentes shells que se ejecutan de forma simultnea en un sistema. Procesos son cooperantes: Son aquellos que estn diseados para trabajar conjuntamente en alguna actividad, para lo que deben ser capaces de comunicarse e interactuar entre ellos. En ambos tipos de procesos (independientes y cooperantes), puede producirse una serie de interacciones entre ellos y pueden ser de dos tipos: Interacciones motivadas porque los procesos comparten o compiten por el acceso a recursos fsicos o lgicos. Por ejemplo, dos procesos independientes compiten por el acceso a disco o para modificar una base de datos. Interaccin motivada porque los procesos se comunican y sincronizan entre s para alcanzar un objetivo comn, Por ejemplo, un compilador que tiene varios procesos que trabajan conjuntamente para obtener un solo archivo de salida.

Elementos a gestionar y disear a causa de la concurrencia. Se pueden enumerar los siguientes: 1. El sistema operativo debe ser capaz de seguir la pista de los distintos procesos activos. Esto lo hace por medio de PBCs (Bloque de Control de Procesos)2. El sistema operativo debe asignar y quitar los distintos recursos a cada proceso activo. Entre estos recursos se incluyen:

Tiempo de procesador: Es funcin de la planificacin. Memoria: La mayora de los sistemas operativos emplean esquemas de memoria virtual.

 Archivos: Dispositivos de E/S:

3. El sistema operativo debe proteger los datos y los recursos fsicos de cada proceso contra injerencias no intencionadas de otros procesos. 4. Los resultados de un proceso deben ser independientes de la velocidad relativa a la que se realiza la ejecucin con respecto a otros procesos concurrentes.[1]

2.4.1 EXCLUSIN MUTUA DE SECCIONES CRTICAS.

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.[1] Los algoritmos de exclusin mutua (comnmente abreviada como mutex por mutual exclusion) 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. 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 multioperacin 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. [2]

Regin Crtica. Protocolo de sincronizacin.

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:

1. 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.

2. 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).

3. 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.

4. 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.

5. 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.

6. 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.[3]

2.5 NIVELES, OBJETIVOS Y CRITERIOS DE PLANIFICACIN

Niveles de Planificacin La planificacin es el proceso por el cual el sistema operativo selecciona que proceso ejecutar. La seleccin del proceso se basa en alguno de los algoritmos de planificacin. La planificacin de la CPU, en el sentido de conmutarla entre los distintos procesos, es una de las funciones del sistema operativo. Este despacho es llevado a cabo por un pequeo programa llamado planificador a corto plazo o dispatcher (despachador). La misin del dispatcher consiste en asignar la CPU a uno de los procesos ejecutables del sistema, para ello sigue un determinado algoritmo. Los acontecimientos que pueden provocar la llamada al dispatcher dependen del sistema (son un subconjunto de las interrupciones), pero son alguno de estos: El proceso en ejecucin acaba su ejecucin o no puede seguir ejecutndose (por una E/S, operacin WAIT, etc). Un elemento del sistema operativo ordena el bloqueo del proceso en ejecucin

El proceso en ejecucin agota su cuantum o cuanto de estancia en la CPU. Un proceso pasa a estado listo. Hay que destacar el hecho de que cuanto menos se llame al dispatcher menos tiempo ocupa la CPU un programa del sistema operativo, y, por tanto, se dedica ms tiempo a los procesos del usuario (un cambio de proceso lleva bastante tiempo). As, si slo se activa el dispatcher como consecuencia de los 2 primeros acontecimientos se estar haciendo un buen uso del procesador. Este criterio es acertado en sistemas por lotes en los que los programas no son interactivos. Sin embargo, en un sistema de tiempo compartido no es adecuado, pues un proceso que se dedicara a realizar clculos, y no realizara E/S, monopolizara el uso de la CPU. En estos sistemas hay que tener en cuenta el conjunto de todos los procesos, activndose el dispatcher con la circunstancia tercera y, posiblemente, la cuarta. Los sistema operativos en que las dos siguientes circunstancias no provocan la activacin del dispatcher muestran preferencia por el proceso en ejecucin, si no ocurre esto se tiene ms en cuenta el conjunto de todos los procesos.

Se puede definir el scheduling -algunas veces traducido como -planificacincomo el conjunto de polticas y mecanismos construidos dentro del sistema operativo que gobiernan la forma de conseguir que los procesos a ejecutar lleguen a ejecutarse. El scheduling est asociado a las cuestiones de: Cundo introducir un nuevo proceso en el Sistema. Determinar el orden de ejecucin de los procesos del sistema. El scheduling est muy relacionado con la gestin de los recursos. Existen tres niveles de scheduling, como se ilustra en la figura 1.1, estos niveles son: Planificador de la CPU o a corto plazo. Planificador a medio plazo. Planificador a largo plazo.

En la planificacin de procesos se suelen incluir varios niveles, en funcin del periodo temporal que cubren: - Planificacin a largo plazo

Este planificador est presente en algunos sistemas que admiten adems de procesos interactivos trabajos por lotes. Usualmente, se les asigna una prioridad baja a los trabajos por lotes, utilizndose estos para mantener ocupados a los recursos del sistema durante perodos de baja actividad de los procesos interactivos. Normalmente, los trabajos por lotes realizan tareas rutinarias como el clculo de nminas; en este tipo de tareas el programador puede estimar su gasto en recursos, indicndoselo al sistema. Esto facilita el funcionamiento del planificador a largo plazo. El objetivo primordial del planificador a largo plazo es el de dar al planificador de la CPU una mezcla equilibrada de trabajos, tales como los limitados por la CPU (utilizan mucho la CPU) o la E/S. As, por ejemplo, cuando la utilizacin de la CPU es baja, el planificador puede admitir ms trabajos para aumentar el nmero de procesos listos y, con ello, la probabilidad de tener algn trabajo til en espera de que se le asigne la CPU. A la inversa, cuando la utilizacin de la CPU llega a ser alta, y el tiempo de respuesta comienza a reflejarlo, el planificador a largo plazo puede optar por reducir la frecuencia de admisin de trabajos. Normalmente, se invoca al planificador a largo plazo siempre que un proceso termina. La frecuencia de invocacin depende, pues, de la carga del sistema, pero generalmente es mucho menor que la de los otros dos planificadores. Esta baja frecuencia de uso hace que este planificador pueda permitirse utilizar algoritmos complejos, basados en las estimaciones de los nuevos trabajos. - Planificacin a Medio Plazo En los sistemas de multiprogramacin y tiempo compartido varios procesos residen en la memoria principal. El tamao limitado de sta hace que el nmero de procesos que residen en ella sea finito. Puede ocurrir que todos los procesos en memoria estn bloqueados, desperdicindose as la CPU. En algunos sistemas se intercambian procesos enteros (swap) entre memoria principal y memoria secundaria (normalmente discos), con esto se aumenta el nmero de procesos, y, por tanto, la probabilidad de una mayor utilizacin de la CPU. El planificador a medio plazo es el encargado de regir las transiciones de procesos entre memoria principal y secundaria, acta intentando maximizar la utilizacin de los recursos. Por ejemplo, transfiriendo siempre a memoria secundaria procesos bloqueados, o transfiriendo a memoria principal procesos bloqueados nicamente por no tener memoria. - Planificacin a corto plazo.

Qu proceso ser el que se ejecutar en el procesador en el instante siguiente.

Figura 6 Niveles de planificacin

Expulsin denota si un proceso acapara el procesador cuando est ejecutndose. Existen sistemas con y sin expulsin:

a) Sin expulsin: un proceso conserva el uso del procesador mientras lo desee; es decir, mientras no solicite del SO un servicio que lo bloquee. Ventajas: minimiza tiempo de planificacin. Inconvenientes: un proceso podra monopolizar el uso del procesador.

b) Con expulsin: el SO puede desalojar a un proceso del uso del procesador (sin que el proceso lo haya solicitado). Ventaja: control sobre el tiempo de ejecucin de cada proceso. Inconveniente: gasto de tiempo.

Objetivos y Criterios de Planificacin

Los objetivos del planificador se resumen en:

a) Reparto equitativo del tiempo de procesador b) Eficiencia en el uso del procesador c) Menor tiempo de respuesta en uso interactivo d) Cumplir plazos de ejecucin de los sistemas de tiempo real

El principal objetivo de la planificacin a corto plazo es repartir el tiempo del procesador de forma que se optimicen algunos puntos del comportamiento del sistema. Generalmente se fija un conjunto de criterios con los que evaluar las diversas estrategias de planificacin. El criterio ms empleado establece dos clasificaciones. En primer lugar, se puede hacer una distincin entre los criterios orientados a los usuarios y los orientados al sistema. Los criterios orientados al usuario se refieren al comportamiento del sistema tal y como lo perciben los usuarios o los procesos. Uno de los parmetros es el tiempo de respuesta. El tiempo de respuesta es el periodo de tiempo transcurrido desde que se emite una solicitud hasta que la respuesta aparece en la salida. Sera conveniente disponer de una poltica de planificacin que ofrezca un buen servicio a diversos usuarios. Otros criterios estn orientados al sistema, esto es, se centran en el uso efectivo y eficiente del procesador. Un ejemplo puede ser la productividad, es decir, el ritmo con el que los procesos terminan. La productividad es una medida muy vlida del rendimiento de un sistema y que sera deseable maximizar. Otra forma de clasificacin es considerar los criterios relativos al rendimiento del sistema y los que no lo son. Los criterios relativos al rendimiento son cuantitativos y, en general, pueden evaluarse o ser analizados fcilmente. Algunos ejemplos son el tiempo de respuesta y la productividad. Los criterios no relativos al rendimiento son, en cambio cualitativos y no pueden ser evaluados fcilmente. Un ejemplo de estos criterios es la previsibilidad. Sera conveniente que el servicio ofrecido a los usuarios tenga las mismas

caractersticas en todo momento, independientemente de la existencia de otros trabajos ejecutados por el sistema. En particular, una disciplina de planificacin debe: Ser equitativa: debe intentar hacer una planificacin justa, esto es, se debe tratar a todos los procesos de la misma forma y no aplazar indefinidamente ningn proceso. La mejor forma de evitarlo es emplear alguna tcnica de envejecimiento; es decir, mientras un proceso espera un recurso, su prioridad debe crecer. Ser eficiente: debe maximizar el uso de los recursos tales como intentar que la ocupacin de la CPU sea mxima. Al mismo tiempo se debe intentar reducir el gasto extra por considerar que es trabajo no productivo. Normalmente el idear algoritmos eficientes supone invertir recursos en gestin del propio sistema. Lograr un tiempo bueno de respuesta, es decir, que los usuarios interactivos reciban respuesta en tiempos aceptables. Lograr un tiempo de proceso global predecible. Esto quiere decir que un proceso debe ejecutarse aproximadamente en el mismo tiempo y casi al mismo costo con independencia de la carga del sistema. Elevar al mximo la productividad o el rendimiento, esto es, maximizar el nmero de trabajos procesados por unidad de tiempo. Eso supone, por un lado, dar preferencia a los procesos que ocupan recursos decisivos y, por otro, favorecer a los procesos que muestran un comportamiento deseable. En el primer caso conseguimos liberar el recurso cuanto antes para que est disponible para un proceso de mayor prioridad. Con el segundo criterio escogemos a los procesos que no consumen muchos recursos dejndole al sistema mayor capacidad de actuacin. Estos criterios son dependientes entre s y es imposible optimizar todos de forma simultnea. Por ejemplo, obtener un buen tiempo de respuesta puede exigir un algoritmo de planificacin que alterne entre los procesos con frecuencia, lo que incrementa la sobrecarga del sistema y reduce la productividad. Por tanto, en el diseo de una poltica de planificacin entran en juego compromisos entre requisitos opuestos; el peso relativo que reciben los distintos requisitos depender de la naturaleza y empleo del sistema.[1]

2.6 TCNICAS ADMINISTRACIN DEL PLANIFICADOR

Las disciplinas de planificacin pueden ser: Expropiativas No expropiativas 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. Los algoritmos (tcnicas) tienen distintas propiedades segn los criterios en los que se basen para su construccin, lo cual se refleja en qu tipo de procesos se puede ver favorecido frente a otro en la disputa del procesador. Antes de realizar la eleccin de un algoritmo se debe considerar las propiedades de estos frente al criterio de diseo elegido. Algunos de estos son: a) Eficacia: Se expresa como un porcentaje del tiempo medio de utilizacin. Aunque puede parecer lgico intentar mantener este parmetro prximo al 100%, con un valor tan elevado otros aspectos importante de medida del comportamiento del sistema pueden verse deteriorados, como por ejemplo el tiempo medio de espera. b) Rendimiento: Es una medida del numero de procesos completados por unidad de tiempo. Por ejemplo 10 procesos por segundo. c) Tiempo de retorno o regreso: Es el intervalo de tiempo que transcurre desde que un proceso se crea o presenta hasta que completa por el sistema. d) Tiempo de espera: Es el tiempo que el proceso espera hasta que se le concede el procesador. Puede resultar una medida mas adecuada de la eficiencia del sistema, ya que se elimina de la media el tiempo que tarda en ejecutarse el mismo. e) Tiempo de respuesta a un evento: Se denomina as el intervalo de tiempo que transcurre desde que se seala un evento hasta que se ejecuta la primera

instruccin de la rutina de servicio de dicho evento. El criterio de seleccin de un algoritmo se suele basar en la maximizacin o minimizacin de una funcin de los parmetros anteriores.