Capítulo 7 sincronización de procesos 09 01-2012
-
Upload
ecuatareas -
Category
Education
-
view
2.362 -
download
0
Transcript of 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”
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.
“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
Mario Naula Guznay
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
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
Jonathan Zamora
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.
• 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
KAROL ANDREA MANRIQUE
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.
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
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
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
JOSÉ DANIEL MENDOZA LOOR
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
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
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
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
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.
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)
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)
CARLOS JAVIER SORNOZA
ALGORITMO 2
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
MARCOS ANTONIO MENÉNDEZ
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]
JONATHAN OSWALDO URDÁNIGO
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
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
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
HENRY ANDRÉS MENDOZA
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:
JESSENIA CEVALLOS
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
GEMA PATRICIA CALDERÓN
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
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
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
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
MARÍA FERNANDA ARÉVALO
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
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
JESÚS ALBERTO CEDEÑO
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
JEAN CARLOS MACÍAS
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
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
INGRID ALEJANDRA CEDEÑO
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
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
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
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
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
LUIS MIGUEL GARCÍA
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.
DARWIN CHÁVEZ
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
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
RAFAEL ANDREE BASURTO
•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
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
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
• 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.
PEDRO MUÑOZ Y MARCOS MERCHÁN
CONDICIÓN DE COMPETENCIA
• 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
• 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
• 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
• 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
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:
DIEGO AVILEZ
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
XAVIER CEDEÑO
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
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
ANDRÉS ANTONIO DAZA
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.
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
DORIS SOLÓRZANO
• 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
SEMÁFOROS JAVA
SEMÁFOROS JAVA
JAQUELINE INTRIAGO MACÍAS
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
ANA LAURA PONCE
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.
MARYURIE LÓPEZ Y ESTEFANÍA DELGADO
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
JOSÉ GABRIEL MOREIRA
• 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
• 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
YORDY EDWIN ALMEIDA
• 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:
Villavicencio Palacios César
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
Intriago Holguín Jenniffer
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.
KARINA JESSENIA HIDROVO
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
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
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