Capítulo 7 sincronización de procesos 09 01-2012

104
FACULTAD DE CIENCIAS INFORMÁTICAS CÁTEDRA: SISTEMAS OPERATIVOS RESPONSABLES: CAPÍTULO 7 - SINCRONIZACIÓN DE PROCESOS CATEDRÁTICO: ING. PABLO FLORES PORTOVIEJO, 09 DE ENERO DE 2012 QUINTO NIVEL “B”

Transcript of Capítulo 7 sincronización de procesos 09 01-2012

Page 1: Capítulo 7 sincronización de procesos 09 01-2012

FACULTAD DE CIENCIAS INFORMÁTICAS

CÁTEDRA:SISTEMAS OPERATIVOS

RESPONSABLES:

CAPÍTULO 7 - SINCRONIZACIÓN DE PROCESOS

CATEDRÁTICO:ING. PABLO FLORES

PORTOVIEJO, 09 DE ENERO DE 2012

QUINTO NIVEL “B”

Page 2: Capítulo 7 sincronización de procesos 09 01-2012

Facultad de Ciencias Informáticas

Misión VisiónFormar profesionales

eficientes en el campo de las Ciencias

Informáticas, que con honestidad, equidad y

solidaridad, den respuesta a las

necesidades de la sociedad elevando su

nivel de vida.

Ser una unidad con alto prestigio académico con eficiencia, transparencia

y calidad en la educación, organizada

en sus actividades, protagonista del

proceso regional y nacional.

Page 3: Capítulo 7 sincronización de procesos 09 01-2012

“Excelente , maestro es aquel, que enseñando poco, hace nacer

en el alumno el gran deseo de aprender”.Anónimo

“El objetivo de la educación es la virtud y el deseo de convertirse en

un buen ciudadano”. Jean de la Fontaine

Page 4: Capítulo 7 sincronización de procesos 09 01-2012

Mario Naula Guznay

Page 5: Capítulo 7 sincronización de procesos 09 01-2012

Procesos cooperativos.En función de que el acceso concurrente

puede generar como resultado inconsistencia en los datos.

Mecanismos.Antecedentes:Código de un hilo productor y de un

consumidor respectivamente.While (count == BUFFER_SIZE)

; // no-op (ninguna operación)

// agregar un elemento al buffer

++count;

Buffer(in) = item;

In = (in + 1) % BUFFER_SIZE;

While (count == BUFFER_SIZE)

; // no-op (ninguna operación)

// agregar un elemento al buffer

++count;

Buffer(in) = item;

In = (in + 1) % BUFFER_SIZE;

SINCRONIZACIÓN DE

PROCESOS

Page 6: Capítulo 7 sincronización de procesos 09 01-2012

Demostración: si las declaraciones ++count y –-count puede implementarse en el lenguaje de máquina como:

Donde register 1 y register 2 son registros locales CPU

Ejecución concurrente de las declaraciones ++count y –count.

register1 = count;

register1 = register1 + 1;

count = register1

Register2 = count;

register2 = register2 + 1;

count = register2

T0= producer execute register1 = count

T1= producer execute register1 = register1 + 1

T2= producer execute register2 = count

T3= producer execute register2 = register2 – 1

T4= producer execute count = register1

T5= producer execute count = register2

register1 = 5;

register1 = 6;

register2 = 5;

register2 = 4;

count = 6;

count = 4;

SINCRONIZACIÓN DE PROCESOS

Page 7: Capítulo 7 sincronización de procesos 09 01-2012

Jonathan Zamora

Page 8: Capítulo 7 sincronización de procesos 09 01-2012

Cuando un hilo se esta ejecutando en sección crítica, se debe permitir que otros hilos se ejecuten en esa misma sección.

PROBLEMA DE LA SECCIÓN CRÍTICA

Cada hilo tiene su segmento de código, denominado sección crítica, donde el hilo puede

estar realizando varias acciones.

Page 9: Capítulo 7 sincronización de procesos 09 01-2012

• Exclusión mutua• Progreso• Espera limitada

La solución al problema de la sección crítica debe satisfacer los siguientes requerimientos:

PROBLEMA DE LA SECCIÓN CRÍTICA

Page 10: Capítulo 7 sincronización de procesos 09 01-2012

KAROL ANDREA MANRIQUE

Page 11: Capítulo 7 sincronización de procesos 09 01-2012

SOLUCIONES PARA DOS TAREAS

Se consideran tres implementaciones diferentes de Java para coordinar las acciones de dos hilos diferentes.

Los hilos se numeran T0 y T1.

Cada hilo se implementa usando la clase Worker.

Page 12: Capítulo 7 sincronización de procesos 09 01-2012

Public class Worker extends Thread{ public worker(String n, int i, MutualExclusion s) { name=n; id=i; shared=s; }Public void run(){ While (true) { Shared.enteringCriticalSection(id); System.out.println(name + “está dentro de la sección crítica”); MutualExclusion.criticalSection(); Shared.leavingCriticalSection(id); System.out.println(name+ “está fuera de la sección crítica”); mutualExclusion.nonCriticalSection(); }} private String name; private int id;Private MutualExlcusion shared;}

Hilo trabajador (Worker thread) criticalSection() y nonCriticalSection() representa los lugares donde cada hilo realiza sus secciones crítica y no crítica.

Antes de llamar a su sección crítica, cada hilo llamará al método enteringCriticalSection(), pasando su identificación de hilo (que será 0 o 1).

Un hilo no puede salir de enteringCriticalSection(),

hasta que sea capaz de entrar a su sección crítica.

Al terminar sus sección crítica, un hilo llamará al

método leavingCriticalSection().

SOLUCIONES PARA DOS TAREAS

Page 13: Capítulo 7 sincronización de procesos 09 01-2012

Public abstract class MutualExclusion{ public static void criticalSection() { try{ Thread.sleep( (int) (Math.random() *TIME) ); } catch (InterruptedException e) () } public static void nonCriticalSection() { try{ Thread.sleep( (int) (Math.random() *TIME) ); } catch (InterruptedException e) {}}

Public abstract void enteringCriticalSection(int t);Public abstract void leavingCriticalSection(int t);

Public static final int TURN_0=0;Public static final int TURN_1=1;private static final int TIME=3000;

Clase abstracta Mutual Exclusion

Los métodos estáticos criticalSection() y nonCriticalSection() son invocados por cada hilo.

Se representan los tres diferentes algoritmos extendiendo la clase MutualExclusion e implementando los métodos abstractos enteringCriticalSection() y leavingCriticalSection().

SOLUCIONES PARA DOS TAREAS

Page 14: Capítulo 7 sincronización de procesos 09 01-2012

public class TestAlgorithm { public static void main (String args[ ]) { MutualExclusion alg=new Algorithm_1();

Worker first =new Worker(“Corredor 0”, 0, alg); Worker second =new Worker(“Corredor 1”, 1, alg);

first.start(); Second.start();

}}

Clase TestAlgorithm

Se emplea la clase TestAlgorithm para crear los dos hilos y probar cada algoritmo.

SOLUCIONES PARA DOS TAREAS

Page 15: Capítulo 7 sincronización de procesos 09 01-2012

JOSÉ DANIEL MENDOZA LOOR

Page 16: Capítulo 7 sincronización de procesos 09 01-2012

ALGORITMO 1

HACER QUE LOS HILOS COMPARTAN UNA

VARIABLE COMÚN (turn), CON 0 O 1.

SI turn = i , SE PERMITE AL HILO EJECUTAR SU SECCIÓN

CRÍTICA.

ASEGURA QUE SÓLO UN HILO A LA VEZ PUEDA ESTAR

EN SU SECTOR CRÍTICO

Page 17: Capítulo 7 sincronización de procesos 09 01-2012

NO SATISFACE EL REQUERIMIENTO DE PROGRESO, YA QUE NECESITA UNA ALTERNANCIA DE HILOS MIENTRAS ESTAN EN SU SECCIÓN CRÍTICA

INTRODUCE EL MÉTODO yield() QUE MANTIENE AL HILO EN ESTADO EJECUTABLE, Y ADEMÁS PERMITE A LA JVM SELECCIONAR OTRO HILO EJECUTABLE DE IGUAL PRIORIDAD PARA QUE SE EJECUTE x

ALGORITMO 1

Page 18: Capítulo 7 sincronización de procesos 09 01-2012

public class Algorithm_1 extends Mutual Exclusion

{

BODY

}

DECLARACIÓN DE LA CLASE PÚBLICA DENOMINADA Algorithm_1, LA CUAL

ES UNA EXTENSIÓN DE LA CLASE ABSTRACTA MUTUAL EXCLUSION

CUERPO DE LA CLASE

ALGORITMO 1

Page 19: Capítulo 7 sincronización de procesos 09 01-2012

public Algorithm_1() {

turn = TURN_0;

}

DECLARACIÓN DE LA FUNCIÓN PÚBLICA DENOMINADA Algorithm_1,

QUE ES PARTE DEL CUERPO (BODY) DE LA CLASE DEL MISMO NOMBRE

A LA VARIABLE turn se le asigna TURN_0, que a su vez contiene 0.

ALGORITMO 1

Page 20: Capítulo 7 sincronización de procesos 09 01-2012

ALGORITMO 1(BODY)

public void enteringCriticalSection(int t) {

While (turn != t)Thread.yield();

}

DECLARACIÓN DEL MÉTODO enteringCriticalSection (). AQUÍ CADA

HILO PASA SU IDENTIFICACION DE HILO, EL CUAL PODRÁ SER 0 O 1, MEDIANTE PASO REFERENCIAL.

AQUÍ UN HILO NO PUEDE SALIR DEL MÉTODO HASTA QUE SEA CAPAZ DE

ENTRAR A SU SECCIÓN CRÍTICA.

Page 21: Capítulo 7 sincronización de procesos 09 01-2012

public void leavingCriticalSection (int t) {

Turn = 1 - t;

}

DECLARACIÓN DEL MÉTODO leavingCriticalSection (). AL TERMINAR SU SECCIÓN CRÍTICA UN HILO, SE LLAMA A LA

MENCIONADA FUNCIÓN PASANDO POR REFERENCIA t, QUE PODR’A SER 0 O 1.

SE ASIGNA A turn LA DIFERENCIA DE 1 Y EL VALOR REFERENCIAL DE t, POR TANTO

EL RESULTADO SIEMPRE SERÁ 0 O 1.

ALGORITMO 1(BODY)

Page 22: Capítulo 7 sincronización de procesos 09 01-2012

Private volatile int turn;

DECLARAMOS LA VARIABLE PRIVADA turn COMO volatile int. LA DECLARACIÓN DE

UNA VARIABLE COMO volatile IMPIDE QUE EL COMPILADOR HAGA EL REFRESH DESDE LA MEMORIA PRINCIPAL DURANTE CADA ITERACIÓN Y ASI EVITA QUE OTRO HILO

CAMBIE EL VALOR DE turn.

ALGORITMO 1(BODY)

Page 23: Capítulo 7 sincronización de procesos 09 01-2012

CARLOS JAVIER SORNOZA

Page 24: Capítulo 7 sincronización de procesos 09 01-2012

ALGORITMO 2

Page 25: Capítulo 7 sincronización de procesos 09 01-2012

public class Algorithm_2 extends MutualExclusion{ public Algorithm_2 () {

flag[0]= false; flag[1]= false; } public void enteringCriticalSection (int t) {

int other;

other = 1 - t ;

flag[t] = true;

while (flag[other] == true ) Thread.yield();

}Public void leavingCriticalSection (int t)

{ flag[t] = false;}private volatile boolean [] flag = new boolean[2];}

ALGORITMO 2

Page 26: Capítulo 7 sincronización de procesos 09 01-2012

MARCOS ANTONIO MENÉNDEZ

Page 27: Capítulo 7 sincronización de procesos 09 01-2012

public class Algorithm_3 extends MutualExclusion { public Algorithm_3 () { flag [0] = false; flag [1] = false; turn = TURN_0; } public void enteringCriticalSection ( int t ){ int other; other = 1 - t; flag [t] = true; turn = other; while ( ( flag [other] == true ) && ( turn == other ) ) Thread.yield (); } public void leavingCriticalSection ( int t ) { flag [t] = false; } private volatile int turn; private volatile boolean [] flag = new boolean [2]; }

ALGORITMO 3

COMBINA: La variable entera turn del algoritmo 1 El arreglo boolean del algortimo 2

boolean [] flag = new boolean [2]

Page 28: Capítulo 7 sincronización de procesos 09 01-2012

JONATHAN OSWALDO URDÁNIGO

Page 29: Capítulo 7 sincronización de procesos 09 01-2012

El problema de la sección crítica se podría resolver simplemente en un ambiente de un procesador único si pudiéramos impedir que se produjeran interrupciones mientras se esta modificando una variable compartida.

Deshabilitar las interrupciones en maquinas con multiprocesador puede consumir mucho tiempo, ya que el mensaje se pasa a todos los procesadores, este paso de mensajes demora la entrada a cada sección critica y disminuye la eficiencia del sistema.

Una solución

en máquinas

con un solo

procesador es

deshabilitar las

interrupciones

En cambio

En muchos sistemas existen instrucciones de hardware que pueden ser usadas para resolver el problema de las secciones críticas

HARDWARE DE SINCRONIZACIÓN

Page 30: Capítulo 7 sincronización de procesos 09 01-2012

Esta función lee y modifica automáticamente una variable.

La característica importante es que esta instrucción se ejecuta atómicamente

Por tanto si dos instrucciones TESTANDSETse ejecutan simultáneamente ( cada una en una

CPU diferente), se ejecutarán secuencialmente en un orden arbitrario

Si la máquina soporta la instrucción TESTANDSET, entonces podemos implementar la exclusión

mutua declarando una variable booleana Lock inicializada con el valor false

TEST AND SET

HARDWARE DE SINCRONIZACIÓN

Page 31: Capítulo 7 sincronización de procesos 09 01-2012

SWAPLa instrucción swap() es para

intercambiar el valor de dos variables , a diferencia de la instrucción TestandSet () opera sobre los contenidos de 2 palabras

ambas se ejecutan atómicamente

Si la máquina soporta la instrucción Swap() , entonces podemos declarar una

variable booleana Lock y se inicializa como false

Además, cada proceso tiene una variable local booleana Key

HARDWARE DE SINCRONIZACIÓN

Page 32: Capítulo 7 sincronización de procesos 09 01-2012

HENRY ANDRÉS MENDOZA

Page 33: Capítulo 7 sincronización de procesos 09 01-2012

proberen = permitirP(S) {While S≤0; / / no-opS-;}Verhogen = incrementar V(S) {S+++;}

Las modificaciones del valor entero del semáforo en las operaciones P y V se deben ejecutar de manera invisible. Es decir cuando un hilo modifica el valor del semáforo, ningún otro hilo puede modificar simultáneamente ese mismo valor.

SEMÁFOROS

Un semáforo S es una variable entera , que aparte de la inicialización , sol e puede acceder a ella mediante dos operaciones P y V.

Estas operaciones se las denominaron así a partir de dos palabras holandesa que son:

Page 34: Capítulo 7 sincronización de procesos 09 01-2012

JESSENIA CEVALLOS

Page 35: Capítulo 7 sincronización de procesos 09 01-2012

El uso de un semáforo binario para controlar el acceso a una sección critica es como sigue:

Semaphore s; P(S); criticalSection (); V(S); Los semáforo de

conteo pueden usarse para

controlar el acceso a un recurso dado

compuesto solo de un numero finito.

Semáforo

binario

Semáforo de

conteo

USO

Page 36: Capítulo 7 sincronización de procesos 09 01-2012

GEMA PATRICIA CALDERÓN

Page 37: Capítulo 7 sincronización de procesos 09 01-2012

La espera ocupada desperdicia ciclos de CPU, este tipo de semáforo también se denomina :

Cerradura con vuelta

No requiere ninguna conmutación de contexto cuando un proceso tiene

que esperar una cerradura.

Ventaja

Para superar la necesidad de la espera ocupada se modifican las definiciones delas

operaciones de semáforo P y V.

IMPLEMENTACIÓN

Page 38: Capítulo 7 sincronización de procesos 09 01-2012

Si un proceso ejecuta la operación P y encuentra que el valor del semáforo no es positivo:

Debe esperar

Se Bloquea a si mismo

La operación de bloqueo coloca a un proceso en una cola de espera asociada con el semáforo.

El estado de proceso cambia a estado de espera

El control se transfiere a la CPU

¿Y si el proceso esta bloqueado?

Se reinicia cuando otro proceso ejecute la operación V

mediante un wakeup.El proceso se coloca en la cola de listos

IMPLEME

NTACIÓN

Page 39: Capítulo 7 sincronización de procesos 09 01-2012

Las operaciones de semáforo ahora pueden definirse como:

P (S) {value-;if(value < 0) {

Agregar este proceso a la listablock;}

}

V(S) {value ++;if (value <= 0 ) {

remover un proceso P a la listawakeup(P);

}}

IMPLEMENTACIÓN

Page 40: Capítulo 7 sincronización de procesos 09 01-2012

Hay que garantizar que no haya dos procesos que ejecuten operaciones P y V al mismo tiempo,

esto se resuelve de dos formas:

En un ambiente de uniprocesador se

inhiben las interrupciones mientras las

operaciones Py V se ejecutan.

Luego se ejecuta el proceso en ejecución hasta que se habiliten

las interrupciones .

En un ambiente de multiproceso, las instrucciones de

diferentes procesos se intercalan en forma

arbitraria.

IMPLEMENTACIÓN

Page 41: Capítulo 7 sincronización de procesos 09 01-2012

MARÍA FERNANDA ARÉVALO

Page 42: Capítulo 7 sincronización de procesos 09 01-2012

La implementación de un semáforo con una cola de espera puede dar por resultado una situación en donde dos o mas procesos estén esperando indefinidamente un evento que puede ser causado solo por uno de los procesos que están en espera.

El evento en cuestión es la ejecución de una operación. Cuando se almacena un estado de este tipo, se dice que estos procesos se encuentran en un bloque mutuo

BLOQUEO MUTUO E INANICIÓN

Page 43: Capítulo 7 sincronización de procesos 09 01-2012

Decimos que un conjunto de procesos se encuentra en un estado de bloqueo mutuo cuando cada proceso en el conjunto esta esperando un evento que solo puede ser ocasionado por otro proceso en el conjunto.

Otro problema relacionado con los bloques mutuos es el bloque indefinido o inacción.

El bloqueo indefinido puede ocurrir si agregamos y removemos procesos de la lista asociada con un semáforo en un orden LIFO

BLOQUEO MUTUO E INANICIÓN

Page 44: Capítulo 7 sincronización de procesos 09 01-2012

JESÚS ALBERTO CEDEÑO

Page 45: Capítulo 7 sincronización de procesos 09 01-2012

Estos problemas se emplean para probar casi cada esquema de sincronización propuesto recientemente.

En nuestras soluciones emplearemos los semáforos para la sincronización

PROBLEMAS CLÁSICOS DE SINCRONIZACIÓN

Page 46: Capítulo 7 sincronización de procesos 09 01-2012

JEAN CARLOS MACÍAS

Page 47: Capítulo 7 sincronización de procesos 09 01-2012

Se emplea comúnmente para poder ilustrar el poder de las primitivas de sincronización.

Un hilo productor se altera entre el estado dormido durante cierto tiempo, producir un mensaje y tratar de colocar dicho

mensaje en el buffer vía el método enter().

Un hilo consumidor se alterna entre el estado de dormido y consumir un elemento utilizando

el método remove().

La clase BoundedBufferServer permite crear hilos productor y consumidor.

EL PROBLEMA DEL BUFFER LIMITADO

Page 48: Capítulo 7 sincronización de procesos 09 01-2012

La función mutex proporciona una exclusión mutua

para el acceso a la reserva del buffer y se inicializa con el

valor 1.

Empty se inicializa con un valor

correspondiente a la capacidad del buffer

BUFFER _SIZE

LA RUTINA DEL HILO PRODUCTOR Y EL

CONSUMIDOR SON CORRECTAS DE FORMA

SEPARADA, TAL VEZ NO FUNCIONEN

ADECUADAMENTE CUANDO SE LAS EJECUTA AL

MISMO TIEMPO (DE FORMA CONCURRENTE).

Recordar

EL PROBLEMA DEL BUFFER LIMITADO

Page 49: Capítulo 7 sincronización de procesos 09 01-2012

INGRID ALEJANDRA CEDEÑO

Page 50: Capítulo 7 sincronización de procesos 09 01-2012

PROBLEMAS DE LOS LECTORES Y ESCRITORES

Una base de datos se comparte entre varios hilos concurrentes

LECTORES

Leer

Si dos lectores acceden simultáneamente a los datos compartidos, esto no dará por resultado efectos adversos .

Si un escritor y algún otro hilo , acceden a los datos compartidos de forma simultánea puede producirse un caos.

Se requiere que los escritores tengan acceso

exclusivo a la base de datos compartida.

ESCRITORES

Actualizar

Page 51: Capítulo 7 sincronización de procesos 09 01-2012

El problema de los lectores y escritores tienen varias variantes, y

en todas ellas intervienen prioridades.

A ningún lector se le mantenga esperando a menos que un escritor ya haya obtenido permiso para usar la base de datos compartida.

Una vez que un escritor esté listo, el escritor en espera realice su operación de escritura tan pronto como sea posible.

1

2

Los escritores pueden morir de inanición

Los lectores pueden sufrir de

inanición.

PROBLEMAS

DE LOS LECTORES Y ESCRITORES

Page 52: Capítulo 7 sincronización de procesos 09 01-2012

NINGÚN LECTOR DEBERÁ ESPERAR QUE TERMINEN OTROS

LECTORES SIMPLEMENTE PORQUE UN ESCRITOR ESTÁ ESPERANDO

Cada hilo lector se alterna entre el estado de dormido y lectura.

Cuando un lector desea leer la base de datos, invoca al método startRead()

Cuando ha terminado de leer llama al método endRead(). Cada hilo escritor realiza operaciones de manera similar.

SOLUCIÓN:

PROBLEMAS DE LOS LECTORES Y ESCRITORES

Page 53: Capítulo 7 sincronización de procesos 09 01-2012

Ingrid Cedeño

Los métodos llamados por cada hilo lector y escritor se definen en

la clase Database.

La variable readerCount lleva un registro del número

de lectores.

El semáforo mutex se emplea para asegurar una exclusión mutua

cuando actualiza readerCount.

El semáforo db funciona como un semáforo

para los escritores.

Utilizado para impedir que los

escritores entren a la base

de datos mientras se

está leyendo.

PROBLEMAS DE LOS LECTORES Y ESCRITORES

Page 54: Capítulo 7 sincronización de procesos 09 01-2012

El primer lector realiza una operación P() sobre db,

impidiendo que cualquier escritor entre a la base de datos.

El lector final realiza una operación V() sobre db.

Si un escritor está activo en la base de datos y n lectores están esperando, entonces un lector se

envía a una cola en bd, y n-1 lectores se envían una cola en

mutex.

PROBLEMAS DE LOS LECTORES Y ESCRITORES

Page 55: Capítulo 7 sincronización de procesos 09 01-2012

LUIS MIGUEL GARCÍA

Page 56: Capítulo 7 sincronización de procesos 09 01-2012

El problema de la cena de los filósofos. Cinco filósofos se sientan en una mesa redonda. En el centro de la mesa hay un plato de arroz. El arroz es tan escurridizo que un filósofo necesita dos palillos para comerlo, pero cada filosofo solo posee un palillo, luego existe el mismo número de filósofos que de palillos. La vida de un filósofo consta de periodos alternados de comer y pensar. Cuando un filósofo siente hambre, intenta coger el palillo de la izquierda y si lo consigue, lo intenta con el de la derecha. Si logra asir dos palillos toma unos bocados y después deja los palillos y sigue pensando.

Si dos filósofos adyacentes intentan tomar el mismo palillo a una vez, se produce una condición de carrera: ambos compiten por tomar el mismo palillo, y uno de ellos se queda sin comer.

EL PROBLEMA DE LOS FILÓSOFOS COMENSALES

RESOLUCIÓN DE CONFLICTOS EN COLAS DE PALILLOS.

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

Page 57: Capítulo 7 sincronización de procesos 09 01-2012

DARWIN CHÁVEZ

Page 58: Capítulo 7 sincronización de procesos 09 01-2012

MONITORES

Es un mecanismo de sincronización

de alto nivel.

Un monitor presenta un conjunto de operaciones

definidas por el programador que tienen provisto la exclusión mutua

dentro del monitor.

El tipo monitor también contiene la declaración de variables cuyos

valores definen el estado de una

instancia de dicho tipo, juntos con los

cuerpos de procedimiento o

funciones que operan sobre esas

variables.

MONITORES

Page 59: Capítulo 7 sincronización de procesos 09 01-2012

La construcción monitor prohíbe el acceso concurrente a todos los procedimientos definidos dentro del monitor. Por lo tanto, solo un hilo (o proceso) a la vez puede estar activo dentro del monitor en un momento dado.

MONITORES

Page 60: Capítulo 7 sincronización de procesos 09 01-2012

RAFAEL ANDREE BASURTO

Page 61: Capítulo 7 sincronización de procesos 09 01-2012

•sincroniza la actividad de los hilos, permitiendo al programador desarrollar soluciones generalizadas que obliguen la exclusión mutua entre hilos.

•una aplicación es segura en hilos si la consistencia de datos queda asegurada, incluso cuando varios hilos estén accediendo a ellos de manera concurrente.

SINCRONIZACIÓN EN JAVA

Page 62: Capítulo 7 sincronización de procesos 09 01-2012

La memoria compartida presenta al problema del buffer limitado.

Se divide en dos problemasTanto el

productor como el consumidor emplean ciclos

de espera ocupada si él

buffer está lleno o vacio.

En segundo lugar, como se mostro por el productor

y el consumidor.

BUFFER LIMITADO

Page 63: Capítulo 7 sincronización de procesos 09 01-2012

Aquí examinamos una implementación de las operaciones de semáforo P y V.

Describimos como un proceso se podría bloquear a si mismo como una alternativa a la espera ocupada.

ESPERA OCUPADA

Page 64: Capítulo 7 sincronización de procesos 09 01-2012

• Si el productor entrara al ciclo while y permaneciera en espera ocupada invocara al método yield() para dar preferencia a otro hilo ejecutable de igual prioridad mientras espera que count se decremente a un valor menor que BUFFER_SIZE.

Page 65: Capítulo 7 sincronización de procesos 09 01-2012

PEDRO MUÑOZ Y MARCOS MERCHÁN

Page 66: Capítulo 7 sincronización de procesos 09 01-2012

CONDICIÓN DE COMPETENCIA

Page 67: Capítulo 7 sincronización de procesos 09 01-2012

• Java impide condiciones de competencia manejando el acceso concurrente a los datos compartidos

• Esta situación introduce una nueva palabra clave: synchronized

• Todo objeto en java tiene asociado a el una solo cerradura

• Cuando los métodos están siendo invocados, la cerradura se ignora, pero cuando un método es declarado como synchronized, el llamado al método requiere ser propietario de la cerradura del objeto.

CONDICIÓN DE COMPETENCIA

Page 68: Capítulo 7 sincronización de procesos 09 01-2012

• Si se posee la cerradura ,el hilo que llama al método synchronized se bloquea y es colocado en el conjunto de entradas para la cerradura del objeto

• Al referirnos a conjunto de entradas hablamos de el conjunto de hilos que están esperando a que la cerradura este disponible

• Y en caso de estar disponible la cerradura cuando se llama al método synchronized el hilo que hace el llamado se convierte en propietario de la cerradura del objeto y puede entrar al método

CONDICIÓN DE COMPETENCIA

Page 69: Capítulo 7 sincronización de procesos 09 01-2012

• La cerradura se libera cuando el hilo abandona el método

• Si el método de entrada para la cerradura no esta vacio cuando se libera la cerradura , la JVM selecciona un hilo de este conjunto como el nuevo propietario de la cerradura

• Se a asegurado que solo un hilo puede estar activo en cualesquiera de estos métodos a la vez

CONDICIÓN DE COMPETENCIA

Page 70: Capítulo 7 sincronización de procesos 09 01-2012

• La situación donde varios procesos accesan y manipulan concurrentemente datos compartidos. El valor final de los datos compartidos depende del proceso que termine al ultimo.

Esto quiere decir Las condiciones de competencia se dan cuando dos o más procesos intentan acceder a un mismo recurso.

• Para prevenir la condición de competencia, los procesos concurrentes deberán estar sincronizados.

Condición Competencia

Page 71: Capítulo 7 sincronización de procesos 09 01-2012

Para evitar una condición de competencia debemos establecer un conjunto de reglas:

• Dos o más procesos no pueden estar simultáneamente dentro de sus regiones críticas

• Ningún proceso que se ejecute fuera de su región crítica puede bloquear a otros procesos

• Ningún proceso deberá tener que esperar indefinidamente para entrar a su región crítica

La regla de oro para evitar las condiciones de competencia es garantizar el acceso seguro a recursos compartidos, es decir, debemos hacer coordinación y sincronización de procesos.

Para lograr implementar esta regla es que se inventaron las secciones críticas en la que hay que cumplir estas sencillas reglas:

Page 72: Capítulo 7 sincronización de procesos 09 01-2012

DIEGO AVILEZ

Page 73: Capítulo 7 sincronización de procesos 09 01-2012

Los métodos llamados por el

hilo lector y escritor se

definen database .

Ahora el problema de los lectores y escritores se pueden solucionar con la sincronizacion en java

VARIABLES:readerCount: mantiene el registro de Nº de lectores

Dbreading: fija el valor true si la bd esta siendo leída caso contrario false.

Dbwritig : indica si el escritor esta accediendo a la bd.Startread: ,endread,startwrite,endwrite todos estos se

declaran como synchronized para la exclusión a las variables compartidas.

Cuando el escritor desea comenzar a escribir verifica primero si se esta leyendo y escribiendo la bd.

Y es aquí donde se procede a utilizar las variables.- dbwriting en true.- dbwriting en false

- Startread verifica sin o esta siendo utlizada utiliza:Dbreading en true cuando finaliza endread y luego dbreading

en false.

EL PROBLEMA DE LOS LECTORES Y ESCRITORES

Page 74: Capítulo 7 sincronización de procesos 09 01-2012

XAVIER CEDEÑO

Page 75: Capítulo 7 sincronización de procesos 09 01-2012

Free Powerpoint TemplatesPage 75

NOTIFICACIONES MULTIPLES

Notify () selecciona un hilo arbitrario de la lista

de hilos.

En el caso donde hay varios hilos en conjunto de espera y más de una condición por la

cual esperar.

Cuando un hilo desea realizar trabajo, llama al método

doworki(). Solo el hilo cuyo número corresponde al valor de turn puede proceder; los demás

deben esperar su turno

Page 76: Capítulo 7 sincronización de procesos 09 01-2012

Algoritmo dowork//pnum es el número del hilo //que desea hacer algun trabajo

• Public synchronized void dwork (int pnum){• while (turn != pnum) {• Try{• wait();• }• Catch / interrupted exception e) { }

• If (turn <5)• ++turn;• Else turn=1;• Notify();• }

NOTIFICACIONES MULTIPLES

Page 77: Capítulo 7 sincronización de procesos 09 01-2012

ANDRÉS ANTONIO DAZA

Page 78: Capítulo 7 sincronización de procesos 09 01-2012

SINCRONIZACIÓN DE

BLOQUES

Además de declarar métodos como synchronized, Java también permite declarar bloques de código como synchronized.

synchronized se usa para indicar que ciertas partes del código, están sincronizadas

La rutina mutex lock aplica una cerradura a una variable mutex.

Page 79: Capítulo 7 sincronización de procesos 09 01-2012

El acceso al método criticalSection () requiere ser propietario de la cerradura de mutexlock. La declaración de un método someMethod () como synchronized es equivalente a:

El alcance de la cerradura es el tiempo q transcurre al asignar una cerradura y el momento en el que esta se libera.

Java proporciona sincronización de bloques ya que synchronized solo tiene una pequeña parte de su código manipulando datos compartidos y puede producir un alcance grande.

Además se puede utilizarlos métodos wait () y notify () en un bloque sincronizado solo que estos debe usarse en el mismo objeto utilizado para sincronización.

SINCRONIZACIÓN DE

BLOQUES

Page 80: Capítulo 7 sincronización de procesos 09 01-2012

DORIS SOLÓRZANO

Page 81: Capítulo 7 sincronización de procesos 09 01-2012

• Un semáforo nos sirve para poder permitir o restringir a los procesos o hilos el acceso a algún recurso compartido utilizan los métodos de sincronización p() y v() como synchronized asegura que cada operación que realice automáticamente la clase semaphore mostrada en la figura 7.41 implementa un semáforo de conteo

• Los semáforos cuentan con dos operaciones básicas, una de ellas es para reservarlo y la otra para liberarlo, wait (espera) y signal (señal) respectivamente, equivalente down y up.

SEMÁFOROS JAVA

Page 82: Capítulo 7 sincronización de procesos 09 01-2012

SEMÁFOROS JAVA

Page 83: Capítulo 7 sincronización de procesos 09 01-2012

SEMÁFOROS JAVA

Page 84: Capítulo 7 sincronización de procesos 09 01-2012

JAQUELINE INTRIAGO MACÍAS

Page 85: Capítulo 7 sincronización de procesos 09 01-2012

La palabra clave Synchronized es una construcción fácil y directa.

Es importante conocer algunas reglas de su comportamiento.

1.- Un hilo que posee la cerradura de un objeto puede entrar a otro método Synchronized del mismo objeto.

2.- Un hilo puede anidar invocaciones al método Synchronized para diferentes objetos.

3.- Si no se declara un método Synchronized puede ser invocado independiente de la posesión de la cerradura, aun cuando se este ejecutando otro método Synchronized para el mismo objeto

4.- Si el conjunto de espera para un objeto esta vacio, entonces una llamada a notify() o notifyAll() no tiene efecto alguno

REGLAS DE SINCRONIZACIÓN

Page 86: Capítulo 7 sincronización de procesos 09 01-2012

ANA LAURA PONCE

Page 87: Capítulo 7 sincronización de procesos 09 01-2012

La sincronización en Java empleando la cerradura de un objeto. Esta cerradura actúa como un monitor. Cada objeto en Java tiene

un monitor asociado. Un hilo puede adquirir el monitor de un objeto ya sea entrando a un método synchronized o bloqueando.

Java no proporciona soporte para variables de condición con nombre. Con los monitores, las operaciones wait y signal pueden ser aplicadas a variables de condición con nombre, permitiendo a

un hilo esperar por una condición específica o ser notificado cuando se cumple una de tales condiciones

Cada monitor de Java solo tiene una variable de condición sin nombre asociada a él. Las operaciones wait(), notify(), notifyall() solo pueden aplicarse a esta variable de condición única. Cuando

un hilo Java es despertado mediante notify() o notifyall(), no recibe información acerca de por qué fue despertado.

Page 88: Capítulo 7 sincronización de procesos 09 01-2012

MARYURIE LÓPEZ Y ESTEFANÍA DELGADO

Page 89: Capítulo 7 sincronización de procesos 09 01-2012

SINCRONIZACION DE SISTEMAS OPERATIVOS

Los mecanismos de sincronización proporcionados por los sistemas operativos son:

SINCRONIZACION EN SOLARIS 2

SINCRONIZACION EN WINDOWS NT

Fue diseñado para soportar computo en tiempo real, trabajar con multihilos y soportar procesadores múltiples.Para controlar el acceso a las secciones criticas proporciona mutex adaptivo, variables de condición, semáforos y cerraduras de lector-escritor.

Proporciona varios tipos de objetos de sincronización para manejar la exclusión mutua, incluyendo mutex, secciones criticas, semáforos y objetos de eventos. Sección critica

EventosMutex adaptivo

Delgado Estefania y López Maryuri

Page 90: Capítulo 7 sincronización de procesos 09 01-2012
Page 91: Capítulo 7 sincronización de procesos 09 01-2012

JOSÉ GABRIEL MOREIRA

Page 92: Capítulo 7 sincronización de procesos 09 01-2012

• Un proceso cooperativo es aquel puede afectar o verse afectado por otros procesos.

• Estos comparten directamente un espacio lógico de direcciones (códigos y datos) o datos a través de archivos.

• El acceso concurrente a datos compartidos puede dar como resultado una inconsistencia en los datos.

SINCRONIZACIÓN DE PROCESOS

Page 93: Capítulo 7 sincronización de procesos 09 01-2012

• Al desarrollar el modelo de un sistema compuesto de procesos secuenciales cooperativos o hilos, todos ellos ejecutándose de manera síncrona y posiblemente compartiendo datos el productor y consumidor posiblemente no pueden trabajar de forma concurrente.

• Aparece la condición de competencia, por lo que es necesario la sincronización y coordinación de hilos.

ANTECEDENTES

Page 94: Capítulo 7 sincronización de procesos 09 01-2012

YORDY EDWIN ALMEIDA

Page 95: Capítulo 7 sincronización de procesos 09 01-2012

• Controla el acceso a los recursos

compartidos • Mediante una sección de código

como critica

• Cada hilo tiene un segmento de

código denominado sección critica • El hilo puede modificar variables

comunes

• Cuando un hilo se ejecuta en sección critica no se debe permitir que otros hilos se ejecuten en la misma sección

PROBLEMA DE LA SECCIÓN CRÍTICA

Exclusión mutua

Proceso

Espera limitada

Una solución al problema de la sección critica debe satisfacer los

siguientes requerimientos:

Page 96: Capítulo 7 sincronización de procesos 09 01-2012

Villavicencio Palacios César

Page 97: Capítulo 7 sincronización de procesos 09 01-2012

Para soluciones de dos tareas se consideran 3 implementaciones diferentes de Java esto nos ayudara a coordinar las acciones de los hilos diferentes.Los hilos se numeran .

criticalSection()nonCriticalSection()

•Representa los lugares donde cada hilo realiza sus secciones críticas y no críticas, antes de llamar a su sección crítica, cada hilo llamará al método enteringCriticalSection()

LeavingCriticalSection() •Al terminar su sección critica llamamos a este método

Astracta MutualExclusion.java •Esta clase abstracta servirá como padrón para los tres algoritmos.

Testalgorithm •Sirve para crear los hilos y probar cada algoritmo.

Archivos de clase Java

SOLUCIONES PARA DOS TAREAS

Page 98: Capítulo 7 sincronización de procesos 09 01-2012

Intriago Holguín Jenniffer

Page 99: Capítulo 7 sincronización de procesos 09 01-2012

ALGORITMO 1

Nuestro primer enfoque consiste en hacer que los hilos compartan una variable entera común TURN, con un valor inicial de 0 o 1.Si turn = , entonces al hilo se le permite ejecutar una sección critica.

Esta solución asegura que solo un hilo a la vez puede estar en sección critica.El algoritmo 1 introduce un nuevo método: yield( ). La invocación del método yield( ) mantiene al hilo en el estado Ejecutable, pero también le permite a la JVM seleccionar otro hilo ejecutable de igual prioridad para que se ejecute.

Page 100: Capítulo 7 sincronización de procesos 09 01-2012

KARINA JESSENIA HIDROVO

Page 101: Capítulo 7 sincronización de procesos 09 01-2012

Este problema se puede solucionar sustituyendo la variable turn con el siguiente arreglo:

El algoritmo 1 tiene el problema de que no retiene suficiente información sobre el estado de cada hilo, este algoritmo sólo permite recordar a qué hilo permite entrar a su sección crítica.

boolean[] flag= new boolean[2];

ALGORITMO 2

Page 102: Capítulo 7 sincronización de procesos 09 01-2012

Los elementos de este arreglo se van a inicializar con el valor false.

Si flag[i] es true (verdadero), el hilo Ti está listo para entrar sección crítica.

El hilo Ti se fija con el valor de flag[i] en true, para señalar que está listo para

entrar a su sección crítica

Ti verifica que el hilo Tj no esté listo para entrar a su sección crítica al igual

que el.

Si Tj estuviera listo, Ti tendría que esperar hasta Tj indique que ya no necesita estar en su sección crítica

(hasta que flag[j] fuera false)Cuando ocurre esto Tj entraría a su

sección crítica, y al salir de la misma Ti fijaría su valor de flag en false, permitiendo así que el otro hilo

ingrese a su sección crítica en caso de que esté esperando-

ALGORITMO 2

Page 103: Capítulo 7 sincronización de procesos 09 01-2012

Esta solución satisface el

requerimiento de exclusión mutua.

Desafortunadamente

El requerimiento de progreso todavía no se cumple.

Consideremos la

siguiente secuencia

de ejecución

T0 fija el valor de flag[0] en

true

Antes de ejecutarse el ciclo while, se da

una conmutación de contexto y el hilo T1

fija el valor de flag[1] en true al

igual que el flag[0]

Cuando ambos hilos efectúan la

declaración while, entonces estarán en un

ciclo infinito, ya que el valor de

flag para el otro hilo es true.

Esto se lo realiza para indicar que

desea entrar a su sección

crítica.

ALGORITMO 2

Page 104: Capítulo 7 sincronización de procesos 09 01-2012