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. EJEMPLOS DE INTERBLOQUEO Ejemplo 1: 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 mas 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. Ejemplo 2: Cruce en un puente (es parecido al interbloqueo de trafico)

En una carretera de dos direcciones, donde en un determinado cruce con la va del ferrocarril, se ha construido un puente que solo deja pasar vehculos en un solo sentido. El bloqueo ocurre cuando dos carros intentan pasar por el puente al mismo tiempo.

Una manera de resolver el bloqueo es: el conductor situado en uno de los extremos es lo suficientemente educado que deja pasar en primer lugar al del otro extremo y luego pasa l. Este ejemplo nos muestra como sucede el interbloqueo en nuestra vida diaria. Ejemplo 3 Dos procesos desean imprimir cada uno un enorme archivo en cinta. El proceso A solicita el permiso para utilizar la impresora, el cual se le concede. Es entonces cuando el proceso B solicita permiso para utilizar la unidad de cinta y se le otorga. El proceso A solicita entonces la unidad de cinta, pero la solicitud es denegada hasta que B la libere. Por desgracia, en este momento, en vez de liberar unidad de cinta, B solicita la impresora. Los procesos se bloquean en ese momento y permanecen as por siempre. RECURSOS Un sistema se compone de un numero 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:

Apropiable 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 calculo. 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 esta 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 esta 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 esta bloqueado, para todos los efectos esta 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. CONDICIONES PARA PRODUCIR INTERBLOQUEO En la poltica del sistema operativo, deben darse tres condiciones para que pueda producirse un interbloqueo: 1- 1- Condicin de exclusin mutua: Cada recurso esta asignado a un nico proceso o esta disponible. 2- 2- Condicin de posesin y espera: Los procesos que tienen, en un momento dado, recursos asignados con anterioridad, pueden solicitar nuevos recursos. 3- 3- Condicin de no apropiacin: Los recursos otorgados con anterioridad no pueden ser forzados a dejar un proceso. El proceso que los posee debe liberarlos en forma explicita.

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, desde el que el proceso puede finalmente repetir sus acciones. Puede no existir interbloqueo con solo estas tres condiciones. Para que se produzca interbloqueo, se necesita una cuarta condicin: 4- 4- Condicin de espera circular (o circulo vicioso de espera): Debe existir una cadena circular de dos o mas 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 circulo vicioso de espera irresoluble. El circulo 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. PREVENCIN DEL INTERBLOQUEO La estrategia bsica de la prevencin del interbloqueo consiste, a grandes rasgos, en disear su sistema de manera que est excluida, a priori, la posibilidad de interbloqueo. Los mtodos para prevenir el interbloqueo son de dos tipos: - - Los mtodos indirectos que consisten en impedir la aparicin de alguna de las tres condiciones necesarias para que se de el interbloqeo. - - Los mtodos directos que consisten en evitar la aparicin del circulo vicioso de espera. Exclusin mutua Si ningn recurso se puede asignar de forma exclusiva, no se producir interbloqueo. Sin embargo, existen recursos para los que no es posible negar la condicion de exclusin mutua. No obstante, es posible eliminar esta condicion en algunos procesos. Por ejemplo, una impresora es un recurso no compatible pues si se permite que dos procesos escriban en la impresora al mismo tiempo, la salida resulta catica. Pero con el spooling de salida varios procesos pueden generar salida al mismo tiempo. Puesto que el spooler nunca solicita otros recuersos, se elimina el bloqueo originado por la impresora.

El inconveniente es que no todos los recursos pueden usarse de esta forma (por ejemplo, la tabla de procesos no se presenta al spooling y, ademas, la implementacion de esta tcnica puede introducir nuevos motivos de interbloqueo, ya que el spooling emplea una zona de disco finita) Retencion y espera La condicion de retencion y espera puede prevenirse exigiendo que todos los procesos soliciten todos los recursos que necesiten a un mismo tiempo y bloqueando el proceso hasta que todos los recursos puedan concederse simultneamente. Esta solucion resulta ineficiente por dos factores: - - En primer lugar, un proceso puede estar suspendido durante mucho tiempo, esperando que concedan todas sus solicitudes de recursos, cuando de hecho podria haber avanzado con solo algunos de los recursos. - - Y en segundo lugar, los recursos asignados a un proceso pueden permanecer sin usarse durante periodos considerables, tiempo durante el cual se priva del acceso a otros procesos. No apropiacin La condicin de no apropiacin puede prevenirse de varias formas. Primero, si a un proceso que retiene ciertos recursos se le deniega una nueva solicitud, dicho proceso deber liberar sus recursos anteriores y solicitarlos d eneuvo, cuando sea necesario, junto con el recurso adicional. Por otra parte, si un proceso solicita un recurso que actualmente esta retenido por otro proceso, el sistema operativo debe expulsar al segundo proceso y exigirle que libere sus recursos. Este ultimo esquema evitar el interbloqueo slo si nho hay dos procesos que posean la misma prioridad. Esta tcnica es prctica slo cuando se aplica a recursos cuyo estado puede salvarse y restaurarse ms tarde de una forma facil, como es el caso de un procesador. Circulo vicioso de espera La condicin del circulo vicioso de espera puede prevenirse definiendo una ordenacin lineal de los tipos de recursos. Si a un proceso se le han asignado recursos de tipo R, entonces slo podr realizar peticiones posteriores sobre los recursos de los tipos siguientes a R en la ordenacin. Para comprobar el funcionamiento de esta estrategia, se asocia un ndice a cada tipo de recurso. En tal caso, el recurso Ri antecede a Rj en la ordenacin si i<j. Entonces, supngase que dos procesos A y B, estn interbloqueados, porque A ha adquirido Ri y solicitado Rj, mientras que B ha adquirido Rj y solicitado Ri. Esta condicin es imposible porque implica que i<j y j<i. Como en la retencin y espera, la prevencin del circulo vicioso de espera puede ser ineficiente, retardando procesos y denegando accesos a recursos innecesariamente. PREDICCIN DEL INTERBLOQUEO Una forma de resolver el problema del interbloqueo, que se diferencia sutilmente de la prevencin, es la prediccin del interbloqueo. En la prevencin de interbloqueo, se obligaba a las solicitudes de recursos a impedir que sucediera , por lo menos, alguna de las cuatro condiciones de interbloqueo. Esto se hace indirectamente, impidiendo la aparicin de una

de las tres condiciones necesarias (exclusin mutua, retencin y espera, no apropiacin) o directamente, impidiendo la aparicin de un circulo viciosos de espera. Se llega as a un uso ineficiente de los recursos y una ejecucin ineficiente de los procesos. Con prediccin del interbloqueo, por otro lado, se pueden alcanzar las tres condiciones necesarias, pero se realizan elecciones acertadas para asegurar que nunca se llega al punto de interbloqueo. La prediccin, por lo tanto, permite ms concurrencia que la prevencin. Con prediccin del interbloqueo, se decide dinmicamente si la peticin actual de asignacin de un recurso podra, de concederse, llevar potencialmente a un interbloqueo. La prediccin del interbloqueo necesita, por lo tanto, conocer las peticiones futuras de recursos. Enfoques para la prediccin del interbloqueo: - - No iniciar un proceso si sus demandas pueden llevar a interbloqueo. - - No conceder una solicitud de incrementar los recursos de un proceso si esta asignacin puede llevar a interbloqueo. Negativa de iniciacin de procesos Confedrese un sistemas de n procesos y m tipos diferentes de recursos. Se definen los vectores y matrices siguientes: Recursos = (R1, R2, ... Rm) cantidad total de cada recurso en el sistema Disponible = (D1, D2, ... Dm) cantidad total de cada recurso sin asignar a los procesos
C11 C12 ... C1m

Demanda =

C21 C22 ... C2m . . . . . . . .

exigencias de recursos para cada proceso

. . . . A11 A12 ... A1m

Asignacin =

A21 A22 ... A2m . . . . . . . .

asignacin actual

La matriz Demanda indica las exigencias mximas de recursos para cada proceso, con una . . . . fila para cada uno. Es decir, Cij = demanda del recurso j por parte del proceso i. Esta An1 informacin debe An2 ... Anm por adelantado para que funcione la prediccin de declararse interbloqueo. De forma similar, Aij = asignacin del recurso j al proceso i. Se puede ver que se cumplen las siguientes relaciones: 1. Para todo i, Ri = Di + Aki : todos los recursos estn asignados o disponibles. 2. Para todo k e i, Cki <= Ri: ningn proceso puede demandar ms recursos que la cantidad total de recursos del sistema 3. Para todo k e i, Aki <= Cki: ningn proceso tiene asignados ms recursos de cualquier tipo que los que ha declarado necesitar.

Con estas tres cantidades, se puede definir una poltica de prediccin del interbloqueo que rechace iniciar un nuevo proceso si sus exigencias de recursos pueden conducir a un intebloqueo. Un nuevo proceso Pn+1 comenzar slo si: Ri >= C(n+1)i + Cki, para todo i

Es decir, un proceso comenzar slo si puede servirse la demanda mxima de todos los procesos actuales ms la del nuevo proceso. Esta estrategia es poco ptima, puesto que asume el caso peor: que todos los procesos expresen su demanda mxima a la vez. Negativa de asignacin de recursos La estrategia de negar la asignacin de recursos, denominada algoritmo del banquero, fue propuesta por primera vez por Dijkstra, que us este nombre por la analoga de este problema con el de un banco cuando los clientes quieren obtener dinero prestado. Los clientes sera los procesos y el dinero a prestar, los recursos. Si se enuncia de esta manera, el banco tiene una reserva limitada de dinero para prestar y un conjunto de clientes con lneas de crdito. Un cliente puede elegir pedir dinero a cargo de la lnea de crdito en un instante dado y no hay garanta de que el cliente realice ninguna reposicin hasta despus de sacar la cantidad mxima. El banquero puede rechazar un prstamo a un cliente si hay riesgo de que el banco no tenga fondos suficientes para hacer prstamos futuros que los clientes finalmente repondrn. Para empezar se definen los conceptos de estado y de estado seguro. Considrese un sistema con un nmero fijo de procesos. As pues, el estado estar formado por los dos vectores, Recursos y Disponible, y las dos matrices, Demanda y Asignacin, definidas anteriormente. Un estado seguro es un estado en el cual existe al menos una secuencia que no lleva al interbloqueo ( es decir, todos los procesos pueden ejecutarse hasta el final). Un estado inseguro es, naturalmente, un estado que no es seguro. El algoritmo del banquero usa una tabla de recursos para saber cuntos recursos tiene de todo tipo. Tambin requiere que los procesos informen del mximo de recursos que va a usar de cada tipo. Cuando un proceso pide un recurso, el algoritmo verifica si asignndole ese recurso todava le quedan otros del mismo tipo para que alguno de los procesos en el sistema todava se le pueda dar hasta su mximo. Si la respuesta es afirmativa, el sistema se dice que est en 'estado seguro' y se otorga el recurso. Si la respuesta es negativa, se dice que el sistema est en estado inseguro y se hace esperar a ese proceso. Los algoritmos siguientes muestran una versin abstracta de la logica de prediccin del interbloqueo. Con el estado del sistema definido por la estructura de datos estado, solicitud [*] es un vector que define los recursos pedidos por el proceso i. En primer lugar, se hace una comprobacin para asegurar que la solicitud no excede la demanda inicial del proceso. Si la solicitud es vlida, el paso siguiente es determinar si es posible satisfacer la solicitud, esto es, si hay suficientes recursos disponibles. Si no es posible, el proceso se suspende. Si es posible, el paso final es determinar si es seguro satisfacer la solicitud. Para hacer esto, se prueba a asignar los recursos al proceso i desde nuevo_estado. Despus, se realiza un test d seguridad usando el algoritmo del banquero. Estructura de datos globales

struct estado { int recursos [m]; int disponible [m]; int demada [n] [m]; int asignacin [n] [m]; } Algoritmo de asignacin de recursos if (asignacin[i, ] + solicitud [*] > demanda [I, *]) { < error >; /*-- solicitud total > demanda */ } else if (solicitud [*] > disponible [*]) { < suspender proceso > ; } else /*-- simular asignacin */ { < definir nuevo_estado como: asignacin[i, ] = asignacin[i, ] + solicitud [*]: disponible [*] = disponible [*] solicitud [*] >; } if (seguro (nuevo_estado)) { < realizar asignacin >; } else { < restaurar estado original >; < suspender proceso >; } Algoritmo de comprobacin de estado seguro (algoritmo del banquero) booleano seguro (estado S) { int disponible_actual [m]; proceso resto [< nmero de procesos >]; disponible_actual = disponible; resto = {todos los procesos}; posible = true; while (posible) { encontrar un PK en resto tal que demanda [k, *] asignacin [k, *] < = disponible_actual;

if (encontrado) /*-- simular ejecucin de P */ { disponible_actual = dispible_actual + asignacin [k, *]; resto = resto {PK}; } else posible = falso; } seguro (resto = = null); } La prediccin del interbloqueo tiene la ventaja de que no es necesario expulsar y hacer retroceder procesos, como en la deteccin del interbloqueo, y es menos restrictiva que la prevencin. Sin embargo, su uso supone una serie de restricciones como las siguientes: - - Se debe presentar la mxima demanda de recursos por anticipado. - - Los procesos a considerar deben ser independientes, es decir, que el orden en que se ejecuten no debe estar forzado por condiciones de sincronizacin. - - Debe haber un nmero fijo de recursos a repartir y un nmero fijo de procesos. - - Los procesos no pueden finalizar mientras retengan recursos. DETECCIN DEL INTERBLOQUEO Las estrategias de prevencin de interbloqueo son muy conservadoras; resuelven el problema limitando el acceso a 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 S. O. ejecuta un algoritmo que permite detectar la condicin de circulo 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 que 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 implicita 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 de costeabilidad, tan habitual en los sistemas operativos. Los algoritmos de deteccin de interbloqueo determinan por lo general si existe una espera circular. RECUPERACIN DE 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. La recuperacin despus de un interbloqueo se complica porque puede no estar claro que el sistema se haya bloqueado. Las mayoras de los Sistemas Operativos no tienen los medios suficientes para suspender un proceso, eliminarlo del sistema y reanudarlo ms tarde. 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. Algunas veces es necesario, eliminar varios procesos hasta que se hayan liberado los recursos necesarios para que terminen los procesos restantes. 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 enmucho 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. UNA ESTRATEGIA INTEGRADA DE INTERBLOQUEO Puede ser mas eficiente usar diferente estrategias en diferentes situaciones, una de ellas sugiere lo siguiente: Agrupar los recursos en un numero de clases diferentes. - Usar la estrategia de ordenacin lineal definida anteriomente para la prevencin de circulo viciosos de espera e impedir el interbloqueo entre clases de recursos. - Dentro de cada clase de recursos, emplear el algoritmo mas apropiado para dicha clase.

Como ejemplo de esta tcnica, considrense las siguientes clases de recursos:

- Espacio intercambiable: bloques de memoria en almacenamiento secundario para el intercambio de procesos. Recursos de procesos: dispositivos asignables, como unidades de cintas y archivos. - Memoria principal: asignable a los procesos en paginas o segmentos. - Recursos internos: como canales de E / S.

El orden en que se encuentran estas clases de recursos es el orden en que se asignan. El orden es razonable, teniendo en cuenta la secuencias de pasos que un proceso debe seguir durante su vida. En cada clase se pueden usar las siguientes estrategias : - Espacio Intercambiable: puede 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: 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: la prevencin por apropiacin parece ser la estrategia mas adecuada para la memoria principal. Cuando se expulsa un proceso, simplemente es trasladado a la memoria secundaria - - Recursos Internos: puede usarse la prevencin por ordenacin de recursos. EL PROBLEMA DE LA CENA DE LOS FILOSOFOS 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.

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 ultimo termino tiene un significado literal adems del algortmico). Este problema, propuesto por Dijkstra, puede no parecer importante o relevante por si mismo. Sin embargo, sirve para ilustrar los problemas bsicos del interbloqueo y la inanicin. Es ms, intentar desarrollar una solucin revela muchas de las dificultades de la programacin concurrente. Adems, el problema de la cena de los filsofos puede verse como un caso representativo de los problemas relacionados con la coordinacin sobre recursos compartidos, que se produce cuando una aplicacin incluye hilos de ejecucin concurrentes. Por consiguiente, este problema es un caso de prueba estndar para examinar soluciones a la sincronizacin. Una primera solucin al problema de la cena de los filsofos es: /* 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)); } Sugiere una solucin por medio de semforos. Cada filosofo toma 1 el tenedor de su izquierda , y despus el de su derecha. Cuando un filosofo termina de comer, devuelve los dos tenedores a la mesa. Esta solucin, desafortunadamente, produce nterbloqueo: si todos los filsofos estn hambriento 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.Para superar el riesgo de nter bloqueo se podran adquirir 5 tenedores adicionales ( una solucin mas 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. En esta figura se muestra con semforos. Esta solucin esta libre de nter bloqueo e inanicin. /* 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)); } MECANISMOS DE CONCURRENCIA EN UNIX Los distintos mecanismos ms importantes que ofrece UNIX para la comunicacin entre procesos y la sincronizacin son los siguientes: - - Tubos - - Mensajes - - Memoria Compartida - - Semforos - - 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. Tubos Es un buffer circular que permite a dos procesos comunicarse segn el modelo productor/consumidor. Cuando se crea un tubo, se le da un tamao fijo en bytes. Cuando un proceso intenta escribir en el tubo, la solicitud 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 mas bytes de los que tiene disponible en ese momento. El sistema

operativo es el encargado de la exclusin mutua, es decir, al tubo solo puede accederlo un proceso por vez. Hay dos tipos de tubos: con nombre y sin nombre. Los tubos sin nombre pueden ser compartidos por procesos afines y los tubos con nombre pueden ser compartidos por procesos no afines. Mensajes Es un bloque de texto 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 envo y el receptor puede usarlo como criterio de seleccin. El receptor puede recuperar los mensajes tanto en orden FIFO como por el tipo asociado. Un proceso se suspender cuando intente leer de una cola vaca. Si un proceso intenta leer un mensaje de cierto tipo y falla, el proceso no se suspender. Memoria Compartida Es la forma ms rpida de comunicacin entre procesos que brinda UNIX, se trata de un bloque comn de memoria virtual compartido por varios procesos. Los procesos pueden leer y escribir en la memoria compartida usando las mismas instrucciones que la maquina que emplea para leer y escribir en otras partes de su espacio de direcciones virtual. Los permisos de un proceso son solo lectura o lectura-escritura, segn el proceso. Las limitaciones de exclusin mutua no forman parte del servicio de memoria compartida, sino que las debe proporcionar el proceso que hace uso del mismo. Semforos Las llamadas al sistema para semforos en el UNIX Versin V son una generalizacin de las primitivas "wait y signal", en estas se pueden realizar conjuntamente varias operaciones y los incrementos y disminuciones pueden ser valores mayores que 1. El ncleo ejecuta atmicamente todas las operaciones solicitadas; 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 del ultimo 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, un conjunto tiene uno o ms semforos. Hay una llamada al sistema semctl 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 que esperaban a que el valor del semforo se incrementase. - 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 esperando a 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. Seales Es un mecanismo de software que informa a un proceso que se ha producido un suceso asncrono. Una seal es similar a una interrupcin de hardware, pero no emplea prioridades. 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. Una seal se entrega actualizando un campo de la tabla de procesos del proceso al que se le enva. Dado que cada seal se mantiene como un nico bit, las seales de un tipo en particular no pueden colocarse en la cola. Una seal se procesa en el instante despus de que el proceso despierte para ejecutarse o cuando el proceso este dispuesto a volver de una llamada al sistema. Un proceso puede responder a una seal ejecutando alguna accin por omisin (por ejemplo, terminar), ejecutando una funcin de gestin de la seal o ignorando la seal.

Esta tabla enumera algunas de las seales definidas en el UNIX SVR4 Valor Nombre Descripcin 01 Sighup Colgar; se le enva a un proceso cuando el ncleo supone que el usuario de ese proceso no est realizando un trabajo til. 02 Sigint Interrumpir. 03 Sigquit Salir; la enva el usuario para provocar una parada del proceso y la genracin de un volcado de memoria. 04 Sigill Instruccin ilegal. 05 Sigtrap Seguimiento de cepo (trap); provoca la ejecucin de un cdigo de seguimiento del proceso. 06 Sigiot Ejecucin de la instruccin IOT. 07 Sigemt Ejecucin de la instruccin MT. 08 Sigfpt Excepcin de coma flotante. 09 Sigkill Matar; terminacin del proceso.

10 11 12 13 14 15 16 17 18 19

Sigbus Sigsev Sigsys Sigpipe Sigalarm Sigterm Sigusr1 Sigusr2 Sigcld Sigpwr

Error de bus. Violacin de segmento; un proceso intenta accedet a una posicin fuera de su espacio de direcciones virtual Argumentos incorrectos en una llamada al sistema. Escritura en un tubo que no tiene lectores asociados. Alarma de relog Terminacin por software Seal 1 definida por el usuario. Seal 2 definida por el usuario. Muerte de un hijo. Corte de energa.

PRIMITIVAS DE SINCRONIZACIN DE HILOS EN SOLARIS Adems de los mecanismos de concurrencia de UNIX SVR4, Solaris soporta cuatro primitivas de sincronizacin de hilos: - - Cierres de exclusin mutua (mutex, mutual exclucin). - - Semforos. - - Cierre de mltiples lectores, un escritor (lectoress escritores). - - Variables de condicin. Solaris implementa estas primitivas para los hilos de ncleo dentro del ncleo; tambien las ofrece en la biblioteca de hilos para los hilos de usuario. La ejecucin de una primitiva crea una estructura de datos que contiene parmetros especificados por el hilo creador (figura 6.13). Una vez que est creado el objeto de sincronizacin, hay dos operaciones, fundamentalmente, que se puedan realizar: entrar(adquirir, bloquear) y salir (desbloquear). El ncleo o la biblioteca de hilos no incluyen mecanismos para hacer cumplir la exclusin mutua o prevenir el interbloqueo. Si un hilo intenta accder a datos un fragmento de cdigo o que se supone protegido pero no utiliza la primitiva de sincronizacin correspondiente, se produce ese acceso. Si un hilo bloquea un objeto y, despus, falla al desbloquearlo, el ncleo no hace nada.

(a) Cierre MUTEX

(b) Cierre de lectores/escritores

(c) Semforo

(d) Variable de condicin

Cierre de exclusin mutua Un cierre mutex impide que ejecute ms de un hilo cuando el cierre est activo. El hilo que bloquea el mutex debe ser el que lo desbloquea. Un hilo intenta adquirir un cierre mutex ejecutando la primitiva mutex_enter. Si mutex_enter no puede activar el cierre (debido a que ya est activado por otro hilo), la accin mediante la que se bloquea el hilo depende de la informacin especfica de tipo almacenada en el objeto mutex. La poltica de bloqueo por defecto es un cierre circular, un hilo bloqueado comprueba el estado del cierre mientras ejecuta en un bucle de espera. Opcionalmente se aplica un mecanismo de bloqueo basado en interrupciones. En este ltimo caso, el mutex un id de torno que identifica una cola de hilos dormidos en este cierre. Las primitivas asociadas a un cierre mutex son: mutex_enter() Adquiere el cierre; potencialmente se bloquea si ya est adquirido. mutex_exit() Libera el cierre; potencialmente desbloquea a uno que espera. mutex_tryenter() Adquiere el cierre si an no est adquirido. La primitiva mutex_tryenter() proporciona un modo no bloqueador de ejecutar la funcin de exclucin mutua. Esto permite al programador utilizar un metodo de espera activa para hilos de usuario, lo que evita que se bloquee el proceso completo debido al bloqueo de un hilo. Semforos Solaris ofrece semforos enteros clsicos, con las siguientes primitivas: sema_p () Disminuye el semforo, potencialmente bloquea el hilo. sema_v () Incrementa el semforo, potencialmente desbloquea un hilo que espera. sema_tryp () Si nos es necesario bloquearse, disminuye el semforo. De nuevo, la primitiva sema_tryp () permite espera activa. Cierre lectores/escritores El cierre lectores/escritores permite a mltiples hilos tener accesos slo-lectura simultneos a un objeto protegido por el cierre. Tambin permite a un solo hilo acceder, en un instante dado, al objeto pra escritura, excluyendo a todos los lectores. Cuando se adquiere el cierre para escritura, pasa al estado de cerradura-escritura. todos los hilos que intenten acceder para leer o escribir deben esperar. Si uno o ms lectores adquieren el cierre, su estado pasa a cerrado-lectura. Las primitivas son como sigue: rw_enter() Intenta adquirir un cierre como lector o escritor. rw_exit() Libera un cierre como lector escritor. rw_tryenter() Si no es necesario bloquearse, adquiere el cierre. rw_downgrade() Un hilo que ha adquirido un cierre de escritura lo convierte en cierre de lectura. Cualquier escritor que estuviese esperando contina esperando hasta que el hilo libere el cierre. Si no hay escritores esperando, la primitiva despierta a los lectores que esperan. rw_tryupgrade() Intenta convertir un cierre de lectura en un cierre de escritura. Variables de condicin

Una variable de condicin se utiliza para esperar hasta que sea cierta una determinada condicin. Las variables de condicin deben usarse junto con un cierre mutex. Las primitivas son como sigue: c_wait() Bloquea hasta que se sealiza la condicin. cv_signal() Despierta un hilo bloqueado en en c_wait(). cv_broadcast() Despierta todos los hilos bloqueados en c_wait() c_wait() libera el mutex asociado antes de bloquearse y lo readquiere antes de retornar. Puesto que la readquisiscin del mutex puede estar bloqueada por otro hilo que espera en el mutex, se debe reevaluar la condicin de espera, de este modo un uso habitual es el siguiente: mutex_enter(&m); . . . while (alguna condicin) { cv_wait (&cv , &m); } . . . mutex_exit (&m);

Esto permite que la condicin sea una expresin compleja, puesto que est protegida por el mutex. MECANISMOS DE CONCURRENCIA EN WINDOWS 2000 Windows 2000 (W2K) ofrece sincronizacin entre los hilos como parte de la arquitectura de objetos. El mecanismo usado por el ejecutor de W2K para implementar los servicios de sincronizacin es la familia de objetos de sincronizacin, que esta formada por los siguientes: - - Proceso. - - Hilo. - - Archivo. - - Entrada de consola. - - Notificacin de cambio de archivo. - - Mutante. - - Semforo. - - Suceso. - - Temporizador. Cada caso de objeto de sincronizacin puede estar en estado sealizado o no sealizado. Un hilo puede estar suspendido por un objeto en estado no sealizado: el hilo es liberado cuando el objeto pasa a estado sealizado. El mecanismo es sencillo: un hilo genera una solicitud de espera al ejecutor de W2K por medio del descriptor (handle) del objeto de

sincronizacin. Cuando un objeto pasa a estado sealizado, el ejecutor de W2K libera todos los objetos hilo que estaban esperando por dicho objeto de sincronizacin. El objeto mutante se utiliza para hacer cumplir la exclusin mutua en el acceso a un recurso, permitiendo que slo un objeto hilo obtenga el acceso en cada instante. Por lo tanto, funciona como un semforo binario. Cuando el objeto mutante pasa a estado sealizado, slo se libera uno de los hilos que esperan. Los objetos mutante pueden utilizarse para sincronizar hilos que ejecutan en distintos procesos. Al igual que los mutantes, hilos de diferentes procesos pueden compartir semforos. El semforo de W2K es un semforo entero clsico. El temporizador en esencia, seala determinado momento o intervalos regulares. Objetos de sincronizacin de Windows 2000 (Resume los sucesos que hacen que cada tipo de objetos pase a estado sealizado y el efecto que tiene en los hilos que esperan)

Tipo de objeto Proceso

Definicin Invocacin a un programa, incluyendo el espacio de direcciones y los recursos Entidad ejecutable dentro de un proceso Caso particular de un archivo abierto o de un dispositivo de E/S Un buffer de pantalla para ventana de texto (por ejemplo, se utiliza para gestionar una pantalla de E/S de una aplicacin MS-DOS) Una notificacin de que cambia cualquier sistema de archivos.

Pasa a estado sealado cuando Termina el ultimo hilo

Efectos sobre los hilos que esperan Todos se liberan

Hilo Archivo

Termina el hilo Se completa la operacin de E/S La entrada esta disponible

Todos se liberan Todos se liberan

Entrada de consola

Se libera un hilo

Notificacin de cambio de archivo

Mutante

Mecanismo que proporciona exclusin mutua a los entornos Win32 y OS/2 Contador que regula el numero de hilos que pueden emplear un recurso Anuncio de que ha ocurrido un suceso del sistema Contador que registra el paso del tiempo

El cambio se produce en un sistema de archivos que asocia un criterio de filtrado a ese objeto El hilo propietario u otro hilo libera al mutante El contador del semforo llega a cero Un hilo activa el suceso Llega el tiempo de activacin o expira el intervalo de guarda

Se libera un hilo

Se libera un hilo

Semforo

Todos se liberan

Suceso

Todos se liberan

Temporiza-dor

Todos se liberan

Nota: Las columnas sombreadas corresponden a objetos que tienen otros usos, pero tambin se pueden emplear para la sincronizacin.