Cena de Filosofos y Sincronizacion Java PDF

Cena de filosofos y sincronizacion java
Programacin concurrente y Distribuda Curso 2011-12
Miguel Telleria, Laura Barros, J.M. Drake

telleriam AT unican.es
Computadores y Tiempo Real http://www.ctr.unican.es
Computadores y Tiempo Real Universidad de Cantabria
Programacin concurrente y distribuda
Objetivos
Presentaros la aplicacin de filsofos chinos con UML
Practicar lo visto en sincronismo de java
Prepararos para la practica 2 que es muy similar
14 Oct 2011
Miguel Telleria de Esteban telleriam AT unican.es)
Pgina 2 de 34
Contenido
Presentacin de los filsofos chinos Especificacin UML Paralelizacin Sincronizacin de espera Sincronizacin bloqueante
14 Oct 2011
Pgina 3 de 34
Presentacindelosfilsofoschinos
Los filsofos chinos
4 filsofos
Rojo, azul, amarillo, verde 1 entre cada 2 filsofos Numero de sillas configurable

4 palillos
Gestor de sillas:
Ciclo de cada filosofo:

Pensando esperando silla esperando palillo derecho esperando palillo izquierdo comiendo
Miguel Telleria de Esteban telleriam AT unican.es) Pgina 5 de 34
14 Oct 2011
Vamos a verla funcionar
14 Oct 2011
Pgina 6 de 34
EspecificacinUML
Diagrama de clases
14 Oct 2011
Pgina 8 de 34
Misiones
Comedor
Palillo
Datos globales Punto de acceso para el resto de las clases Determina si da una silla o no GUI Objetos activos Mantiene la cantidad de sillas libres
Modo polling: Devuelve falso si el palillo est cogido Modo espera: Bloquea hasta que el palillo est libre Instancia el sistema Crea los threads Termina la ejecucin
Prueba secuencial

Filosofo
Gestor de sillas
14 Oct 2011
Pgina 9 de 34
Filosofo

Objeto activo con su ciclo de vida Decisin de diseo:
Aunque tiene asociados los palillos, invoca los mtodos coge() y deja() a travs del comedor
14 Oct 2011
Pgina 10 de 34
Comedor
Da acceso al resto de elementos Eleccin de diseo:
La clase Palillo devuelve si el palillo est libre El Gestor de Sillas simplemente informa es el comedor el que devuelve si s o si no.
14 Oct 2011
Pgina 11 de 34
Palillo
Se deja coger o no:
Es decir, es el propio palillo el que maneja su poltica de acceso El atributo privado palilloTomado es el que lleva la cuenta de si hay palillo o no
14 Oct 2011
Pgina 12 de 34
GestorSillas
Usado para evitar el bloqueo mltiple
El cojoSilla() directamenta da el acceso a la silla El atributo privado sillasDisponibles es el que lleva la cuenta de si hay silla libre o no.
14 Oct 2011
Pgina 13 de 34
Programa principal
Instancia los threads y espera a que el tiempo de ejecucin se termine. Define el numero de sillas Define el tiempo de actualizacin
14 Oct 2011
Pgina 14 de 34
Estados del filosofo
El filsofo pasa de un estado a otro mediante el mtodo actualiza().
14 Oct 2011
Pgina 15 de 34
Paralerizacin (similaralaprctica1)
Cambios en el programa principal
El main() ya no llama a actualiza
Lo har el propio thread en su run() Se crean los filosofos
El main se simplifica a:
Se les arrancan (si no se arrancan ellos slos)
Se espera un tiempo de ejecucin Se ejecuta termina() en ellos
14 Oct 2011
Pgina 17 de 34
Cambios en el filsofo

El actualiza() se llama internamente desde el run() Se puede auto-arrancar (si heredamos de Thread)
Si no nos arranca el que nos crea
14 Oct 2011
Pgina 18 de 34
Vamos a ejecutarlo
Se respeta el nmero de sillas?
Se mantiene el acceso exclusivo a los palillos?
14 Oct 2011
Pgina 19 de 34
Sincronizacindeespera
Identificamos la sincronizacin
Que Objetos tenemos que sincronizar
Informacin compartida concurrentemente Y que es posible que entre en incoherencia
Limitacin de las secciones crticas
Lectura?, Escritura? Atomicidad
mbito de la sincronizacin
Que objetos tienen que esperar No sobresincronizar

14 Oct 2011
Cosas que no hace falta sincronizar
Variables locales (ej estado)
Ya que estn duplicadas en cada thread Mientras no haya ningn escritor a la vez claro (mientras no importe que se haga en un orden u otro) La GUI: SWT mantiene su propio thread para ello Dispositivos: discos duro, pantalla...
Acceso concurrente en slo lectura
Accesos ya gestionado por una librera o sistema operativo

14 Oct 2011
Pgina 22 de 34
Mtodos synchronized vs bloque synchronized
El mtodo synchronized es equivalente a:
Envolver todo el cdigo del mtodo con

synchronize(this)
Si la clase est bien diseada con esto puede bastar Nos aseguramos de que nadie se olvida sincronizar
Con que uno se olvidase no se mantiene la exclusin mutua
14 Oct 2011
Pgina 23 de 34
Mtodos synchronized vs bloque synchronized
Sin embargo a veces esto no siempre es posible
La sincronizacin (duracin o mbito) puede depender de un argumento, un estado, un instante...
Si s que en cierto estado voy a ser el nico en acceder a la informacin Ej: test_and_set()
A veces la seccin crtica abarca ms de un mtodo
Buen diseo: poner el mutex lo ms profundo posible
Los objetos llamantes no deberan verlo La implementacin es quien debera definir el mbito en funcin de un atributo privado
Si es necesario se pone synchronize(this) en parte del cdigo
Caso test_and_set(), dar un mtodo sincronizado que englobe los dos.
14 Oct 2011
Pgina 24 de 34
Es necesario sincronizar en la implementacin secuencial?
Si?, No?, Por qu?
Y no vale con que no hay concurrencia ya que actualiza no deja de ser un planificador cclico...
14 Oct 2011
Pgina 25 de 34
Es necesario sincronizar en la implementacin secuencial? (respuesta)
NO es necesario Puesto que todas las llamadas a actualiza()
Se ejecutan de manera atmica Dejan las variables en estado coherente
Podra no ser as
Ej: que haya un estado (miro si silla libre) y luego otro (cojo silla).
14 Oct 2011
Pgina 26 de 34
Solucin primera
Puesto que todos usamos el comedor
Hacemos los mtodos del comedor synchronized
Funciona?
Que inconvenientes presenta?
14 Oct 2011
Pgina 27 de 34
Inconvenientes de la solucin primera
Dos filosofos de frente accederan a coge y deja palillo de manera exclusiva. El tomar la silla tambin impedira a otro filsofo empezar a tomar (o dejar el palillo).
Tenemos sobre-sincronizacin al usar un nico lock global
14 Oct 2011
Pgina 28 de 34
Hilamos ms fino
Cada filosofo retendr el lock del objeto que est usando
No habr contencin en palillos enfrentados No habr contencin entre palillos y sillas
14 Oct 2011
Pgina 29 de 34
Sincronizacinbloqueante
Esperas activa vs espera bloqueante
Independientemente del mbito, duracin y datos protegidos tenemos 2 estrategias de actuacin:
Espera activa: Se pregunta reiteradamente el estado de un recurso opcionalmente con un sleep.

Ventaja 1: Sencillez de implementacin, Ventaja 2: No es bloqueante (ej multicore en ciertos entornos) Inconveniente: Gasto intil de CPU Ventaja: Ahorro de CPU (a veces es relativo) Desventaja: Requiere de ciertos recursos del entorno y de bloqueos
Espera bloqueante: Se queda dormido a la espera de ser notificado

En la mayora de los casos preferiremos la espera bloqueante.
Ejemplo donde no: Las interrupciones hardware

Si nos bloqueamos, el scheduler no nos despierta (no somos proceso del S.O.). Alternativa: Hacemos un pooling y nos volvemos a programar
14 Oct 2011
Como lo hacemos
Comportamiento de variable de condicin + mutex:
wait(): Nos suspendemos y soltamos el lock notify(): Despertamos a uno y le entregamos el lock notifyAll(): Despertamos a todos y se ejecutarn 1 a 1 atmicamente con el lock tomado. Slo podemos ejecutarlos sobre el objeto en el que estamos sincronizados.
Cosas a tener en cuenta:
Por lo tanto tenemos que estar en mbito synchronized
Siempre que hagis un wait() no olvidis que tiene que haber un notify() o notifyAll() correspondiente. Englobar todo en un predicado lgico
Ya que al salir del wait() puede seguir habiendo contencin y nos tenemos que volver a dormir. Esto ocurre siempre con los notifyAll()
14 Oct 2011
Wait() y sleep()
Dos diferencias:
sleep() no suelta el lock
Por lo tanto impedimos el acceso al objeto mientras el objeto duerme. wait() vuelve slo cuando se le notifica en ambos casos salta la interrupcin InterruptedException
sleep() vuelve inmediatamente de un interrupt()

14 Oct 2011
Pgina 33 de 34
Hagamos la prueba!!
Diferencias entre palillo y gestor de sillas
El objeto palillo puede hacer el wait() el mismo La clase sillas no puede hacer el wait() a menos de que tome la responsabilidad de gestionar su propio acceso.
14 Oct 2011
Pgina 34 de 34

Cena de Filosofos y Sincronizacion Java PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Cena de Filosofos y Sincronizacion Java PDF

Загружено:

Авторское право:

Доступные форматы

Cena de filosofos y sincronizacion java

Programacin concurrente y Distribuda Curso 2011-12

Miguel Telleria, Laura Barros, J.M. Drake

Computadores y Tiempo Real http://www.ctr.unican.es

Computadores y Tiempo Real Universidad de Cantabria

Programacin concurrente y distribuda