Cap08 - Sincronizacion de Procesos

SISTEMAS
OPERATIVOS
DEPARTAMENTO DE
CIENCIAS DE LA COMPUTACION
UNIVERSIDAD NACIONAL
DEL COMAHUE
CAPITULO 8
Sincronización
de
Procesos
TEMARIO
Motivaciones
El problema de Productores/Consumidores
El problema de la Sección Crítica
Hardware de sincronización
Semáforos
Problemas clásicos de sincronización
Construcciones de lenguaje
Sistemas Operativos 2008 Capítulo 8 3

MOTIVACIONES
El acceso concurrente de procesos cooperativos a
datos compartidos puede generar inconsistencias en
los datos.
Para evitar esas inconsistencias es necesario

disponer de mecanismos que garanticen la ejecución
correctamente ordenada de los procesos
cooperativos.
Veamos un ejemplo clásico de procesos cooperativos.

PRODUCTORES/CONSUMIDORES
Procesos productores producen información que es

consumida por procesos consumidores.
El intercambio de información se realiza sobre un

buffer de memoria compartida.

El buffer compartido puede tener:
Capacidad limitada: admite un máximo de N

elementos.
Capacidad ilimitada: no hay límite en la cantidad

de elementos que puede contener.

Restricciones:
Si el buffer está vacío, ningún proceso consumidor

puede consumir, y por lo tanto debe esperar que un
proceso productor produzca.
Si el buffer está lleno, ningún proceso productor

puede producir, y por lo tanto debe esperar que un
proceso consumidor consuma (esto no ocurre con
buffer ilimitado).
No puede acceder al buffer más de un proceso a la

vez, sea este productor o consumidor.

SOLUCION AL PROBLEMA DE
Datos compartidos:
type item=....;
var buffer: array [0..n-1] of item;
in, out: 0..n-1;
counter: 0..n;
in, out, counter:=0;

Proceso Productor Proceso Consumidor
repeat repeat
.... while counter=0 do no-op;
producir un item en nextp nextc:=buffer[out];
.... out:=out+1 mod n;
while counter=n do no-op; counter:=counter-1;
buffer[in]:=nextp; ....
in:=in+1 mod n; consumir item de nextc
counter:=counter+1; ....
until false; until false;

Las instrucciones
counter:=counter+1; productor
counter:=counter-1; consumidor
se deben ejecutar atómicamente.
Una operación es atómica si se ejecuta en forma

completa sin interrupciones (por ejemplo, una
instrucción de máquina).

La traducción a lenguaje de máquina de ambas

instrucciones es:
counter:=counter+1 counter:=counter-1
registro1 counter registro2 counter

registro1 registro1+1 registro2 registro2-1
counter registro1 counter registro2

Si el productor y el consumidor intentan

modificar el buffer concurrentemente, puede
suceder que las instrucciones de máquina se
intercalen dando resultados no esperados.
La intercalación de instrucciones va a depender

de como sean planificados los procesos
productor y consumidor.

Supongamos que el valor inicial de counter es 5. Una
posible secuencia de ejecución de las instrucciones
de máquina es:
Prod registro1 counter registro1 = 5

Prod registro1 registro1 + 1 registro1 = 6
Cons registro2 counter registro2 = 5
Cons registro2 registro2 – 1 registro2 = 4
Prod counter registro1 counter = 6
Cons counter registro2 counter = 4
El valor final de counter va a ser 4.

Veamos otra posible secuencia de ejecución de las
instrucciones de máquina:
Prod registro1 counter registro1 = 5

Prod registro1 registro1 + 1 registro1 = 6
Cons registro2 counter registro2 = 5
Cons registro2 registro2 – 1 registro2 = 4
Cons counter registro2 counter = 4
Prod counter registro1 counter = 6
Ahora, el valor final de counter va a ser 6.

En ambos casos, el valor final de counter debería
haber sido 5, pues un productor produjo un ítem y
un consumidor consumió un ítem.
Se pueden considerar otras secuencias de

ejecución de las instrucciones de máquina y se
obtendrán resultados diferentes.

CONDICION DE CARRERA
Esos resultados distintos se producen porque no se

sabe a priori el orden en que se realizan las diversas
operaciones.
Este fenómeno es conocido como Condición de

Carrera.

CONDICION DE CARRERA
Cuando varios procesos acceden y manipulan

datos compartidos en forma concurrente, el
resultado final depende del proceso que finalizó
último.
Para prevenir la ocurrencia de la condición de

carrera, los procesos concurrentes que acceden a
datos compartidos (procesos cooperativos) deben
estar sincronizados.

SINCRONIZACION DE PROCESOS
Se han sugerido diferentes soluciones para

sincronizar procesos, algunas de software y
otras de hardware.
El principal concepto empleado para sincronizar

procesos es el de la Sección Crítica.

EL PROBLEMA DE LA SECCION CRITICA
n procesos compiten en el uso de algún dato

compartido.
Cada proceso tiene una porción de código,

llamada sección crítica, en la que accede al dato
compartido.
El problema consiste en asegurar que cuando un

proceso está ejecutando su sección crítica ningún
otro proceso tenga acceso a ejecutar su
correspondiente sección crítica.

El programador es el responsable de definir con

claridad la sección crítica en cada uno de los
procesos involucrados.
La sección crítica de cada proceso debe ser lo

más pequeña posible para no entorpecer al
conjunto.
Se deben cumplir varias condiciones para que

funcione la sincronización entre el conjunto de
procesos.

Toda solución al problema de la sección crítica debe

cumplir las siguientes tres condiciones:
1. Exclusión mutua
2. Progreso
3. Espera definida

Exclusión mutua:
Si el proceso Pi esta ejecutando en su sección

crítica, entonces ninguno de los otros procesos del
conjunto pueden estar ejecutando en sus
correspondientes secciones críticas.

Progreso:
Si ningún proceso del conjunto está ejecutando en

su sección crítica, y hay algunos procesos que
desean entrar en su correspondiente sección crítica,
la selección del próximo proceso que entrará en la
sección crítica no se puede posponer
indefinidamente.

Espera definida:
Desde que un proceso hace un requerimiento para

ingresar en su sección crítica y hasta que ese
requerimiento sea garantizado, se debe limitar la
cantidad de veces que otros procesos sean
autorizados a entrar en sus respectivas secciones
críticas.

Espera definida:
Esta condición parte de 2 consideraciones:
Cada proceso se ejecuta a una velocidad distinta

de cero.
No se conoce a priori la velocidad relativa de los n

procesos.

Consideraremos sólo 2 procesos, P0 y P1. La estructura

general del proceso Pi es:
repeat
sección de entrada
sección crítica
sección de salida
sección restante
until false;
P0 y P1 pueden compartir algunas variables comunes

para sincronizarse.

ALGORITMO 1
Variables compartidas:
int turno;
inicialmente turno=0
turno=i ⇒ Pi puede entrar en su SC
Proceso Pi :
repeat
while (turno !=i) do no-op;
sección crítica
turno=j;
sección restante
until false;

ALGORITMO 1
Se satisface la condición de exclusión mutua.
No se satisface la condición de progreso:
Si Pi ejecuta la sección crítica y le deja el turno a Pj,

pero, por razones de velocidad de ejecución,
nuevamente llega Pi a pedir la sección crítica, no
podrá entrar hasta que Pj ejecute su sección crítica
y le pase el turno a Pi.

ALGORITMO 2
boolean flag[2]; inicialmente flag[0]=flag[1]=false

flag[i]=true ⇒ Pi está listo para
entrar en su sección crítica
Proceso Pi :
repeat
flag[i]:=true;
while (flag[j]) do no-op;
sección crítica
flag[i]=false;
sección restante
until false;

ALGORITMO 2
No se satisface la condición de progreso:
El análisis es similar al del algoritmo 1. Esta vez el

turno está dado por el seteo del flag.

ALGORITMO 3
Variables compartidas: combina las de los algoritmos 1 y 2
Proceso Pi :
repeat
flag[i]:=true;
turno=j;
while (flag[j] and turno=j) do no-op;
sección crítica
flag[i]=false;
sección restante
until false;

ALGORITMO 3
Probar si se satisfacen las restantes condiciones.

SOLUCIONES PARA 2 PROCESOS
Toda solución al problema de la sección crítica

para 2 procesos debe satisfacer las 3 condiciones:
exclusión mutua, espera definida y progreso.
Si alguna de ellas no se cumple, entonces no es

una solución válida aunque verifique la exclusión
mutua.

SOLUCIONES PARA 2 PROCESOS
El algoritmo de la panadería:
Antes de entrar en su SC, cada proceso recibe un

número: el proceso que posea el número más
pequeño es el que entrará en la SC.
Si dos procesos Pi y Pj reciben el mismo número,

entonces si i < j Pi será atendido primero; de lo
contrario Pj será atendido primero.
El esquema de numeración siempre produce

números en orden creciente: 1, 2, 3, 3, 3, 3, 4, 5...

SINCRONIZACION POR HARDWARE
Hasta acá hemos desarrollado soluciones mediante

software.
Existen también varias soluciones por hardware.

Las que veremos:
Inhibir interrupciones
TestAndSet
Swap

INHIBIR INTERRUPCIONES
Consiste en impedir la ocurrencia de

interrupciones mientras se ejecuta el conjunto
de instrucciones de la sección crítica.
Solo es posible de implementar en un ambiente

monoprocesador.
Es una alternativa muy riesgosa para el sistema.

EXCLUSION MUTUA CON INHIBICION
DE INTERRUPCIONES
Proceso Pi :
repeat
inhibir interrupciones;
sección crítica
desinhibir interrupciones;
sección restante
until false;

TestAndSet
Es una instrucción del procesador que modifica el

contenido de una variable. Su “código” es:
function TestAndSet(var target:boolean):boolean

begin
TestAndSet:=target;
target:=true;
end;
Al ser una instrucción de máquina se ejecuta en

forma atómica.

EXCLUSION MUTUA CON TestAndSet
var lock:boolean; inicialmente en false
Proceso Pi :
repeat
while TestAndSet(lock) do no-op;
sección crítica
lock:=false;
sección restante
until false;

SWAP
Instrucción del procesador que intercambia el valor

entre dos variables. Su “código” es:
procedure swap(var a,b:boolean)

var temp:boolean
begin
temp=a;
a=b;
b=temp;
end;
Igual que TestAndSet, se ejecuta atómicamente.

EXCLUSION MUTUA CON SWAP
var lock:boolean; inicialmente lock=false
Proceso Pi :
var key:boolean;
repeat
key:=true;
repeat
swap(lock,key);
until key=false;
sección crítica
lock:=false;
sección restante
until false;

SEMAFOROS
Son herramientas de sincronización de procesos

provistas por el Sistema Operativo.
Un semáforo consta de 3 elementos:
Una variable entera S;
Dos operaciones atómicas sobre S:

• wait(S) ó P(S) Solicitud de recurso
• signal(S) ó V(S) Liberación de recurso

SEMAFOROS
La implementación de las operaciones es:
wait (S):
while S≤0 do no-op;
S:=S-1;
signal (S):
S:=S+1;

EXCLUSION MUTUA CON SEMAFOROS
var mutex: semaphore; //inicialmente mutex=1
Proceso Pi :
repeat
wait(mutex);
sección crítica
signal(mutex);
sección restante
until false;

EXCLUSION MUTUA CON SEMAFOROS
Esta solución, si bien garantiza la exclusión mutua,

no representa una solución para el problema de la
sección crítica pues no se cumplen necesariamente
las condiciones de espera definida y de progreso.

ESPERA OCUPADA
El uso de do no-op significa que la CPU gasta ciclos

iterando sobre la misma instrucción hasta que
pueda avanzar.
Este fenómeno se conoce como espera ocupada o

bussy-waiting.
La solucion: dormir al proceso.

IMPLEMENTACION DE SEMAFOROS
SIN BUSSY-WAITING
Definimos un semáforo como un record:
type semaphore = record

value: integer
L: List of process;
end;
Además, el SO provee las siguientes dos operaciones:
block() suspende al proceso que la invoca

wakeup(P) despierta el proceso P suspendido

IMPLEMENTACION DE SEMAFOROS
SIN BUSSY-WAITING
La implementación de las operaciones wait y signal
es ahora:
Wait(S) Signal(S)
S.value:=S.value-1; S.value:=S.value+1;
if (S.value < 0) if (S.value <= 0)
then begin then begin
agregar proceso P remover proceso
a S.L; P de S.L;
block(); wakeup(P);
end; end;

SEMAFORO USADO COMO
HERRAMIENTA DE SINCRONIZACION
Sean 2 procesos colaborativos Pi y Pj .
Se debe cumplir que la instrucción B en Pj se ejecute

luego que la instrucción A en Pi .
Para implementar la solución definimos un semáforo

flag inicializado en 0. El código será:
Pi Pj
M M
A wait (flag)
signal (flag) B

SEMAFORO USADO COMO
HERRAMIENTA DE SINCRONIZACION
Su uso puede traer como consecuencia 2 tipos de

problemas para los procesos:
Deadlock
Starvation

DEADLOCK CON SEMAFOROS
Dos o más procesos esperan por un evento que

solamente puede ser producido por alguno de los
procesos en espera.
Sean S y Q dos semáforos inicializados en 1:
P0 P1
wait(S); wait(Q);
wait(Q); wait(S);
M M
signal(S); signal(Q);
signal(Q); signal(S);

STARVATION CON SEMAFOROS
Se puede producir si un proceso demora mucho en

ser sacado de la cola del semáforo en la que se
encuentra suspendido por, por ejemplo, razones de
prioridad.

TIPOS DE SEMAFOROS
Binario – el valor de la variable puede ser 0 y 1.

Es muy simple de implementar.
Contador – la variable puede tomar cualquier

valor entero.
Se puede implementar un semáforo contador con

semáforos binarios (ver libro de Silberchatz).

PROBLEMAS CLASICOS DE
SINCRONIZACION
Productores/Consumidores
Lectores/Escritores
Filósofos cenando

Volvemos a estudiar este problema, con buffer limitado
(capacidad finita), pero ahora usando semáforos.
Las restricciones eran:
Si el buffer está vacío, ningún proceso consumidor puede

consumir, y por lo tanto debe esperar que un proceso
productor produzca.
Si el buffer está lleno, ningún proceso productor puede

producir, y por lo tanto debe esperar que un proceso
consumidor consuma (esto no ocurre con buffer ilimitado).
No puede acceder al buffer más de un proceso a la vez, sea

este productor o consumidor.

Los datos compartidos son:
type item=.....
var buffer=.....
full, empty, mutex: semaphore;
nextp,nextc: item;
Inicialmente: full=0, empty=n, mutex=1

Proceso Productor Proceso Consumidor
repeat repeat
… wait(full);
producir un item en wait(mutex);
nextp …
… mover un item de buffer a nextc
wait(empty); …
wait(mutex); signal(mutex);
… signal(empty);
agregar nextp a buffer …
… consumir item de nextc
signal(mutex); …
signal(full); until false;
until false;

LECTORES/ESCRITORES
Hay un buffer compartido al que acceden

proceso lectores, que leen datos y procesos
escritores, que escriben datos.
No hay limitación alguna sobre el tamaño del

buffer.
Es una aplicación clásica de Bases de Datos.

LECTORES/ESCRITORES
Restricciones:
Procesos escritores y lectores o procesos

escritores entre si deben excluirse en el acceso
al buffer.
No hay restricción alguna entre procesos

lectores.
No hay limitación alguna sobre el tamaño del

buffer.

LECTORES/ESCRITORES
var mutex, wrt: semaphore

readcount : integer
Inicialmente
mutex=1, wrt=1, readcount=0

LECTORES/ESCRITORES
Proceso Escritor Proceso Lector
wait(wrt); wait(mutex);
…. readcount:=readcount+1;
escribir if readcount = 1 then wait(wrt);
…. signal(mutex);
signal(wrt); …
leer
…
wait(mutex);
readcount :=readcount-1;
if readcount =0 then signal(wrt);
signal(mutex):

LECTORES/ESCRITORES
Si hay lectores y escritores listos para ejecutar,

¿quién tiene prioridad?
Prioridad de escritores: lectores pueden sufrir

starvation.
Prioridad de lectores: escritores pueden sufrir

starvation y además los datos pueden quedar
desactualizados.

FILOSOFOS CENANDO
5 filósofos pasan su vida

pensando y comiendo
arroz.
En la mesa hay 5 platos, 5

palitos y 5 lugares.
Para comer, un filósofo

requiere usar los 2 palitos
situados a sus lados.
La cantidad de arroz es
ilimitada.

FILOSOFOS CENANDO
var palito: array[0..4] of semaphore;
Inicialmente todos los semáforos están en 1.

FILOSOFOS CENANDO
repeat
wait(palito[i])
wait(palito[(i+1) mod 5])
…
comer
…
signal(palito[i]);
signal(palito[(i+1) mod 5]);
…
pensar
…
until false;

FILOSOFOS CENANDO
Existen muchas soluciones para este problema.
Algunas de ellas pueden ocasionar deadlock o

starvation.

CONSTRUCCIONES DE LENGUAJE
Hay lenguajes de programación (lenguajes

concurrentes) que incluyen herramientas de
sincronización de alto nivel. Las principales son:
Regiones críticas
Regiones críticas condicionales
Monitores
Analizaremos el caso de los monitores.

MONITORES
Un monitor es una construcción de lenguaje que se

compone de:
Variables locales (de uso compartido)
Procedimientos
Variables de condición

MONITORES
La sincronización entre los procesos la brinda el monitor

a través de:
Los procesos invocan a los procedimientos del

monitor.
No puede haber más que un solo proceso ejecutando

un procedimiento dentro del monitor.
Si un proceso no puede progresar (por las

restricciones del problema) entonces se debe
bloquear dentro del monitor en las variables de
condición.

MONITORES
Estructura general de un monitor:
declaración de nombre y tipo

declaración de variables
Procedimiento 1
begin ..... end;
….....
….....
Procedimiento n
begin ..... end;
begin
código de inicialización
end

MONITORES
Una variable de condición se declara como

var x:condition
Las variables de condición solo pueden ser

usadas con las operaciones wait y signal
(aunque parecidas, no son las mismas que para
los semáforos).

MONITORES
La operación x.wait significa que el proceso que

la invocó se suspende en la condición x hasta
que otro proceso invoque la operación x.signal
La operación x.signal despierta a solo un

proceso suspendido en la condición x. Si no hay
procesos suspendidos en la condición, signal no
tiene efecto.

MONITORES

FILOSOFOS CENANDO CON MONITORES
monitor dp
{
enum {thinking, hungry, eating} state[5];
condition self[5];
void pickup(int i) // procedimiento

void putdown(int i) // procedimiento
void test(int i) // procedimiento
init() {
for (int i = 0; i < 5; i++)
state[i] = thinking;
}
}

void pickup(int i) {
state[i] = hungry;
test[i];
if (state[i] != eating)
self[i].wait();
}
void putdown(int i) {
state[i] = thinking;
// testea a derecha e izquierda
test((i+4) % 5);
test((i+1) % 5);
}

void test(int i) {
if ( (state[(I + 4) % 5] != eating) &&
(state[i] == hungry) &&
(state[(i + 1) % 5] != eating)) {
state[i] = eating;
self[i].signal();
}
}

IMPLEMENTACION DE MONITORES
USANDO SEMAFOROS
Variables
semaphore mutex; // (inicialmente = 1)

semaphore next; // (inicialmente = 0)
int next-count = 0;

USANDO SEMAFOROS
Procedimientos
wait(mutex);
…
Proci
…
if (next-count > 0)
signal(next)
else
signal(mutex);
Se asegura la Exclusión Mutua dentro del monitor.

USANDO SEMAFOROS
Variables de condición
Cada una de las variables de condición X estará

definida por:
semaphore x-sem; // (inicialmente = 0)

int x-count = 0;

USANDO SEMAFOROS
Operaciones con las variables de condición
x.wait x.signal
x-count++; if (x-count > 0) {

if (next-count > 0) next-count++;
signal(next); signal(x-sem);
else wait(next);
signal(mutex); next-count--;
wait(x-sem);
}
x-count--;

Cap08 - Sincronizacion de Procesos

Cargado por

Información del documento

Título original

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

Cap08 - Sincronizacion de Procesos

Cargado por

Copyright:

Formatos disponibles

SISTEMAS

Sistemas Operativos 2008 Capítulo 8 3

Para evitar esas inconsistencias es necesario

Veamos un ejemplo clásico de procesos cooperativos.

Sistemas Operativos 2008 Capítulo 8 4

Procesos productores producen información que es

El intercambio de información se realiza sobre un

Sistemas Operativos 2008 Capítulo 8 5

El buffer compartido puede tener:

Capacidad limitada: admite un máximo de N

Capacidad ilimitada: no hay límite en la cantidad

Sistemas Operativos 2008 Capítulo 8 6

Si el buffer está vacío, ningún proceso consumidor

Si el buffer está lleno, ningún proceso productor

No puede acceder al buffer más de un proceso a la

Sistemas Operativos 2008 Capítulo 8 7

Sistemas Operativos 2008 Capítulo 8 8

Proceso Productor Proceso Consumidor

Sistemas Operativos 2008 Capítulo 8 9

se deben ejecutar atómicamente.

Una operación es atómica si se ejecuta en forma

Sistemas Operativos 2008 Capítulo 8 10

La traducción a lenguaje de máquina de ambas

registro1 counter registro2 counter

Sistemas Operativos 2008 Capítulo 8 11

Si el productor y el consumidor intentan

La intercalación de instrucciones va a depender

Sistemas Operativos 2008 Capítulo 8 12

Prod registro1 counter registro1 = 5

El valor final de counter va a ser 4.

Sistemas Operativos 2008 Capítulo 8 13

Prod registro1 counter registro1 = 5

Ahora, el valor final de counter va a ser 6.

Sistemas Operativos 2008 Capítulo 8 14

Se pueden considerar otras secuencias de

Sistemas Operativos 2008 Capítulo 8 15

Esos resultados distintos se producen porque no se

Este fenómeno es conocido como Condición de

Sistemas Operativos 2008 Capítulo 8 16

Cuando varios procesos acceden y manipulan

Para prevenir la ocurrencia de la condición de

Sistemas Operativos 2008 Capítulo 8 17

Se han sugerido diferentes soluciones para

El principal concepto empleado para sincronizar

Sistemas Operativos 2008 Capítulo 8 18

n procesos compiten en el uso de algún dato

Cada proceso tiene una porción de código,

El problema consiste en asegurar que cuando un

Sistemas Operativos 2008 Capítulo 8 19

El programador es el responsable de definir con

La sección crítica de cada proceso debe ser lo

Se deben cumplir varias condiciones para que

Sistemas Operativos 2008 Capítulo 8 20

Toda solución al problema de la sección crítica debe

Sistemas Operativos 2008 Capítulo 8 21

Si el proceso Pi esta ejecutando en su sección

Sistemas Operativos 2008 Capítulo 8 22

Si ningún proceso del conjunto está ejecutando en

Sistemas Operativos 2008 Capítulo 8 23

Desde que un proceso hace un requerimiento para

Sistemas Operativos 2008 Capítulo 8 24

Esta condición parte de 2 consideraciones:

Cada proceso se ejecuta a una velocidad distinta