CAPÍTULO 8. Comunicación y sincronización basada en variables compartidas

Save this PDF as:
 WORD  PNG  TXT  JPG

Tamaño: px
Comenzar la demostración a partir de la página:

Download "CAPÍTULO 8. Comunicación y sincronización basada en variables compartidas"

Transcripción

1 CAPÍTULO 8. Comunicación y sincronización basada en variables compartidas 8 Comunicación y sincronización basada en variables compartidas Exclusión mutua y condición de sincronización Espera ocupada Suspender y reanudar Semáforos Críticas a los semáforos Regiones criticas condicionales Monitores Llamadas anidadas al monitor Criticas a los monitores Objetos protegidos Métodos de sincronización Espera y notificación Herencia y sincronización Rafael Álvarez García Última revisión Nota importante: Este documento no pretende reemplazar al material propuesto por la UNED para la asignatura Sistemas en Tiempo Real. Cualquier sugerencia, comentario o corrección sobre este documento, envíelo a para poder realizar los cambios necesarios. 1

2 8 Comunicación y sincronización basada en variables compartidas Las mayores dificultades asociadas con la programación concurrente surgen de la interacción de procesos. Casi nunca los procesos son independientes entre si. El comportamiento correcto de un programa concurrente depende estrechamente de la sincronización y la comunicación entre procesos. En su sentido más amplio, sincronizar es satisfacer las restricciones en el entrelazado de las acciones de diferentes procesos (por ejemplo, una acción particular de un proceso solo ocurre después de una acción especifica de otro proceso). La comunicación entre procesos se basa normalmente o en el uso de variables compartidas o en el paso de mensajes. Las variables compartidas son objetos a los que puede acceder más de un proceso; la comunicación puede realizarse, por tanto, referenciado en cada proceso dichas variables cuando sea apropiado. El paso de mensajes implica el intercambio explicito de datos entre dos procesos mediante un mensaje que pasa de un proceso a otro siguiendo algún mecanismo. Hay que señalar que la elección entre variables compartidas y paso de mensajes deben realizarla los diseñadores de los lenguajes o de los sistemas operativos, y no implica que deba utilizarse un método particular de implementación. Las variables compartidas son más fáciles de soportar si hay memoria compartida entre procesos, pero pueden ser utilizadas incluso si el hardware incorpora un medio de comunicación. De forma similar, puede obtenerse una primitiva de paso de mensajes mediante memoria compartida o mediante una red física de paso de mensajes. 8.1 Exclusión mutua y condición de sincronización. Aunque las variables compartidas parecen una forma directa de pasar información entre procesos, su uso no restringido es poco fiable e inseguro, debido a los múltiples problemas de actualización. Considere dos procesos que actualizan una variable compartida, X, mediante la sentencia: X := X+l En la mayoría del hardware esto no se ejecuta como una operación indivisible (atómica), sino que se implementara en tres instrucciones distintas: (1) Carga el valor de X en algún registro (o en la parte superior de la pila). (2) Incrementa el valor en el registro en 1. (3) Almacena el valor del registro de nuevo en X. Como ninguna de las tres operaciones es indivisible, dos procesos que actualicen la variable simultáneamente generarían un entrelazamiento que podía producir un resultado incorrecto. Por ejemplo, si X era originalmente 5, los dos procesos podrían cargar cada uno 5 en sus registros, incrementarlos, y almacenar entonces 6. Una secuencia de sentencias que debe aparecer como ejecutada indivisiblemente se denomina sección critica. La sincronización que se precisa para proteger una sección crítica se conoce como exclusión mutua. La atomicidad, aunque ausente de la operación de asignación, se supone que esta presente en el nivel de la memoria. Por tanto, si un proceso esta ejecutando X := 2

3 5 simultáneamente con otra ejecución de X : =6, el resultado sería o 5 o 6 (no otro valor). Si esto no fuera cierto, seria difícil razonar sobre los programas concurrentes o implementar niveles de atomicidad más altos, como sincronización de exclusión mutua. Sin embargo, esta claro que si: dos procesos están actualizando un objeto estructurado, esta atomicidad solo se aplicara ai nivel del elemento palabra. EI problema de la exclusión mutua esta en el núcleo de la mayoría de las sincronizaciones de procesos concurrentes, y tiene un gran interés teórico y practico. La excusión mutua no es la única sincronización importante; evidentemente, si dos procesos no comparten variables no se necesita exclusión mutua. La sincronización condicionada, o de condición, es otro requisito significativo, y es necesaria cuando un proceso desea realizar una operación que solo puede ser realizada adecuadamente, o de forma segura, si otro proceso ha realizado alguna acción o esta en algún estado definido. Un ejemplo de sincronización de condición se produce al usar búferes. Dos procesos intercambiando datos funcionaran mejor si no se comunican directamente, sino mediante un búfer. La ventaja esta en el desacoplamiento de los procesos, que permitirá pequeñas fluctuaciones en la velocidad de trabajo de los dos procesos. Un proceso de entrada, por ejemplo, podrá recibir ráfagas de datos que deberá almacenar en el búfer destinado al proceso de usuario correspondiente. Los búferes son habituales en la programación concurrente para enlazar dos procesos, que forman un sistema productor-consumidor. Si se implementa un buffer finito (limitado), se precisa de dos condiciones de sincronización. En primer lugar, el proceso productor no deberá intentar llenar el búfer si este esta lleno. En segundo lugar, no se permite al proceso consumidor extraer objetos del búfer si esta vacío. Además, si es posible insertar y extraer simultáneamente, habrá que garantizar que se excluyan mutuamente ciertas operaciones, como por ejemplo que dos productores utilicen a la vez el apuntador «hueco libre siguiente» del búfer, corrompiéndolo. La implementación de cualquier forma de sincronizaeión, suele acarrear la detención de algún proceso hasta que pueda continuar. 8.2 Espera ocupada. Una forma de implementar la sincronización es comprobar las variables compartidas que actúan como indicadores en un conjunto de procesos. Esta aproximación sirve razonablemente bien para implementar sincronización de condición, pero no hay un método simple para la exclusión mutua. Para indicar una condición, un proceso activa el valor de un indicador; para esperar por esta condición, otro proceso comprueba este indicador, y continúa solo cuando se lee el valor apropiado: process P1; (* proceso esperando *) while indicador = abajo do nu ll end; end P1; 3

4 process P2; * proceso indicando *) indicador := arriba; end P2; Si la condición no es aún correcta (esto es, si el indicador esta aun abajo), Si no tiene elección, y deberá continuar en el bucle para volver a comprobar el indicador. Esto se conoce como espera ocupada, y también como giro y a los indicadores como cerrojos de giro (spin locks). Los algoritmos de espera ocupada son en general ineficientes, y hacen que los procesos consuman ciclos de proceso en un trabajo inútil, Es más, en sistemas multiprocesador, pueden dar lugar a un exceso de tráfico en el bus de memoria o en la red (si el sistema es distribuido) Además, no es posible imponer fácilmente disciplinas de colas si hay más de un proceso esperando por una condición (es decir, comprobando el valor de un indicador). Si los algoritmos usados son más complejos, la exclusión mutua se vuelve también más dificultosa. Considere dos procesos (P1 y P2) con secciones críticas mutuas. Para proteger el acceso a ellas, se puede pensar en un protocolo que es ejecutado por cada proceso antes de entrar en la sección critica, y que va seguido de otro protocolo de salida. El aspecto que tendría cada proceso viene a ser el siguiente: process P; loop end end P; protocolo de entrada sección critica protocolo de entrada sección no critica Antes de dar una solución que sirva para la exclusión mutua, se discutirán tres aproximaciones inexactas. La primera emplea una solución con dos indicadores que es (casi) una extensión lógica del algoritmo de sincronización de condición de espera ocupada; process P1; loop indicador1!:= arriba; (* anuncia el intento de entrar *) while indicador2 = arriba do null (* espera ocupada si el otro proceso esta dentro *) end; (*' de su sección critica *) <sección critica> indicadorl := abajo; (* fin del protocolo*) <sección no critica> end end P1; process P2; loop indicador2!:= arriba; (* anuncia el intento de entrar *) 4

5 end P1; end while indicador1 = arriba do null (* espera ocupada si el otro proceso esta dentro *) end; (*' de su sección critica *) <sección critica> indicador2 := abajo; (* fin del protocolo*) <sección no critica> Ambos procesos anuncian su intención de entrar en sus secciones criticas y comprueban si el otro proceso esta dentro de su sección crítica. Pero esta «solución» adolece de un problema no despreciable. Considere un entrelazado con la siguiente traza: P1 activa su indicador (indicadorl ahora arriba) P2 activa su indicador (indicador2 ahora arriba) P2 comprueba indicadorl (esta arriba, por tanto P2 se mantiene en su bucle) P2 entra en su espera ocupada P1 comprueba indicador2 (esta arriba, por tanto P1 se mantiene en su bucle P1 entra en su espera ocupada El resultado es que ambos procesos permanecen en sus esperas ocupadas. Ninguno podrá salir, porque el otro no puede salir. Este fenómeno se conoce como interbloqueo activo (livelock), y es una severa condición de error. El problema con el algoritmo anterior nace de que cada proceso anuncia su intención de entrar en su sección critica antes de comprobar si es aceptable anunciarlo. En esta otra aproximación se invierte el orden de estas dos acciones: process P1; loop while indicador2 = arriba do null (* espera ocupada si el otro proceso esta dentro *) end; (* su sección critica.*) indicadorl := arriba; (* anuncia su intento de entrar *) <sección critica> indicadorl := abajo; "(* protocolo de salida *) <sección no crítica> end end P1; process P2; loop while indicador1 = arriba do null (* espera ocupada si el otro proceso esta dentro *) end; (* su sección critica.*) indicador2 := arriba; (* anuncia su intento de entrar *) <sección critica> indicador2 := abajo; "(* protocolo de salida *) <sección no crítica> end end P2; Ahora se puede producir un entrelazado, que de hecho falla al proporcionar la exclusión mutua. 5

6 Pl y P2 están en su sección no critica ( indicadorl = indicador2 = abajo) Pl comprueba flag2 (esta abajo) P2 comprueba flagl (esta abajo) P2 activa su indicador (indicaclor2 ahora arriba) P2 entra en su sección critica Pl activa su indicador (indicadorl ahora arriba P1 entra en su sección critica (Pl y P2 están ambos en sus secciones criticas). El problema de estas dos estructuras es que la activación del indicador propio y la comprobación de los otros procesos no es una acción indivisible. Así, podría pensarse que el camino correcto es usar solo un indicador que indique que próximo proceso debería entrar en su sección critica. Como este indicador decide de quien es el turno de entrar, se llamara turno. process P1; loop while turno = 2 do null end; <sección critica> turno := 2; <sección no crítica> end end P1; process P2; loop while turno = 1 do null end; <sección critica> turno := 1; <sección no crítica> end end P2; Con esta estructura, la variable turno deberá valer o 1 o 2. Si vale 1, entonces Pl no puede ser retrasado indefinidamente, y P2 no puede entrar en su sección critica. Sin embargo, turno no podrá tomar el valor 2 mientras P1 este en su sección critica, dado que la única forma de asignarle 2 es en el protocolo de salida de P1. De una forma simétrica, si el turno tiene el valor 2, implica que se garantiza la exclusión mutua, y no es posible el interbloqueo activo si ambos procesos están ejecutando sus respectivos bucles. Sin embargo, este ultimo punto es crucial; si P1 falla a en su sección no critica, turno tendrá eventualmente el valor 1, y permanecerá con ese valor (es decir, P2 tendrá prohibido entrar en su sección critica aunque no se este ejecutando P1). Incluso aunque se ejecute normalmente, al usar una sola variable de turno, los procesos funcionaran con el mismo tiempo de ciclo. No es posible que, por ejemplo, P1 entre tres veces en su sección crítica por una de P2. Y esta restricción es inaceptable para procesos autónomos. Por ultimo, se presenta un algoritmo que evita el estrecho acoplamiento anterior, pero que da exclusión mutua y ausencia de interbloqueo activo. Ambas aproximaciones tienen dos 6

7 indicadores (indicadorl e indicador2), que son tratados por el proceso que las «posee», y una variable turno que solo se utiliza en caso de contienda al entrar en las secciones criticas: process P1; loop indicadorl:= arriba; (* anuncia su intento de entrar *) turno:= 2; * da prioridad al otro proceso * while indicador2 = arriba and turno = 2 do null end; <sección critica> indicador1 := abajo; <sección no critica> end end P1; process P2; loop indicador2:= arriba; (* anuncia su intento de entrar *) turno:= 1; * da prioridad al otro proceso * while indicador1 = arriba and turno = 1 do null end; <sección critica> indicador2 := abajo; <sección no critica> end end P2; Si no hay más que un proceso queriendo entrar en su sección critica, entonces el indicador del otro proceso estará abajo y entrará inmediatamente. Pero si se han establecido ambos indicadores, se tendrá en cuenta el valor de turno. Suponga que tiene un valor inicial de 1; esto supone que habrá cuatro posibles entrelazamientos, en función del orden en que cada proceso asigne un valor a turno y después compruebe su valor en la sentencia while: Primera posibilidad: P1 primero, después P2 P1 coloca turno a 2 P1 comprueba turno. y entra en su bucle ocupado P2 coloca turno a 1 turno se mantendrá con ese valor) P2 comprueba turno y entra en.su bucle ocupado P1 realize el bucle, vuelve a comprobar turno y entra en su sección critics Segunda posibilidad: P2 primero, después P1 P2 coloca turno a 1 P1 comprueba turno y antra en su bucle ocupado P1 coloca turno a 2 (turno se mantendrá con ese valor) P1 comprueba turno y entra en su bucle ocupado P2 realiza el bucle, vuelve a comprobar turno y entra en su sección critica Tercera posibilidad; P1 y P2 entrelazados P1 coloca turno a 2 P2 coloca turno a 1 (turno se mantendrá con ese valor) P2 entra en su bucle ocupado P1 entra en su sección critica 7

8 Cuarta posibilidad: P2 y P1 entrelazados P2 coloca turno a 1 P1 coloca turno a 2 (turno se mantendrá con ese valor) P1 entra en su bucle ocupado P2 entra en su sección critica Las cuatro posibilidades conducen a un proceso a su sección critica, y al otro a un bucle de espera. En general, aunque un sencillo entrelazado puede ilustrar que un sistema falla al satisfacer su especificación, no sirve para mostrar fácilmente que todos los posibles entrelazados están conformes con la especificación. Para esto ultimo, es preciso usar demostraciones formales y comprobación de modelos. Curiosamente, el algoritmo anterior es equitativo en caso de contienda en el acceso a las secciones criticas, y, por ejemplo, si P1 tuvo éxito (según el primer o tercer entrelazado), se obliga a que P2 entre a continuación. Cuando P1 sale de su sección critica, baja su indicador 1. Esto podría permitir que P2 entrara en su sección critica, pero incluso si no lo hace (porque no se estuviera ejecutando en ese instante), entonces P1 podría continuar, entrar, y dejar su sección no crítica, levantar indicador1, colocar turno a 2, y pasar a un bucle de espera. Permanecería allí hasta que P2 entrara, dejara su sección crítica y bajara indicador2 según su protocolo de salida. En términos de fiabilidad, el fallo de un proceso dentro de su sección no crítica no afectara a los demás procesos. No ocurre así cuando fallan los protocolos o la sección crítica. Aquí, la finalización prematura de un proceso supondría problemas de interbloqueo activo para el resto del programa. Se ha discutido extensamente este problema para mostrar la dificultad de implementar la sincronización entre procesos usando solo variables compartidas y ninguna otra primitiva adicional distinta de las encontradas en los lenguajes secuenciales. Estas dificultades pueden resumirse en lo siguiente: Los protocolos de espera ocupada son difíciles de diseñar y comprender, y es complicado probar su corrección. (El lector podría querer considerar la generalización del algoritmo de Peterson para n procesos.) Los programas de prueba pueden ignorar entrelazamientos raros que rompen la exclusión mutua o llevan a un interbloqueo activo. Los bucles de espera ocupada son ineficientes. Una tarea no fiable (engañosa) que utilice falsamente las variables compartidas, corromperá el sistema completo. Ningún lenguaje de programación concurrente se basa completamente en esperas ocupadas y variables compartidas; hay otros métodos y primitivas. Para sistemas con variables compartidas, los semáforos y monitores son las construcciones más usuales. 8.3 Suspender y reanudar Uno de los problemas de los bucles de espera ocupada es que desperdician tiempo valioso de procesador. Un método alternativo es suspender (es decir, eliminar del conjunto de procesos 8

9 ejecutables) al proceso solicitante si la condición por la que espera no es cierta. Considere, por ejemplo, una sencilla sincronización de condición con un indicador. Un proceso activa el indicador, y otro espera hasta que el indicador esta activado y lo desactiva a continuación. Una forma sencilla de suspender (suspend) y reanudar (resume) podría ser la siguiente: process P1; (* proceso que espera *)... if indicador = abajo do suspend; end; indicador := abajo; end P1; process P2; (* signalling process *)... indicador := arriba; resume P1; (* no tiene efecto si P1 no ha sido suspendido *) end P2; Esta aproximación estaba soportada por una de las primeras versiones de la clase Thread de Java: public final void suspend(); // lanza SecurityException; public final void resume O; // lanza SecurityException; El ejemplo anterior se puede representar en Java axial: boolean indicador; final boolean arriba = true; final boolean abajo = false; class PrimerHilo extends Thread public void run() if(indicador == abajo) suspend; ; indicador = abajo;... ; class SegundoHilo extends Thread // H2 PrimerHilo Hi; public SegundoHilo(PrimerHilo H) súper(); 9

10 HI =H; public void runo indicador = arriba; H1.resume();... Desgraciadamente, esta aproximación padece lo que se conoce como una condición de carrera. El hilo HI podría comprobar el indicador, y el soporte subyacente de ejecución (o sistema operativo) decidir desalojarlo y ejecutar H2. H2 activa el indicador y resume HI. Hi no esta suspendido, como es obvio, por lo que resume no tiene efecto. Ahora, cuando Hi vuelva a ejecutarse, piensa que indicador esta abajo y, por tanto, se suspende el mismo. La razón de este problema, que estaba presente en los ejemplos dados en la sección previa, es que el indicador es un recurso compartido que esta siendo comprobado, y una acción que va a ser tomada que depende de su estatus (el proceso se esta suspendiendo el mismo). Esta comprobación y suspensión no es una acción atómica, y por tanto puede ser interferenciada por otros procesos. Esta es la causa de que la versión más reciente de Java de por obsoletos estos métodos. Hay varias soluciones bien conocidas para resolver este problema de condición de carrera, y todas ellas ofrecen cierta forma de operación de suspensión en dos etapas. Esencialmente, P1 debe anunciar que planea suspenderse próximamente. Cualquier operación de reanulación que encuentre con que P1 no esta suspendido vera aplazado su efecto, y cuando P1 se suspenda, será reiniciado inmediatamente; es decir, anulara la suspensión. Aunque la funcionalidad suspender y reanudar es de bajo nivel, propensa a una utilización errónea, es un mecanismo eficiente que puede usarse para construir primitivas de sincronización de nivel superior. Aunque suspender y reanudar son útiles primitivas de bajo nivel, ningún sistema operativo o lenguaje depende únicamente de estos mecanismos para la exclusión mutua o la sincronización de condición. 8.4 Semáforos Los semáforos son un mecanismo sencillo para la programación de la exclusión mutua y la sincronización de condición. Aportan los dos beneficios siguientes: (1) Simplifican los protocolos para la sincronización. (2) Eliminan la necesidad de bucles de espera ocupados. Un semáforo es una variable entera no negativa que, aparte de la inicialización, solo puede ser manejada por dos procedimientos. se denominaran wait y signal. La semántica de wait y signal es como sigue: 10

11 (1) wait (S) Si, el valor del semáforo, S, es mayor que cero, entonces decrementa su valor en uno; en caso contrario, demora el proceso hasta que S sea mayor que cero (y entonces decrementa su valor). (2) signal (S Incrementa el valor del semáforo, S, en uno. Los semáforos generalizados suelen conocerse como semáforos de conteo, ya que sus operaciones incrementan o decrementa un contador entero. La propiedad adicional importante de wait y signal es que sus acciones son atómicas (indivisibles). Dos procesos, que ejecuten sendas llamadas a wait sobre el mismo semáforo no interfieren. Además, un proceso no falla durante la ejecución de una operación de semáforo. La sincronización de condición y la exclusión mutua pueden programarse fácilmente con semáforos. Primero, considere la sincronización de condición: * sincronización de condición *) var sincon : semáforo; (* inicialmente 0 *) proccess P!; (* proceso que espera *)... end P1; wait (sincon) process P2; (* proceso que ejecuta signal *)... signal (sincon);... end P2; Cuando P1 ejecuta wait en un semáforo a 0, será demorado hasta que P2 ejecute signal. Esto pondrá sincon a 1, con lo que terminara wait; P1 continuará, y sincon se decrementa a 0. Hay que añadir que si P2 ejecuta signal primero, el semáforo se pone a 1, por lo que P1 no se demora al ejecutar wait. La exclusión mutua es igualmente sencilla. * exclusión mutua *) var mutex : semáforo; (* inicialmente a 1 *) process P1; loop wait (mutex); 11

12 end end P1; process P2; end end P2; loop <sección critica> signal (mutex); <sección no critica> wait (mutex); <sección critica> signal (mutex); <sección no critica> P1 y P2 se disputan la entrada en la sección crítica (están en contienda) si ejecutan sus sentencias wait simultáneamente. Sin embargo, al ser wait atómica, uno de ellos completara la ejecución de su sentencia antes de que comience el otro. Un proceso ejecutara un wait (mutex) con mutex=l, lo que le permitirá dirigirse a su sección critica y poner mutex a 0; el otro proceso ejecutara wait (mutex) con mutex=0, y será demorado. Una vez que el primer proceso salga de su sección critica, efectuará signal(mutex) lo que producirá que el semáforo se coloque a 1 de nuevo. y permitirá entrar en su sección critica al segundo proceso (y colocar mutex a 0 de nuevo). Al delimitar una sección de código con wait/signal, el valor inicial del semáforo restringirá la cantidad máxima de objetos de código que se ejecutan concurrentemente. Si el valor inicial es 0. no entrara ningún proceso; si es 1, podrá entrar solo un proceso (es decir, exclusión mutua); para valores mayores que uno, se permitirá el numero dado de ejecuciones concurrentes del código Críticas a los semáforos. Aunque el semáforo es una elegante primitiva de sincronización de bajo nivel, un programa de tiempo real construido solo sobre el uso de semáforos es de nuevo propenso a errores. Basta con que se produzca la omisión o mala ubicación de un semáforo para que el programa completo falle en tiempo de ejecución. No se puede garantizar la exclusión mutua, y puede aparecer el bloqueo indefinido justo cuando el software esta tratando con un suceso raro pero crítico. Se precisa una primitiva de sincronización más estructurada. Lo que proporciona un semáforo es un medio para programar exclusión mutua sobre una sección critica. Una aproximación más estructurada debiera proporcionar la exclusión mutua directamente. 12

13 8.5 Regiones criticas condicionales Las regiones criticas condicionales (CCR; conditional critical regions) son un intento de superar algunos de los problemas asociados con los semáforos. Una región crítica es una sección de código que esta garantizado que será ejecutado en exclusión mutua. Debe compararse con el concepto de sección critica, la cual debiera ejecutarse bajo exclusión mutua (pero cuando hay error pudiera no serlo). Claramente, la programación de una sección critica como una región critica satisface inmediatamente el requisito para exclusión mutua. Las variables que deben ser protegidas de un uso concurrente son agrupadas juntas en las llamadas regiones, y son etiquetadas como recursos. Esta prohibido que los procesos entren en una región en la que hay otro proceso activo. La condición de sincronización se proporciona mediante guardas en las regiones. Cuando un proceso desea entrar en una región critica, evalúa la guarda (bajo exclusión mutua): si la guarda se evalúa a cierto podrá entrar, pero si es falsa el proceso se demorara. Como con los semáforos, el programador no supone ningún orden de acceso si hay más de un proceso demorado intentando entrar en la misma región critica (por cualquier razón). Para ilustrar el uso de las CCR, se proporciona a continuación un esbozo del programa del búfer limitado. program bufer_eg; type bufer_t is record end record; huecos : array(l..n of character; talla : integer range 0..N; tope, base : integer range 1..N; buter : bufer t; resource buf : bufer; process procructor;... loop región buf when bufer.talla < N do end region poner caracter en el búfer, etc end loop; 13

14 end process consumidor; end... loop end región buf when buffer.talla > 0 do end region... end loop; toma caracter del bufer, etc Un posible problema de prestaciones con CGR es que los procesos deben reevaluar sus guardas cada vez que se abandona una CCR que llama al recurso. Un proceso suspendido debe volver a ejecutable de nuevo con el fin de comprobar la guarda, y, si todavía es falsa, volver al estado suspendido. 8.6 Monitores El problema principal con las regiones condicionales es que pueden estar dispersas a lo largo de todo el programa. Los monitores están pensados para atenuar este problema proporcionando regiones de control más estructuradas. También pueden utilizar una forma de sincronización de condición que es más eficiente de implementar. Las regiones críticas consideradas se escriben como procedimientos, y están encapsuladas en un único modulo, llamado monitor. Como modulo, se ocultan todas las variables que deben ser miembros del modulo tienen garantizada su ejecución con exclusión mutua. Los monitores surgen como un refinamiento de las regiones criticas condicionales. Continuando, a efectos de comparación, con el ejemplo del búfer limitado, un monitor búfer debiera tener la siguiente estructura: monitor búfer; export agrega, toma; var * declaración de lasvariables necesarias *) procedure agrega (I : integer); 14

15 end; begin end procedure toma var I : integer); end; (* inicialización de las variables del monitor *) Con lenguajes como Modula2 y Ada, es natural programar el búfer como un modulo distinto (package). Ocurre lo mismo al programarlo como monitor, aunque la diferencia entre un modulo y un monitor esta en que, en este ultimo caso, las llamadas concurrentes para agregar o tomar (en el caso anterior) son secuencializadas por definición, haciendo innecesarios los semáforos para la exclusión mutua. Aunque el monitor proporciona exclusión mutua, existe todavía una necesidad de sincronización de condición en el. En teoría, podrían seguir utilizándose semáforos, pero normalmente se incluye una primitiva de sincronización más sencilla. En los monitores de Hoare (Hoare, 1974), esta primitiva se llama variable de condición, y se maneja mediante dos operadores que, por sus similitudes con la estructura de semáforo, serán llamados de nuevo wait y signal. Cuando un proceso lanza una operación wait, se bloquea (suspendido) y se ubica en una cola asociada con esa variable de condición (comparable con un wait en un semáforo con valor cero). Sin embargo, hay que indicar que un wait sobre una variable de condición siempre bloquea, a diferencia de un wait en un semáforo. Cuando un proceso bloqueado libera su bloqueo mutuamente exclusivo en el monitor, permitirá entrar a otro proceso. Cuando un proceso ejecuta una operación signal, liberara un proceso bloqueado. Si no hay ningún proceso bloqueado en la variable especificada, entonces signal no tiene efecto. De nuevo, hay que señalar el contraste con signal en un semáforo, que siempre tiene un efecto en el semáforo. Evidentemente, la semántica de wait y signal para monitores es más similar a la de suspender y reanudar. El ejemplo del buffer limitado tiene este aspecto: monitor búfer; export agrega, toma; const talla = 32; : " var buf : array[0...talla1] of integer; tope, base : 0..tallal; EspacioDisponible, ItemDisponible : condición; NumeroEnBufer : integer; 15

16 procedure agrega (I : integer); begin if NumeroEnBufer = talla then wait(espaciodisponible); buf[tope] := I; NumeroEnBufer := NumeroEnBufer + 1; tope := (tope+1) mod talla; signal(itemdisponible) end agrega; procedure toma (var I : integer); begin if. NumeroEnBufer = 0 then wait(itemdisponible) ; I : = buf [base] ; base := (base+1) mod talla; NumeroEnBufer := NumeroEnBufer - 1 ; signal(espaciodisponible) end toma; begin (* inicialización *) end ; NumeroEnBufer := 0; tope := 0; base := 0 Si un proceso invoca, por ejemplo, toma cuando no hay nada en el búfer, entonces será suspendido en Itemdisponible. Sin embargo, un proceso que añade un ítem realizara un signal sobre el proceso suspendido cuando este disponible un ítem. Las semántica para wait y signal dadas anteriormente no son completas; dos o más procesos podrían llegar a estar activos en un monitor. Esto podría ocurrir siguiendo cierta operación 16

17 signal que liberara un proceso bloqueado. Tanto el proceso liberado cono el que lo liberó se encontraran en ejecución dentro del monitor. Para prohibir esta actividad claramente indeseable, debe modificarse la semántica de signal. En los lenguajes se utilizan cuatro aproximaciones diferentes: (1) Se permite un signal solo como la ultima acción de un proceso antes de dejar el monitorv(este es el caso del ejemplo anterior del bitter limitado). (2) Una operación signal tiene el efecto colateral de ejecutar una sentencia return; es decir, el proceso es forzado a dejar el monitor. (3) Una operación signal que desbloquea otro proceso tiene el efecto de bloquearse a si misma, y solo se desbloqueara cuando quede libre el monitor. (4) Una operación signal que desbloquea otro proceso no bloquea, y el proceso liberado debe competir por el acceso al monitor una vez que acaba el proceso que lanzo el signal. En el caso (3), propuesto por Hoare en su trabajo original sobre monitores, los procesos que bloqueados por una acción signal se ponen en una «cola de dispuestos», y son elegidos, cuando el monitor es liberado, con preferencia sobre los procesos bloqueados en la entrada. En el caso (4), el proceso liberado es el que se coloca en la «cola de dispuestos» Llamadas anidadas al monitor. Hay muchos problemas asociados con el uso de monitores, pero uno de los que más atención ha recibido es el de las implicaciones semánticas de la llamada a un procedimiento monitor desde otro monitor. La controversia esta en lo que debería hacerse si un proceso que ha hecho una llamada anidada al monitor es suspendido en otro monitor. debería renunciarse a la exclusión mutua de la ultima llamada al monitor, debido a la semántica de wait y operaciones equivalentes. Sin embargo, no se debe renunciar a la exclusión mutua por parte de los procesos en los monitores desde los que se han hecho las llamadas anidadas. Los procesos que intenten invocar a procedimientos en esos monitores serán bloqueados. Esto tiene implicaciones en cuanto a las prestaciones, puesto que el bloqueo disminuirá la cantidad de concurrencia exhibida por el sistema. Se han sugerido varias aproximaciones al problema del monitor anidado. La más popular, adoptada por Java, POSIX y Mesa, es mantener el bloqueo. Otras aproximaciones son prohibir llamadas anidadas conjuntas a procedimientos (como en Modula1), o proporcionar construcciones que especifiquen que ciertos procedimientos del monitor pueden liberar su bloqueo de exclusión mutua durante las llamadas remotas Criticas a los monitores. El monitor proporciona una solución estructurada y elegante a problemas de exclusión mutua como el del búfer limitado. Sin embargo, no soluciona bien las sincronizaciones de condición 17

18 fuera del monitor. En Modula1, por ejemplo, las señales son una característica general de programación, y su uso no esta restringido dentro de un monitor. Por tanto, un lenguaje basado en monitores presenta una mezcla de primitivas de alto y bajo nivel. Todas las criticas relacionadas con el uso de semáforos se aplican igualmente (incluso más, si cabe) a las variables de condición. Además, aunque los monitores encapsulan todas las entradas relacionadas con un recurso, y proporcionan la importante exclusión mutua, su estructura interna puede ser todavía difícil de leer, debido al uso de variables de condición. 8.7 Objetos protegidos. Las criticas a los monitores se centran en el uso de las variables de condición. Sustituyendo esta aproximación a la sincronización por el uso de guardas, se obtiene una abstracción más estructurada. Esta forma de monitor se denominará objeto protegido. Ada es el único lenguaje importante que proporciona este mecanismo que aquí será descrito en relación con Ada. En Ada, un objeto protegido encapsula elementos de datos, y solo se permite el acceso a los mediante subprogramas protegidos o entradas protegidas. El lenguaje garantiza que estos programas y entradas serán ejecutados de manera que se asegure que los datos son actualizados mediante exclusión mutua. La sincronización de condición se proporciona mediante expresiones booleanas en entradas (se trata de guardas, pero en Ada se denominan barreras), que deben evaluar a cierto antes que a una tarea se le permita su entrada. Por consiguiente, los objetos protegidos son más bien como monitores o regiones criticas condicionales. Proporcionan la funcionalidad estructurada de los monitores con el mecanismo de sincronización de alto nivel de las regiones criticas condicionales. Una unidad protegida puede declararse como un tipo o eomo una simple instancia; tiene una especificación y un cuerpo (aquí se declara de forma similar a una tarea). Su especificación puede contener funciones, procedimientos y entradas (entry). La declaración siguiente ilustra eomo se pueden utilizar los tipos protegidos para proporcionar exclusión mutua simple: - - sobre un simple entero protected type Entero_Compartido(Valor_Inicial : Integer) is private functión Lee return Integer; procedure Escribe (Nuevo_Talor : Integer); procedure Incrementa(Por : Integer); EI_Dato : Integer := Inicial_Valor; end Entero_Compartido; 18

19 Mi_ Dato : Entero_Compartido (42) ; El tipo protegido anterior encapsula un entero compartido. La declaración de objeto Mi_Dato declara una instancia del tipo protegido y pasa el valor inicial al dato encapsulado. El dato encapsulado solo puede ser accedido por tres subprogramas: Lee, Escribe e incrementa. Un procedimiento protegido proporciona acceso mutuamente excluyente de lectura/escritura a los datos encapsulados. En este caso, las llamadas concurrentes al procedimiento Escribe o Incrementa serán ejecutadas en exclusión mutua, es decir, solo se podrá ejecutar una de ellas cada vez. Las funciones protegidas proveen acceso concurrente de solo lectura para datos encapsulados,. En el ejemplo anterior, esto significa que se pueden ejecutar simultáneamente muchas llamadas a Lee. Sin embargo las llamadas a funciones protegidas siguen siendo mutuamente excluyentes con las llamadas a procedimientos protegidos. Una llamada Lee no puede ser ejecutada si hay pendiente una llamada a procedimiento; tampoco un procedimiento podrá ser ejecutado si hay pendiente una o más llamadas a función. El cuerpo de Entero_Compartido es, simplemente: protected body Entero_Compartido is functión Lee return Integer is begin end Lee; return El_Dato; procedure Escribe(Nuevo_Valor : Integer) is begin end Escribe; El_Dato := Nuevo_Valor; procedure Incrementa(Por : Integer) is begin El_Dato := El_Dato + Por; end Increments; end Entero_Compartido; Una entrada protegida es semejante a un procedimiento protegido en el que se garantiza la exclusión mutua en la ejecuci6n, y tiene acceso de lectura/escritura sobre los datos encapsulados. Sin embargo, una entrada protegida esta guardada por una expresión booleana (o barrera) dentro del cuerpo del objeto protegido; si esta barrera se evalúa a falso cuando se realiza la llamada a la entrada, se suspende la tarea invocadora hasta que la barrera se evalúe a cierto y no existan otras 19

20 tareas activas actualmente dentro del objeto protegido. Por lo tanto, las llamadas a entradas protegidas se pueden utilizar para implementar sincronización de condición. Consideremos un búfer limitado compartido entre varias tareas. La especificación del búfer es: - - un búfer limitado Talla_Bufer : constant Integer := 10; type Indice is mod Talla_búfer ; subtype Cuenta is Natural range 0.. Talla_Bufer; type Bufer is array (Indice) of Item_Dato; protected type Bufer_Limitado is private entry Extrae (Item: out Item_Dato) ; entry Pon(Item. in Item_Dato) ; Primero : Indice := Indice'First; Ultimo : Index := Indice'Last; Numero_En_Bufer : Cuenta := 0; Buf : Bufer; end Bufer_Limitado; Mi_Bufer : Bufer_Limitado; Se han declarado dos entradas, que representan la interfaz publica del búfer. Los elementos de datos declarados en la parte privada son aquellos elementos que deben ser accedidos bajo exclusión mutua. En este caso, el búfer es un array, y es accedido mediante dos índices; hay también un contador que indica el numero de elementos en el buffer. El cuerpo de este tipo protegido se proporciona a continuación: protected body Bufer_Limitado is entry Extrae(Item: out Item_Dato) begin when Numero_En_Bufer /= 0 is Item := Buf(Primero); 20

Concurrencia. Primitivas IPC con bloqueo

Concurrencia. Primitivas IPC con bloqueo Concurrencia Primitivas IPC con bloqueo Primitivas de IPC con bloqueo La solución de Peterson es correcta, pero tiene el defecto de requerir espera ocupada: Cuando un proceso quiere entrar en su región

Más detalles

Implementación de monitores POSIX

Implementación de monitores POSIX Implementación de monitores POSIX Ampliación de Sistemas Operativos (prácticas) E.U. Informática en Segovia Universidad de Valladolid Programación concurrente: Problemática Presencia de condiciones de

Más detalles

Receta general para resolver problemas de sincronización con semáforos

Receta general para resolver problemas de sincronización con semáforos Receta general para resolver problemas de sincronización con semáforos La primera vez que te enfrentas a la tarea de implementar una solución a un problema de sincronización entre procesos, es normal que

Más detalles

Concurrencia: deberes. Concurrencia: Exclusión Mutua y Sincronización. Concurrencia. Dificultades con la Concurrencia

Concurrencia: deberes. Concurrencia: Exclusión Mutua y Sincronización. Concurrencia. Dificultades con la Concurrencia Concurrencia: deberes Concurrencia: Exclusión Mutua y Sincronización Capítulo 5 Comunicación entre procesos Compartir recursos Sincronización de múltiples procesos Asignación del tiempo de procesador Concurrencia

Más detalles

PROGRAMACION CONCURRENTE

PROGRAMACION CONCURRENTE PROGRAMACION CONCURRENTE II.3 Sincronización basada en memoria compartida: Semáforos J.M. Drake 1 Procesos concurrentes y memoria compartida. Si los diferentes procesos de un programa concurrente tienen

Más detalles

Concurrencia entre Procesos.

Concurrencia entre Procesos. Concurrencia entre Procesos. Sistemas Operativos Tema 3. 1 Procesamiento concurrente. Procesamiento concurrente: base de los sistemas operativos modernos (multiprogramados): Un conjunto de procesos que

Más detalles

MONITORES EN JAVA. Antonio Tomeu Control de la Concurrencia en Java: API Estándar

MONITORES EN JAVA. Antonio Tomeu Control de la Concurrencia en Java: API Estándar MONITORES EN JAVA Un monitor es un objeto que implementa acceso bajo e.m. a todos sus métodos, y provee sincronización En Java, son objetos de una clase cuyos métodos públicos son todos synchronized Un

Más detalles

Concurrencia: Exclusión mutua y Sincronización

Concurrencia: Exclusión mutua y Sincronización Concurrencia: Exclusión mutua y Sincronización Prof. Carlos Figueira Basado en materiales de Yudith Cardinale (USB) Williams Stallings, Eugene Styer Concurrencia Múltiples aplicaciones Aplicaciones estructuradas

Más detalles

Object 1. Threads en Java

Object 1. Threads en Java Object 1 Threads en Java Introducción En este artículo voy a explicar cómo se usan los threads en Java (también traducidos como "hilos de ejecución"). La intención no es solamente explicar cuáles son las

Más detalles

Tema 3. Monitores Programación Concurrente

Tema 3. Monitores Programación Concurrente Tema 3. Monitores Programación Concurrente Depto. de Lenguajes y Sistemas Informáticos Universidad de Granada Contenidos 1. Concepto de Monitor 1.1. Fundamento teórico de los monitores 1.2. Sintaxis de

Más detalles

1 HILOS (THREADS) EN JAVA

1 HILOS (THREADS) EN JAVA 1 HILOS (THREADS) EN JAVA 1.1QUÉ ES UN THREAD La Máquina Virtual Java (JVM) es un sistema multihilo. Es decir, es capaz de ejecutar varios hilos de ejecución simultáneamente. La JVM gestiona todos los

Más detalles

Programación Avanzada para Sistemas de Telecomunicación. Objetos y clases. J.C. Cruellas. Objetos y clases

Programación Avanzada para Sistemas de Telecomunicación. Objetos y clases. J.C. Cruellas. Objetos y clases Programación Avanzada para Sistemas de Telecomunicación Objetos y clases Juan Carlos Cruellas cruellas@ac.upc.es Objetos y clases Concepto de objeto. Concepto de clase. Clases, objetos y programas. Clases

Más detalles

TEMA 5: Control de la Concurrencia en Java (API Estándar)

TEMA 5: Control de la Concurrencia en Java (API Estándar) TEMA 5: Control de la Concurrencia en Java (API Estándar) CONTENIDO Exclusión Mutua con código synchronized. Exclusión Mutua con métodos synchronized. Protocolos de Control de la Exclusión Mutua. Interbloqueos

Más detalles

Java nos ofrece la clase Thread y la interfaz Runable que permiten que varios procesos estén funcionando de forma concurrente.

Java nos ofrece la clase Thread y la interfaz Runable que permiten que varios procesos estén funcionando de forma concurrente. Threads (hilos) Java nos ofrece la clase Thread y la interfaz Runable que permiten que varios procesos estén funcionando de forma concurrente. Conceptos: Proceso (thread o hilo): es un programa en ejecución

Más detalles

PROGRAMACIÓN CONCURRENTE. Tema 5 Monitores

PROGRAMACIÓN CONCURRENTE. Tema 5 Monitores PROGRAMACIÓN CONCURRENTE Tema 5 Monitores 1 Indice Definición de los monitores Sincronización condicional usando monitores Algunos problemas con monitores 2 Problemas de las regiones críticas condicionales

Más detalles

Programación Concurrente y Paralela. P(S) ; sección crítica P(S);

Programación Concurrente y Paralela. P(S) ; sección crítica P(S); 2.5.2 Monitores Los semáforos, a pesar de su sencillez de uso, son el equivalente a las instrucciones goto y el manejo de apuntadores en los lenguajes de programación imperativos: son muy susceptibles

Más detalles

Mensajes. Interbloqueo

Mensajes. Interbloqueo CONCURRENCIA DE PROCESOS Preparado por: Angel Chata Tintaya (angelchata@hotmail.com) Resumen Los procesos comparten variables globales, comparten y compiten por recursos, se ejecutan simultáneamente intercalándose

Más detalles

SIMM: TEORÍA DE LOS S.O. I.E.S. JUAN DE LA CIERVA CURSO 2007/2008

SIMM: TEORÍA DE LOS S.O. I.E.S. JUAN DE LA CIERVA CURSO 2007/2008 SIMM: TEORÍA DE LOS S.O. I.E.S. JUAN DE LA CIERVA CURSO 2007/2008 1.- INTRODUCCIÓN A LOS PROCESOS 1.1.- Concepto 1.2.- Composición y estructura 1.3.- Estados y transiciones 2.- COMUNICACIÓN ENTRE PROCESOS

Más detalles

PROGRAMACION CONCURRENTE Y DISTRIBUIDA. II.5 Sincronización basada en memoria compartida: Monitores

PROGRAMACION CONCURRENTE Y DISTRIBUIDA. II.5 Sincronización basada en memoria compartida: Monitores PROGRAMACION CONCURRENTE Y DISTRIBUIDA II.5 Sincronización basada en memoria compartida: Monitores J.M. Drake 1 Monitor Son módulos que encierran los recursos o variables compartidas como componentes internos

Más detalles

Hilos en Java. Crear un Hilo. Detener un hilo. Fuente: http://www.chuidiang.com/java/hilos/hilos_java.php

Hilos en Java. Crear un Hilo. Detener un hilo. Fuente: http://www.chuidiang.com/java/hilos/hilos_java.php Fuente: http://www.chuidiang.com/java/hilos/hilos_java.php Hilos en Java A veces necesitamos que nuestro programa Java realice varias cosas simultáneamente. Otras veces tiene que realizar una tarea muy

Más detalles

un programa concurrente

un programa concurrente Introducción un programa concurrente asumimos que tengamos un programa concurrente que quiere realizar acciones con recursos: si los recursos de los diferentes procesos son diferentes no hay problema,

Más detalles

Sistemas Operativos. Características de la Multiprogramación. Interacción entre Procesos. Características de la Multiprogramación

Sistemas Operativos. Características de la Multiprogramación. Interacción entre Procesos. Características de la Multiprogramación Universidad Simón Bolívar Departamento de Electrónica y Circuitos EC3731 Arquitectura del Computador II Prof. Osberth De Castro Prof. Juan C. Regidor Sistemas Operativos Concurrencia y Sincronización de

Más detalles

Ejemplos de conversión de reales a enteros

Ejemplos de conversión de reales a enteros Ejemplos de conversión de reales a enteros Con el siguiente programa se pueden apreciar las diferencias entre las cuatro funciones para convertir de reales a enteros: program convertir_real_a_entero print

Más detalles

CDI Exclusión mutua a nivel alto. conceptos

CDI Exclusión mutua a nivel alto. conceptos conceptos El concepto de usar estructuras de datos a nivel alto libera al programador de los detalles de su implementación. El programador puede asumir que las operaciones están implementadas correctamente

Más detalles

Benemérita Universidad Autónoma del Estado de Puebla

Benemérita Universidad Autónoma del Estado de Puebla Benemérita Universidad Autónoma del Estado de Puebla Facultad de Cs. De la Computación Programación Concurrente y Paralela Práctica de Laboratorio No. 5 Profr: María del Carmen Cerón Garnica Alumno: Roberto

Más detalles

Concurrencia en Java

Concurrencia en Java Concurrencia en Java Herramientas proporcionadas por Java La Máquina Virtual (JVM) Pedro Pablo Gómez Martín La clase Thread Clase principal con la que conseguir concurrencia. La llamada a su método start()

Más detalles

Procesos. Planificación del Procesador.

Procesos. Planificación del Procesador. Procesos. Planificación del Procesador. Sistemas Operativos. Tema 2. Concepto de Proceso. Una definición sencilla: Programa en ejecución. Entidad pasiva Programa RECURSOS CPU Memoria Ficheros Dispositivos

Más detalles

Threads. La plataforma JAVA soporta programas multhreading a través del lenguaje, de librerías y del sistema de ejecución. Dos.

Threads. La plataforma JAVA soporta programas multhreading a través del lenguaje, de librerías y del sistema de ejecución. Dos. Threads Un thread es un flujo de control secuencial dentro de un programa. A los threads también se los conoce como procesos livianos ó contextos de ejecución. Un thread es similar a un programa secuencial:

Más detalles

Tema 3: Concurrencia de procesos

Tema 3: Concurrencia de procesos Tema 3: Concurrencia de procesos Yolanda Blanco Fernández yolanda@det.uvigo.es Concurrencia, Tiempo Real y Paralelismo Concurrencia: Convivencia de un conjunto de procesos en un mismo ordenador. Sistemas

Más detalles

Solución Examen Febrero 2006

Solución Examen Febrero 2006 Solución Examen Febrero 2006 Lea detenidamente las siguientes instrucciones. No cumplir los requerimientos puede implicar la pérdida del examen. Formato Indique su nombre completo y número de cédula en

Más detalles

I.3. Interacción entre Procesos Concurrentes.

I.3. Interacción entre Procesos Concurrentes. PROGRAMACION CONCURRENTE I.3. Interacción entre Procesos Concurrentes. J.M. Drake 1 Interacción entre Procesos Concurrentes Modelos de interacción entre procesos. Problemas de sincronización y exclusión

Más detalles

4. Programación Paralela

4. Programación Paralela 4. Programación Paralela La necesidad que surge para resolver problemas que requieren tiempo elevado de cómputo origina lo que hoy se conoce como computación paralela. Mediante el uso concurrente de varios

Más detalles

1 (2 5 puntos) Responda con brevedad y precisión a las siguientes preguntas:

1 (2 5 puntos) Responda con brevedad y precisión a las siguientes preguntas: Universidad de Las Palmas de Gran Canaria Escuela Universitaria de Informática Facultad de Informática Sistemas Operativos Examen parcial, 11 de mayo de 2002 SOLUCIONES Calificación 1 2 3 4 5 1 (2 5 puntos)

Más detalles

Tema 2. El lenguaje de programación Java (Parte 1)

Tema 2. El lenguaje de programación Java (Parte 1) Programación en Java Tema 2. El lenguaje de programación Java (Parte 1) Luis Rodríguez Baena Facultad de Informática Elementos del lenguaje (I) El juego de caracteres. No utiliza ASCII, sino Unicode de

Más detalles

Java Inicial (20 horas)

Java Inicial (20 horas) Java Inicial (20 horas) 1 Temario 1. Programación Orientada a Objetos 2. Introducción y Sintaxis Java 3. Sentencias Control Flujo 4. POO en Java 5. Relaciones entre Objetos 6. Polimorfismo, abstracción

Más detalles

Práctica de programación concurrente 2013-2014 ETSI Informática, UNED David Fernández-Amorós programacion.concurrente@lsi.uned.es. 1.

Práctica de programación concurrente 2013-2014 ETSI Informática, UNED David Fernández-Amorós programacion.concurrente@lsi.uned.es. 1. 1. Enunciado En el bingo hay un presentador y varios jugadores. Antes de comenzar el juego, cada jugador se genera aleatoriamente una cantidad de cartones entre 1 y 10. Obviamente, todos los números de

Más detalles

Modulo 1 El lenguaje Java

Modulo 1 El lenguaje Java Modulo 1 El lenguaje Java 13 - Codificación en Java Una de las grandes diferencias entre Java y Pascal en cuando a la codificación es que Java se trata de un lenguaje de los llamados case sensitive Esto

Más detalles

SISTEMAS OPERATIVOS AVANZADOS

SISTEMAS OPERATIVOS AVANZADOS SISTEMAS OPERATIVOS AVANZADOS TEMA 3 CLAVE: MIS 204 PROFESOR: M.C. ALEJA DRO GUTIÉRREZ DÍAZ 3. PROCESOS CONCURRENTES 3.1 Conceptos de programación concurrente 3.2 El problema de la sección crítica 3.3

Más detalles

Programación Orientada a Eventos

Programación Orientada a Eventos Programación Orientada a Eventos Técnicas de Programación Santiago Pavón V:2012.03.13 Programas Secuénciales El flujo de ejecución del programa sigue la secuencia de sentencias que lo forman. El estado

Más detalles

El problema de los Filósofos

El problema de los Filósofos El problema de los Filósofos Problemas de Programación Concurrente Solución con Semáforos Para evitar una situación de interbloqueo se limita el número de filósofos en disposición de comer a 4. PROGRAM

Más detalles

Comunicación y Sincronización con Monitores Resumen del Tema

Comunicación y Sincronización con Monitores Resumen del Tema Notas de clase de Programación Concurrente Comunicación y Sincronización con Monitores Resumen del Tema Dpto de Lenguajes y Ciencias de la Computación Universidad de Málaga María del Mar Gallardo Melgarejo

Más detalles

PROGRAMACIÓN EN JAVA

PROGRAMACIÓN EN JAVA SISTEMAS INFORMÁTICOS INDUSTRIALES curso 2007-2008 PROGRAMACIÓN EN JAVA PRÁCTICA 3: Comunicación entre tareas. Modelo productor / consumidor. Objetivos Implementar una aplicación en Java en la que existan

Más detalles

CONCEPTOS BASICOS DEL LENGUAJE JAVA

CONCEPTOS BASICOS DEL LENGUAJE JAVA CONCEPTOS BASICOS DEL LENGUAJE JAVA NOMENCLATURA GENERAL En Java se distinguen las letras mayúsculas y minúsculas. Las reglas del lenguaje respecto a los nombres de variables son muy amplias y permiten

Más detalles

www.aprendoencasa.com Curso Introducción JAVA Pág.: 1

www.aprendoencasa.com Curso Introducción JAVA Pág.: 1 www.aprendoencasa.com Curso Introducción JAVA Pág.: 1 Introducción Java es un lenguaje basado en la programación orientada a objetos (POO), este tipo de programación va más allá del tipo de programación

Más detalles

2. Estructura de un programa en Java

2. Estructura de un programa en Java 24 A. García-Beltrán y J.M. Arranz 2. Estructura de un programa en Java Objetivos: a) Describir la estructura del código fuente de una aplicación Java b) Presentar los conceptos de comentario y de identificador

Más detalles

Lenguajes de Programación Curso 04-05. Práctica 4. Herencia. Utilización de interfaces y clases abstractas. 1. Interfaces 1. 2. Clases abstractas 2

Lenguajes de Programación Curso 04-05. Práctica 4. Herencia. Utilización de interfaces y clases abstractas. 1. Interfaces 1. 2. Clases abstractas 2 Objetivos Herencia. Utilización de interfaces y clases abstractas. Índice 1. Interfaces 1 2. Clases abstractas 2 3. Collections Framework 3 3.1. Collection........................................... 3

Más detalles

Repaso de las características más importantes de la programación Java y su adaptación a Android

Repaso de las características más importantes de la programación Java y su adaptación a Android Repaso de las características más importantes de la programación Java y su adaptación a Android 1. Entorno de programación en java 2. Variables y tipos de datos 3. Operaciones y operadores 4. Clases y

Más detalles

Paso de mensajes. Lecturas: Burns & Wellings, Cap.??? Transparencias y apuntes de la asignatura. Filosofía cliente-servidor.

Paso de mensajes. Lecturas: Burns & Wellings, Cap.??? Transparencias y apuntes de la asignatura. Filosofía cliente-servidor. Paso de mensajes Lecturas: Burns & Wellings, Cap.??? Transparencias y apuntes de la asignatura Manuel Carro Universidad Politécnica de Madrid Este texto se distribuye bajo los términos de la Creative Commons

Más detalles

EXAMEN FINAL Metodología y Programación Orientada a Objetos. Curso 2010 2011. Cuatrimestre de otoño. 17 de Enero de 2011

EXAMEN FINAL Metodología y Programación Orientada a Objetos. Curso 2010 2011. Cuatrimestre de otoño. 17 de Enero de 2011 EXAMEN FINAL Metodología y Programación Orientada a Objetos. Curso 2010 2011. Cuatrimestre de otoño. 17 de Enero de 2011 1. (0,75 PUNTOS) Identificad a continuación las sentencias que son ciertas, descartando

Más detalles

RESUMEN DE CONCEPTOS BASICOS DE PROGRAMACION JAVA

RESUMEN DE CONCEPTOS BASICOS DE PROGRAMACION JAVA UNED Centro Asociado de Cádiz RESUMEN DE CONCEPTOS BASICOS DE PROGRAMACION JAVA 1. OBJETOS Cualquier elemento del programa es un objeto. Un programa es un conjunto de objetos que se comunican entre sí

Más detalles

Introducción a los Tipos Abstractos de Datos

Introducción a los Tipos Abstractos de Datos Página 1 de 8 Introducción a los Tipos Abstractos de Datos Introducción: Concepto de abstracción Abstracción funcional y abstracción de datos Construcción de tipos abstractos de datos Especificación de

Más detalles

Tema 1. Introducción a los TAD

Tema 1. Introducción a los TAD Tema 1. Introducción a los TAD Objetivos En este tema nos ocupamos inicialmente del concepto de abstracción, dedicando la mayor atención a la abstracción de datos, estudiando aspectos relacionados con

Más detalles

Proyecto Septiembre. Escuela Politécnica Superior Universidad Autónoma de Madrid 1

Proyecto Septiembre. Escuela Politécnica Superior Universidad Autónoma de Madrid 1 Proyecto Septiembre A. Organización de la práctica 1) Para promediar con la parte teórica de la asignatura es necesario aprobar independientemente prácticas y teoría. 2) La práctica de Septiembre se debe

Más detalles

Capítulo 6. Asociaciones y Declaraciones.

Capítulo 6. Asociaciones y Declaraciones. Capítulo 6. Asociaciones y Declaraciones. Lenguajes de Programación Carlos Ureña Almagro Curso 2011-12 Contents 1 Asociaciones, entornos y ámbitos 2 2 Declaraciones y definiciones 6 3 Definiciones de valores,

Más detalles

Programación Concurrente en Java

Programación Concurrente en Java Hebras y monitores Departamento de Sistemas Informáticos y Programación Universidad Complutense de Madrid 21 de marzo de 2006 Threads Extendiendo la clase java.lang.thread. public class PrThread extends

Más detalles

Elementos léxicos del lenguaje de programación Java

Elementos léxicos del lenguaje de programación Java Elementos léxicos del lenguaje de programación Java Elementos léxicos del lenguaje de programación Java Palabras reservadas Identificadores Literales Operadores Delimitadores Comentarios Apéndices Operadores

Más detalles

Identificadores, palabras reservadas, tipos de datos, operadores aritméticos y el sistema estándar de salida en Java

Identificadores, palabras reservadas, tipos de datos, operadores aritméticos y el sistema estándar de salida en Java Identificadores, palabras reservadas, tipos de datos, operadores aritméticos y el sistema estándar de salida en Java Identificadores Las variables se utilizan en programación para almacenar temporalmente

Más detalles

PROGRAMACION CONCURRENTE. I.2 Recursos para la concurrencia.

PROGRAMACION CONCURRENTE. I.2 Recursos para la concurrencia. PROGRAMACION CONCURRENTE I.2 Recursos para la concurrencia. J.M. Drake 1 Procesos Concurrentes Concepto de proceso. Estructura de los procesos. Estados de un proceso. Gestión de los procesos. 2 2 Plataforma

Más detalles

Concurrencia en.net David Jesús Horat Flotats

Concurrencia en.net David Jesús Horat Flotats Concurrencia en.net David Jesús Horat Flotats ÍNDICE 1. Introducción n a.net 2. Sincronización n en.net 2.1 Contextos sincronizados 2.2 Método M Synchronized 2.3 Regiones de código c sincronizado 2.4 Sincronización

Más detalles

Federico Peinado www.federicopeinado.es

Federico Peinado www.federicopeinado.es Federico Peinado www.federicopeinado.es Depto. de Ingeniería del Software e Inteligencia Artificial disia.fdi.ucm.es Facultad de Informática www.fdi.ucm.es Universidad Complutense de Madrid www.ucm.es

Más detalles

Mensajes. (versión preliminar)

Mensajes. (versión preliminar) Mensajes (versión preliminar) Ejemplo: productor/consumidor con buffer de tamaño 0 void produce(item *p_it); void consume(item *p_it); int nmain() { ntask cons= nemittask(consproc); ntask prod= nemittask(prodproc,

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

TEMA 5. PROGRAMACIÓN CONCURRENTE.

TEMA 5. PROGRAMACIÓN CONCURRENTE. TEMA 5. PROGRAMACIÓN CONCURRENTE. 5.1. Ejecución concurrente. 5.2. Representación de procesos. 5.3. Tareas en Ada. 5.4. Ejemplo. 5.5. Comunicación y sincronización con variables comunes. 5.6. Comunicación

Más detalles

CAPÍTULO IV BREVE DESCRIPCIÓN DE LA INFRAESTRUCTURA DE CÓMPUTO VISUAL BASIC 6.0 PARA WINDOWS

CAPÍTULO IV BREVE DESCRIPCIÓN DE LA INFRAESTRUCTURA DE CÓMPUTO VISUAL BASIC 6.0 PARA WINDOWS CAPÍTULO IV BREVE DESCRIPCIÓN DE LA INFRAESTRUCTURA DE CÓMPUTO VISUAL BASIC 6.0 PARA WINDOWS 4.1 Antecedentes históricos El lenguaje de programación BASIC (Beginner's All purpose Symbolic Instruction Code)

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Secretos de la Programación Concurrente

Secretos de la Programación Concurrente Secretos de la Programación Concurrente Stuart Perez, Luis Castro Autómatas y Compiladores, Escuela de Ciencias de la Computación e Informática, San Pedro de Montes de Oca, Costa Rica jstuartp@gmail.com

Más detalles

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Página 1 de 11 1. Introducción Tom Baeyens es el fundador y arquitecto del proyecto de JBoss jbpm, la máquina de workflow

Más detalles

PROGRAMACION CONCURRENTE

PROGRAMACION CONCURRENTE PROGRAMACION CONCURRENTE II.4 Sincronización basada en memoria compartida: Regiones críticas J.M. Drake 1 Regiones críticas Son bloques de código que al ser declarados como regiones críticas respecto de

Más detalles

Señal de petición de Interrupción

Señal de petición de Interrupción Consideren una tarea que require tomar caracteres desde un teclado y mostrarlos en la pantalla de un monitor. La tasa de transferencia desde un teclado a un computador está limitado por la velocidad del

Más detalles

1 Agencia de viajes: enunciado

1 Agencia de viajes: enunciado 1 AGENCIA DE VIAJES: ENUNCIADO 1 1 Agencia de viajes: enunciado Una agencia de viajes mantiene una base de datos con exactamente N clientes y M destinos turísticos. En una situación real, estos valores

Más detalles

Definición de clases: Herencia, polimorfismo, ligadura dinámica

Definición de clases: Herencia, polimorfismo, ligadura dinámica Tema 7 Definición de clases: Herencia, polimorfismo, ligadura dinámica Con alguna frecuencia es necesario definir clases de objetos entre las cuales hay elementos comunes. En una aplicación en la cual

Más detalles

Arreglos. // Incluir E/S y Librerías Standard #include <stdlib.h> #include <stdio.h>

Arreglos. // Incluir E/S y Librerías Standard #include <stdlib.h> #include <stdio.h> Arreglos Introducción. En los temas anteriores se han estudiado los diferentes tipos de datos simples de C++, usados para representar valores simples como enteros, reales o caracteres. Sin embargo, en

Más detalles

Solución al Examen de Prácticas de Programación (Ingeniería Informática)

Solución al Examen de Prácticas de Programación (Ingeniería Informática) Solución al Examen de Prácticas de Programación (Ingeniería Informática) Junio 2006 Parte I. Cuestiones (3 puntos=50% nota del examen) 1) Se desea crear un conjunto de clases para representar en un programa

Más detalles

Tema 4. Gestión de entrada/salida

Tema 4. Gestión de entrada/salida Tema 4. Gestión de entrada/salida 1. Principios de la gestión de E/S. 1.Problemática de los dispositivos de E/S. 2.Objetivos generales del software de E/S. 3.Principios hardware de E/S. 1. E/S controlada

Más detalles

dit UPM Tema 3: Concurrencia /ejercicios Análisis y diseño de software José A. Mañas 3.4.2014 http://jungla.dit.upm.es/~pepe/doc/adsw/index.

dit UPM Tema 3: Concurrencia /ejercicios Análisis y diseño de software José A. Mañas 3.4.2014 http://jungla.dit.upm.es/~pepe/doc/adsw/index. Análisis y diseño de software dit UPM Tema 3: Concurrencia /ejercicios José A. Mañas http://jungla.dit.upm.es/~pepe/doc/adsw/index.html 3.4.2014 ejercicio 1.1 programar una cuenta bancaria compartida 1.

Más detalles

- Bases de Datos - - Diseño Físico - Luis D. García

- Bases de Datos - - Diseño Físico - Luis D. García - Diseño Físico - Luis D. García Abril de 2006 Introducción El diseño de una base de datos está compuesto por tres etapas, el Diseño Conceptual, en el cual se descubren la semántica de los datos, definiendo

Más detalles

Hilos, comunicación y competencia entre procesos. Dr. Alonso Ramírez Manzanares 2-Sep-2010

Hilos, comunicación y competencia entre procesos. Dr. Alonso Ramírez Manzanares 2-Sep-2010 Hilos, comunicación y competencia entre procesos Dr. Alonso Ramírez Manzanares 2-Sep-2010 Implementación de procesos Se mantiene una tabla de procesos con una entrada por cada proceso: Con lo cual tenemos

Más detalles

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas Departamento de Informática PROGRAMACIÓN DIDÁCTICA Curso 11-12 1 CONSEJERÍA DE EDUCACIÓN I.E.S. NERVIÓN Departamento de Informática CICLO FORMATIVO: TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA.

Más detalles

Benemérita Universidad Autónoma del Estado de Puebla

Benemérita Universidad Autónoma del Estado de Puebla Benemérita Universidad Autónoma del Estado de Puebla Facultad de Cs. De la Computación Programación Concurrente y Paralela Práctica de Laboratorio No. 4 Profr: María del Carmen Cerón Garnica Alumno: Roberto

Más detalles

PATRONES. Experto. Solución:

PATRONES. Experto. Solución: PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los

Más detalles

Creación de Funciones de Conducción

Creación de Funciones de Conducción Creación de Funciones de Conducción Requerimientos Para el desarrollo de esta actividad se requiere que: Contemos con un robot BoeBot armado con placa Arduino. Repetición En estos momentos habremos notado

Más detalles

Ingeniería Superior de Informática. Curso 3º. Sistemas Operativos. Examen Final. TEORÍA. 31 de Enero de 2005

Ingeniería Superior de Informática. Curso 3º. Sistemas Operativos. Examen Final. TEORÍA. 31 de Enero de 2005 Ingeniería Superior de Informática. Curso º. Sistemas Operativos. Examen Final. TEORÍA. de Enero de 005 Nombre: DNI:. ( puntos). La TFA es la tabla que, en UNIX, guarda los punteros de posición de cada

Más detalles

PL/SQL. Con PL/SQL vamos a poder programar las unidades de programa de la base de datos Oracle:

PL/SQL. Con PL/SQL vamos a poder programar las unidades de programa de la base de datos Oracle: PL/SQL (Procedural Language/Structured Query Language) PL/SQL es el lenguaje de programación que proporciona Oracle para extender el SQL estándar con otro tipo de instrucciones y elementos propios de los

Más detalles

Enlaces relacionados: http://otn.oracle.com/tech/pl_sql/index.html

Enlaces relacionados: http://otn.oracle.com/tech/pl_sql/index.html 1.INTRODUCCION PL/SQL (Procedural Language ó Programming Language, según distintas fuentes, aunque la oficial es la primera) es el lenguaje utilizado por Oracle como extensión al SQL, y que nos va a permitir

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 2: Estructura de los sistemas de computación. 2.1 Funcionamiento de los sistemas de computación. 2.2 Ejecución de instrucciones e interrupciones

Más detalles

Para leer la entrada de consola, lo primero que se hace es construir un Scanner que este asociado al flujo de entrada estándar System.

Para leer la entrada de consola, lo primero que se hace es construir un Scanner que este asociado al flujo de entrada estándar System. CICLO: 01/2010 Universidad Don Bosco Materia: Lenguaje de Programación III Contenido: 1-Lectura de Datos de entrada. 2-Introduccion a JOPTIONPANE. 3-Estructuras de Control. ->LECTURA DE DATOS DE ENTRADA

Más detalles

Refactorizar (v) Reestructurar el software aplicando una secuencia de refactorizaciones.

Refactorizar (v) Reestructurar el software aplicando una secuencia de refactorizaciones. Refactorización Definición Refactorización (n) Cambio realizado a la estructura interna del software para hacerlo más fácil de comprender y más fácil de modificar sin cambiar su comportamiento observable.

Más detalles

ESTÁNDAR DIAGRAMA DE SECUENCIA

ESTÁNDAR DIAGRAMA DE SECUENCIA ESTÁNDAR DIAGRAMA DE SECUENCIA Un diagrama de secuencia muestra las interacciones entre objetos ordenadas en secuencia temporal. Muestra los objetos que se encuentran en el escenario y la secuencia de

Más detalles

Programación Concurrente Recopilación de teoría referente a la materia

Programación Concurrente Recopilación de teoría referente a la materia UNIVERSIDAD AMERICANA Programación Concurrente Recopilación de teoría referente a la materia Ing. Luis Müller 2011 Esta es una recopilación de la teoría referente a la asignatura Programación Concurrente,

Más detalles

Tema 4.- Pilas y Colas

Tema 4.- Pilas y Colas Apuntes elaborados por: Eduardo Quevedo, Raquel López y Aaron Asencio Revisado por: Javier Miranda el???? Tema 4.- Pilas y Colas Las pilas y colas son estructuras de datos que se utilizan generalmente

Más detalles

Java: Programación Multithread

Java: Programación Multithread Qué es un thread? Java: Programación Multithread Hasta el momento hemos desarrollado programas secuenciales con un único thread: en cualquier instante durante la ejecución de un programa hay un único punto

Más detalles

Monitores. Implementación de un Buffer con monitores

Monitores. Implementación de un Buffer con monitores Monitores Los monitores corresponden a la segunda herramienta de sincronización que veremos en el curso. Se usan para garantizar la exclusión mutua en secciones críticas y para esperar la ocurrencia de

Más detalles

RAID. Los detalles de las características segunda y tercera, cambian según los distintos niveles RAID. RAID 0 no soporta la tercera característica.

RAID. Los detalles de las características segunda y tercera, cambian según los distintos niveles RAID. RAID 0 no soporta la tercera característica. RAID Como se dijo anteriormente, el ritmo de mejora de prestaciones en memoria secundaria ha sido considerablemente menor que en procesadores y en memoria principal. Esta desigualdad ha hecho, quizás,

Más detalles

INTRODUCCIÓN. Estructura de Datos Tipos Abstractos de Datos (TAD S) Profs. Lorna Figueroa M. Mauricio Solar F. UTFSM 1 / 2008

INTRODUCCIÓN. Estructura de Datos Tipos Abstractos de Datos (TAD S) Profs. Lorna Figueroa M. Mauricio Solar F. UTFSM 1 / 2008 INTRODUCCIÓN Estructura de Datos Tipos Abstractos de Datos (TAD S) Para poder obtener un programa que resuelva un problema dado, son necesarios varios pasos : La formulación y especificación del problema

Más detalles

Objetivo de aprendizaje del tema

Objetivo de aprendizaje del tema Computación II Tema 3. Identificadores, palabras clave y tipos de datos Objetivo de aprendizaje del tema Al finalizar el tema serás capaz de: Distinguir i entre modificadores d válidos y no válidos. Enumerar

Más detalles

Introducción al lenguaje de especificación JML

Introducción al lenguaje de especificación JML Introducción al lenguaje de especificación JML Elena Hernández Pereira Óscar Fontenla Romero Tecnología de la Programación Octubre 2006 Departamento de Computación Facultad de Informática Universidad de

Más detalles

CÓMO TRABAJA TU SISTEMA OPERATIVO?

CÓMO TRABAJA TU SISTEMA OPERATIVO? CÓMO TRABAJA TU SISTEMA OPERATIVO? AUTORÍA MARÍA CATALÁ CARBONERO TEMÁTICA SISTEMAS OPERATIVOS ETAPA CICLO MEDIO Y SUPERIOR DE INFORMÁTICA Resumen Los sistemas operativos nacen de la informática. Su función

Más detalles

Estructuras de Almacenamiento RAID RAID. Nivel FísicoF. Índice. Requisitos Almacenamiento. Nivel Lógico Modelo Entidad-Relación y Modelo Relacional

Estructuras de Almacenamiento RAID RAID. Nivel FísicoF. Índice. Requisitos Almacenamiento. Nivel Lógico Modelo Entidad-Relación y Modelo Relacional Estructuras de Almacenamiento Nivel FísicoF Nivel Lógico Modelo Entidad-Relación y Modelo Relacional El nivel en el que se deben mover los usuario es el nivel lógico El objetivo de un sistema de bases

Más detalles

Sistemas Operativos Temas 4, 5 y 6. Jorge García Duque Despacho: B-202 Tutorías: Lunes 16:00-18:00 y Martes 16:00-20:00

Sistemas Operativos Temas 4, 5 y 6. Jorge García Duque Despacho: B-202 Tutorías: Lunes 16:00-18:00 y Martes 16:00-20:00 Sistemas Operativos Temas 4, 5 y 6 Jorge García Duque Despacho: B-202 Tutorías: Lunes 16:00-18:00 y Martes 16:00-20:00 Índice Tema 4: Herramientas de Sincronización de Alto Nivel. Regiones Críticas. Monitores.

Más detalles

18 y 19 Sistemas de Archivos Distribuidos y Tarea 05

18 y 19 Sistemas de Archivos Distribuidos y Tarea 05 18 y 19 Sistemas de Archivos Distribuidos y Tarea 05 Prof. Edgardo Adrián Franco Martínez http://computacion.cs.cinvestav.mx/~efranco efranco.docencia@gmail.com Estructuras de datos (Prof. Edgardo A. Franco)

Más detalles