Sesión 19: Monitores Traduciendo especificaciones de recurso IIbabel.upm.es/.../material/slides/monitores/slides19.pdf · 2020-04-23 · Sesi´on19:Monitores – Traduciendoespeci1cacionesderecursoII

Sesion 19: Monitores – Traduciendo especificaciones de recurso IIJulio Marinoabril 2020

Concurrencia 2019/2020Universidad Politecnica de MadridGrado en Ingenierıa InformaticaGrado en Matematicas e Informatica2ble. grado en Ing. Informatica y ADEhttp://babel.upm.es/teaching/concurrencia

Marino (UPM) Sesion 19: Monitores III Concurrencia, abril 2020 1 / 15

http://babel.upm.es/teaching/concurrencia

analisis de las CPREs

Recordemos los distintos casos que tenıamos:CPRE a Cierto No se necesita condition.CPRE distinta de Cierto pero no depende de parametros de la accion Una condition.CPRE distinta de Cierto y depende de uno o varios parametros de la accion

Los parametros pueden tomar un numero “pequeno” de valores Indexacion de parametros.Los parametros pueden tomar un numero “grande” de valores o variar en tiempo de ejecucionIndexacion de clientes.Cuando la CPRE de alguna de las acciones depende de algun parametro de entrada ya nopodemos usar una condition queue por accion, ya que estarıamos mezclando en ella hilosbloqueados por motivos diferentes y no podrıamos determinar, dada una condition, laCPRE que provoco que se bloquearan los procesos encolados en ella.De los dos metodos que vamos a ver para tratar este problema el segundo (indexacion declientes) es el mas general, aunque el primero (indexacion de parametros) es un casoparticular que ayuda en muchos casos practicos.El MultiAlmacen (ejercicio de las entregas E8 – E10) puede realizarse usando ambosmetodos.














indexacion de parametrosLa explicacion sencilla serıa que la indexacion de parametros consiste en tener unacondition queue por cada combinacion de parametros de entrada que afectan a la CPRE.Lo malo es que esto no es exacto cuando hay CPREs que solo dependen de ciertapropiedad de algunos parametros (como es el caso del MultiAlmacen).Sea una especificacion de la forma:

PRE: ψ(~in , self )CPRE: ϕ(~in , self )accion(~in , ~out )

Una llamada legal a accion es una instancia de la forma σ(accion(~in , ~out )) donde σ esuna sustitucion de las variables de ~in por los valores de sus tipos tal que existe algunestado del recurso para el que σ(ψ(~in , self )) se cumple.Dos llamadas legales σ1(accion(~in , ~out )) y σ2(accion(~in , ~out )) son CPRE-equivalentes siiσ1(ϕ(~in , self ))⇔ σ2(ϕ(~in , self )).Esto quiere decir que dos llamadas legales pueden ser sintacticamente diferentes pero sison CPRE-equivalentes las podemos bloquear en una misma condition queue.Por tanto, la explicacion concisa y correcta es que la indexacion de parametros consisteen tener una condition queue por cada combinacion de parametros de entrada moduloCPRE-equivalencia.


























ejemplo: puente de un solo sentidoinstanciando CPREs

Recordemos una posible especificacion:C-TAD ControlAccesoPuenteOPERACIONESACCION solicitarEntrada: Lado[e]ACCION notificarSalida: Lado[e]SEMANTICADOMINIOTIPO Lado= N | STIPO ControlAccesoPuente= N

INICIAL: self= 0CPRE: (e= S ∧ self≥ 0) ∨ (e= N ∧ self≤ 0)solicitarEntrada (e)POST: (e= S ∧ self= selfpre + 1) ∨ (e= N ∧ self= selfpre − 1)CPRE: CiertonotificarSalida (x)POST: |self| = |selfpre| − 1

Las sustituciones validas para solicitarEntrada(e) son σ1 = e 7→ S y σ2 = e 7→ N . Seaϕ ≡ (e = S ∧ self ≥ 0) ∨ (e = N ∧ self ≤ 0).

σ1(ϕ) = (S = S ∧ self ≥ 0) ∨ (S = N ∧ self ≤ 0)⇔ self ≥ 0σ2(ϕ) = (N = S ∧ self ≥ 0) ∨ (N = N ∧ self ≤ 0)⇔ self ≤ 0

Por tanto, podemos implementar los bloqueos con dos condition queues, c1 y c2asociadas respectivamente a las condiciones self ≥ 0 y self ≤ 0.
















ejemplo: los filosofos de la mesa redondaclases de equivalencia en un array

C-TADMesaOPERACIONESACCION cogerTenedores: Sitio[e]ACCION soltarTenedores: Sitio[e]SEMANTICADOMINIOTIPO Sitio = {0 . . . 4}TIPOMesa= Sitio→ B

INICIAL: ∀ i ∈ Sitio • self (i )CPRE: self (i ) ∧ self (i + 1 mod 5)cogerTenedores(i)POST: self = self pre ⊕ {i 7→ Falso} ⊕ {i + 1 mod 5 7→ Falso}

CPRE: CiertosoltarTenedores(i)POST: self = self pre ⊕ {i 7→ Cierto} ⊕ {i + 1 mod 5 7→ Cierto}

En este caso es natural tener un array de 5 condition queues. La traduccion de instanciasa posiciones del array es trivial.Cuando usamos arrays de condition queues con indexacion de parametros es habitualimplementar los desbloqueos con un recorrido del array. En ese caso necesitaremos latraduccion inversa (de posiciones del array a instancias de la CPRE).














ejemplo: los filosofos de la mesa redondasolucion simple y mejorablepublic class MesaMon {private boolean t enedor l ib re [ ] =new boolean [ 5 ] ;

private Monitor mutex =new Monitor ( ) ;private Monitor . Cond c tenedores [ ] =new Monitor . Cond [ 5 ] ;public MesaMon ( ) {for ( int i = 0 ; i < 5 ; i ++) {t enedor l ib re [ i ] = true ;c tenedores [ i ] =mutex . newCond ( ) ;

}}public void cogerTenedores ( int i ) {mutex . enter ( ) ;i f ( ! t enedor l ib re [ i ] | |! t enedor l ib re [ ( i + 1) % 5 ] ) {c tenedores [ i ] . await ( ) ;}t enedor l ib re [ i ] = false ;t enedor l ib re [ ( i + 1) % 5] = false ;desbloqueo generico ( ) ;mutex . leave ( ) ;

}

private void desbloqueo generico ( ) {boolean s igna lE jecutado = false ;Monitor . Cond maxCond = null ;for ( int i = 0 ;i < 5 && ! s igna lE jecutado ;i ++) {i f ( t enedor l ib re [ i ] &&tenedor l ib re [ ( i + 1) % 5] &&c tenedores [ i ] . wa i t ing ( ) > 0) {c tenedores [ i ] . s i gna l ( ) ;s igna lE jecutado = true ;}

}}public void soltarTenedores ( int i ) {mutex . enter ( ) ;t enedor l ib re [ i ] = true ;t enedor l ib re [ ( i + 1) % 5] = true ;desbloqueo generico ( ) ;mutex . leave ( ) ;}

}





}



}





}



}





}



}


indexacion de clientesla tecnica mas general

La indexacion de clientes (tambien nos referimos a ella como indexacion de procesos) esla tecnica que usamos cuando el conjunto de clases de equivalencia obtenido en laindexacion de parametros es infinito o demasiado grande.En esta tecnica cada vez que una llamada deba ser bloqueada por no cumplirse su CPRE:

1 Guardaremos la causa del bloqueo, junto con una condition (nueva), en un objeto quellamaremos peticion aplazada. La causa suele ser una copia de los parametros de entrada queafectan a la CPRE. Habitualmente creamos una clase interna para las peticiones aplazadas deuna accion dada.2 Insertaremos la peticion aplazada en una coleccion recorrible y, finalmente3 Ejecutaremos await() sobre dicha condition queue.A la hora de realizar los desbloqueos:1 Recorreremos la estructura en busca de una peticion aplazada cuya CPRE se cumpla (esto esposible porque hemos guardado la causa del bloqueo).2 Ejecutaremos signal () sobre la condition queue de la peticion aplazada y, finalmente3 Borraremos la peticion aplazada de la coleccion recorrible.

El borrado de la peticion aplazada se puede realizar tanto desde el thread que desbloqueacomo desde el thread desbloqueado, pero hay que ser consistente y comentarloadecuadamente.Esta tecnica permite mucho control sobre estrategias de desbloqueo, prioridades, etc.,dependiendo del tipo de estructura de datos que usemos para guardar las peticionesaplazadas. No obstante recomendamos empezar con la estructura mas simple que nospermita obtener una solucion correcta para posteriormente pasar a una mas sofisticadaque nos permita optimizar.




















































ejemplo: control de temperatura

Alarmas

not() det()term

act(1)

act(2)

det(-10,5)

det(38,50)

23

C-TAD AlarmasOPERACIONESACCION notificar: Temp[e]ACCION detectar: Temp[e]× Temp[e]× Temp[s]SEMANTICADOMINIOTIPO Temp= {−10 . . . 50}TIPO Alarmas= TempINICIAL: self = 23CPRE: Ciertonotificar ( t )POST: self = t

CPRE: t ∈ [min ,max ]detectar(min,max,actual)POST: self = self pre ∧ actual = self


ejemplo: control de temperaturaclass AlarmasMonProcs implements Alarmas {private Monitor mutex = new Monitor ( ) ;public class PetDetectar {public int min ;public int max ;public Monitor . Cond c ;

public PetDetectar ( int min , int max) {this . min = min ;this .max = max ;this . c = mutex . newCond ( ) ;}

}

Queue<PetDetectar> espDetectar =new NodeQueue<PetDetectar > ( ) ;private int a = 23;public AlarmasMonProcs ( ) { }public void no t i f i c a r ( int t ) {mutex . enter ( ) ;a = t ;desbloqueoSimple ( ) ;mutex . leave ( ) ;}

public int detectar ( int min , int max) {int res ;mutex . enter ( ) ;i f ( a < min | | a > max) {PetDetectar pet =new PetDetectar (min ,max ) ;espDetectar . enqueue ( pet ) ;pet . c . await ( ) ;}res = a ;desbloqueoSimple ( ) ;mutex . leave ( ) ;return ( res ) ;

}void desbloqueoSimple ( ) {int n = espDetectar . s i z e ( ) ;bool s igna led = false ;for ( int i = 0 ; i < n && ! s igna led ; i ++) {pet = espDetectar . f ront ( ) ;i f ( pet .min < a && a < pet .max) {pet . c . s i gna l ( ) ;espDetectar . dequeue ( ) ;s igna led = true ;} else {espDetectar . dequeue ( ) ;espDetectar . enqueue ( pet ) ;}

}} }




}




}} }




}




}} }




}




}} }


un detalle acerca de las PREs¿y la PRE pa’ cuando?

Hasta ahora nos hemos centrado en el tratamiento de las CPREs porque es lo que masafecta a las decisiones que hay que tomar para implementar los bloqueos y desbloqueosy, en el codigo de las presentaciones he omitido el tratamiento de las PREs simplementepor una cuestion de espacio (sı lo teneis en el codigo de apoyo).La idea fundamental es que si se viola una PRE es que algo se ha hecho mal ya seaporque:

I se ha pasado un parametro incorrecto, e.g. cogerTenedores(5),I o bien porque se ha llamado a una operacion en un orden incorrecto, e.g. finLectura () siendothis. lectores = 0.

Por tanto, las violaciones de PREs deben tratarse antes de hacer ninguna otra cosa relativaa la accion en curso y deben provocar una excepcion significativa. Dicha excepcion debeser tratada o bien por el cliente o por el programa principal tomandose medidaspertinentes – basicamente abortar.Ejemplo:public void cogerTenedores ( int i ) {i f ( i < 0 | | i >= SITIOS )throw new RuntimeException (new Exception ( ” La s i l l a ” + i + ” no ex i s t e ” ) ) ;

/ / comportamiento normalmutex . enter ( ) ;. . .




















diferencias con locks & conditionssignalling policies

Las distribuciones actuales de Java incluyen una implementacion de monitores que coloquialmentellamamos locks & conditions (java. util .concurrent.locks) puesto que se basa en la interfaz Lock y lainterfaz Condition. La primera es la que se corresponde al concepto de monitor y proporciona lasoperaciones lock () (similar a enter()) y unlock() (similar a leave() ). Las operaciones sobre objetosCondition son await(), signal () mas unas cuantas no estandar.Las propuestas iniciales de monitores dejaban cierta libertad en la semantica del signal () , enparticular a que pasa si se modifica el estado del recurso entre el momento de hacer signal() y lareentrada del proceso desbloqueado, dando lugar a diferentes signalling policies:

I SX, signal & exit: en esta polıtica, el signal() lleva implıcito abandonar el monitor, con lo cual esimposible hacer mas de un signal().I SC, signal & continue: el proceso que hace signal() puede seguir en el monitor, y “tocar” cosas.I SW, signal & wait: el proceso que hace signal() cede el uso del monitor al proceso desbloqueadoy queda bloqueado en una sala de espera especial. Esto esta pensado para poder hacer buclesde signals.

Tanto los monitores de java. util .concurrent.locks como los de es.upm.babel.cclib.Monitor siguen lapolıtica SC. Sin embargo, los nuestros garantizan que el thread que recibe el signal() se coloca elprimero de la cola del monitor (priority monitor) y los de locks & conditions no.Esto provoca que entre el thread que ejecuta signal() y el que es desbloqueado pueden haberejecutado terceros threads ya presentes en la cola del lock, obligando a comprobar la CPRE dentro deun while.

















Documents

Sesión 19: Monitores Traduciendo especificaciones de recurso IIbabel.upm.es/.../material/slides/monitores/slides19.pdf · 2020-04-23 · Sesi´on19:Monitores – Traduciendoespeci1cacionesderecursoII