Universidad Nacional del Nordeste

Facultad de Ciencias Exactas y Naturales y Agrimensura Ctedra: Sistemas Operativos Ao: 2013

Concurrencia-Interbloqueo e Inanicin

Grupo Nmero: 1 Integrantes: - Aguirre, Andrs Roberto LU: 28868 - Alegre, Oscar Adrin - LU: 41196 - Brull Valenzuela, Gloria Raquel - LU: 46143 - Cott Lpez, Mara de los ngeles LU: 45390 - Chichi, Carlos Lisandro- LU: 43597 - Garca, Edgardo Javier - LU: 44473 - Mndez, Vctor Vicente LU: 29267 - Risuk, Susana Beatriz - LU: 43721

INTRODUCCION

La administracin de los recursos es una de las principales tareas del sistema operativo. Muchos de los recursos nicamente pueden ser usados por un solo proceso a la vez, como es el caso de las impresoras o los dispositivos de cinta, tambin puede darse que un proceso puede requerir acceso exclusivo no slo a un recurso, sino a varios. En sistemas operativos en los que nicamente se ejecuta un proceso a la vez, el proceso simplemente toma todos los recursos que necesita. Sin embargo en un sistema con multiprogramacin, puede suceder que encontremos procesos que estn en espera de recursos ocupados por otros procesos y no cambian nunca de estado, porque los recursos que solicitan estn en poder de otros procesos tambin en espera. Esto se conoce como Interbloqueo (deadlock-abrazo mortal o bloqueo mutuo), es decir un conjunto de procesos est en interbloqueo cuando cada proceso del conjunto est esperando un evento (liberacin de un recurso) que solo puede generar otro proceso bloqueado del conjunto. En el presente trabajo estudiaremos la concurrencia examinando el interbloqueo y la inanicin. Analizaremos las condiciones y estrategias para tratar el interbloqueo, explicaremos conceptos tales como tipos recursos, estado seguro e inseguro de un sistema; algoritmo del avestruz y algoritmo del banquero. Por ltimo finalizaremos con una breve sntesis sobre sincronizacin y mecanismo de concurrencia de Unix y Windows.

PRINCIPIOS DEL INTERBLOQUEO

El interbloqueo se puede definir como el bloqueo permanente de un conjunto de procesos que compiten por los recursos del sistema o bien se comunican unos con otros. A diferencia de otros problemas de la gestin concurrente de procesos, no existe una solucin eficiente para el caso general. Todos los interbloqueos suponen necesidades contradictorias de recursos por parte de dos o ms procesos.

Ejemplo de interbloqueo Interbloqueo de trfico: Cuatro coches llegan aproximadamente en el mismo instante a un cruce de cuatro caminos. Los cuatro cuadrantes de la interseccin son los recursos compartidos sobre los que se demanda control; por tanto, si

los coches desean atravesar el cruce, las necesidades de recursos son las siguientes: -El coche que va hacia el norte necesita los cuadrantes 1 y 2. -El coche que va hacia el oeste necesita los cuadrantes 2 y 3. -El coche que va hacia el sur necesita los cuadrantes 3 y 4. -El coche que va hacia el este necesita los cuadrantes 4 y 1.

La norma ms habitual en la carretera es que un coche en un cruce de cuatro caminos debe ceder el paso al coche que est a su derecha. Esta norma funciona si solo hay dos o tres coches en el cruce. Por ejemplo, si solo llegan al cruce los coches del norte y del oeste, el coche del norte esperar hasta que el del oeste pase. Sin embargo, si los cuatro coches llegan al mismo tiempo cada uno se abstendr de entrar en el cruce, provocando interbloqueo. Si todos los coches ignoran las normas y entran (con cuidado) en el cruce, cada coche obtendr un recurso (un cuadrante) pero no podr continuar porque el segundo recurso que necesita ya ha sido invadido por otro coche. De nuevo, se tiene interbloqueo.

RECURSOS

Un sistema se compone de un nmero finito de recursos que se distribuyen entre varios tipos: - Fsicos: Ciclo de CPU, espacio en memoria, dispositivos de e/s (impresoras, unidades de cinta, etc.). -Lgicos: Ficheros, tablas del sistemas, semforos.

Por lo general, una computadora tiene distintos recursos que pueden ser otorgados. Algunos recursos podrn tener varias instancias idnticas, como es el caso de tres unidades de cinta. Si se tienen disponibles varias copias de un recurso, cualquiera de ellas se pude utilizar para satisfacer cualquier solicitud del recurso. Un recurso es cualquier cosa que solo puede ser utilizada por un nico proceso en un instante dado. Los recursos son de dos tipos: - Apropiables. -No apropiables. Un recurso apropiable es aquel que se puede tomar del proceso que lo posee sin efectos dainos. La memoria es un ejemplo de recurso apropiable. Por el contrario, un recurso no apropiable, es aquel que no se puede tomar de su poseedor activo sin provocar un fallo de clculo. Si un proceso comienza a imprimir una salida, se toma la impresora y se le da a otro proceso, el resultado ser una salida incomprensible. Las impresoras no son apropiables. Los interbloqueos se relacionan con los recursos no apropiables. Lo usual es que los bloqueos asociados a recursos apropiables se pueden resolver, mediante la reasignacin de recursos de un proceso a otro. La secuencia de eventos necesaria para utilizar un recurso es: -Solicitar el recurso -Utilizar el recurso -Liberar el recurso Si el recurso no est disponible cuando se le solicita, el proceso solicitante debe esperar. En algunos sistemas operativos, el proceso se bloquea de manera automtica al fallar una solicitud de un recurso y se despierta cuando dicho recurso est disponible. En otros sistemas la solicitud falla con un cdigo de error y el proceso solicitante debe esperar un poco e intentar de nuevo. Un proceso cuya solicitud de un recurso ha sido denegada entra por lo general en un ciclo, en el cual solicita el recurso, duerme e intenta de nuevo. Aunque este proceso no est bloqueado, para todos los efectos est como bloqueado, puesto que no puede hacer ninguna labor til. El interbloque se puede definir entonces de la siguiente forma: Un conjunto de procesos se encuentra en estado de interbloqueo cuando cada uno de ellos espera un suceso que solo puede originar otro proceso del mismo conjunto. En la mayora de los casos, el evento que espera cada proceso es la liberacin de cierto recurso que posee por el momento otro miembro del conjunto. En otras palabras, cada miembro del conjunto de procesos bloqueados espera un

recurso posedo por un proceso bloqueado. Ninguno de los procesos puede continuar su ejecucin, ni liberar recursos, y puede ser despertado.

Recursos reutilizables Un recurso reutilizable es aquel 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 los reutilicen. Ejemplo, los procesadores, canales E/S, memoria principal y secundaria, dispositivos y estructuras de datos tales como archivos, bases de datos y semforos. Como ejemplo de interbloqueo con recursos reutilizables, considrese dos procesos que compiten por el acceso exclusivo a un archivo D del disco y una unidad de cinta T. El interbloqueo se produce si cada proceso retiene un recurso y solicita el otro. Una posible estrategia para resolver stos interbloqueos es imponer restricciones en el diseo del sistema sobre el orden en el que se solicitan los recursos.

Recursos consumibles Un recurso consumible es aquel que puede ser creado (producido) y destruido (consumido). Normalmente, no hay lmite en el nmero de recursos consumibles de un tipo en particular. Un proceso productor que no est bloqueado puede liberar cualquier nmero de recursos consumibles. Como ejemplos de recursos consumibles estn las interrupciones, seales, mensajes e informacin en buffers de E/S. Como ejemplo de interbloqueo con recursos consumibles, considrese el siguiente par de procesos, en el que cada proceso intenta recibir un mensaje de otro y, despus, enviar un mensaje a otro. El interbloqueo se produce si el Recieve es bloqueante (por ejemplo, el proceso receptor est bloqueado hasta que recibe el mensaje). La causa del interbloqueo es un error de diseo. Estos errores pueden ser bastante sutiles y difciles de detectar. Un programa puede funcionar durante un periodo de tiempo considerable, incluso aos, antes de que el problema se manifieste. No hay ninguna estrategia sencilla y efectiva que pueda solucionar todas las clases de interbloqueo.

CONDICIONES PARA PRODUCIR INTERBLOQUEO

En la poltica del sistema operativo, deben darse tres condiciones para que pueda producirse un interbloqueo: 1) Condicin de exclusin mutua: Cada recurso est asignado a un nico proceso o est disponible. 2) Condicin de retencin y espera: Los procesos que tienen, en un momento dado, recursos asignados con anterioridad, pueden solicitar nuevos recursos. 3) Condicin sin expropiacin: Los recursos otorgados con anterioridad no pueden ser forzados a dejar un proceso. El proceso que los posee debe liberarlos en forma explcita. En la mayora de los casos, estas condiciones son bastantes necesarias. La exclusin mutua hace falta para asegurar la consistencia de resultados y la integridad de la base de datos. De forma similar, la apropiacin no se puede aplicar arbitrariamente y, cuando se encuentran involucrados recursos de datos, debe estar acompaada de un mecanismo de recuperacin y reanulacin, que devuelva un proceso y sus recursos a un estado previo adecuado. Puede no existir interbloqueo con solo estas tres condiciones. Para que se produzca interbloqueo, se necesita una cuarta condicin: 4) Condicin de espera circular (o crculo vicioso de espera): Debe existir una cadena circular de dos o ms procesos, cada uno de los cuales espera un recurso posedo por el siguiente miembro de la cadena.

Las tres primeras condiciones son necesarias, pero no suficientes, para que exista interbloqueo. La cuarta condicin es, en realidad, una consecuencia potencial de las tres primeras. Es decir, dado que se producen las tres primeras condiciones, puede ocurrir una secuencia de eventos que desemboque en un crculo vicioso de espera irresoluble. El crculo de espera de la condicin 4 es irresoluble porque se mantienen las tres primeras condiciones. Las cuatro condiciones en conjunto constituyen una condicin necesaria y suficiente para el interbloqueo.

ESTRATEGIAS Se utilizan cuatro estrategias para lidiar con los interbloqueos. 1) Slo ignorar el problema, "Algoritmo de la avestruz (Tal vez si usted lo ignora, l lo ignorar a usted). 2) Prevencin, al evitar estructuralmente una de las cuatro condiciones requeridas. 3) Evitarlos en forma dinmica mediante la asignacin cuidadosa de los recursos. 4) Deteccin y recuperacin. Dejar que ocurran los interbloqueos, detectarlos y tomar accin. Algoritmo del avestruz La avestruz, mete su cabeza en la arena y pretenda que no hay ningn problema. Aunque parezca sorprendente a priori, muchos sistemas operativos usan frecuentemente esta poltica. Es la estrategia ms sencilla es simplemente ignorar el problema (interbloqueo). A esta estrategia se la denomina algoritmo del avestruz (Ostrich): esconder la cabeza en la tierra y pretender que no existe problema alguno. La justificacin de este mtodo es que si el interbloqueo se presenta con una frecuencia baja en comparacin con los fallos del sistema por otras razones (errores en el sistema operativo, fallos en el hardware, etc.), no tiene sentido tomar medidas para evitar el problema a costa de reducir el rendimiento del sistema. Esta opcin no es tan descabellada si se tiene en cuenta, por un lado, las restricciones que limitan considerablemente el tratamiento general de los interbloqueos en un sistema real y, por otro, las consecuencias negativas que conllevan las tcnicas de tratamiento (como la baja utilizacin de los recursos o el coste de los algoritmos de tratamiento). Observe que ignorar el problema trae como consecuencia que, cuando se produce un interbloqueo, los procesos implicados seguirn indefinidamente bloqueados y, lo que puede ser ms grave todava, los recursos involucrados quedan permanentemente inutilizables. La decisin de adoptar esta solucin puede basarse en muchas justificaciones razonables: Que la frecuencia con que se producen interbloqueos en el sistema sea pequea en comparacin con la de otros errores (hardware, compiladores, etc.). Que un interbloqueo no tenga consecuencias demasiado graves sobre la instalacin y/o los usuarios. Que el coste de utilizar otras polticas resulte muy elevado en trminos de prdida de eficiencia. Que las soluciones adoptadas introduzcan restricciones insoportables para los usuarios.

En definitiva, se trata de evaluar el coste asociado a introducir un conjunto de tcnicas para actuar contra los interbloqueos (en trminos de sobrecoste en el diseo y la implementacin, prdida de rendimiento, restricciones que introducen), frente al coste de convivir con los interbloqueos (coste de las horas de trabajo perdidas, insatisfaccin de los usuarios). Si el primero se valora como superior al segundo, conviene aplicar el algoritmo del avestruz.

PREVENCION DEL INTERBLOQUEO

La estrategia de prevencin del interbloqueo consiste, en disear un sistema, de manera que se excluya la posibilidad del interbloqueo. El objetivo es conseguir que sea imposible la aparicin de situaciones de interbloqueo. Se pueden clasificar en dos mtodos: -mtodo indirecto: consiste en impedir la aparicin de las siguientes tres condiciones de interbloqueo es decir, la exclusin mutua, la retencin y espera y sin expropiacin. -mtodo directo: impide que se produzca una espera circular. A continuacin, se explican las tcnicas relacionas con las cuatro condiciones de interbloqueo. Exclusin Mutua: generalmente esta condicin no puede eliminarse. Si ningn recurso se asignara de manera exclusiva a un solo proceso, nunca tendramos interbloqueos. No obstante, es igual de claro que al permitir que dos procesos escriban en la impresora al mismo tiempo se producir un caos (ninguno terminara de producir su salida completa). Si el acceso a un recurso requiere exclusin mutua, el sistema operativo debe proporcionarlo. Algunos recursos, como los ficheros, pueden permitir mltiples accesos de lectura, pero nicamente un proceso puede escribir o grabar a la vez. Incluso en este caso, puede ocurrir un interbloqueo si ms de un proceso requiere de escritura. Sin embargo se aconseja evitar asignar un recurso cuando no sea absolutamente necesario para luego tratar de asegurar que la menor cantidad posible de procesos reclamen ese recurso. Retencin y espera: Si podemos evitar que los procesos que contienen recursos esperen por ms recursos, podemos eliminar los interbloqueos. Puede darse dos posibilidades: a) Que el proceso solicite todos los recursos necesarios antes de comenzar su ejecucin; de esta forma al proceso se le asignara lo que necesite y podr ejecutarse hasta completarse. Y si algn recurso est ocupado no se asignara nada y deber esperar.

b) El proceso solicita los recursos de forma incremental a lo largo de su ejecucin, pero libera todos los recursos retenidos si se encuentra con una negativa. Es una estrategia insuficiente porque: -existe una pobre utilizacin de recursos y una reduccin del nivel de concurrencia. -en primer lugar un proceso puede quedarse esperando mucho tiempo hasta que todas sus solicitudes de recursos puedan satisfacerse, cuando de hecho, podra haber continuado con solamente algunos de los recursos. -en segundo lugar los recursos asignados a un proceso pueden permanecer inutilizados durante un periodo de tiempo considerable, durante el cual se impide su uso a otros procesos. Otro problema es que un proceso puede no conocer por anticipado todos los recursos que requerir de hecho si lo supiera se podra usar el algoritmo del banquero. Hay tambin un problema practico muy utilizado en una aplicacin, que es el uso de una programacin modular a una estructura multihilo (permiten la ejecucin varias tareas en forma simultanea). La aplicacin necesitara ser consciente de todos los recursos que se solicitaran en todos los niveles o en todos los mdulos para hacer una solicitud simultnea. Sin expropiacin: es permitir que el sistema revoque la propiedad de ciertos recursos a los procesos bloqueados. Se puede producir de varias maneras, en primer lugar si a un proceso que mantiene varios recursos se le deniega una peticin posterior, ese proceso deber liberar sus recursos originales y si es necesario, los solicitara de nuevo junto con el recurso adicional. Alternativamente, si un proceso solicita un recurso que otro proceso mantiene actualmente, el sistema opertico puede expropiar al segundo proceso y obligarle a liberar sus recursos. Este ltimo esquema impedir el interbloqueo solo si no hay dos procesos que posean la misma prioridad. Esta estrategia es solo prctica cuando se aplica a recursos cuyo estado se puede salvar y restaurar ms tarde como es el caso de un procesador (registros de CPU, memoria). Espera circular: se puede eliminar de varias formas, una de ellas es tener una regla que diga que un proceso tiene derecho slo a un recurso en cualquier momento. Si necesita un segundo recurso, debe liberar el primero. Para un proceso que necesita copiar un enorme archivo de una cinta a una impresora, esta restriccin es inaceptable .Otra manera de evitar la espera circular es proporcionar una numeracin global de todos los recursos que defina un orden lineal entre los distintos tipos de recursos. Ahora la regla es sta: los procesos pueden solicitar recursos cada vez que quieran, pero todas las peticiones se deben realizar en orden numrico. Un proceso puede pedir primero una impresora y despus una unidad de cinta, pero tal vez no pueda pedir primero un trazador y despus una impresora.

Si a un proceso le han asignado recursos de tipo R, posteriormente puede pedir solo aquellos recursos cuyo tipo tenga un orden posterior al de R. Para comprobar que esta estrategia funciona correctamente, se puede asociar un ndice a cada tipo de recurso, de manera que el recurso Ri, precede al Rj, en la ordenacin si i < j. A continuacin, supngase que dos procesos A y B estn involucrados en un interbloqueo debido a que A ha adquirido Ri y solicitado Rj y B ha adquirido Rj y solicitado Ri. Esta condicin es imposible puesto que implica que i < j y j < i. Como ocurra en el caso de la retencin y espera, la prevencin de la espera circular puede ser ineficiente, ralentizando los procesos y denegando innecesariamente el acceso a un recurso.

(a)Recursos ordenados en forma numrica

(b) Un grfico de recursos

1. Fotocomponedora 2. Escner 3. Trazador 4. Unidad de cinta 5. Unidad de CD-RO Ventajas: _ No se pueden producir ciclo _ El respecto de los procesos a la ordenacin prescrita puede ser comprobada en tiempo de compilacin Desventajas: _ No se aprovechan adecuadamente los recursos: se adquieren en el orden prescrito y no se solicitan cuando realmente se necesitan.
Resumen de los mtodos expuestos

Condicin Exclusin Mutua Retencin y espera Sin expropiar Espera circula

Mtodo Poner todo en la cola de impresin Solicitar todos los recursos al principio Quitar recursos Ordenar los recursos en forma numrica

PREDICCION DEL INTERBLOQUEO

En la mayora de los sistemas informticos los recursos se solicitan a la vez y el sistema debe decidir si es seguro asignarle dicho recurso. La prediccin del interbloqueo permite la toma decisiones dinmicas basadas en el estado actual de asignacin de recursos, para asegurarse, de que nunca se alcance el punto del interbloqueo. De esta manera permite ms concurrencia que la prevencin. Los algoritmos de prediccin se basarn, por tanto, en evitar que el sistema cruce el punto de no retomo que conduce al interbloqueo. Para ello se necesitar conocer a priori las necesidades mximas de recursos que tiene cada programa(es decir las futuras solicitudes de recursos del proceso). A partir de esta informacin, se deber determinar si el estado del sistema en cada momento es seguro.

TECNICAS PARA PREDECIR EL INTERBLOQUEO

Existen dos tcnicas: 1) Denegacin de la iniciacin de un proceso: es decir no iniciar la ejecucin de un proceso si sus demandas podran llevar al interbloqueo Si tenemos un sistema: a) de n procesos: N= necesidades del proceso i con respecto al proceso j A= asignacin actual al proceso i con respecto al recurso j

b) de m recursos distintos: R= (R1, R2,.., Rm) cantidad total de cada recurso en el sistema D= (D1,.., Dm) cantidad total de cada recurso no asignada a ningn proceso La matriz de Necesidad provee la informacin que necesita el sistema, es decir contiene los requisitos mximos de cada proceso con respecto a cada recurso que necesitara para ejecutarse, estando una fila dedicada a cada proceso. Y la matriz de Asignacin nos da la informacin de la asignacin actual a cada proceso. Se cumplen las siguientes relaciones:

Rj = Dj +

Todos los recursos estn disponibles o asignados

Nij <= Rj para todo i, j Ningn proceso puede necesitar ms de la cantidad total de recursos existentes en el sistema. Aij <= Nij para todo i, j Ningn proceso tiene asignados ms recursos de cualquier tipo que sus necesidades originales de ese recurso La prediccin del interbloqueo rechazara un nuevo proceso si sus requisitos de recursos pudiesen conducir al interbloqueo. Entonces se inicia un nuevo proceso P n+1 solo si: Rj >= N (n+1) j + para todo j

Concluimos solo se puede iniciarse un proceso si se pueden satisfacer las necesidades mximas de todos los procesos actuales ms las del nuevo proceso. Por lo tanto esta estrategia no es ptima debido a que todos los procesos solicitaran sus necesidades mximas simultneamente. 2) No conceder una peticin adicional de recurso, por parte de un proceso, si esta asignacin podra provocar un interbloqueo en el sistema. Ejemplo algoritmo del banquero.

Algoritmo del banquero Es una forma de evitar el interbloqueo, fue propuesto por primera vez por Edsger Dijkstra. El funcionamiento de un banco: banquero(es el sistema operativo) presta dinero a sus clientes y cada cliente (proceso) tiene asignado un crdito mximo. El banquero tiene disponible una determinada cantidad de dinero (recurso) para prestar y confa en que no todos los clientes necesitaran su crdito mximo otorgado en forma inmediata, por ello reserva menos unidades (recursos) se las totales necesarias para dar servicio a los clientes. Los clientes van solicitando y devolviendo el dinero (libera recursos).El algoritmo controla las peticiones para que el sistema se mantenga en un estado seguro. O sea si todos los clientes solicitan su crdito mximo, al menos uno de ellos satisfara su peticin para luego devolver el dinero a la entidad, permitiendo servir a otros clientes. En el algoritmo del banquero se presenta los siguientes trminos: Los procesos pueden conservar recursos mientras piden y esperan recursos a dicionales. Los recursos no pueden arrebatarse a los procesos que los tienen. Los usuarios facilitan el trabajo al sistema pidiendo un solo recurso a la vez. El sistema puede satisfacer o rechazar una peticin. Si una peticin es rechazada, el usuario conserva los recursos que ya tenga a signados y espera un tiempo finito a que se satisfaga la peticin.

 El sistema slo satisface peticiones que llevan a estados seguro, si lo es concede la peticin sino se bloquea el proceso hasta que sea seguro conceder la peticin. Defectos del algoritmo: 1) requiere un nmero fijo de recursos asignables. 2) requiere una poblacin de usuarios constante. 3) requiere que el banquero satisfaga todas las peticiones en un tiempo finito. 4) requiere que los clientes salden (retornar) todos sus prstamos en un tiempo finito. 5) requiere que los usuarios declaren por anticipado sus necesidades mximas (recursos).

Se garantiza que todos los procesos actan de la siguiente manera en dos fases: 1. primero se obtiene todos los recursos necesarios para realizar una tarea, eso se realiza solamente si se puede obtener todos a la vez, 2. despus se realiza la tarea durante la cual posiblemente se liberan recursos que no son necesarias. Ejemplo: Asumimos que tengamos 3 procesos que actan con varios recursos. El sistema dispone de 12 recursos. Es decir, de los 12 recursos disponibles ya 10 estn ocupados. La nica forma que se puede proceder es dar el acceso a los restantes 2 recursos al proceso B. Cuando B haya terminado va a liberar sus 6 recursos que incluso pueden estar distribuidos entre A y C, as que ambos tambin pueden realizar su trabajo. Con un argumento de induccin se verifica fcilmente que nunca se llega a ningn bloqueo.

Proceso Recursos Reservados A 1 B 4 C 5 Suma 10

Recursos Pedidos 4 6 8 18

ESTADO DE UN SISTEMA

La idea bsica del estado de un sistema, es asignar recursos nicamente las peticiones que no conduzcan a estados propensos al interbloqueo. Para ello se debe examinar dinmicamente el estado de asignacin de recursos para asegurar que no se presente la condicin de espera circular y llegar a un estado seguro.
Grfico de asignacin de recursos

Definimos el estado del sistema, diciendo que refleja la asignacin actual de recursos a procesos, por tanto el estado consiste en; los dos vectores, Recursos y Disponibles, y las dos matrices, Necesidad y Asignacin, definidas anteriormente. Un estado es seguro si hay cierto orden de programacin en el que se puede ejecutar cada proceso hasta completarse, incluso aunque todos ellos solicitaran de manera repentina su nmero mximo de recursos. Un sistema est en un estado inseguro cuando existe la posibilidad de que ocurra un interbloqueo. En otras palabras para que un estado sea seguro tiene que haber un proceso cuyas necesidades mximas puedan satisfacerse, hipotticamente dicho proceso al terminar de ejecutarse devolvera todos sus recursos. Los recursos disponibles podran permitir que se satisficieran las necesidades mximas de al menos un proceso que terminara liberando sus recursos, lo que a su vez podra hacer que otro proceso obtuviera sus necesidades mximas. Repitiendo este proceso, se genera una secuencia de ejecucin de procesos tal que cada uno de ellos, pueda obtener sus necesidades mximas. Y si la secuencia incluye todos los procesos del sistema, el estado es seguro. La diferencia entre un estado seguro y un estado inseguro es, que desde un estado seguro, el sistema puede garantizar que todos los procesos terminarn; desde un estado inseguro, no se puede dar esa garanta.

Trayectoria de los recursos Analizamos el concepto de la seguridad grficamente y vemos un modelo con dos procesos y dos recursos (una impresora y un trazador). El eje horizontal representa el nmero de instrucciones ejecutadas por el proceso A y el eje vertical el nmero de instrucciones ejecutadas por el proceso B. En I1, A solicita una impresora; en I2 necesita un trazador. La impresora y el trazador se liberan en I3 y en I4, respectivamente. El proceso B necesita el trazador de I5 a I7 y la impresora de I6 a I8

u=ambos procesos terminaron

Cada punto en la figura representa un estado conjunto de los dos procesos. Al principio el estado est en p, en donde ninguno de los procesos ha ejecutado instrucciones. Si se decide ejecutar primero a A, llegamos al punto 1, en el que A ha ejecutado cierto nmero de instrucciones, pero B no ha ejecutado ninguna. En el punto q, la trayectoria se vuelve vertical, indicando que se opt por ejecutar a B. Con un solo procesador, todas las rutas deben ser horizontales o verticales (nunca diagonales). Cuando A cruza con la lnea I1en la ruta de r a s, solicita la impresora y se le otorga. Cuando B llega al punto t, solicita el trazador.

Analizamos las zonas sombreadas y vemos que la regin con las lneas que se inclinan de suroeste a noreste representa cuando ambos procesos tienen la impresora. La regla de exclusin mutua hace imposible entrar a esta regin. De manera similar, la regin sombreada de la otra forma representa cuando ambos procesos tienen el trazador, y es igual de imposible. Si el sistema entra alguna vez al cuadro delimitado por I1e I2 en los lados, y por I5 e I6 en la parte superior e inferior, entrar en interbloqueo en un momento dado, cuando llegue a la interseccin de I2 e I6. En este punto, A est solicitando el trazador y B la impresora, y ambos recursos ya estn asignados. Todo el cuadro es inseguro y no se debe entrar en l. En el punto t, lo nico seguro por hacer es ejecutar el proceso A hasta que llegue a I4. Ms all de eso, cualquier trayectoria hasta u bastar. Finalmente observamos y concluimos que en el punto t, B est solicitando un recurso y el sistema debe decidir si lo otorga o no. Si se le otorga el recurso, el sistema entrar en una regin insegura y en el interbloqueo, en un momento dado. Para evitar el interbloqueo, B se debe suspender hasta que A haya solicitado y liberado el trazador. Ventajas de la prediccin del interbloqueo -No es necesario expropiar a los procesos ni retroceder su ejecucin, como ocurre con la deteccin del interbloqueo y es menos restrictivo que la prevencin del interbloqueo.

Desventajas de la prediccin del interbloqueo -Deben establecerse por anticipado (a priori) los requisitos mximos de todos los recursos que utilizara cada proceso para poder ejecutarse: Difcil de obtener basado en peor caso posible -Necesidades mximas no pueden expresar el uso exacto de los recursos durante la ejecucin de los programas. -Debe haber un nmero fijo de recursos que asignar a cada proceso del sistema. -Los procesos deben ser independientes, o sea el orden en que se ejecutan no debe estar restringido por ningn requisito de sincronizacin. -Infrautilizacin de los recursos. Estos algoritmos pueden denegar la concesin de un recurso aunque est disponible producindose el consiguiente desaprovechamiento del mismo. -Ningn proceso puede terminar mientras mantenga el uso de los recursos del sistema.

DETECCION DEL INTERBLOQUEO Las estrategias de prevencin de interbloqueo son muy conservadoras; solucionan el problema del interbloqueo limitando el acceso a los recursos e imponiendo restricciones sobre los procesos. En cambio, las estrategias de deteccin de interbloqueo no limitan el acceso a recursos ni restringen las acciones del proceso. Con la deteccin del interbloqueo, se concedern los recursos que los procesos necesiten siempre que sea posible. Peridicamente, el Sistema Operativo ejecuta un algoritmo que permite detectar la condicin de crculo vicioso de espera. La deteccin del interbloqueo es el proceso de determinar si realmente existe un interbloqueo e identificar los procesos y recursos implicados en l. Una posibilidad detectar un interbloqueo es monitorear cada cierto tiempo el estado de los recursos. Cada vez que se solicita o se devuelve un recurso, se actualiza el estado de los recursos y se hace una verificacin para observar si existe algn ciclo. Este mtodo est basado en suponer que un interbloqueo no se presente y que los recursos del sistema que han sido asignados, se liberarn en el momento que otro proceso lo requiera. Algoritmo de deteccin del interbloqueo Una comprobacin para interbloqueo puede hacerse con igual o menor frecuencia que cada solicitud de recursos, dependiendo de qu tan probable es que ocurra un interbloqueo. Comprobar cada solicitud de recursos tiene dos ventajas: Conduce a la deteccin temprana y el algoritmo es simple, de manera relativa porque se basa en cambios crecientes al estado del sistema. Adems, las comprobaciones frecuentes consumen un tiempo considerable de procesador. Los algoritmos de deteccin de bloqueos implican cierta sobrecarga en tiempo de ejecucin: Surge el siguiente interrogante: Compensa la sobrecarga implcita en los algoritmos de deteccin de bloqueos, el ahorro potencial de localizarlos y romperlos? El empleo de algoritmos de deteccin de interbloqueo implica cierto gasto extra durante la ejecucin. As pues, se presenta de nuevo la cuestin del costo, tan habitual en los sistemas operativos. Los algoritmos de deteccin de interbloqueo determinan por lo general si existe una espera circular.

RECUPERACION DEL INTERBLOQUEO Cuando se ha detectado que existe un interbloqueo, podemos actuar de varias formas. Una posibilidad es informar al operador que ha ocurrido un interbloqueo y dejar que el operador se ocupe de l manualmente. La otra posibilidad es dejar que el sistema se recupere automticamente del interbloqueo. Dentro de esta recuperacin automtica tenemos dos opciones para romper el interbloqueo: Una consiste en abortar uno o ms procesos

hasta romper la espera circular, y la segunda es apropiar algunos recursos de uno o ms de los procesos bloqueados. Actualmente, la recuperacin se suele realizar eliminando un proceso y quitndole sus recursos. El proceso eliminado se pierde, pero gracias a esto ahora es posible terminar. Los procesos pueden eliminarse de acuerdo con algn orden de prioridad, aunque es posible que no existan prioridades entre los procesos bloqueados, de modo que el operador necesita tomar una decisin arbitraria para decidir que procesos se eliminarn.

Recuperacin Manual Est forma de recuperacin consiste en avisarle al administrador o al operador del sistema que se ha presentado un interbloqueo, y ser el administrador el que solucione dicho problema de la manera ms conveniente posible, de modo que su decisin no afecte demasiado a al usuario del proceso en conflicto, y sobre todo que no afecte a los dems usuarios del sistema. Abortar los Procesos Para eliminar interbloqueos abortando un proceso, tenemos dos mtodos; en ambos, el sistema recupera todos los recursos asignados a los procesos terminados. 1 ) Abortar todos los procesos interbloqueados. Esta es una de las soluciones ms comunes, adoptada por Sistemas Operativos. Este mtodo romper definitivamente el ciclo de interbloqueo pero con un costo muy elevado, ya que estos procesos efectuaron clculos durante mucho tiempo y habr que descartar los resultados de estos clculos parciales, para quiz tener que volver a calcularlos ms tarde. 2) Abortar un proceso en cada ocasin hasta eliminar el ciclo de interbloqueo. El orden en que se seleccionan los procesos para abortarlos debe basarse en algn criterio de costo mnimo. Despus de cada aborto, debe solicitarse de nuevo el algoritmo de deteccin, para ver si todava existe el interbloqueo. Este mtodo cae en mucho tiempo de procesamiento adicional. Quiz no sea fcil abortar un proceso. Si ste se encuentra actualizando un archivo, cortarlo a la mitad de la operacin puede ocasionar que el archivo quede en un mal estado. Si se utiliza el mtodo de terminacin parcial, entonces, dado un conjunto de procesos bloqueados, debemos determinar cul proceso o procesos debe terminarse para intentar romper el interbloqueo. Se trata sobre todo de una cuestin econmica, debemos abortar los procesos que nos representen el menor costo posible. Existen muchos factores que determinan el proceso que se seleccionar, siendo los principales los siguientes: 1. La prioridad del proceso. Se elimina el proceso de menor prioridad.

2. Tiempo de procesador usado. Se abortar aquel proceso que haya utilizado menos tiempo el procesador, ya que se pierde menos trabajo y ser ms fcil recuperarlo ms tarde. 3. Tipos de recursos utilizados. Si los recursos son muy necesarios y escasos ser preferible liberarlos cuanto antes. 4. Cuntos recursos ms necesita el proceso. Es conveniente eliminar a aquellos procesos que necesitan un gran nmero de recursos. 5. Facilidad de suspensin / reanudacin. Se eliminarn aquellos procesos cuyo trabajo perdido sea ms fcil de recuperar. Apropiacin de Recursos Para eliminar interbloqueos utilizando la apropiacin de recursos, vamos quitando sucesivamente recursos de los procesos y los asignamos a otros hasta romper el ciclo de interbloqueo. Si se utiliza la apropiacin de recursos para tratar los interbloqueos, hay que considerar tres aspectos: Seleccin de la vctima Retroceso Bloqueo indefinido

La deteccin y recuperacin es la estrategia que a menudo se utiliza en grandes computadoras, especialmente sistemas por lote en los que la eliminacin de un proceso y despus su reiniciacin suele aceptarse. La deteccin y recuperacin es la estrategia que a menudo se utiliza en grandes computadoras, especialmente sistemas por lote en los que la eliminacin de un proceso y despus su reiniciacin suele aceptarse. UNA ESTRATEGIA INTEGRADA DE INTERBLOQUEO Puede ser ms eficiente usar diferente estrategias en diferentes situaciones: Se debe agrupar los recursos en un nmero de clases diferentes, usar la estrategia de ordenacin lineal para la prevencin del crculo vicioso e impedir el interbloqueo y dentro de cada clase de recursos, emplear el algoritmo ms apropiado para dicha clase. Considrense las siguientes clases de recursos: Espacio intercambiable: bloques de memoria en almacenamiento secundario para el intercambio de procesos. Pueden aplicarse la prevencin de interbloqueos, pidiendo que todos los recursos sean asignados de una vez, como la estrategia de prevencin de retencin y espera. Esta estrategia es razonable si se conoce los requisitos mximo de almacenamiento, lo que suele ser habitual. Otra posibilidad es la prediccin de interbloqueos.

Recursos de procesos: dispositivos asignables, como unidades de cintas y archivos. La prediccin es a menudo efectiva en esta categora, puesto que es razonable esperar que los procesos declaren por anticipados los recursos de esta clase que necesitaran. Tambin es posible en esta clase la prevencin mediante la ordenacin de recursos. Memoria principal: asignable a los procesos en pginas o segmentos. La prevencin por apropiacin parece ser la estrategia ms adecuada para la memoria principal. Cuando se expulsa un proceso, simplemente es trasladado a la memoria secundaria. Recursos internos: como canales de E / S. Puede usarse la prevencin por ordenacin de recursos El orden en que se encuentran estas clases de recursos es el orden en que se asignan. El problema de la cena de los filsofos Haba una vez cinco filsofos que vivan juntos. La vida de cada filsofo consista principalmente en pensar y comer y, tras aos de pensar, todos los filsofos se haban puesto de acuerdo en que la nica comida que contribua a sus esfuerzos eran los espaguetis.

Disposicin para los filsofos comensales

Los preparativos de la comida eran simples: una mesa redonda en la que haba una gran fuente de espaguetis, cinco platos, uno para cada filsofo y cinco tenedores. Un filsofo que quisiera comer ira a su lugar asignado en la mesa y, usando los dos tenedores de cada lado del plato, cogera los espaguetis y se los comera. El problema es lo siguiente: inventar un ritual (algoritmo) que permita comer a los filsofos. El algoritmo debe satisfacer la exclusin mutua (dos filsofos no pueden emplear el mismo tenedor a la vez), adems de evitar el interbloqueo y

la inanicin (en este caso, este ltimo trmino tiene un significado literal adems del algortmico). Una primera solucin al problema de la cena de los filsofos es: Sugiere una solucin por medio de semforos. Cada filsofo toma 1 el tenedor de su izquierda, y despus el de su derecha. Cuando un filsofo termina de comer, devuelve los dos tenedores a la mesa. Esta solucin, desafortunadamente, produce interbloqueo: si todos los filsofos estn hambrientos al mismo tiempo, todos se sientan, todos toman el tenedor de su izquierda y todos intentan tomar el otro tenedor que no estar. Esta solucin es poco decorosa, pues todos los filsofos pasan hambre. /* program cena_filsofos */ semforo tenedor [5] = {1}; int i; void filosofo (int i) { while (cierto) { pensar ( ); wait (tenedor [i]); wait (tenedor [(i + 1) mod 5] ; comer ( ); signal (tenedor [(i + 1) mod 5]); wait (tenedor [1]); } } void main ( ) { parbegin (filosofo (0), filosofo (1), filosofo (2), filosofo (3), filosofo (4)); } Para superar el riesgo de nter bloqueo se podran adquirir 5 tenedores adicionales (una solucin ms saludable), o ensear a los filsofos a comer espaguetis con un solo tenedor. Como otra solucin posible, se podra considerar incorporar un sirviente que permita pasar solo a 4 cuatro filsofos a la vez al comedor. Con un mximo de 4 filsofos sentados, al menos uno de los filsofos tendr acceso a los dos tenedores. /* program cena_filsofos */ semforo tenedor [5] = {1}; semforo habitacin = {4}; int i; void filosofo (int i) { while (cierto) { pensar ( ); wait (habitacin); wait (tenedor [i]); wait (tenedor [(i + 1) mod 5]); comer ( ); signal (tenedor [(i +1) mod 5]);

wait (tenedor [i]); signal (habitacin); } void main ( ) { parbegin (filosofo (0), filosofo (1), filosofo (2), filosofo (3), filosofo (4)); -}

INANICION

En un sistema, las peticiones de recursos ocurren constantemente y se necesita cierta poltica para decidir acerca de quin obtiene qu recurso y cundo. Esta poltica, aunque parece razonable, puede ocasionar que ciertos procesos nunca reciban atencin, aun cuando no estn en interbloqueo. Ejemplo: un sistema utiliza cierto algoritmo para asegurar que la asignacin de la impresora no produzca un interbloqueo. Ahora suponga que varios procesos la quieren al mismo tiempo, un posible algoritmo de asignacin es: -otorgar la impresora al proceso con el archivo ms pequeo a imprimir (suponiendo que esta informacin est disponible). Este mtodo maximiza el nmero de clientes satisfechos y parece razonable. Ahora considere lo que ocurre en un sistema ocupado, cuando un proceso tiene que imprimir un archivo enorme. Cada vez que la impresora est libre, el sistema buscar y elegir el proceso con el archivo ms pequeo. Si hay un flujo constante de procesos con archivos cortos, el proceso con el archivo enorme nunca recibir la impresora. Entonces se pospondr de manera indefinida, aun cuando no est bloqueado. La inanicin se puede evitar mediante el uso de una poltica de asignacin de recursos del tipo primero en llegar, primero en ser atendido (FIFO). Con este mtodo, el proceso que espere ms tiempo ser el que se atienda primero. A su debido tiempo, cualquier proceso dado se convertir en el ms antiguo y, por ende, obtendr el recurso que necesita.

MECANISMO DE CONCURRENCIA EN UNIX

Los programas concurrentes necesitan algn tipo de comunicacin entre procesos. Hay dos razones: -los procesos compiten para obtener acceso a recursos compartidos, -los procesos quieren intercambiar datos Debemos recordar que para cualquier tipo de comunicacin hace falta un mtodo de sincronizacin entre los procesos que quieren comunicarse entre

ellos. Los distintos mecanismos ms importantes que ofrece UNIX para la comunicacin entre procesos y la sincronizacin son los siguientes: a) Tuberas (pipes) b) Mensajes b) Memoria Compartida d) Semforos e) Seales Los tubos, los mensajes y la memoria compartida brindan un medio de comunicacin de datos entre procesos, mientras que los semforos y las seales se utilizan para provocar acciones en otros procesos. a) Tubos: Es un buffer circular que permite a dos procesos se comuniquen segn el modelo productor-consumidor. Por lo tanto, se trata de una cola de tipo el primero en entrar es el primero en salir,en la que escribe un proceso y lee otro.Cuando se crea un tubera, se le da un tamao fijo en bytes. Cuando un proceso intenta escribir en la tubera, la peticin de escritura se ejecuta inmediatamente si hay suficiente espacio; de otro modo, el proceso se bloquea. De la misma manera, un proceso lector se bloquea si intenta leer ms bytes de los que tiene disponible en la tubera actualmente, en caso contrario la peticin de lectura se ejecuta inmediatamente. El sistema operativo asegura la exclusin mutua, es decir, al tubo solo puede accederlo un proceso por vez. Hay dos tipos de tubos: con nombre y sin nombre. Solo los procesos relacionados pueden compartir tuberas sin nombre, mientras que, los procesos pueden compartir tuberas con nombre tanto si estn relacionados como si no. b) Mensajes: Es un conjunto de bytes con un tipo asociado. UNIX proporciona las llamadas al sistema msgsnd y msgrcv para que los procesos puedan enviarse mensajes. Cada proceso tiene asociada una cola de mensajes, que funciona como un buzn de correos. El emisor del mensaje especifica el tipo de mensaje en cada mensaje que enva y el receptor puede usarlo como criterio de seleccin. El receptor puede recuperar los mensajes tanto en orden de llegada (FIFO) o por su tipo asociado. Un proceso se bloqueara cuando intente leer un mensaje de una cola vaca. Si un proceso intenta leer un mensaje de cierto tipo y no es posible debido a que no est ningn mensaje de este tipo, el proceso no se bloquea. c) Memoria compartida: Es la forma ms rpida de comunicacin entre procesos brinda por UNIX, es la memoria compartida. Se trata de un bloque de memoria virtual compartido por mltiples procesos. Los procesos leen y escriben en la memoria compartida usando las mismas instrucciones de mquina que emplea para leer y escribir en otras partes de su espacio de memoria virtual. Los permisos de un proceso son solo lectura o lectura y escritura, segn el proceso. Las limitaciones de exclusin mutua no forman parte del mecanismo de memoria compartida, sino que las debe proporcionar el proceso que hace uso de la memoria compartida. En sntesis generalmente

la memoria compartida sirve para comunicar datos, no para sincronizar, salvo si se ocupa en forma combinada con una herramienta de sincronizacin, por ejemplo, semforos para la sincronizacin de procesos independientes, no hilos.

d) Semforos: Los semforos son herramientas para la sincronizacin entre procesos. Mas precisamente es un tipo de dato abstracto que permite el uso de un recurso de manera exclusiva cuando varios procesos estn compitiendo. Las llamadas al sistema para semforos en el UNIX Versin V son una generalizacin de las funciones "wait y signal" (esperar y sealizar), se pueden realizar varias operaciones simultneamente y las operaciones de incrementos y disminuciones pueden ser valores mayores que 1. Podemos definir una operacion atomica diciendo que ejecuta sin interrupcion y sin interferencia.Entonces el ncleo ejecuta atmicamente todas las operaciones solicitadas y ningn otro proceso puede acceder al semforo hasta que todas las operaciones hayan culminado. Un semforo consta de los siguientes elementos: - Valor actual del semforo. - ID(identificador) del ltimo proceso que opero con el semforo. - Numero de procesos esperando a que el valor del semforo sea mayor que su valor actual. - Numero de procesos esperando a que el valor del semforo sea cero -Asociadas con cada semforo existen colas de procesos suspendidos. Los semforos, se crean por conjuntos, en el cual, cada conjunto consta de uno o ms semforos. Hay una llamada al sistema semct 1 que permite dar valores a todos los semforos del conjunto al mismo tiempo. Adems, hay una llamada al sistema sem-op que recibe como argumento una lista de operaciones sobre semforos, cada una de ellas definida sobre uno de los semforos del conjunto. Cuando se genera esta llamada, el ncleo realiza las operaciones indicadas una a una. Para cada operacin, se especifica la funcin real por medio del valor sem_op. Existen las siguientes posibilidades: - Si sem_op es mayor que 0, el ncleo incrementa el valor del semforo y despierta a los procesos en espera de que el valor del semforo se incremente. - Si sem_op es igual a 0, el ncleo comprueba el valor del semforo. Si el semforo es 0, contina con las otras operaciones de la lista; en caso contrario, incrementa el nmero de procesos en espera de que este semforo sea igual a 0 y suspende el proceso hasta que el valor del semforo sea 0. - Si sem_op es negativo y su valor absoluto es menor o igual que el valor del semforo, el ncleo suma sem_op (un nmero negativo) al valor del semforo.

Si el resultado es 0, el ncleo despierta a todos los procesos que esperan a que el valor del semforo sea igual a 0. - Si sem_op es negativo y su valor absoluto es mayor que el valor del semforo, el ncleo suspende al proceso, caso de que el valor del semforo se incremente. Esta generalizacin de los semforos ofrece una considerable flexibilidad para realizar sincronizacin y coordinacin de procesos. e) Seales: Es una herramienta de comunicacin /sincronizacin entre procesos. Tambin podemos decir que es una interrupcin a un proceso provocada por ese proceso, por otro proceso o por el SO. Otra definicin es un mecanismo de software que informa a un proceso que se ha producido un evento: a) evento error: -generado por el proceso en ejecucin. -violacin de segmento, instruccin ilegal, escritura en zona de solo lectura etc. b) evento asincrnico: -generado externamente al proceso pero relacionado con el -alarma de un reloj, desconexin de un terminal etc. Quin enva y a quien se enva: -un proceso a otro proceso -el SO a un proceso Una seal es similar a una interrupcin de hardware, pero no emplea prioridades y cada proceso tiene informacin de cmo tratar cada seal. Es decir, todas las seales se tratan de igual manera; las seales que se producen en un mismo momento se presentan al proceso en el mismo instante, sin una ordenacin en particular. Los procesos pueden enviarse seales entre si y el ncleo puede enviar seales internas. La recepcin de una seal corresponde a la activacin del bit asociado a la seal en la componente correspondiente de la estructura del proceso que recibe. Entonces una seal se entrega actualizando un campo de la tabla de procesos del proceso al que se le enva. Dado que por cada seal se mantiene como un nico bit, las seales de un tipo en particular no pueden encolarse. El SO chequea la recepcin de una seal (y la trata si procede) por ejemplo: -cuando selecciona un nuevo proceso a ejecutar -al retornar de una llamada al sistema Reaccin de un proceso ante la recepcin de una seal: -ignorar la seal -bloquear la seal -ejecutar la accin por defecto asociada a la seal: finalizar, parar o reanudar un proceso.

En sntesis en la implementacin de seales, el SO tiene que ,recordar las seales enviadas y bloqueadas por cada proceso; chequear la seales recibidas, determinar si la seal es aceptada para luego tratarla ,ejecutando la accin correspondiente.

FUNCIONES DE SINCRONIZACION DE HILOS DE SOLARIS

Existen cuatro funciones de sincronizacin de hilos: 1) Cerrojos de exclusin mutua (mutex) 2) Semforos 3) Cerrojos de mltiples lectores y un nico escritor (lectores/escritor) 4) Variables de condicin Solaris implementa estas funciones dentro del ncleo para los hilos del ncleo y proporciona en la biblioteca de hilos para los hilos de nivel de usuario. Las funciones de iniciacin de iniciacin de estos mecanismos rellenan algunos de los campos de datos. Luego de crear un objeto sincronizacin, se puede realizar las operaciones de: entrar (adquirir un cerrojo) y liberar (desbloquearlo).No hay manera de asegurar la exclusin mutua o impidan el interbloqueo. Si un hilo intenta acceder a un fragmento de datos que debera estar protegido pero no utiliza la funcin de sincronizacin apropiada, a pesar de ello, ese acceso se produce. Si un hilo establece un cerrojo sobre un objeto y despus no lo desbloquea, el ncleo no toma ninguna accin correctiva.

Recordemos que todas las primitivas de sincronizacin requieren la existencia de una instruccin hardware que permita que un objeto sea consultado y modificado en una operacin atmica. 1) Cerrojo de exclusin mutua: Mutex es una variable que puede estar en dos estados bloqueado o desbloqueado y requiere solo 1 bit para representarla, pero en la prctica se utiliza con frecuencia un entero, en donde 0 indica que esta desbloqueado y todos los dems valores indican que esta bloqueado. Un mutex asegura que solo un hilo (o proceso) en cada momento puede acceder al recurso protegido por el mutex. El hilo obtiene el cerrojo mutex ejecutando la funcin mutex_enter, y debe ser el mismo hilo quien lo libera. Si un mutex no puede establecer el cerrojo porque ya lo ha hecho otro hilo, la accin bloqueante depender de la informacin especfica de tipo almacenada en el objeto mutex. La poltica bloqueante es la de un cerrojo cclico; un hilo bloqueado comprueba el estado del cerrojo mientras ejecuta un bucle de espera activa. Otra opcin es un mecanismo de espera bloqueante basado en interrupciones, en el cual el mutex incluye un identificador de turnstile que identifica una cola de los hilos bloqueados en este cerrojo. Las operaciones en un cerrojo mutex son: _mutex_enter (): adquiere el cerrojo bloqueando potencialmente si ya lo posee otro hilo. _mutex_exit (): libera el cerrojo desbloqueando potencialmente a un hilo en espera. _mutex_tryenter (): adquiere un cerrojo si no lo posee otro hilo(es una manera no bloqueante de realizar una funcin de exclusin mutua, permitindole al programador usar una estrategia de espera activa para hilo del nivel de usuario evitando bloquear todo el proceso cuando un hilo se bloquea).

Estructura de datos de sincronizacin de Solaris

2) Semforos: Solaris proporciona los clsicos semforos con contador, ofreciendo las siguientes funciones: _sema_p():decrementa el semforo, bloqueando potencialmente el hilo _sema_v():incrementa el semforo, desbloqueando potencialmente un hilo en espera _sema_try():decrementa el semforo si no se requiere un bloqueo 3)Cerrojo de lectura/escritura: Permite que mltiples hilos tengan acceso simultneo de lectura a objetos protegidos por un cerrojo, adems permite que en cada momento un nico hilo acceda al objeto para modificarlo mientras se excluye el acceso de todos los lectores. Entonces cuando se adquiere el cerrojo para realizar una escritura, este toma el estado de cerrojo de escritura, y todos los hilos que intenten acceder para escribir o leer debern esperar. Si uno o ms lectores han adquirido el cerrojo, su estado es de cerrojo de lectura. Las funciones son: _rw_enter(): intenta adquirir un cerrojo lector o escritor _rw_exit():libera un cerrojo como lector o escritor _rw_tryenter():decrementa el semforo si no se requiere un bloqueo _rw_downgrade():un hilo a la funcin adquiere un cerrojo de escritura y lo convierte en uno de lectura. Cualquier escritor en espera permanece esperando hasta que este hilo libere el cerrojo; si no existe escritores en espera, la funcin despierta a los lectores pendientes ,si los hay. _rw_trypgrade():intenta convertir un cerrojo de lectura en uno de escritura 4)Variable condicin: Se utiliza para esperar hasta que se cumpla una determinada condicin.

Este mecanismo se usa con un cerrojo mutex y para ello se implementa un monitor. Monitor en un proceso que se encarga de verificar el funcionamiento de algn recurso garantizando la exclusin mutua(mutex),en un monitor los procesos se bloquean y desbloquean y pueden existir diversas implementaciones no estandarizadas de un monitor: Las funciones son: _cv_signal():despierta uno de los hilos bloqueados en cv_wait() _cv_broadcast():despierta todos los hilos bloqueados en cv_wait() _cv_wait():bloquea hasta que se activa la condicin. Esta funcin libera el mutex asociado antes de bloquearse y lo devuelve a adquirir antes de retornar. Dado que al intentar volverlo a adquirir puede bloquearse por otros hilos que compiten por el mutex, la condicin que causo la espera debe volver a comprobar. Ejemplo de su uso: Mutex_enter(&m); While(condicin){ Cv_wait(&vc,&m);} Mutex_exit(&m); Este ejemplo permite que la condicin sea una expresin compleja, puesto que est protegida por el mutex.

MECANISMO DE CONCURRENCIA DE WINDOWS

Tanto Windows XP y 2003 proporcionan sincronizacin entre hilos en su arquitectura de objetos. Existen dos mtodos de sincronizacin : -los objetos de sincronizacin (utilizan funciones de espera) -los de seccin critica Funciones de espera Permiten que un hilo bloquee su propia ejecucin. Las funciones de espera no retornan hasta que se cumplan los criterios especificados. Y el tipo de funcin de espera determina el conjunto de criterios utilizado. Cuando de llama a una funcin de espera, esta comprueba si se satisface el criterio de espera y en caso negativo el hilo que realizo la llamada transita al estado de espera, no usando tiempo de procesador mientras no se cumplan los criterios de la misma.

El tipo de funcin de espera ms sencillo es aquel que espera por un solo objeto; WaitForSingleObject la cual requiere un manejador que corresponda con el objeto de sincronizacin. La funcin retorna cuando se produce una de las siguientes circunstancias: -el objeto especificado est en el estado de sealado -ha trascurrido el plazo mximo de espera, el cual puede fijarse en INFINITE para especificar que la espera ser limitada. Objetos de sincronizacin Windows implementa las funciones de sincronizacin basada en las familias de objetos de sincronizacin, que se muestra en la siguiente tabla:

Los primeros cuatro objetos de la tabla estn diseados especficamente para dar soporte a la sincronizacin. Los restantes objetos tienen otros usos adicionales pero tambin se utilizan para la sincronizacin. Cada instancia de un objeto de sincronizacin puede estar en el estado sealado o de no sealado. Un hilo se puede bloquear en un objeto si est en estado de no sealado, desbloquendose cuando el objeto transite al estado de sealado.

El funcionamiento es el siguiente; un hilo hace una peticin de espera al ejecutivo de Windows, utilizando el manejador del objeto de sincronizacin. Cuando el objeto transita al estado de sealado, el ejecutivo de Windows desbloquea todos los objetos de tipo hilo que estn esperando en ese objeto de sincronizacin. El objeto evento es til para enviar una seal a un hilo para indicarle que ha ocurrido un determinado evento. Ejemplo: en la entrada o salida asncrona, el sistema establece un objeto evento especfico de manera que dicho objeto transitara al estado de sealado cuando se haya completado la operacin asncrona. El objeto mutex se usa para garantizar el acceso mutuamente exclusivo a un recurso, permitiendo que, en cada momento, solo un hilo pueda conseguir el acceso al mismo. Este tipo de objeto funciona, por tanto, como un semforo binario. Cundo el objeto mutex pasa al estado de sealado, slo se desbloquea uno de los hilos que estaba esperando por el mutex. Los mutex se pueden utilizar para sincronizar hilos que se ejecutan en procesos diferentes. Como los mutex, los objetos semforos pueden compartir los hilos pertenecientes a distintos procesos. El semforo de Windows es un semforo con contador. El objeto temporizador con espera avisa cuando ha transcurrido un cierto tiempo o en intervalos regulares. Objetos de seccin sincrnica Su mecanismo de sincronizacin es similar a los objetos mutex, excepto que los objetos de seccin crtica solo los pueden utilizar hilos del mismo proceso. Los objetos mutex, eventos y semforos se pueden utilizar tambin en una aplicacin que tenga un nico proceso, pero los objetos de seccin crtica proporcionan un mecanismo de sincronizacin para exclusin mutua ligeramente ms rpido y ms eficiente. El proceso es responsable de asignar la memoria utilizada por una seccin crtica, esto se hace declarando una variable de tipo CRITICAL_SECTION. Antes de que los hilos del proceso puedan utilizarla, la seccin crtica se inicia con las funciones Initialize-CriticalSection o InitializeCriticalSectionAndSpinCount. Un hilo utiliza las funciones EnterCriticalSection o TryEnterCriticalSection para solicitar la posesin de una seccin crtica, utilizando la funcin LeaveCriticalSection para liberar la posesin de la misma. Si el objeto de seccin crtica lo posee actualmente otro hilo, EnterCriticalSection espera indefinidamente hasta poder obtener su posesin. En contraste cuando se utiliza un objeto mutex para lograr exclusin mutua, las funciones de espera aceptan que se especifique un plazo de tiempo de espera mximo. La funcin TryEnterCriticalSection intenta entrar en una seccin critica sin bloquear el hilo que realizo la llamada.

CONCLUSION

La presencia de interbloqueos es una caracterstica no deseable para todo sistema concurrente (paralelo o distribuido) ,que busque optimizar el uso de sus recursos. Todos los sistemas estn propensos a presentar interbloqueos, por lo tanto, es importante conocer cmo se producen los interbloqueos , como se puede controlar mediante las distintas estrategias y/o como se puede evitarlos definitivamente. Muchos sistemas han optado por garantizar que nunca se presentaran interbloqueos dentro de ellos, y esto se hace imponiendo restricciones(o protocolos) en cuanto a la forma y orden de solicitar recursos administrados por el sistema, por ejemplo asignar prioridades o mantener informado al sistema y al usuario de los estados de procesamiento. Llegamos a la conclusin, depender del sistema operativo, la eleccin del mtodo utilizar para tratar los interbloqueos de los procesos. Y observamos que una solucin radical seria eliminar los procesos que han ocasionado el interbloqueo, lo que se conoce como reanudacin de los procesos. Aunque tambin estamos de acuerdo que lo ms eficaz, es que para detener un interbloqueo debemos prevenir su presencia, de esta manera haremos un mejor uso de los recursos de nuestro sistema.

BIBLIOGRAFIA

-Libro de Sistemas Operativos. Diseo e Implementacin. A.S.Tanenbaum-Impreso por Prentice Hall- ao 2009.3 EDICION

Autor:

-Libro de Sistemas Operativos Autor: Silberchatz, A-Impreso por Prentice Hallao2004-7EDICION -Libro Sistemas Operativos Aspectos internos y principios de William Stallings diseo. Impreso por Pearson Educacin S.A. Espaa. Ao 2005-5EDICION -Libro Sistemas Operativos Modernos-Andrew S. Tanenbaun. Impreso por Pearson Educacin ,Mxico ao 2009 -3 EDICION -Libro de Sistemas Operativos Una visin aplicada. Autores: Carretero Jess Perez,Felix Garca Carballeira, Pedro DE Miguelanasagasti, Fernando Perez

Costoya. Editorial:McGraw-Hill/Interamericana de Espaa,S.A.U.-ao 20051EDICION -http://www.ing.unp.edu.ar/asignaturas/sistemasoperativos/2010/SO-mod%207Interbloqueos%20-2010.pdf (Departamento de Informtica Facultad de Ingeniera de la Universidad Nacional de la Patagonia San Juan Bosco) -http://www.lcc.uma.es/~rusman/docencia/so/Tema4.Interbloqueo.pdf(Material brindado por la ctedra del Departamento de Lenguajes y Ciencias de la Computacin Universidad de Mlaga) -http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/dso/interbloqueos4pp.pdf -http://www.sc.ehu.es/acwlaroa/SO2/Apuntes/Cap2.pdf -http://mixteco.utm.mx/~resdi/historial/materias/capitulo4.pdf
-http://mermaja.act.uji.es/docencia/ii22/teoria/TraspasTema3.pdf -http://trevinca.ei.uvigo.es/~formella/doc/cd05/condis.pdf

-http://trevinca.ei.uvigo.es/~formella/doc/cd05/node77.htm -http://www.slideshare.net/titonet3000/tuberias-en-unix-presentation