Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

BLOQUEO MUTUO 2

No description
by

elizabeth rodriguez

on 15 April 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of BLOQUEO MUTUO 2

SISTEMAS OPERATIVOS Maria Carolina Niño
Elizabeth Rodriguez A Bloqueo mutuo Condiciones para el bloqueo mutuo Modelado de bloqueos mutuos Holt (1972) Evitar los bloqueos mutuos No siempre resulta práctico porqué Detección * (Se conocía como abrazo mortal en los primeros SO), es un enredo a nivel del sistema de solicitudes de recursos que se inicia cuando 2 o más trabajos se ponen en espera.

* Eran poco frecuentes en los primeros SO por lotes por que los usuarios incluían en las tarjetas de control de los trabajos precedían una lista completa de los recursos del sistema. En cada uno de estos 7 casos, el bloqueo comprendió la interacción de varios programas y recursos, pero la ocurrencia simultanea de 4 condiciones procedió cada bloqueo mutuo, condiciones que el sistema operativo u otro sistema podría haber reconocido: exclusivo mutua, retención de recursos, no apropiatividad y espera circular. Demostró la forma en que las 4 condiciones se pueden modelar utilizando graficas dirigidas. Una línea solida de un recurso hacia un proceso significa que el proceso retiene dicho recurso; una línea solida de un proceso a un recurso, que un proceso espera dicho recurso. La dirección de la flecha indica el flujo. La espera circular se puede obviar si el SO impide la formación de un circulo. Havender (1968) propuso una solución de este tipo, la cual se basa en un sistema de numeración para los recursos: impresa =1, disco =2, cinta = 3, graficador = 4 etc. El sistema obliga a que cada trabajo solicite sus recursos en orden ascendente: cualquier dispositivo “número uno” requerido por el trabajo será solicitado primero y así sucesivamente. Si llegaba otra tarea solicitando un recurso número uno tendría que anticipar dicha necesidad cuando la solicito por primera vez y antes de pedir el disco Dijkstra (1965) propuso un algoritmo para regular la asignación de recursos a fin de evitar bloqueos. Este algoritmo, conocido como algoritmo del banquero, se basa en un banco con una cantidad fija de capital que opera según los principios siguientes:
* A ninguno de los clientes se concederá un préstamo que exceda el capital total del banco.
* A todos los clientes se dará el límite de crédito máximo al abrir una cuenta.
* A ningún cliente se permitirá que pida prestado más allá de su límite.
* La suma de todos los préstamos no excederá el capital total del banco. A diferencia del algoritmo para evitar bloqueos mutuos, que se debe ejecutar cada que existe una solicitud, el algoritmo utilizado para detectar la circularidad se puede correr siempre que sea apropiado: cada hora, una vez al día, o cuando el operador note que producción se ha deteriorado o cuando se queje un usuario. Siete casos de bloqueo mutuo Caso#1 Bloqueos mutuos en solicitudes de archivo Si se permite que las tareas soliciten y conserven archivos durante la duración de su ejecución, puede ocurrir un bloqueo mutuo.
Bloqueo mutuo mediante una representación modificada de graficas dirigidas Caso#2 Bloqueos mutuos en bases de datos Bloqueo mutuo si dos procesos acceden y bloquean registros de una base de datos.
Es una técnica utilizada para garantizar la integridad de los datos, a través de la cual el usuario bloquea a los demás usuarios mientras está trabajando con la base de datos.
Si ocurre un bloqueo lo más exitoso es bloquear la base de datos, pero el acceso a la base queda restringido a un usuario a la vez y en un entorno multiusuario, los tiempos de respuesta se reducen de manera significativa. Si se bloque solo una parte de la base de datos, el tiempo de respuesta mejora, pero se incrementa la posibilidad de un bloqueo mutuo porque diferentes procesos a veces necesitan trabajar con varias porciones de las bases de datos al mismo tiempo Caso#3 Bloqueos Mutuos en la asignación de dispositivos dedicados El uso de un grupo de dispositivos dedicados puede bloquear el sistema, todos los trabajos están esperando que termine otra tarea y que libere su unidad de cinta, un hecho que no pasara. Caso#4 Bloqueos en la asignación múltiple de dispositivos Pueden presentarse cuando varios procesos solicitan y se quedan con dispositivos dedicados. Caso#5 Bloqueos mutuos en operaciones periféricas simultaneas en línea Instalar un dispositivo de alta velocidad, un disco entre ella y el CPU. El disco acepta las salidas de varios usuarios y actúa como un área de almacenamiento temporal para todas las salidas, hasta que la impresa puede aceptarlas. Operaciones periféricas simultaneas en línea. (Spooling=se refiere al proceso mediante el cual la computadora introduce trabajos en un buffer ).

Cualquier parte del sistema que se base en spooling, como el que maneja los trabajos de entrada o transfiere archivos en una red, es vulnerable ante un bloqueo mutuo Caso#6 Bloqueos al compartir archivos Los discos están diseñados para ser compartidos, por lo que no es raro que 2 procesos usen áreas diferentes del mismo disco. Sin controles para regular el uso de la unidad de disco, los procesos en competencia podrían enviar comandos conflictivos y bloquear el sistema. Caso#7 Bloqueos mutuos en una red Una red congestionada, que ha llenado un porcentaje grande de su buffer de E/S se puede bloquear totalmente si no tiene protocolos para controlar el flujo de mensajes a través de la red. Estrategias para el manejo de bloqueos En general los SO utilizan 3 estrategias para manejar bloqueos mutuos:

* Impedir que ocurra alguna de las 4 condiciones

* Evitar el bloqueo si se hace probable

* Detectarlo cuando ocurre y recuperarse del mismo con gracia Prevención Para impedir un bloqueo mutuo, el SO debe eliminar una de las 4 condiciones necesarias, tarea complicada porque no es posible suprimir la misma condición de todos los recursos. La exclusión mutua es necesaria en cualquier SO de computo, porque algunos recursos solo pueden ser aprovechados por un usuario a la vez.
En el caso de los dispositivos de E/S la exclusión mutua es obvia mediante el uso de spool, cada archivo de salida completo se manda a imprimir cuando el dispositivo está listo.
La retención de recursos, podría evitarse obligando a cada trabajo a solicitar, en el momento de la creación, todos los recursos que necesitara. Por ejemplo Si se da tanta memoria como necesita cada trabajo en un sistema
por lotes, el número de tareas activas quedará regido por cuantas quepan en la memoria. Es una política que reducirá de manera significativa el grado de multiprogramación. Además, los dispositivos periféricos quedarían ociosos porque se asignarían a un trabajo aunque no se utilizaran todo el tiempo. Como hemos dicho, esto funcionaba en entornos por lotes 1. Conforme los trabajos entran al sistema, deben enunciar por adelantado el número máximo de los recursos necesarios. Como hemos dicho, esto no resulta práctico en sistemas interactivos.

2. El total de recursos para cada clase debe mantenerse constante. Si un dispositivo se rompe y súbitamente deja de estar disponible, el algoritmo no funcionará (el sistema puede quedar en un estado inseguro).

3. El número de trabajos debe mantenerse fijo, algo que no es posible en los sistemas interactivos, donde la cantidad de trabajos activos cambia en forma constante.

4. El costo por carga general incurrida al ejecutar el algoritmo para evitar bloqueos mutuos puede resultar bastante elevado cuando hay muchos trabajos activos y dispositivos, ya que se debe correr con cada solicitud.

5. Los recursos no se utilizan bien porque el algoritmo supone el caso peor y, como resultado, conserva recursos vitales no disponibles como protección contra estados inseguros.

6. La planificación sufre como resultado de la mala utilización y los trabajos se quedan esperando la asignación de recursos: un flujo uniforme de trabajos que solicitan unos cuantos recursos puede causar una posposición indefinida de un trabajo más complejo, que requiere muchos recursos. Los pasos para reducir una gráfica son los que siguen (Lañe & Mooney, 1988):

1. Encuentre un proceso que esté utilizando un recurso y que no esté en espera de uno. Este proceso se puede eliminar de la gráfica (desconectando el vínculo que une el recurso al proceso) y los recursos se pueden devolver a la "lista disponible'. Esto es posible porque el proceso terminará y devolverá el recurso.
2. Encuentre un proceso que nada más espere clases de recursos que no están asignados por completo. Este proceso no contribuye al bloqueo mutuo, ya que terminará por obtener el recurso que espera, terminará su trabajo y devolverá el recurso a la "lista disponible".
3. Vuelva al paso 1 y continúe la iteración, hasta eliminar todas las líneas que conecten recursos con procesos. Recuperación Una vez que se detecta un bloqueo mutuo hay que desarmarlo y devolver el sistema a lo normal con tanta rapidez como sea posible. Existen varios algoritmos de recuperación, pero todos tienen una característica en común: requieren por lo menos una víctima, un trabajo consumible, mismo que, al ser eliminada del bloqueo mutuo, liberará al sistema. Por desgracia, para eliminar la víctima generalmente hay que reiniciar el trabajo desde el principio o a partir de un punto medio conveniente (Calingaert, 1982). El primer método y más simple de recuperación, y el más drástico, es terminar los trabajos que están activos en el sistema y volver a arrancarlos desde el principio.
El segundo método es terminar sólo los trabajos incluidos en el bloqueo mutuo y solicitar a sus usuarios que los vuelvan a enviar. El tercero es identificar qué trabajos intervienen en el bloqueo mutuo y terminarlos uno por uno y comprobar la desaparición del bloqueo mutuo después de cada eliminación hasta resolverlo. Una vez liberado el sistema, se deja que los trabajos restantes terminen su procesamiento; luego, los trabajos detenidos se inician de nuevo desde el principio.

El cuarto procedimiento se puede poner en efecto sólo si el trabajo mantiene un registro, una instantánea (descanso) de su progreso, de manera que se pueda interrumpir y después continuar sin tener que reiniciar desde el principio. El quinto método de nuestra lista, selecciona un trabajo no bloqueado,
retira los recursos que contiene
y los asigna a procesos bloqueados, de manera que pueda reanudarse la ejecución
—esto deshace el bloqueo mutuo—.


El sexto método detiene los trabajos nuevos e impide que entren al sistema,
lo que permite que los que no estén bloqueados sigan hasta su terminación
y liberen sus recursos. Deben considerarse varios factores al elegir la víctima para que tenga el efecto menor negativo sobre el sistema. Los más comunes son:

1. La prioridad del trabajo en consideración —por lo general no se tocan los trabajos de alta prioridad.

2. El tiempo de CPU utilizado por el trabajo —no suelen tocarse los trabajos que están a punto de terminar.

3. La cantidad de tareas en que repercutiría la elección de la víctima. Inanición La inanición, el resultado de la asignación conservadora de recursos, donde una tarea no puede ejecutarse porque permanece en espera de recursos que nunca quedan disponibles.
Full transcript