Comentarios de las preguntas de la clase anterior

Presentación del tema: "Comentarios de las preguntas de la clase anterior"— Transcripción de la presentación:

1 Comentarios de las preguntas de la clase anterior
En el esquema de scheduling por SJN, suponga que lo quiere cambiar por un esquema LJN (longest JOB next). Analice rápidamente el código y comente los cambios. Cuál de los dos esquemas le parece más fair? Cuál generará una cola mayor de procesos diferentes pendientes?   En el esquema de scheduling por SJN, suponga que lo quiere cambiar por un esquema FIFO. Analice rápidamente el código y comente los cambios. Cuál de los dos esquemas le parece más eficiente? Más Fair ? Programación Concurrente Clase 4

2 Comentarios de las preguntas de la clase anterior
1 Utilizaría la técnica de “passing the baton” en el problema de los filósofos? Cómo? (si contesta que NO, indique por qué) 1Utilizaría la técnica de “passing the baton” en el problema del buffer limitado con múltiples productores y consumidores? Y si se tratara de un buffer de tamaño 1 que deben acceder alternadamente productores y consumidores? Programación Concurrente Clase 4

3 Comentarios de las preguntas de la clase anterior
1Una primitiva de semáforos que se ha propuesto es Pmultiple(s1,s2....sn) y Vmultiple(s1,s2....sn) que realizarían respectivamente el AWAIT por n semáforos s1 a sn y la señalización (liberación) de los n semáforos en un única operación. Se le ocurre algún caso de los estudiados anteriormente o de los mencionados en la clase de hoy en los que le podrían ser útiles estas primitivas? 1Puede existir un programa concurrente sin acciones de sincronización entre procesos? Por qué? Programación Concurrente Clase 4

4 Conceptos de la clase anterior
La técnica de “passing the baton” puede ser de interés cuando los procesos al liberar el recurso aplican una política de scheduling (fija o dinámica) para asignar el proceso que queda “a cargo” del resurso. La asignación de recursos limitados a N procesos (nombrados o no) requiere la resolución de primitivas Request y Release con una política de scheduling espécífica que puede requerir un proceso servidor. Programación Concurrente Clase 4

5 Conceptos básicos de Monitores
Semáforos  variables compartidas globales a los procesos sentencias de control de acceso a la sección crítica dispersas en el código. Monitores  módulos de programa que proveen más estructura y pueden ser implementados eficientemente como los semáforos. Son un mecanismo de abstracción de datos: encapsulan las representaciones de recursos. proveen un conjunto de operaciones que son los únicos medios para manipular la representación. Programación Concurrente Clase 5

6 Conceptos básicos de Monitores
Exclusión mutua  implícita. Sincronización x condición  explícita con variables de condición. Ahora podemos ver un Programa Concurrente como =procesos activos y monitores pasivos Dos procesos interactúan invocando procedures en el mismo monitor. Programación Concurrente Clase 5

7 Conceptos básicos de Monitores.
Ventajas: = un proceso que llama a un procedure de monitor puede ignorar cómo está implementado. = el programador de un monitor puede ignorar cómo o dónde se usan los procedures del mismo.  pueden diseñarse cada proceso y el monitor en forma relativamente independiente. Programación Concurrente Clase 5

8 Conceptos básicos de Monitores. Notación.
monitor NombreMonitor { declaraciones de variables permanentes; código de inicialización procedure op1 (par. formales1) { cuerpo de op1 } procedure opn (par. formalesn) { cuerpo de opn } } Programación Concurrente Clase 5

9 Conceptos básicos de Monitores. Notación.
Variables permanentes  estado del recurso Procedures  implementan las operaciones sobre el recurso Lo que distingue a un monitor de un TAD en procesos secuenciales, es que es compartido por procesos que ejecutan concurrentemente. Sólo los nombres de los procedures son visibles desde afuera. Sintácticamente, los llamados al monitor tienen la forma: call NombreMonitor.opi (argumentos) Programación Concurrente Clase 5

10 Conceptos básicos de Monitores. Propiedades.
Los procedures de un monitor pueden acceder sólo las variables permanentes, sus variables locales y los parámetros que le sean pasados en la invocación. El programador de un monitor no puede conocer a priori el orden de llamado de los procedures del monitor  se define un invariante del monitor que especifica los estados “razonables” de las variables permanentes cuando ningún proceso las está accediendo. Programación Concurrente Clase 5

11 Conceptos básicos de Monitores. Sincronización.
La exclusión mutua en monitores se provee implícitamente. La sincronización por condición es programada explícitamente usando variables condición  COND cv; cv representa la variable de control de una cola de procesos demorados para el acceso a los procedimientos del monitor. Operaciones sobre esta cola?? Programación Concurrente Clase 5

12 Conceptos básicos de Monitores. Sincronización.
empty(cv) retorna true si la cola controlada por cv está vacía. wait(cv) el proceso se demora al final de la cola de cv y deja el acceso exclusivo al monitor. signal(cv) despierta al proceso que está al frente de la cola y lo saca de ella (cola vacía= skip). Ese proceso puede ejecutar cuando readquiera el acceso exclusivo al monitor. Programación Concurrente Clase 5

13 Conceptos básicos de Monitores. Sincronización.
2 Signal & Continue Signal & Wait Wait 3 1 Monitor Free Return Call Signal & Wait 1- Cola de Entrada 2-Cola por Variable de condición 3- Ejecutando en el Monitor Programación Concurrente Clase 5

14 Conceptos básicos de Monitores. Sincronización.
El proceso que ejecuta SIGNAL retiene el control exclusivo del monitor y puede seguir ejecutando (signal-and-continue) WAIT y SIGNAL son similares a P y V, pero hay diferencias: wait siempre demora un proceso hasta un signal posterior. signal no tiene efecto si ningún proceso está demorado sobre la variable condición. El proceso que hace SIGNAL siempre ejecuta antes (retiene el control) que un proceso despertado como resultado del mismo SIGNAL. Programación Concurrente Clase 5

15 Semáforo con monitores
monitor Semaphore { int s = 0; ## s >= 0 cond pos; # signaled when s > 0 procedure Psem() { while (s == 0) wait(pos); s = s-1; } procedure Vsem() { s = s+1; signal(pos); Programación Concurrente Clase 5

16 Semáforo con monitores
monitor FIFOsemaphore { int s = 0; ## s >= 0 cond pos; # signaled when s > 0 procedure Psem() { If (s == 0) wait(pos); else s = s-1; } procedure Vsem() { if (empty(pos)) s = s+1; signal(pos); Programación Concurrente Clase 5

17 Buffer limitado con monitores
monitor Bounded_Buffer { typeT buf[n]; # an array of some type T int front = 0, # index of first full slot rear = 0; # index of first empty slot count = 0; # number of full slots # rear == (front + count) % n cond not_full, # signaled when count < n not_empty; # signaled when count > 0 Programación Concurrente Clase 5

18 Buffer limitado con monitores
procedure deposit(typeT data) { while (count == n) wait(not_full); buf[rear] = data; rear = (rear+1) % n; count++; signal(not_empty); } procedure fetch(typeT &result) { while (count == 0) wait(not_empty); result = buf[front]; front = (front+1) % n; count--; signal(not_full); Programación Concurrente Clase 5

19 Monitores en sincronización: comentarios.
El invariante: { BUFFER: 1  front  n AND 1  rear  n AND 0  count  n AND rear = (front + count - 1) mod n + 1} buf es una la cola circular comenzando en buf[front] Operaciones adicionales: empty(cv) determina si al menos un proceso está demorado sobre la variable condición cv. wait(cv,rank) wait con prioridad: permite tener más control sobre el orden en que los procesos son encolados y despertados Los procesos demorados en cv son despertados en orden ascendente de rank. minrank(cv) función que retorna el mínimo ranking de demora signal_all(cv)-despierta todos los procesos demorados en cv. El tiempo en que cada uno reinicie efectivamente la ejecución dependerá de las condiciones de exclusión mútua. Programación Concurrente Clase 5

20 Sincronización con monitores: Alocación de un recurso por SJN.
monitor Shortest_Job_Next { bool free = true; cond turn; # signaled when resource available procedure request(int time) { if (free) free = false; else wait(turn, time); # Ordenado de acuerdo al tiempo del JOB } procedure release() { if (empty(turn)) free = true signal(turn); Programación Concurrente Clase 5

21 Alocación de recurso SJN con Monitores: comentarios.
Se usa wait con prioridad para ordenar los procesos demorados por la cantidad de tiempo que usarán el recurso. Se usa empty para determinar si hay procesos demorados. Cuando el recurso es liberado, si hay procesos demorados, el que tiene mínimo rank es despertado. Wait no se pone en un loop pues la decisión de cuándo puede continuar un proceso la hace el proceso que libera el recurso. Programación Concurrente Clase 5

22 Lectores-Escritores con monitores.
Monitor===> arbitrar el acceso a la BD Los procesos dicen cuando quieren acceder y cuando terminaron requieren un monitor con 4 procedures: request_read, release_read, request_write y release_write nr número de lectores y nw número de escritores (variables permanentes). Invariante: RW: (nr = 0  nw = 0)  nw  1 Programación Concurrente Clase 5

23 Lectores-Escritores con monitores.
monitor RW_Controller var nr := 0, nw := 0 var oktoread : cond # signal cuando nw = 0 var oktowrite : cond # signal cuando nr = 0  nw = 0 procedure request_read( ) do nw > 0  wait(oktoread) od nr := nr + 1 end Programación Concurrente Clase 5

24 Lectores-Escritores, con monitores.
procedure release_read( ) nr := nr - 1 if nr = 0  signal(oktowrite) fi end procedure request_write( ) do nr > 0  nw > 0  wait(oktowrite) od nw := nw + 1 procedure release_write( ) nw := nw - 1 signal(oktowrite) signal_all(oktoread) Programación Concurrente Clase 5

25 El problema del peluquero dormilón, sincronizado c/monitores (rendezvous)
Problema del sleeping barber. Una ciudad tiene una peluquería con dos puertas y unas pocas sillas. Los clientes entran por una puerta y salen por la otra.Dado que el negocio es chico, a lo sumo un cliente o el peluquero se pueden mover en él a la vez. El peluquero pasa su vida atendiendo clientes, uno por vez. Cuando no hay ninguno, el peluquero duerme en su silla. Cuando llega un cliente y encuentra que el peluquero está durmiendo, el cliente lo despierta, se sienta en la silla del peluquero, y duerme mientras el peluquero le corta el pelo.Si el peluquero está ocupado cuando llega un cliente, el cliente se va a dormir en una de las otras sillas. Después de un corte de pelo, el peluquero abre la puerta de salida para el cliente y la cierra cuando el cliente se va. Si hay clientes esperando, el peluquero despierta a uno y espera que el cliente se siente. Sino, se vuelve a dormir hasta que llegue un cliente. Programación Concurrente Clase 5

26 El problema del peluquero dormilón, sincronizado c/monitores (rendezvous)
1 2 4 3 7 8 5 6 1- Peluquero, 2- Cliente siendo atendido, 3 y 4- Puertas, 5, 6, 7, Clientes en espera Programación Concurrente Clase 5

27 El problema del peluquero dormilón sincronizado con Monitores.
Procesos  clientes y peluquero. Monitor  administrador de la peluquería Relación cliente/servidor. Tres procedures: get_haircut: llamado por los clientes, que retornan luego de recibir un corte de pelo. get_next_customer: llamado por el peluquero para esperar que un cliente se siente en su silla, y luego le corta el pelo finished_cut: llamado por el peluquero para que el cliente deje la peluquería. Programación Concurrente Clase 5

28 El peluquero sormilón sincronizado con monitores.
El peluquero y un cliente necesitan rendezvous: el peluquero tiene que esperar que llegue un cliente, y este tiene que esperar que el peluquero esté disponible. El cliente necesita esperar que el peluquero termine de cortarle el pelo, indicado cuando le abre la puerta de salida. Antes de cerrar la puerta de salida, el peluquero necesita esperar hasta que el cliente haya dejado el negocio.  el peluquero y el cliente atraviesan una serie de etapas sincronizadas, comenzando con un rendezvous similar a una barrera de dos procesos pues ambas partes deben arribar antes de que cualquiera pueda seguir. Programación Concurrente Clase 5

29 El peluquero dormilón sincronizado con monitores.
Podemos usar contadores incrementales para especificar las etapas de sincronización. Etapas del cliente: - sentarse en la silla del peluquero (cinchair) - dejar la peluquería (cleave) Etapas del peluquero: - estar disponible (bavail) - estar cortando el pelo (bbusy) - terminar de cortar el pelo (bdone) Programación Concurrente Clase 5

30 El peluquero dormilón sincronizado con monitores.
Condiciones: C1: cinchair  cleave  bavail  bbusy  bdone C2: cinchar  bavail  bbusy  cinchair C3: cleave  bdone El invariante del monitor es: BARBER: { C1 AND C2 AND C3 } Programación Concurrente Clase 5

31 Peluquero dormilón (rendezvous) con monitores.
Problema: los valores de los contadores pueden crecer sin límite  podemos cambiar variables Podemos hacerlo siempre que, como aquí, la sincronización depende solo de las diferencias entre valores de los contadores barber = bavail - cinchair chair = cinchair - bbusy open = bdone - cleave Las nuevas variables satisfacen el invariante: BARBER’ : { 0  barber  1  0  chair  1  0  open  1} Programación Concurrente Clase 5

32 Peluquero dormilón (rendezvous) con monitores.
barber es 1 cuando el peluquero está esperando a que un cliente se siente en su silla chair es 1 cuando el cliente se sentó en la silla pero el peluquero aún no está ocupado open es 1 cuando la puerta de salida fue abierta pero el cliente todavía no se fue Necesitamos implementar los await usando variables condición---> Usamos 4 variables condición, una para cada una de las cuatro distintas condiciones booleanas. Finalmente, agregamos signal donde las condiciones se hacen verdaderas. Programación Concurrente Clase 5

33 Peluquero dormilón (rendezvous) con monitores.
monitor Barber_Shop { int barber = 0, chair = 0, open = 0; cond barber_available; # signaled when barber > 0 cond chair_occupied; # signaled when chair > 0 cond door_open; # signaled when open > 0 cond customer_left; # signaled when open == 0 procedure get_haircut() { while (barber == 0) wait(barber_available); barber = barber - 1; chair = chair + 1; signal(chair_occupied); while (open == 0) wait(door_open); open = open - 1; signal(customer_left); } Programación Concurrente Clase 5

34 Peluquero dormilón (rendezvous) con monitores.
procedure get_next_customer() { barber = barber + 1; signal(barber_available); while (chair == 0) wait(chair_occupied); chair = chair - 1; } procedure finished_cut() { open = open + 1; signal(door_open); while (open > 0) wait(customer_left); Programación Concurrente Clase 5

35 Scheduling de disco rígido con monitores. Conceptos básicos.
Programación Concurrente Clase 5

36 Scheduling de disco con monitores. Conceptos básicos.
El disco contiene varios “platos” conectados a un eje central y que rotan a velocidad constante. Las pistas forman círculos concéntricos---> concepto de cilindro de información. Los datos se acceden posicionando una cabeza lectora/escritora sobre la pista apropiada, y luego esperando que el plato rote hasta que el dato pase por la cabeza. dirección física  cilindro, número de pista, y desplazamiento Para acceder al disco, un programa ejecuta una instrucción de entrada/salida específica Los parámetros para esa instrucción son: dirección física del disco, el número de bytes a transferir, la clase de transferencia a realizar (lectura o escritura), y la dirección de un buffer. Programación Concurrente Clase 5

37 Scheduling de disco con monitores. Conceptos básicos.
El tiempo de acceso al disco depende de tres cantidades: a) seek time para mover una cabeza al cilindro apropiado. b) rotational delay. c) transmission time (depende solo del número de bytes). a) y b)dependen del estado del disco (seek time>>rotational delay).  para reducir el tiempo de acceso promedio conviene minimizar el movimiento de la cabeza (reducir el tiempo de seek). Programación Concurrente Clase 5

38 Scheduling de disco con monitores. Conceptos básicos.
El scheduling de disco puede tener distintas políticas: Shortest-Seek-Time (SST): selecciona siempre el pedido pendiente que quiere el cilindro más cercano al actual. Es unfair SCAN, LOOK, o algoritmo del ascensor: se sirven pedidos en una dirección y luego se invierte. Es fair. Problema: un pedido pendiente justo detrás de la posición actual de la cabeza no será servido hasta que la cabeza llegue al final y vuelva (gran varianza del tiempo de espera). CSCAN o CLOOK: se atienden pedidos en una sola dirección. Es fair y reduce la varianza del tiempo de espera. Programación Concurrente Clase 5

39 Scheduling de disco con monitores ---> hacia una solución.
El scheduler es implementado por un monitor para que los datos de scheduling sean accedidos solo por un proceso usuario a la vez. El monitor provee dos operaciones: request y release. Un proceso usuario que quiere acceder al cilindro cyl llama a request(cyl), y retoma el control cuando el scheduler seleccionó su pedido. Entonces el proceso usuario accede al disco (llamando a un procedure o comunicándose con un proceso manejador del disco). Luego de acceder al disco, el usuario llama a release. Disk_Scheduler.request(cyl) Accede al disco Disk_Scheduler.release( ) Programación Concurrente Clase 5

40 Scheduling de disco con monitores. Una solución.
Suponemos cilindros numerados de 0 a MAXCYL y scheduling CSCAN. A lo sumo un proceso a la vez puede tener permiso para usar el disco, y los pedidos pendientes son servidos en orden CSCAN. position es la variable que indica posición corriente de la cabeza (cilindro que está siendo accedido por el proceso que está usando el disco). Para implementar CSCAN, hay que distinguir entre los pedidos pendientes a ser servidos en el scan corriente y los que serán servidos en el próximo scan. Programación Concurrente Clase 5

41 Scheduling de disco. Solución con monitor separado.
monitor Disk_Scheduler { ## Invariant DISK int position = -1, c = 0, n = 1; cond scan[2]; # scan[c] signaled when disk released procedure request(int cyl) { if (position == -1) # disk is free, so return position = cyl; elseif (position != -1 && cyl > position) wait(scan[c],cyl); else wait(scan[n],cyl); } Programación Concurrente Clase 5

42 Scheduling de disco. Solución con monitor separado.
procedure release() { int temp; if (!empty(scan[c])) position = minrank(scan[c]); elseif (empty(scan[c]) && !empty(scan[n])) { temp = c; c = n; n = temp; # swap c and n } else position = -1; signal(scan[c]); Programación Concurrente Clase 5

43 Scheduling de disco. Monitor de interface con el disco.
monitor Disk_Interface permanent variables for status, scheduling, and data transfer procedure use_disk(int cyl, transfer and result parameters) { wait for turn to use driver store transfer parameters in permanent variables wait for transfer to be completed retrieve results from permanent variables } procedure get_next_request(someType &results) { select next request wait for transfer parameters to be stored set results to transfer parameters procedure finished_transfer(someType results) { store results in permanent variables wait for results to be retrieved by client Programación Concurrente Clase 5

44 Scheduling de disco. Monitor de interface con el disco.
monitor Disk_Interface { int position = -2, c = 0, n = 1, args = 0, results = 0; cond scan[2]; cond args_stored, results_stored, results_retrieved; argType arg_area; resultType result_area; procedure use_disk(int cyl; argType transfer_params; resultType &result_params) { if (position == -1) position = cyl; elseif (position != -1 and cyl > position) wait(scan[c],cyl); else wait(scan[n],cyl); arg_area = transfer_params; args = args+1; signal(args_stored); while (results == 0) wait(results_stored); result_params = result_area; results = results-1; signal(results_retrieved); } Programación Concurrente Clase 5

45 Scheduling de disco. Monitor de interface con el disco.
procedure get_next_request(argType &transfer_params) { int temp; if (!empty(scan[c])) position = minrank(scan[c]); elseif (empty(scan[c]) && !empty(scan[n])) { temp = c; c = n; n = temp; # swap c and n } else position = -1; signal(scan[c]); while (args == 0) wait(args_stored); transfer_params = arg_area; args = args-1; Programación Concurrente Clase 5

46 Scheduling de disco. Monitor de interface con el disco.
procedure finished_transfer(resultType result_vals) { result_area := result_vals; results = results+1; signal(results_stored); while (results > 0) wait(results_retrieved); } Programación Concurrente Clase 5

47 Casos problema de interés: Semáforos/Monitores
Administrador de páginas de memoria. Los pedidos (Request) y las liberaciones (Release) tienen una CANTIDAD de páginas como parámetro. Analizar la resolución con semáforos y monitores. La condición de atender el Request es tener el número de páginas disponible. Ahora el problema “contiene” una política de scheduling. A- SJN (menor pedido primero) B- FIFO C- GJN (mayor pedido primero). Discuta las modificaciones a las soluciones anteriores. Programación Concurrente Clase 4

48 Casos problema de interés: Semáforos/Monitores
N procesos P[i] comparten 2 impresoras identificadas r1, r2. Los pedidos de impresora (Request) pueden tener la identificación de la impresora o xx (cualquiera). Las liberaciones (Release) tiene la identificación de la impresora. Analizar la resolución con semáforos y monitores. La condición de atender el Request es la impresora disponible. Ahora el problema “contiene” una política de scheduling. A- Por prioridad de proceso. B- Por menor número de hojas prometidas a imprimir. Discuta las modificaciones a las soluciones anteriores. Programación Concurrente Clase 4

49 Casos problema de interés: Semáforos/Monitores
El problema de los “baby birds”, “parent bird” y el plato de F porciones de comida. N consumidores con dos actividades. Un productor múltiple. Passing the baton ? El problema de las “abejas productoras de miel”, el “oso” y el pote de H porciones de miel. N productores con dos actividades. Un consumidor múltiple. Passing the baton ? Programación Concurrente Clase 4

50 Concurrencia en JAVA JAVA es un lenguaje que tiene soporte de concurrencia, mediante Threads. Un thread es un proceso “liviano” (lightweight process) que tiene un contexto privado mínimo. Cada Thread en JAVA tiene su propio contador de programa, su pila de ejecución (stack) y su conjunto de registros (working set), pero la zona de datos es compartida por todos los threads, exigiendo sincronización. En la próxima clase discutiremos una biblioteca de ejemplos en JAVA desarrollada en el 2002 por Andrés Barbieri. Programación Concurrente Clase 5

51 Tareas para la próxima clase
Analizar cómo se modificaría la solución del peluquero si fueran DOS peluqueros. Ver la solución de lectores-escritores en JAVA con monitores. (Andrews) Programación Concurrente Clase 5