Summary
Sumario Andrew Tanenbaum - Sistemas Operativos Modernos - Capitulo 6
- Course
- Institution
- Book
Andrew Tanenbaum - Sistemas Operativos Modernos - Capitulo 6 en Español
[Show more]
Connected book
Book Title:
Author(s):
- Edition:
- ISBN:
- Edition:
Seller
Follow
agusmitrobeda
Content preview
6INTERBLOQUEOS
Los sistemas computacionales están llenos de recursos que pueden ser utilizados por sólo un pro-
ceso a la vez. Algunos ejemplos comunes son las impresoras, las unidades de cinta y las ranuras en
los tableros internos del sistema. Cuando dos procesos escriben de manera simultánea en la impre-
sora se producen incoherencias. Si dos procesos utilizan la misma entrada en la tabla del sistema de
archivos invariablemente se corrompe el sistema de archivos. En consecuencia, todos los sistemas
operativos tienen la habilidad de otorgar (en forma temporal) a un proceso el acceso exclusivo a
ciertos recursos.
Para muchas aplicaciones, un proceso necesita acceso exclusivo no sólo a un recurso, sino a
varios. Por ejemplo, suponga que cada uno de dos procesos quiere grabar un documento digitaliza-
do en un CD. El proceso A pide permiso para utilizar el escáner y se le otorga. El proceso B se pro-
grama de manera distinta y solicita primero el grabador de CDs, y también se le otorga. Ahora A
pide el grabador de CDs, pero la petición se rechaza hasta que B lo libere. Por desgracia, en vez de
liberar el grabador de CD, B pide el escáner. En este punto ambos procesos están bloqueados y per-
manecerán así para siempre. A esta situación se le conoce como interbloqueo.
Los interbloqueos también pueden ocurrir entre máquinas. Por ejemplo, muchas oficinas tie-
nen una red de área local con muchas computadoras conectadas. A menudo, los dispositivos como
escáneres, grabadores de CD, impresoras y unidades de cinta se conectan a la red como recursos
compartidos, disponibles para cualquier usuario en cualquier equipo. Si estos dispositivos se pue-
den reservar de manera remota (es decir, desde el equipo doméstico del usuario), pueden ocurrir los
mismos tipos de interbloqueos antes descritos. Las situaciones más complicadas pueden ocasionar
interbloqueos que involucren a tres, cuatro o más dispositivos y usuarios.
433
,434 INTERBLOQUEOS CAPÍTULO 6
Los interbloqueos pueden ocurrir en una variedad de situaciones, además de solicitar disposi-
tivos de E/S dedicados. Por ejemplo, en un sistema de bases de datos, un programa puede tener que
bloquear varios registros que esté utilizando para evitar condiciones de competencia. Si el proceso
A bloquea el registro R1 y el proceso B bloquea el registro R2, y después cada proceso trata de blo-
quear el registro del otro, también tenemos un interbloqueo. Por ende, los interbloqueos pueden
ocurrir en los recursos de hardware o de software.
En este capítulo analizaremos varios tipos de interbloqueos, veremos cómo surgen y estudiare-
mos algunas formas de prevenirlos o evitarlos. Aunque este libro es sobre los interbloqueos en el
contexto de los sistemas operativos, también ocurren en los sistemas de bases de datos y en muchos
otros contextos en las ciencias computacionales, por lo que en realidad este material se puede apli-
car a una amplia variedad de sistemas de multiproceso. Se ha escrito mucho sobre los interbloqueos.
Dos bibliografías sobre el tema han aparecido en Operating Systems Review y deben consultarse en
busca de referencias (Newton, 1979; y Zobel, 1983). Aunque estas bibliografías son antiguas, la ma-
yor parte del trabajo sobre los interbloqueos se hizo mucho antes de 1980, por lo que aún son de
utilidad.
6.1 RECURSOS
Una clase principal de interbloqueos involucra a los recursos, por lo que para empezar nuestro es-
tudio veremos lo que son. Los interbloqueos pueden ocurrir cuando a los procesos se les otorga ac-
ceso exclusivo a los dispositivos, registros de datos, archivos, etcétera. Para que el análisis sobre
los interbloqueos sea lo más general posible, nos referiremos a los objetos otorgados como recur-
sos. Un recurso puede ser un dispositivo de hardware (por ejemplo, una unidad de cinta) o una pie-
za de información (como un registro bloqueado en una base de datos). Por lo general, una
computadora tendrá muchos recursos que se pueden adquirir. Para algunos recursos puede haber
disponibles varias instancias idénticas, como tres unidades de cinta. Cuando hay disponibles varias
copias de un recurso, se puede utilizar sólo una de ellas para satisfacer cualquier petición de ese
recurso. En resumen, un recurso es cualquier cosa que se debe adquirir, utilizar y liberar con el
transcurso del tiempo.
6.1.1 Recursos apropiativos y no apropiativos
Los recursos son de dos tipos: apropiativos y no apropiativos. Un recurso apropiativo es uno que
se puede quitar al proceso que lo posee sin efectos dañinos. La memoria es un ejemplo de un re-
curso apropiativo. Por ejemplo, considere un sistema con 256 MB de memoria de usuario, una im-
presora y dos procesos de 256 MB, cada uno de los cuales quiere imprimir algo. El proceso A
solicita y obtiene la impresora, y después empieza a calcular los valores a imprimir. Antes de ter-
minar con el cálculo, excede su quantum de tiempo y se intercambia por el otro proceso.
Ahora el proceso B se ejecuta y trata (sin éxito) de adquirir la impresora: se crea una situación
potencial de interbloqueo, ya que A tiene la impresora y B tiene la memoria, y ninguno puede pro-
ceder sin el recurso que el otro posee. Por fortuna, es posible apropiarse (quitar) de la memoria de
,SECCIÓN 6.1 RECURSOS 435
B al intercambiarlo y colocar el proceso A de vuelta. Ahora A se puede ejecutar, realizar su impre-
sión y después liberar la impresora. Así no ocurre ningún interbloqueo.
Por el contrario, un recurso no apropiativo es uno que no se puede quitar a su propietario ac-
tual sin hacer que el cómputo falle. Si un proceso ha empezado a quemar un CD-ROM y tratamos
de quitarle de manera repentina el grabador de CD y otorgarlo a otro proceso, se obtendrá un CD
con basura. Los grabadores de CD no son apropiativos en un momento arbitrario.
En general, los interbloqueos involucran a los recursos no apropiativos. Los interbloqueos po-
tenciales que pueden involucrar a los recursos apropiativos por lo general se pueden resolver me-
diante la reasignación de los recursos de un proceso a otro. Por ende, nuestro análisis se enfocará
en los recursos no apropiativos.
La secuencia de eventos requerida para utilizar un recurso se proporciona a continuación, en
un formato abstracto.
1. Solicitar el recurso.
2. Utilizar el recurso.
3. Liberar el recurso.
Si el recurso no está disponible cuando se le solicita, el proceso solicitante se ve obligado a espe-
rar. En algunos sistemas operativos, el proceso se bloquea de manera automática cuando falla la so-
licitud de un recurso, y se despierta cuando el recurso está disponible. En otros sistemas, la solicitud
falla con un código de error y depende del proceso que hizo la llamada decidir si va a esperar un
poco e intentar de nuevo.
Un proceso al que se le ha negado la petición de un recurso por lo general permanece en un
ciclo estrecho solicitando el recurso, después pasa al estado inactivo y después intenta de nuevo.
Aunque este proceso no está bloqueado, para toda intención y propósito es como si lo estuviera, de-
bido a que no puede realizar ningún trabajo útil. En nuestro siguiente análisis vamos a suponer que
cuando a un proceso se le niega un recurso solicitado pasa al estado inactivo.
La naturaleza exacta de solicitar un recurso es en gran medida dependiente del sistema. En al-
gunos sistemas se proporciona una llamada al sistema request para permitir que los procesos pidan
los recursos en forma explícita. En otros, los únicos recursos que conoce el sistema operativo son los
archivos especiales que sólo un proceso puede tener abiertos en un momento dado. Éstos se abren
mediante la llamada al sistema open ordinaria. Si el archivo ya está en uso, el proceso que llama es
bloqueado hasta que su propietario actual lo cierra.
6.1.2 Adquisición de recursos
Para ciertos tipos de recursos, como los registros de una base de datos, es responsabilidad de los
procesos de usuario administrar su uso. Una manera de permitir que los usuarios administren los re-
cursos es asociar un semáforo con cada recurso. Estos semáforos se inicializan con 1. Se pueden
utilizar mutexes de igual forma. Los tres pasos antes listados se implementan como una operación
, 436 INTERBLOQUEOS CAPÍTULO 6
down en el semáforo para adquirir el recurso, usarlo y finalmente realizar una operación up en el
recurso para liberarlo. Estos pasos se muestran en la figura 6-1(a).
typedef int semaforo; typedef int semaforo;
semaforo recurso_1; semaforo recurso_1;
semaforo recurso_2;
void proceso_A(void) { void proceso_A(void) {
down(&recurso_1); down(&recurso_1);
usar_recurso_1(); down(&recurso_2);
up(&recurso_1); usar_ambos_recursos();
} up(&recurso_2);
up(&recurso_1);
}
(a) (b)
Figura 6-1. Uso de un semáforo para proteger los recursos. (a) Un recurso. (b) Dos re-
cursos.
Algunas veces los procesos necesitan dos o más recursos. Se pueden adquirir de manera se-
cuencial, como se muestra en la figura 6-1(b). Si se necesitan más de dos recursos, sólo se adquie-
ren uno después del otro.
Hasta ahora todo está bien. Mientras sólo haya un proceso involucrado, todo funciona sin pro-
blemas. Desde luego que con sólo un proceso, no hay necesidad de adquirir formalmente los recur-
sos, ya que no hay competencia por ellos.
Ahora consideremos una situación con dos procesos, A y B, y dos recursos. En la figura 6-2 se
ilustran dos escenarios. En la figura 6-2(a), ambos procesos piden los recursos en el mismo orden.
En la figura 6-2(b), los piden en un orden distinto. Esta diferencia puede parecer insignificante, pe-
ro no lo es.
En la figura 6-2(a), uno de los procesos adquirirá el primer recurso antes del otro. Después ese
proceso adquirirá con éxito el segundo recurso y realizará su trabajo. Si el otro proceso intenta ad-
quirir el recurso 1 antes de que sea liberado, el otro proceso simplemente se bloqueará hasta que es-
té disponible.
En la figura 6-2(b), la situación es distinta. Podría ocurrir que uno de los procesos adquiera am-
bos recursos y en efecto bloquee al otro proceso hasta que termine. Sin embargo, también podría
ocurrir que el proceso A adquiera el recurso 1 y el proceso B adquiera el recurso 2. Ahora cada uno
se bloqueará al tratar de adquirir el otro. Ninguno de los procesos se volverá a ejecutar. Esa situa-
ción es un interbloqueo.
Aquí podemos ver cómo lo que parece ser una diferencia insignificante en el estilo de codifi-
cación (cuál recurso adquirir primero) constituye la diferencia entre un programa funcional y uno
que falle de una manera difícil de detectar. Como los interbloqueos pueden ocurrir con tanta facili-
dad, gran parte de la investigación se ha enfocado en las formas de lidiar con ellos. En este capítu-
lo analizaremos los interbloqueos con detalle y lo que se puede hacer con ellos.
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller agusmitrobeda. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $5.49. You're not tied to anything after your purchase.
Can Stuvia be trusted?
4.6 stars on Google & Trustpilot (+1000 reviews)
62890 documents were sold in the last 30 days
Founded in 2010, the go-to place to buy study notes for 14 years now