Tarea 3 (Final)

FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA INGENIERÍA EN SOFTWARE

UNIVERSIDAD DE GUAYAQUIL
Tarea # 3
SISTEMAS OPERATIVOS
Investigación y exposición
INTEGRANTES
Baque Steven
Medina Julio
Reinoso Aarón
Sarmiento Joselyne
Curso
Sof-No-3-3
Comunicación y sincronización entre procesos

Comunicación entre procesos
la comunicación entre proceso es una función básica de los SO. Permite la
transferencia de información entre dos procesos. Los procesos pueden comunicarse
entre sí compartiendo espacio de memoria. Ya sean variables compartidas o buffers, o
a través de las herramientas provistas por las rutinas de IPC. (Inter-process
communication o Comunicación entre procesos)
Necesaria si se desea que varios procesos puedan colaborar para realizar una misma
tarea. El SO ofrece mecanismos básicos de comunicación, que permiten transferir
cadenas de bytes. Deben ser los procesos que se comunican quienes interpreten el
significado de las cadenas transferidas para su labor coordinada. Los mecanismos de
comunicación y sincronización son dinámicos. Es decir, cuando se necesita un
mecanismo de este estilo, se crea, usa y destruye, de forma que no se establezca de
forma definitiva ningún mecanismo de comunicación, ya que ellos podrían producir
efectos indeseados. Es decir, la comunicación es algo puntual.
Los servicios básicos de comunicación son:
✓ Crear: el proceso solicita la creación del mecanismo.
✓ Enviar o escribir: el proceso emisor envía información al proceso receptor.
✓ Recibir o leer: el proceso receptor recibe información.
✓ Destruir: el proceso solicita la destrucción del mecanismo de comunicación
La comunicación puede ser síncrona y asíncrona.
✓ Síncrona: los dos procesos han de ejecutar servicios de forma simultánea. El
emisor ha de ejecutar el servicio enviar mientras el receptor ejecuta recibir.
✓ Asíncrona: el emisor hace el envío y prosigue su ejecución. El SO ofrece un
almacenamiento intermedio para guardar la información enviada, hasta que el
receptor la solicite.
Sincronización entre procesos

Es necesaria para prevenir y corregir errores de sincronización debido al acceso
concurrente a recursos compartidos, tales como estructuras de datos o dispositivos de
E/S, de procesos contendientes. La sincronización entre procesos también permite
intercambiar señales de tiempo (ARRANQUE/PARADA) entre procesos cooperantes
para garantizar las relaciones específicas de precedencia impuestas por el problema
que se resuelve.
concurrente donde los procesos compiten por el acceso a los recursos compartidos o
cooperan dentro de una misma aplicación para comunicar información. coordinada a
los recursos y a los elementos de comunicación compartidos.
Un sistema operativo multiprogramado es un caso particular de sistema concurrente
donde los procesos compiten por el acceso a los recursos compartidos o cooperan
dentro de una misma aplicación para comunicar información. Ambas situaciones son
tratadas por el sistema operativo mediante mecanismos de sincronización que
permiten el acceso exclusivo de forma coordinada a los recursos y a los elementos de
comunicación compartidos.
Semáforo
Son herramientas poderosas para exclusión mutua y coordinación de procesos. Difícil

entender sus efectos cuando los wait(S) y signal(S) están esparcidos entre varios
procesadores.
El tiempo durante el cual un proceso esta loqueado en un semáforo no esta limitado
Un semáforo es una variable entera (positiva), cuyo valor solo puede ser accesado
mediante las operaciones atómicas y mutuamente wait y signal.
Wait (S) o P(S) o down(S)
Signal (S) o V(S) o up(S)
✓ WAIT (espera): verifica si el valor de un semáforo es mayor que cero y en este
así decrementa dicho valor y el proceso continúa. Si es cero, el proceso se va
a dormir.
Las modificaciones al valor del semáforo solo se ejecutan en forma indivisible,
es decir, si un proceso está modificando un semáforo ningún otro proceso
puede estar modificando el mismo valor.
✓ SIGNAL (señal): incrementa el valor del semáforo respectivo. Si uno o más
proceso dormían y no podían completar una operación SIGNAL anterior, el SO
elige alguno de ellos y se le permite terminar a operación WAIT.
Después de un SIGNAL en un semáforo con procesos durmiendo, dicho
semáforo seguirá con valor 0, pero habrá un menor número de procesos
durmiendo.
Para evitar busy-waiting, cuando un proceso tiene que esperar, se pondrá en
una cola de procesos bloqueados esperando un evento.
Semáforo puede ser implementado como una estructura con dos campos.
• Count: integer
• Queue: list of processes
Cuando un proceso debe esperar por un semáforo S, él es bloqueado (block ()) y
colocado en la cola del semáforo.
La operación de signal remueve (wakeup ()) un proceso desde la cola y lo coloca en la
lista de procesos ready.
Semáforo binario
Es un indicador de condición que registra si un recurso está disponible o no. Solo
puede tener dos valore, 0 y 1. Si para un semáforo binario, S = 1 entonces el recurso
esta disponible y la tarea lo puede utilizar; si S = 0 el recurso no está disponibles y el
proceso debe esperar, esta es la forma más común de semáforo.
Semáforo general
Son semáforo que pueden tomar muchos valores positivos.
Tuberías
Tubería con nombre o ficheros FIFOS
Se crean invocando a la llamada al sistema mknod y pueden ser utilizadas por
cualquier proceso siempre que disponga de los permisos adecuados. La sintaxis de
esta llamada es:
resultado= mknod (ruta, modo, 0);
El parámetro de entrada ruta permite especificar el nombre del fichero FIFO. Mientras
que modo permite especificar el tipo de fichero (S_IFIFO) y los usuales permisos de
acceso. Si la llamada al sistema se ejecuta con éxito en resultado se almacenará el
valor 0, en caso contrario se almacenará el valor -1.
La comunicación por medio de tuberías se basa en la interacción
productor/consumidor, los procesos productores (aquellos que envían datos) se
comunican con los procesos consumidores (que reciben datos) siguiendo un orden
FIFO. Una vez que el proceso consumidor recibe un dato, este se elimina de la
tubería.
Si se escribe en una tubería llena, se bloquea la ejecución del proceso hasta poder
escribir. Cuando todos los procesos escritos cierran la parte de escritura, entonces se
manda un final de fichero (EOF) a los lectores.
Tubería sin nombre

Una tubería es un mecanismo de comunicación unidireccional, que permite la
transmisión de un flujo de datos no estructurados de tamaño fijo.
Una tubería es un fichero especial que se crea con la llamada al sistema pipe () dicha
llamada crea la tubería y reserva do descripciones de ficheros: lectura y escritura
Las tuberías sin nombre se crean invocando a la llamada al sistema pipe y solamente
pueden ser utilizadas por el proceso que hace la llamada y sus descendientes. La
sintaxis de esta llamada es:
Resultado = pipe(tubería);
donde tubería es un array entero de dos elementos, mientras que resultado es una
variable entera. Si la llamada al sistema se ejecuta con éxito en resultado se
almacenará el valor 0 y en tubería se habrán almacenado dos descriptores de ficheros.
Para leer de la tubería hay que usar el descriptor almacenado en tubería [0], mientras
que para escribir en la tubería hay que usar el descriptor almacenado en tubería [1].
En caso de error durante la ejecución de pipe en resultado se almacenará el valor -1.
Como mecanismo IPC, las tuberías proporcionan una forma eficiente de transferir
datos de un proceso a otro. Sin embargo, poseen algunas limitaciones importantes:
✓ Una tubería no puede ser utilizada para transmitir datos a múltiples procesos
receptores de forma simultánea, ya que al leer los datos de la tubería estos son
borrados.
✓ Si existen varios procesos que desean leer en un extremo de la tubería, un

proceso que escriba en el otro extremo no puede dirigir los datos a un proceso
en concreto. Asimismo, si existen varios procesos que desean escribir en la
tubería, no existe forma de determinar cuál de ellos envía los datos.
✓ Si un proceso envía varios mensajes de diferente longitud en una sola

operación de escritura en la tubería, el proceso que lee el otro extremo de la
tubería no puede determinar cuántos mensajes han sido enviados, o donde
termina un mensaje y donde empieza el otro, ya que los datos en la tubería son
tratados como un flujo de bytes no estructurados de tamaño fijo.
Mutex
Cuando no se necesita la habilidad del semáforo de contar, algunas veces se utiliza
una versión simplificada, llamada mutex. Los mutexes son buenos sólo para
administrar la exclusión mutua para cierto recurso compartido o pieza de código. Se
implementan con facilidad y eficiencia, lo cual hace que sean especialmente útiles en
paquetes de hilos que se implementan en su totalidad en espacio de usuario.
Un mutex es una variable que puede estar en uno de dos estados: abierto
(desbloqueado) o cerrado (bloqueado). En consecuencia, se requiere sólo 1 bit para
representarla, pero en la práctica se utiliza con frecuencia un entero, en donde 0 indica
que está abierto y todos los demás valores indican que está cerrado. Se utilizan dos
procedimientos con los mutexes. Cuando un hilo (o proceso) necesita acceso a una
región crítica, llama a mutex_lock. Si el mutex está actualmente abierto (lo que
significa que la región crítica está disponible), la llamada tiene éxito y entonces el hilo
llamador puede entrar a la región crítica.
Por otro lado, si el mutex ya se encuentra cerrado, el hilo que hizo la llamada se
bloquea hasta que el hilo que está en la región crítica termine y llame a
mutex_unlock. Si se bloquean varios hilos por el mutex, se selecciona uno de ellos al
azar y se permite que adquiera el mutex. Como los mutexes son tan simples, se
pueden implementar con facilidad en espacio de usuario, siempre y cuando haya una
instrucción TSL o XCHG disponible.
Son elementos del POSIX para el manejo de secciones críticas y evitar que múltiples
hilos ingresen en las mismas. Las funciones más importantes para su uso son:
int pthread_mutex_init(pthread_mutex_t *restrict mutex,
const pthread_mutexattr_t *restrict attr);
int pthread_mutex_destroy(pthread_mutex_t *mutex);
int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_unlock (pthread_mutex_t *mutex);
Las primeras dos funciones servirán para crear y destruir las variables para control de
la sección crítica. Las siguientes te permitirán controlar la entrada y la salida de la
sección respectivamente. Es necesario tener en cuenta si las funciones requieren
punteros o no. El siguiente ejemplo muestra la forma en que se pueden lanzar
múltiples hilos, declarando los descriptores para cada uno como arreglos. Lo anterior
permite que se inicialicen las variables, se lancen los hilos y se sincronicen mediante
ciclos for. En el ejemplo se define una función llamada proceso que recibe un puntero
a una estructura, para mostrar un dato un número de veces p.
Problemas de concurrencia
El peluquero dormilon
El problema consiste en una barbería en la que trabaja un barbero que tiene un único
sillón de barbero y varias sillas para esperar. Cuando no hay clientes, el barbero se
sienta en una silla y se duerme. Cuando llega un nuevo cliente, éste o bien despierta
al barbero o —si el barbero está afeitando a otro cliente— se sienta en una silla (o se
va si todas las sillas están ocupadas por clientes esperando). El problema consiste en
realizar la actividad del barbero sin que ocurran condiciones de carrera. La solución
implica el uso de semáforos y objetos de exclusión mutua para proteger la sección
crítica.
Un semáforo es una variable protegida (o tipo abstracto de datos) que constituye el

método clásico para restringir o permitir el acceso a recursos compartidos (por
ejemplo, un recurso de almacenamiento) en un entorno de multiprocesamiento. Fueron
inventados por Edsger Dijkstra y se usaron por primera vez en el sistema operativo
THEOS.
En electrónica y en programación concurrente, se conoce como condición de carrera

al error que se produce en programas o circuitos lógicos que no se han construido
adecuadamente para su ejecución simultánea con otros procesos.
Implementacion
El próximo pseudo-código garantiza la sincronización entre el barbero y el cliente, pero

puede llevar a inanición del cliente. wait() y signal() son funciones provistas por
el semáforo.
Se necesita:
Semáforo barberoListo = 0 // (Mutex, sólo 1 o 0)

Semáforo sillasAccesibles = 1 // (Mutex) Cuando sea 1, el número de sillas libres puede
aumentar o disminuir
Semáforo clientes = 0 // Número de clientes en la sala de espera
int sillasLibres = N // N es el número total de sillas
• Función barbero (Proceso/hilo-thread):
while(true) // Ciclo infinito

{
wait(clientes) // Espera la señal de un hilo cliente para despertar.
wait(sillasAccesibles) // (Ya está despierto) Espera señal para poder modificar
sillasLibres.
sillasLibres += 1 // Aumenta en uno el número de sillas libres.
signal(barberoListo) // El barbero está listo para cortar y manda señal al hilo cliente.
signal(sillasAccesibles) // Manda señal para desbloquear el acceso a sillasLibres
// Aquí el barbero corta el pelo de un cliente (zona de código no crítico).
}
• Función cliente (Proceso/hilo-thread):
wait(sillasAccesibles) // Espera la señal para poder acceder a sillasLibres.
if (sillasLibres > 0) // Si hay alguna silla libre, se sienta en una.
{
sillasLibres -= 1 // Decrementando el valor de sillasLibres en 1.
signal(clientes) // Manda señal al barbero de que hay un cliente disponible.
signal(sillasAccesibles) // Manda señal para desbloquear el acceso a sillasLibres.
wait(barberoListo) // El cliente espera a que el barbero esté listo para atenderlo.
// Se le corta el pelo al cliente.
}
else // Si no hay sillas libres.
{
signal(sillasAccesibles) // Manda señal para desbloquear el acceso a sillasLibres.
// El cliente se va de la barbería y no manda la señal de cliente disponible.
}
Problema de lectores y editores

El problema de los lectores y escritores es un problema clásico
de la teoría informática, que permite modelar el acceso a las bases de datos .
Así lo planteó Edsger Dijkstra , que también está en el origen del problema de la cena
de los filósofos (problema relacionado en particular con el ordenamiento de los
procesos)
Suponga que una base de datos tiene lectores y escritores, y los lectores y escritores
de esa base de datos deben estar programados.
Las restricciones son las siguientes:
• varios lectores deben poder leer la base de datos al mismo tiempo;
• si un editor está modificando la base de datos, ningún otro usuario (ni editor ni lector)
debería poder acceder a ella.
Es bastante sencillo tener el editor en espera mientras todavía hay lectores.

Pero esta solución presenta grandes problemas, si el flujo de lectores es regular: el
editor podría tener que esperar un tiempo infinito.
Por tanto, existe una segunda solución, que consiste en poner en espera a todos los
lectores que han enviado su solicitud de acceso después de la de un editor.
Edsger Dijkstra , quien formuló este problema, propone resolverlo
mediante semáforos .
Solución con uso de semáforos y prioridad a los lectores
La siguiente solución resuelve el problema de lectores y escritores al priorizar a los
lectores. Esta solución requiere tres semáforos y una variable, a saber:
• Un semáforo M_Lect , inicializado a 1, que permite proteger la variable lect. Por

tanto, es un mutex .
• Un semáforo M_Red , inicializado a 1, que permite bloquear las tareas de
escritura (dando prioridad a los lectores). Por tanto, es un mutex .
• Un semáforo rojo , inicializado a 1, que permite bloquear las tareas de lectura si
se está escribiendo en curso.
• Variable lectque cuenta el número de lectores.
Esta solución utiliza los siguientes cuatro métodos:

Empieza a leer
Commencer_Lire:
P(M_Lect)
SI (red) ALORS
pbloque=true
V(M_Lect)
p(synch)
FIN SI
SINON
lect++;
V(M_Lect)
Este método incrementa el número de lectores; entonces, si este es el primer lector

que intenta ingresar, solo permite la entrada si no hay escritura actual. De lo contrario,
el método debe esperar hasta que finalice la redacción. El uso de dos semáforos para
los editores permite inducir la prioridad a los lectores.
Termina una lectura
Finir_Lire:
P(M_Lect)
lect--
SI Lect==0 ALORS
V(Red)
FIN SI
V(M_Lect)
Este método reduce el número de lectores. Luego, si este es el último lector en salir,
permite que los editores ingresen (si es necesario).
Empiece a escribir
Commencer_Ecrire:
P(M_Red)
P(Red)
SI (red or lect>0) ALORS
pbloque=true
V(Red)
SINON
red=true
V(Red)
V(M_Red)
Este método que utiliza el semáforo M_Red permite garantizar que se dé prioridad a
los lectores al final de un escritor (de hecho, el final de un escritor libera el semáforo
rojo, liberando así a un posible lector, antes de liberar el semáforo M_Red).
Terminar una escritura
Finir_Ecrire:
V(Red)
V(M_Red)
Este método permite asegurar que se dé prioridad a los lectores (de hecho, liberar el
semáforo rojo libera a un posible lector antes de liberar un posible editor usando el
semáforo M_Red).
Solución con copia asincrónica de la estructura de datos
Suponga que el objetivo de los lectores es leer datos de forma asincrónica. Todos los
lectores tienen la información en el momento en que se realizó su solicitud
(posiblemente desde una máquina remota).
O un puntero de DATOS a una estructura de datos que contiene toda la información
disponible. Los editores enviarán solicitudes que se almacenarán en una cola
de ARCHIVO .
Un mutex M1 protege la siguiente estructura:
Liste de DATA : PRECEDENT
DATA : ACTUEL
DATA : PROCHAIN
booléen : MISAJOUR
Un mutex M2 protege la siguiente estructura:
File de mises à jour : FILE
Date de dernière modification : DERNIER
Código ejecutado por el lector
verrouille M1:
si MISAJOUR est vrai:
enfile ACTUEL dans PRECEDENT
pour chaque élément de PRECEDENT:
effacer l'élément si son compteur de références est nul (1)
fin pour
ACTUEL := PROCHAIN (2)
PROCHAIN := copie de ACTUEL
MISAJOUR := faux
fin si
récupérer un pointeur P sur ACTUEL et incrémenter son compteur de références
déverrouille M1
lire dans P
...
décrémenter le compteur de références de P
Código ejecutado por el escritor
verrouille M2:
enfiler les modifications dans FILE
si DERNIER est dépassé de 10 secondes:
verrouiller M1:
effectuer toute modification de FILE dans PROCHAIN
vider FILE
MISAJOUR:= vrai (3)
déverrouille M1
fin si
déverrouille M2
Observaciones
1. Cuando se ha actualizado la estructura de datos, su versión anterior puede

permanecer como puntero en procesos ligeros concurrentes. Por tanto, una buena
forma de evitar pérdidas de memoria es mantener un contador de referencia para
borrar las áreas de memoria puntiagudas cuando ya no lo esté utilizando ningún otro
proceso.
2. ACTUAL y SIGUIENTE son punteros estáticos, copiar el segundo al primero
equivale a una asignación de puntero. Como se dijo en el primer punto, el puntero
antiguo permanece en los procesos de luz ejecutados anteriormente. Por otro lado,
en la siguiente línea, se realiza una copia completa de los datos señalados por
CURRENT y apunta a NEXT a la copia.
3. El simple hecho de establecer este booleano en verdadero permitirá a los futuros
lectores utilizar la versión correcta de los datos.
Este modelo es adecuado cuando las actualizaciones no requieren la gestión de

transacciones, que deben proporcionar las bases de datos .
Problema del productor - consumidor

El problema del productor- consumidor es un ejemplo clásico de problema de
sincronización de multiprocesos. El programa describe dos procesos, productor y
consumidor, ambos comparten un buffer de tamaño finito. La tarea del productor es
generar un producto, almacenarlo y comenzar nuevamente; mientras que el
consumidor toma (simultáneamente) productos uno a uno. El problema consiste en
que el productor no añada más productos que la capacidad del buffer y que el
consumidor no intente tomar un producto si el buffer esta vació.
La idea para la solución es la siguiente, ambos procesos (productor y consumidor) se
ejecutan simultáneamente y se “despiertan” o se “duermen” según el estado del buffer.
Concretamente, el productor agrega productos mientras quede espacio y en el
momento en que se llene el buffer se pone a “dormir”. Cuando el consumidor toma un
producto notifica al productor que puede comenzar a trabajar nuevamente. En caso
contrario, si el buffer se vacía, el consumidor se pone a dormir y en el momento en que
el productor agrega un producto crea una señal para despertarlo. Se puede encontrar
una solución usando mecanismos de comunicación de interprocesos, generalmente se
usan semáforos.
Solución usando semáforos

El uso de semáforos resuelve el problema de las llamadas perdidas. En la solución
que se muestra a continuación se usan dos semáforos fillCount y emptyCount . El
primero es el número de objetos que existen en el buffer mientras que emptyCount es
el número de espacios disponibles donde se puede insertar objetos. fillCount es
incrementado y emptyCount es decrementado cuando se inserta un objeto en el buffer.
Si el productor intenta decrementar emptyCount cuando su valor es cero, el productor
es puesto a dormir. La próxima vez que se consuma un objeto el productor despierta.
El consumidor funciona análogamente.
semaphore fillCount = 0; // items produced

semaphore emptyCount = BUFFER_SIZE; // remaining space
procedure producer() {
while (true) {
item = produceItem();
down(emptyCount);
putItemIntoBuffer(item);
up(fillCount);
}
}
procedure consumer() {
while (true) {
down(fillCount);
item = removeItemFromBuffer ();
up(emptyCount);
consumeItem(item);
}
}
Problemas de Los Filósofos Comensales

El problema de la cena de los filósofos o problema de los filósofos comensales
(dining philosophers problem) es un problema clásico de las ciencias de la
computación propuesto por Edsger Dijkstra en 1965 para representar el
problema de la sincronización de procesos en un sistema operativo.
Enunciado
Cinco filósofos se sientan alrededor de una mesa y pasan su vida cenando y

pensando. Cada filósofo tiene un plato de fideos y un tenedor a la izquierda de
su plato. Para comer los fideos son necesarios dos tenedores y cada filósofo
sólo puede tomar los que están a su izquierda y derecha. Si cualquier filósofo
toma un tenedor y el otro está ocupado, se quedará esperando, con el tenedor
en la mano, hasta que pueda tomar el otro tenedor, para luego empezar a
comer.
Si dos filósofos adyacentes intentan tomar el mismo tenedor a una vez, se
produce una condición de carrera: ambos compiten por tomar el mismo
tenedor, y uno de ellos se queda sin comer.
Si todos los filósofos toman el tenedor que está a su derecha al mismo tiempo,
entonces todos se quedarán esperando eternamente, porque alguien debe
liberar el tenedor que les falta. Nadie lo hará porque todos se encuentran en la
misma situación (esperando que alguno deje sus tenedores). Entonces los
filósofos se morirán de hambre. Este bloqueo mutuo se denomina interbloqueo
o deadlock.
El problema consiste en encontrar un algoritmo que permita que los filósofos
nunca se mueran de hambre.
El problema planteado cuenta con diversas soluciones:
• Por turno cíclico

Se empieza por un filósofo, que si quiere puede comer y después pasa su turno
al de la derecha. Cada filósofo sólo puede comer en su turno. Problema: si el
número de filósofos es muy alto, uno puede morir de hambre antes de su turno.
• Varios turnos
Se establecen varios turnos. Para hacerlo más claro supongamos que cada
filósofo que puede comer (es su turno) tiene una ficha que después pasa a la
derecha. Si por ejemplo hay 7 comensales podemos poner 3 fichas en
posiciones alternas (entre dos de las fichas quedarían dos filósofos).
Se establecen turnos de tiempo fijo. Por ejemplo, cada 5 minutos se pasan las
fichas (y los turnos) a la derecha.
• Colas de tenedores
Cuando un filósofo quiere comer se pone en la cola de los dos tenedores que
necesita. Cuando un tenedor está libre lo toma. Cuando toma los dos
tenedores, come y deja libre los tenedores.
Visto desde el otro lado, cada tenedor sólo puede tener dos filósofos en cola,
siempre los mismos.
• Resolución de conflictos en colas de tenedores

Cada vez que un filósofo tiene un tenedor espera un tiempo aleatorio para
conseguir el segundo tenedor. Si en ese tiempo no queda libre el segundo
tenedor, suelta el que tiene y vuelve a ponerse en cola para sus dos tenedores.
Si un filósofo A suelta un tenedor (porque ha comido o porque ha esperado
demasiado tiempo con el tenedor en la mano) pero todavía desea comer,
vuelve a ponerse en cola para ese tenedor. Si el filósofo adyacente B está ya
en esa cola de tenedor (tiene hambre) lo toma y si no vuelve a cogerlo A.
• El portero del comedor

Se indica a los filósofos que abandonen la mesa cuando no tengan hambre y
que no regresen a ella hasta que vuelvan a estar hambrientos (cada filósofo
siempre se sienta en la misma silla). La misión del portero es controlar el
número de filósofos en la sala, limitando su número a n-1, pues si hay n-1
comensales seguro que al menos uno puede comer con los dos tenedores.
Introducción a interbloqueos
¿Qué se entiende por interbloqueo?
Es el bloqueo permanente de un conjunto de procesos que juntos compiten por recursos del
sistema o se comunican entre ellos.
Entran en conflicto por recursos necesitados por dos o más procesos.

Recursos reusables:
Usados por un proceso en el momento y no se agota por ese uso
❖ Tiempo del procesador

❖ Canales de E/S
❖ Memoria principal y secundaria
❖ Archivos
❖ Base de datos
❖ Semáforos
El interbloqueo ocurre si cada proceso retiene un recurso y solicita otro.
Recursos consumibles:
Creados (producidos) y destruidos (consumidos) por un proceso
❖ Interrupciones
❖ Señales
❖ Mensajes
❖ Información en buffers de E/S
El interbloqueo puede ocurrir si la recepción de un mensaje es bloqueante.
Puede llevar una rara combinación de eventos que causen el interbloqueo.

Detección y recuperación de un interbloqueo
1.- Fase de detección:
Debe ejecutarse un algoritmo que determine si el estado actual del sistema esté libre de
bloqueo y que, en caso de que no lo esté, identifique qué procesos están implicados en el
interbloqueo.
Se realiza mediante la aplicación del concepto de reducción a partir de una representación del
sistema (procesos y recursos) mediante un grafo.
Sea N = Conjunto que contiene los nodos del grafo (formado por los recursos y los procesos)
Sea A = Conjunto de las aristas que conectan a los nodos del grafo
Estado inicial
S = ∅ (Conjunto de la secuencia de la reducción)
D = Conjunto de procesos desbloqueados que NO están en el conjunto S
Mientras 𝐷 ≠ ∅, se puede reducir cualquier proceso del conjunto D y añadirlo a S
Si 𝐷 = ∅ 𝑦 𝑆 = 𝑃, donde P es el conjunto de todos los procesos
Entonces No existe interbloqueo
Sino los procesos del conjunto resultante P-S están en interbloqueo
2.- Fase de recuperación:
Una vez detectado el bloqueo mutuo, se debe aplicar una acción que lo elimine.
Permitir al sistema operativo recuperarse después de la ocurrencia de un deadlock, sin

intervención directa del operador.
Alternativas:
I) Abortar uno o más procesos.

II) Arrebatar recursos a uno o más procesos que se encuentran en deadlock
Abortar
Método:
Abortar todos los procesos en deadlock
*Costo alto.
*Pérdida total del trabajo realizado.
- Abortar un proceso a la vez, hasta que el deadlock haya sido eliminado:
Factores para la escogencia del proceso:
1.- Prioridad de los procesos.
2.- Cuantos y que tipos de recursos tiene asignado el proceso.
3.- Cuantos recursos más necesita el proceso para culminar.
4.- Tiempo que lleva ejecutado cada proceso.
Como evitar interbloqueos

Si se presentan las condiciones necesarias para un bloqueo mutuo, todavía es posible predecir
su ocurrencia mediante una cuidadosa asignación de recursos.
Se concede únicamente las peticiones de recursos disponibles que no conduzcan a estados

propensos a interbloqueos.
Como prevenir interbloqueos
Exclusión mutua: Los recursos implicados deben usarse en exclusión mutua, o sea, debe
tratarse de recursos de uso exclusivo.
Solo debe conservarse par aquellos recursos que por naturaleza propia o función no pueden
compartirse.
Contención y espera: Cuando no se puede satisfacer la petición de un proceso, éste se bloquea

manteniendo los recursos que tenía previamente asignados.
No apropiativa: Los recursos no se pueden quitar, es decir, un recurso sólo puede ser liberado
voluntariamente por el proceso que lo retiene, después que haya cumplido su tarea.
Espera circular: Debe existir una cadena circular de procesos tal que cada proceso en la lista
esté esperando por uno o más recursos que tiene asignado el siguiente proceso.
Caracterización y administración de la Sección crítica de un proceso.

¿Qué es la sección crítica?
Se denomina así a la porción de código de un programa de ordenador en la que se accede a un

recurso compartido (estructura de datos o dispositivo). Que no debe ser accedido por más de
un proceso o hilo en ejecución.
• Comandos para administración de procesos.
man ps
– Ver ayuda del comando ps
ps aux
– Muestra todos los procesos del sistema
ps axjf
– Mostrar árbol jerárquico con la ruta del programa al que pertenece
ps aux | grep bash

– Filtrado para obtener unicamente los procesos pertenecientes a bash
ps -U root -u root u
– Muestra cada proceso con permiso root
top
– Informe en tiempo real
man top
– Ver ayuda del comando top
top -o %CPU
– Donde %CPU es el valor por el que vamos a ordenar los procesos
top –d 5
– Donde 5 es el número de segundos a transcurrir entre cada muestreo
top –u usuario
– Donde usuario es el usuario del cual queremos mostrar los procesos
htop
– Administra interactivamente los procesos del sistema
man htop
– Ver ayuda del comando top
htop -d –delay=TIEMPO
– Tiempo de espera para refrescar (Tiempo en décimas de segundo)
htop -C –no-color –no-colour

– Arranca htop en blanco y negro (Monocromo)
htop -u –user=USUARIO
– Muestra solo los procesos de dicho usuario
kill [PID del proceso]

– Gestiona función de cierre, completa tareas necesarias y limpia la información
cargada en memoria
kill –KILL [PID del proceso]

– Eliminar proceso por la fuerza
pkill -9 [Nombre del proceso]

– Función de cierre con nombre del proceso en vez de PID
kill –HUP [PID de Apache]

– Reinicio de Apache
killall [programa]
– Variante de kill, cierra todos los procesos de un programa

Tarea 3 (Final)

Cargado por

Copyright:

Formatos disponibles

Tarea 3 (Final)

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tarea 3 (Final)

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS

CARRERA INGENIERÍA EN SOFTWARE

Comunicación y sincronización entre procesos

Sincronización entre procesos

Son herramientas poderosas para exclusión mutua y coordinación de procesos. Difícil

Tubería sin nombre

✓ Si existen varios procesos que desean leer en un extremo de la tubería, un

✓ Si un proceso envía varios mensajes de diferente longitud en una sola

Un semáforo es una variable protegida (o tipo abstracto de datos) que constituye el

En electrónica y en programación concurrente, se conoce como condición de carrera

El próximo pseudo-código garantiza la sincronización entre el barbero y el cliente, pero

Semáforo barberoListo = 0 // (Mutex, sólo 1 o 0)

while(true) // Ciclo infinito

Problema de lectores y editores

Es bastante sencillo tener el editor en espera mientras todavía hay lectores.

• Un semáforo M_Lect , inicializado a 1, que permite proteger la variable lect. Por

Esta solución utiliza los siguientes cuatro métodos:

Este método incrementa el número de lectores; entonces, si este es el primer lector

Date de dernière modification : DERNIER

Código ejecutado por el lector

Código ejecutado por el escritor

1. Cuando se ha actualizado la estructura de datos, su versión anterior puede

Este modelo es adecuado cuando las actualizaciones no requieren la gestión de

Problema del productor - consumidor

Solución usando semáforos

semaphore fillCount = 0; // items produced

semaphore emptyCount = BUFFER_SIZE; // remaining space

Problemas de Los Filósofos Comensales

Cinco filósofos se sientan alrededor de una mesa y pasan su vida cenando y

El problema planteado cuenta con diversas soluciones:

• Por turno cíclico

• Resolución de conflictos en colas de tenedores

• El portero del comedor

Entran en conflicto por recursos necesitados por dos o más procesos.

Usados por un proceso en el momento y no se agota por ese uso

❖ Tiempo del procesador

El interbloqueo ocurre si cada proceso retiene un recurso y solicita otro.

Creados (producidos) y destruidos (consumidos) por un proceso

El interbloqueo puede ocurrir si la recepción de un mensaje es bloqueante.

Puede llevar una rara combinación de eventos que causen el interbloqueo.

Detección y recuperación de un interbloqueo

1.- Fase de detección:

S = ∅ (Conjunto de la secuencia de la reducción)

D = Conjunto de procesos desbloqueados que NO están en el conjunto S

Mientras 𝐷 ≠ ∅, se puede reducir cualquier proceso del conjunto D y añadirlo a S

Si 𝐷 = ∅ 𝑦 𝑆 = 𝑃, donde P es el conjunto de todos los procesos

Entonces No existe interbloqueo

Sino los procesos del conjunto resultante P-S están en interbloqueo

2.- Fase de recuperación:

Permitir al sistema operativo recuperarse después de la ocurrencia de un deadlock, sin

I) Abortar uno o más procesos.

Abortar todos los procesos en deadlock

*Pérdida total del trabajo realizado.

- Abortar un proceso a la vez, hasta que el deadlock haya sido eliminado:

Factores para la escogencia del proceso:

1.- Prioridad de los procesos.

2.- Cuantos y que tipos de recursos tiene asignado el proceso.

3.- Cuantos recursos más necesita el proceso para culminar.

4.- Tiempo que lleva ejecutado cada proceso.

Como evitar interbloqueos