PROCESO

Un proceso es un programa en ejecucin. Esta definicin vara ligeramente en el caso de sistemas operativos multihilo, donde un proceso consta de uno o ms hilos (threads), de memoria de trabajo, es decir, la memoria que ha reservado y sus contenidos (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. Hay dos tipos de procesos: los independientes que no afectan ni pueden ser afectados por otro proceso y los cooperativos que afectan y pueden ser afectados por algn otro proceso del sistema operativo.

COMUNICACION ENTRE PROCESOS (INTERPROCESS COMUNICATION).

Frecuentemente los procesos necesitan comunicarse con otros procesos. La comunicacin entre procesos o IPC es una funcin bsica del sistema operativo; provee un mecanismo que permite a los procesos comunicarse y sincronizarse entre si a travs de comparticiones de espacios de memoria ya sean variables compartidas o buffers por medio de las herramientas provistas por las rutinas de la IPC. Normalmente la IPC se efecta mediante un sistema de bajo nivel de paso de mensajes. Es importante sealar tres cuestiones: La primera; cmo puede un proceso pasar informacin a otro. La segunda consiste en asegurar que dos o ms procesos no se interfieran mientras realizar tareas crticas. La tercera cuestin tiene que ver con el secuencia correcta cuando exista dependencias es decir si el proceso B necesite datos de un proceso A tiene que esperarlo hasta que este lo produzca. Dos de estas tres cuestiones se aplican con los hilos siendo la primera y ultima; estos problemas tanto a los procesos como a los hilos se le aplican la misma solucin.

MEMORIA COMPARTIDA
En algunos sistemas operativos los procesos que trabajan juntos pueden compartir algn rea comn donde cada proceso puede leer y escribir. Situaciones como estas donde dos o mas procesos estn leyendo o escribiendo sobre datos compartidos y el resultado final depende de quien se ejecute precisamente en un momento dado se le conoce como condiciones de carrera. La memoria compartida puede estar en memoria principal o puede ser un fichero compartido; la ubicacin de la memoria compartida no afecta la comunicacin entre procesos o los problemas que puedan surgir en ellos. La parte del programa que accede a la memoria compartida se le llama regin o seccin crtica. Debemos asegurar que cuando un proceso esta utilizando memoria compartida ficheros o cualquier otra cosa este no lea ni escriba al mismo tiempo con otro(s) procesos. Dicho en otras palabras lo que necesitamos es exclusin mutua que los dems procesos estn excluidos o bloqueados de hacer uso del mismo dato compartido que un proceso esta utilizando. La eleccin de las operaciones para lograr la exclusin mutua es una de las principales cuestiones de diseo de cualquier sistema operativo. Para asegurar que los procesos concurrentes cooperen correcta y eficientemente utilizando datos compartidos; se debe cumplir cuatro condiciones para obtener una solucin satisfactoria: 1. Ningn par de procesos deben estar simultneamente dentro de sus regiones crticas.

2. No debe hacerse ninguna suposicin sobre la velocidad o nmeros de CPUs. 3. Ningn proceso fuera de la regin crtica puede bloquear a otros procesos. 4. Ningn proceso deber tener que esperar infinitamente para entrar a su regin critica.

Proceso A

Proceso B

La no habilitacin de interrupciones o inhibicin de interrupciones de procesos es a menudo una tcnica til dentro del propio sistema operativo; ya que cada proceso al entrar a su regin crtica deshabilita las interrupciones y las rehabilita nicamente al salir de ella; pero no es apropiada como un mecanismo de exclusin mutua general para los procesos de usuarios. Suponiendo que es un sistema multiprocesador es decir cuenta con dos o ms CPUs este deshabilitar nicamente a la CPU que ejecut la instruccin disable y los dems procesos podran perfectamente ejecutarse en las dems CPUs y acceder tambin a la memoria compartida. Intentado solucionar el problema que un proceso no entre en su regin crtica si otro lo esta ocupando se llevo a cabo varias tcnicas como las variables cerrojo que no es mas que una variable compartida (variable cerrojo) que si posee el valor 1 esta ocupado y 0 esta en espera. La alternancia estricta esta utiliza una variable entera turno indicando a quien le corresponde el turno de entrar en la regin crtica y examinar o actualizar la memoria compartida con el uso un bucle vaco comprobando continuamente a turno para ver cuando pasa a valer 1. La comprobacin continua de una variable hasta que contenga algn valor determinado se denomina espera activa y un cerrojo que utiliza espera activa se le conoce como un spin lock. La solucin de Peterson cambiando la idea de establecer turnos con la idea de utilizar variables cerrojo y variables de aviso no requiriendo alternancia estricta. La instruccin TSL (Test and Set Lock) la CPU que ejecuta la instruccin TSL bloquea el bus de memoria para prohibir al resto de las CPUs acceder a la memoria hasta que termine la instruccin; para utilizarla debemos utilizar una variable entera compartida lock, para coordinar el acceso a la memoria compartida. Tanto la solucin de Peterson como la instruccin TSL son correctas pero ambas tienen el defecto de requerir espera activa. En esencia lo que estas dos soluciones y prcticamente todas las anteriores hacen es lo siguiente: cuando un proceso quiere entrar en su regin crtica, comprueba si se le permite la entrada. Si no es as, el proceso se mete en un bucle vaco esperando hasta que s se le permita entrar estos mtodos no solo gastan tiempo de CPU sino que tambin sus efectos son impredecibles. Algunas primitivas de comunicacin entre procesos que bloquean a los procesos en vez de consumir tiempo de CPU cuando no se les permite entrar en sus regiones crticas ms simples es el par de llamadas Sleep y Wakeup Sleep es una llamada al sistema que provoca que el proceso que la invoque se bloquee esto es la suspensin de este hasta que otro proceso lo despierte. La llamada Wakeup que tiene un parmetro que es el proceso a ser despertado. Tanto Sleep como Wakeup podran tener ambas un parmetro una posicin de memoria utilizada para ajustarlos. E.W.Dijkstra (1965) sugiri utilizar una variable entera para contar el nmero de seales enviadas para despertar un proceso guardadas para su uso futuro. En su propuesta introdujo un nuevo tipo de variable, denominado semforo. El valor de un semforo puede ser 0, indicando que no se ha guardado ninguna seal, o algn valor positivo de acuerdo con el nmero de seales pendientes para despertar al proceso. Se establecen dos operaciones sobre los semforos, bajar (P) y subir (V) como las operaciones sleep y wakeup, respectivamente. La operacin bajar sobre un semforo comprueba si el valor es mayor que 0. Si lo es, simplemente decrementa el valor (es decir utiliza una de las seales guardadas). Si el valor es 0, el proceso procede a dormirse sin completar la operacin bajar por el momento. La comprobacin del valor del semforo, su modificacin y la posible accin de dormirse, se realizan como una nica accin atmica indivisible. Est garantizado que una vez que comienza una operacin sobre un semforo, ningn otro proceso puede acceder al semforo hasta que la operacin se completa o hasta que el proceso se bloquea. La operacin subir incrementa el valor del semforo al cual se aplica. Si uno o ms procesos estuviesen dormidos sobre ese semforo, incapaces de completar una anterior operacin de bajar, el sistema elige a uno de ellos de forma aleatoria y se le permite completar esa operacin bajar pendiente. Para hacer ms fcil escribir programas correctos, Hoare (1974) y Brinch Hansen (1975) propusieron una primitiva de sincronizacin de alto nivel denominada monitor. Un monitor es una coleccin de procedimientos, variables y estructuras de datos que estn todos agrupados juntos en un tipo especial de mdulo o paquete. Tienen una importante propiedad que los hace tiles para conseguir exclusin mutua: en cualquier instante solamente un proceso puede estar activo dentro del monitor. Los procesos pueden llamar a los procedimientos de un monitor siempre que quieran, pero no se les permite acceder directamente a las estructuras de datos internas del monitor desde procedimientos declarados fuera del monitor.

PASO DE MENSAJES
Este mtodo de comunicacin entre procesos utiliza dos primitivas, enviar y recibir, que igual que los semforos y de forma diferente a los monitores son llamadas al sistema en vez de construcciones del lenguaje de programacin. Pueden incluirse fcilmente en libreras de procedimientos, tales como

Enviar (destinatario, &mensaje) Recibir (remitente, &mensaje)

La primera llamada enva un mensaje a un destinatario dado y la segunda recibe un mensaje de un remitente dado (o de cualquiera, si al receptor no le importa el remitente). Si no est disponible ningn mensaje, el receptor puede bloquearse hasta que llegue uno. De forma alternativa, puede retornar inmediatamente indicando un cdigo de error. Los sistemas de paso de mensajes plantean numerosos problemas desafiantes y cuestiones de diseo que no se presentan con los semforos o los monitores, especialmente si los procesos que se comunican residen en mquinas diferentes conectadas por una red.

INTERBLOQUEOS (DEADLOCKS)
En un entorno de multiprogramacin varios procesos pueden competir por un nmero finito de recursos. Un procesos solicita recursos y, si los recursos no estn disponibles en ese momento, el proceso pasa al estado de espera. Es posible que algunas veces, un proceso en espera no pueda nunca cambiar de estado, porque los recursos que ha solicitado estn ocupados por otro proceso que a su vez est esperando de otros recursos. Cuando se produce una situacin como esta se dice que ha ocurrido un interbloqueo. En un interbloqueo, los procesos nunca terminan de ejecutarse y los recursos del sistema estn ocupados lo que impide que se inicie otro trabajo. En modo de operacin normal, un proceso puede emplear un recurso solo siguiendo esta secuencia: 1. Solicitud

2. Uso 3. Liberacin La solicitud y liberacin de los recursos son llamadas al sistema. CONDICIONES NECESARIAS PARA UN INTERBLOQUEO Para que se produzca un interbloqueo deben cumplirse las cuatro condiciones. Asegurando que un de estas cuatro no se cumplan podemos prevenir la aparicin de interbloqueos. o Exclusin mutua: Al menos un recurso debe estar en modo no compartido, es decir, solo un procesos puede usarlo cada vez. Si otro proceso solicita el recurso, el proceso solicitante tendr que esperar hasta que el recurso sea liberado. o Retencin y espera: Un proceso debe estar retenido al menos un recurso y esperando para adquirir otro recurso adicional que actualmente estn retenidos por otro proceso. o Sin desalojo: Los recursos no pueden ser desalojados, es decir un recurso solo puede ser liberado voluntariamente por el proceso que le retiene, despus de que dicho proceso haya completado su tarea. o Espera circular: Debe existir un conjunto de procesos en espera, tal que este proceso est esperando a un recurso retenido por P1, P1 est esperando a un recurso retenido por P2, ,Pn-1 est esperando a un recurso retenido por Pn, y Pn est esperando a un recurso retenido por P0. ESTRATEGIAS PARA RESOLVER INTERBLOQUEOS Podemos abordar el problema de los interbloqueos de las siguientes tres formas. Podemos emplear un protocolo para impedir o evitar los interbloqueos, asegurando que el sistema nunca entre en estado de interbloqueo. Podemos permitir que el sistema entre en estado interbloqueo, detectarlo y realizar una recuperacin. Podemos ignorar el problema y actuar como si nunca se produjeran interbloqueos en el sistema.

La tercera solucin es la que utilizan la mayora de los sistemas operativos. Para detectar los interbloqueos el sistema debe proporcionar: Un algoritmo que Examine el estado del sistema para determinar si se ha producido un interbloqueo. Un algoritmo para recuperarse del interbloqueo.

Cuando el algoritmo de deteccin determina que existe un interbloqueo, tenemos varias alternativas. Una posibilidad es informar al operador de que se ha producido un interbloqueo y dejar que lo trate de forma manual. Otra forma es dejar que el sistema sea el que haga la recuperacin del interbloqueo de forma automtica. Existen

dos opciones para romper un interbloqueo una de ellas consiste en interrumpir uno o ms procesos para romper la cadena de espera circular, La otra consiste en desalojar recursos de uno o ms de los procesos bloqueados.