Primitivas de Sincronización

Transcripción

1 Primitivas de Sincronización JUAN CARLOS CONDE RAMÍREZ DISTRIBUTED COMPUTING

2 Introducción Todas las soluciones previas al problema de mutex fueron un desperdicio de algún modo: Si un proceso es incapaz de entrar a la CR, este verifica repetidamente que la condición de entrada sea verdadera; se está realizando trabajo inútil. Esta forma de espera es llamada espera activa (busy-wait). En lugar de verificar la condición de entrada repetidamente, si el proceso verifica la condición sólo cuando esta podría llegar a ser verdadera, este podría no desperdiciar ciclos de CPU. FCC-BUAP 2

3 Introducción Que un proceso verifique la condición de acceso a la CR sólo cuando esta podría llegar a ser verdadera requiere soporte desde el Sistema Operativo. Por lo tanto, las primitivas de sincronización existen para anular la espera activa y son utilizadas: para exclusión mutua para proporcionar orden entre varias operaciones de diferentes hilos. Aunque existen muchos tipos de sincronización, construidos en varios lenguajes de programación, dos de ellos son los más prevalecientes: semáforos y monitores. FCC-BUAP 3

4 Semáforos Dijkstra propuso el concepto de semáforo que soluciona el problema de espera activa. Un semáforo tiene dos campos, su valor y una cola de procesos bloqueados, así como dos operaciones asociadas a este: P() y V() La semántica de un semáforo binario se muestra en el siguiente programa: FCC-BUAP 4

5 Semáforos public class SemaforoBinario boolean value; SemaforoBinario( boolean initvalue ) value = initvalue public synchronized void P() while( value == false ) Util.myWait(this); //en cola de procesos bloqueados value = false; public synchronized void V() value = true; notify(); FCC-BUAP 5

6 Funcionamiento El contenido de value de un semáforo (o semáforo binario) sólo puede ser falso o verdadero. La cola de procesos bloqueados está vacía inicialmente y un proceso puede añadirse a sí mismo a la cola cuando este realiza una llamada a P(). Cuando un proceso llama a P() y value es verdadero, entonces el valor de value se convierte en falso. Sin embargo, si el valor del semáforo es falso, entonces el procesos se bloquea (línea 10) hasta que este llega a ser verdadero. La invocación a Util.myWait() (línea 11) consigue esto. La clase Util se muestra al final de este documento pero por ahora se asume que esta llamada inserta al proceso que la invocó a la cola de procesos bloqueados. FCC-BUAP 6

7 Funcionamiento Cuando value se hace verdadero, el proceso puede hacerlo falso en la línea 12 y regresar desde P(). La llamada a V() hace a value true y también le notifica al proceso si la cola de procesos dormidos en dicho semáforo es no-vacía. Ahora, implementar exclusión mutua es casi trivial: SemaforoBinario mutex = new SemaforoBinario(true); mutex.p(); criticalsection(); mutex.v(); FCC-BUAP 7

8 Semáforo Contador Otra variante del semáforo le permite a este tomar un entero arbitrario como value. Estos semáforos son llamados semáforos de conteo. Su semántica se muestra a continuación: FCC-BUAP 8

9 Semáforo Contador public class SemaforoContador int value; public SemaforoContador( int initvalue ) value = initvalue; public synchronized void P() value--; if( value < 0 ) Util.myWait( this ); public synchronized void V() value++; if( value <= 0 ) notify(); FCC-BUAP 9

10 Semáforo Contador Los semáforos pueden ser usados para resolver una amplia variedad de problemas de sincronización. Nótese que Java NO proporciona semáforos como base del lenguaje, pero pueden ser implementados fácilmente usando la idea de monitores (de los que se hablará más adelante). FCC-BUAP 10

11 Problema: Productor-Consumidor En este problema, existe un buffer compartido entre dos procesos nombrados el productor y el consumidor: El primero produce artículos que son depositados en un buffer y el consumidor extrae artículos del buffer y los consume. Por simplicidad, se asume que los ítems son del tipo double. Dado que el buffer es compartido, cada proceso debe acceder al buffer de una manera mutuamente excluyente. Por ahora, se usará un arreglo de elementos double de tamaño size como buffer. El buffer tiene dos apuntadores, inbuf y outbuf, los cuales contienen los índices del arreglo para depositar un artículo y extraer un artículo, respectivamente. La variable count da seguimiento al número actual de ítems en el buffer. FCC-BUAP 11

12 Problema: Productor-Consumidor La siguiente figura muestra el buffer como un arreglo circular en el que inbuf y outbuf son incrementados en base al módulo con size para mantener la congruencia de los slots para depositar y extraer artículos. FCC-BUAP 12

13 Problema: Productor-Consumidor Se puede observar que además de la exclusión mutua, existen dos restricciones de sincronización adicionales que necesitan ser satisfechas: 1. El consumidor no debe extraer ningún artículo de un buffer vacío. 2. El productor no debe depositar ningún artículo en un buffer lleno. NOTA: El buffer puede llenarse si el productor se mantiene produciendo a una mayor velocidad de la que el consumidor extrae los artículos. FCC-BUAP 13

14 Problema: Productor-Consumidor Tal forma de sincronización se conoce como sincronización condicional. Esta requiere que un proceso espere por alguna condición que llega a ser verdadera (así como el buffer llega a ser no vacío) antes de continuar sus operaciones. La clase BufferLimitado se muestra a continuación: FCC-BUAP 14

15 Clase BufferLimitado class BufferLimitado final int size = 10; double buffer[] = new double[size]; int inbuf = 0, outbuf = 0; SemaforoBinario mutex = new SemaforoBinario(true); SemaforoContador isempty = new SemaforoContador(0); SemaforoContador isfull = new SemaforoContador( size ); FCC-BUAP 15

16 Clase BufferLimitado public void deposit( double value ) isfull.p(); mutex.p(); // espera si el buffer está lleno // asegura la exclusión mutua buffer[inbuf] = value; inbuf = (inbuf + 1) % size; mutex.v(); isempty.v(); // notifica a algún consumidor en espera FCC-BUAP 16

17 Clase BufferLimitado public double fetch() double value; isempty.p(); mutex.p(); value = biffer[outbuf]; // esperar si el buffer está vacío // asegura la exclusión mutua // lee desde el buffer outbuf = (outbuf+1) % size; mutex.v(); isfull.v(); // notifica a cualquier productor en espera return value; FCC-BUAP 17

18 Problema: Productor-Consumidor Aquí se utiliza un semáforo de exclusión mutua para asegurar que todas las variables compartidas son accedidas de manera mutuamente excluyente. El semáforo de conteo isfull es utilizado para hacer que un productor espere en caso de que el buffer esté lleno, y el semáforo isempty es utilizado para hacer que un consumidor espere cuando el buffer está vacío. En el método deposit, de la línea 9 se verifica si el buffer está lleno. Si es así, el proceso hace una llamada y espera usando el semáforo isfull. FCC-BUAP 18

19 Problema: Productor-Consumidor Nótese que este semáforo ha sido inicializado de acuerdo al valor de size, y por lo tanto en ausencia de un consumidor, primero size llama a isfull.p() para que no se bloquee. En este punto, el buffer estaría lleno y cualquier llamada a isfull.p() haría posible el bloqueo. Si la llamada a isfull.p() no bloquea, entonces es posible acceder a la CR para utilizar el buffer compartido. La llamada mutex.p() en la línea 12 sirve como entrada a la CR, y mutex.v() sirve como salida de la CR. FCC-BUAP 19

20 Problema: Productor-Consumidor Aquí se utiliza un semáforo de exclusión mutua para asegurar que todas las variables compartidas son accedidas de manera mutuamente excluyente. El semáforo de conteo isfull es utilizado para hacer que un productor espere en caso de que el buffer esté lleno, y el semáforo isempty es utilizado para hacer que un consumidor espere cuando el buffer está vacío. En el método deposit, de la línea 9 se verifica si el buffer está lleno. Si es así, el proceso hace una llamada y espera usando el semáforo isfull. FCC-BUAP 20

21 Problema: Productor-Consumidor Una dentro de la CR, se deposita el valor en el buffer usando el índice inbuf de la línea 13. En la línea 15 se hace una llamada a isempty.v() para despertar a cualquier consumidor que pueda estar esperando debido a que el buffer estaba vacío. El método fetch es el complemento del método deposit. La clase BufferLimitado puede ser probada mediante el programa productor-consumidor mostrado a continuación. FCC-BUAP 21

22 Clase Productor import java.util.random; class Productor implements Runnable BufferLimitado b = null; public Productor( BufferLimitado initb ) b = initb; new Thread( this ).start(); public void run() double item; Random r = new Random(); while( true ) item = r.nextdouble(); System.out.println( Artículo producido + ítem ); b.deposit( item ); Util.mySleep(200); FCC-BUAP 22

23 Clase Consumidor class Consumidor implements Runnable BufferLimitado b = null; public Consumidor( BufferLimitado initb ) b = initb; new Thread( this ).start(); public void run() double item; while( true ) item = b.fetch(); System.out.println( Artículo extraído + item ); Util.mySleep(50); FCC-BUAP 23

24 Clase ProductorConsumidor class ProductorConsumidor public static void main(string args[]) BufferLimitado buffer = new BufferLimitado(); Productor productor = new Productor( buffer ); Consumidor = new Consumidor( buffer ); FCC-BUAP 24

25 Monitores Un Monitor es un objeto de alto nivel orientado a la construcción para la sincronización en programación concurrente. Un monitor puede ser visto como una clase que puede ser usada en programas concurrentes. Como cualquier clase, un monitor tiene atributos y métodos para manipular dichos datos. FCC-BUAP 25

26 Monitores Debido a que múltiples hilos pueden acceder a datos compartidos al mismo tiempo, los monitores soportan la noción de métodos de ingreso para garantizar la exclusión mutua. Esto garantiza que sólo uno de los hilos puede ser ejecutado en cualquier método de ingreso en cualquier momento. Algunas veces la frase el hilo t está dentro del monitor es utilizada para denotar que el hilo t está ejecutándose un método de ingreso. Es claro que a lo más un hilo puede estar en el monitor en cualquier momento, entonces cualquier objeto monitor asociado es una cola de hilos que están esperando a entrar al monitor. FCC-BUAP 26

27 Monitores En el estudio y uso de los semáforos se puede ver que las llamadas a las funciones necesarias para utilizarlos quedan repartidas en el código del programa, haciendo difícil corregir errores y asegurar el buen funcionamiento de los algoritmos. Para evitar estos inconvenientes se desarrollaron los monitores. El concepto de monitor fue definido por primera vez por Charles Antony Richard Hoare en el artículo Monitors: An Operating System Structuring Concept de FCC-BUAP 27

28 Monitores Como hemos visto antes, los programas concurrentes también requieren sincronización condicional cuando un hilo debe esperar por determinada condición que llegará a ser verdadera. Para dirigir la sincronización condicional, el constructor del monitor soporta la noción de variables de condición. Una variable de condición tiene dos operaciones definidas: wait y notify (también conocida como signal). FCC-BUAP 28

29 Monitores Para cualquier variable de condición x, cualquier hilo, por decir t 1, realiza una llamada a x.wait() y se bloquea y coloca dentro de una cola asociada con x. Cuando otro hilo, por decir t 2, realiza una llamada a x.notify(). Si la cola asociada con x es no-vacía, un hilo es removido de una cola e insertado en otra cola de hilos disponibles para ser ejecutados. Dado que a lo más un hilo puede estar en el monitor, esto inmediatamente genera un problema: cuál hilo debe continuar después de la operación de notificación? aquel que invoque al método notify o el hilo que estuvo esperando más tiempo?. FCC-BUAP 29

30 Monitores Existen dos posibles respuestas: 1. Continúa su ejecución uno de los hilos que estuvo esperando sobre la variable de condición. Los Monitores que siguen esta regla son conocidos como Monitores Hoare. 2. Continúa con su ejecución el hilo que hizo la llamada de notificación. Cuando este hilo sale del monitor, entonces otros hilos pueden entrar al monitor. Esta es la semántica que se sigue en Java. Una ventaja del Monitor de Hoare s es que el hilo que fue notificado sobre la condición comienza su ejecución sin intervención de cualquier otro hilo. FCC-BUAP 30

31 Monitores Por lo tanto, el estado en el que este hilo comienza su ejecución es el mismo que cuando notify fue llamado. Al despertar, este puede asumir que la condición es verdadera. En consecuencia, para usar un monitor de Hoare s, el código de un hilo puede ser: if ( B) x.wait(); FCC-BUAP 31

32 Monitores Asumiendo que t 2 notifica sólo cuando B es verdadero, podemos saber que t 1 puede asumir B al despertar. En un monitor estilo Java, a pesar de que t 2 emite la notificación, este continúa su ejecución. Por lo tanto, cuando t 1 obtiene su turno de ejecutarse, la condición B puede ya no ser verdad más. De aquí que, cuando usamos Java, los hilos esperan usualmente por la condición como: while ( B ) x.wait( ); El hilo t 1 puede tomar un notify()sólo como una señal o indicio de que B puede ser verdadero. Por ende, este necesita verificar explícitamente la veracidad de B cuando este despierto. Si B es falso actualmente, este invoca a wait()de nuevo. FCC-BUAP 32

33 Monitores En Java, especificamos que un objeto es un monitor utilizando la palabra synchronized con sus respectivos métodos. Para obtener sincronización condicional, Java proporciona: wait(): el cual inserta al hilo en la cola de espera. Por simplicidad, se utiliza Util.myWait() en lugar de wait() en Java. La única diferencia es que mywait cacha la InterruptedException. notify(): el cual despierta un hilo de la cola de espera. notifyall(): el cual despierta a todos los hilos de la cola de espera. FCC-BUAP 33

34 Monitores Java no tiene variables de condición. Por lo que las asociadas con cada objeto hay una simple cola wait. Esto es suficiente para la mayoría de las necesidades de programación. Si se necesita, también es fácil simular variables de condición en Java. Una representación gráfica de un monitor en Java se muestra a continuación. Existen dos tipos de colas asociadas con un objeto: una cola de hilos esperando por el bloqueo asociado con el monitor y otra cola de hilos esperando por que la condición llegue a ser verdadera. FCC-BUAP 34

35 Monitores Esto permite resolver algunos problemas de sincronización con Monitores en Java. Por ejemplo, el problema del Productor-Consumidor: FCC-BUAP 35

36 Monitores class BoundedBufferMonitor final int sizebuf = 10; double buffer[] = new double[sizebuf]; int inbuf = 0, outbuf = 0, count = 0; public synchronized void deposit( double value ) while( count == sizebuf ) Util.myWait( this ); buffer[inbuf] = value; inbuf = ( inbuf + 1 ) % sizebuf; count++; if( count == 1 ) notify(); // buffer lleno // items disponibles para extraer FCC-BUAP 36

37 Monitores public synchronized double fetch( ) double value; while( count == 0 ) // buffer vacío Util.myWait( this ); value = buffer[outbuf]; outbuf = ( outbuf + 1 ) % sizebuf; count--; if( count == sizebuf - 1 ) // slots vacíos disponibles notify(); return value; FCC-BUAP 37

38 Monitores La clase BoundedBufferMonitor mostrada anteriormente tiene dos métodos de ingreso: deposit y fetch. Esto significa que si un hilo está ejecutando al método deposit o fetch, entonces ningún otro hilo puede ejecutar dichos métodos. La palabra reservada synchronized permite la exclusión mutua durante el acceso a las variables compartidas y corresponde a obtener el monitor de bloqueo. FCC-BUAP 38

39 Monitores Enfocándonos en el método deposit en la línea 8, si el buffer está lleno (i.e. count igual a sizebuf), entonces el hilo que llamó a deposit debe esperar a que se consuma un ítem y quede libre al menos un slot en el buffer. Por lo tanto, este invoca al método mywait(). Cuando un hilo espera por la condición, éste se va a una cola esperando a ser notificado por alguno otro hilo. Éste también debe liberar el monitor de bloqueo para que otro proceso pueda acceder al monitor y hacer verdadera la condición por la cual este hilo esta esperando. Cuando este hilo es notificado, éste tiene que adquirir el monitor de bloqueo de nuevo antes de continuar su ejecución. FCC-BUAP 39

40 Monitores Ahora asume que la condición en la sentencia while de la línea 8 es falsa. Entonces value puede ser depositado en el buffer. La variable inbuf apunta al rabo de la cola circular buffer. Éste avanza después de la inserción y el contador del número de ítems es incrementado. Aún no hemos terminado realmente. Mientras se diseña un monitor, es posible que sea necesario asegurarse que si algún hilo está esperando por una condición que pueda llegar a ser verdadera, entonces dicho hilo debe ser notificado. FCC-BUAP 40

41 Monitores En este caso, un hilo consumidor puede estar esperando en el método fetch por que algún ítem esté disponible. Finalmente, si el contador es 1, se notifica a cualquier hilo en espera en la línea 14. FCC-BUAP 41

42 Clase Util import java.util.*; public class Util public static int max(int a, int b) if( a > b ) return a; return b; Public static void mysleep(int time) try Thread.sleep(time); catch(interruptedexception e) public static void mywait(object obj) System.out.println( waiting ); try obj.wait(); catch(interruptedexception e) FCC-BUAP 42