Modelos de Coordinación: Conceptos
Un modelo de coordinación separa las actividades de
cómputo de un proceso de las actividades de
cooperación entre procesos.
A fines de los 80 Carriero & Gelernter definieron la
coordinación como el proceso de “construir programas
por la comunicación y sincronización de piezas activas”.
“piezas activas” podían ser TASKs, THREADS,
AGENTES, PROCESOS. Coordinar aspectos
temporales y espaciales, sin necesidad de acoplar los
procesos.
23-5-2005 1
Sistemas Paralelos 2005 - Clase 7
Modelos de Coordinación: Definición
Un modelo de Coordinación describe la
interacción entre tareas autónomas, incluyendo
comunicación, sincronización y manejo de las
mismas.
El término coordinación se refiere a un enfoque
en el que cómputo e interacción están
estrictamente separados y las tareas que
cooperan son anónimas entre sí.
23-5-2005 2
Sistemas Paralelos 2005 - Clase 7
Modelos de Coordinación: Ventajas
1- Separar cómputo e interacción facilita la
estructuración de los programas.
2- Se soporta la heterogeneidad y la interoperabilidad.
3- El concepto de “anónimo” entre procesos, soporta su
manejo dinámico ya que las tareas no requieren
conocerse antes del run time.
4- Se soporta la movilidad de código y la computación
móvil (por la misma “anonimidad”)
23-5-2005 3
Sistemas Paralelos 2005 - Clase 7
Lenguajes de Coordinación
Mientras los modelos de coordinación describen los
principios del método de interacción de los procesos, los
Lenguajes de Coordinación son las primitivas o
construcciones que se ofrecen al programador para
expresar prácticamente el modelo.
Veremos que normalmente todo modelo de coordinación
tendrá al menos un conjunto de lenguajes (o subsets de
lenguajes) que lo representan. Más aún: un entorno
paralelo puede soportar más de un modelo de
coordinación.
23-5-2005 4
Sistemas Paralelos 2005 - Clase 7
Coordinación basada en Tuplas
Los procesos interactúan en base a una “estructura
de datos” que puede residir en memoria compartida
centralizada o distribuida, pero que es transparente a
los procesos.
El término “estructura de datos” se refiere no sólo a
datos pasivos, sino también a procesos activos que
pueden residir en la memoria compartida.
Esta “estructura de datos” toma la forma de una
memoria asociativa, denominada “Tuple Space”.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 5
Coordinación basada en Tuplas
Un espacio de tuplas contiene un multiconjunto de
tuplas que por la memoria asociativa son
identificadas (por los procesos) por contenido, no
por posición.
Los procesos interactúan entre sí (en forma
“desacoplada”) leyendo y escribiendo sobre el espacio
de tuplas. A su vez las tuplas activas pueden producir
resultados que generen nuevas tuplas en el espacio de
datos compatidos. El modelo es esencialmente
asincrónico.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 6
Coordinación basada en Tuplas: El
Lenguaje LINDA
Como se ha explicado anteriormente (Prog.
Concurrente) el paradigma “bag of tasks” y la
coordinación por tuplas en memoria compartida se
hicieron viables a partir de LINDA, una biblioteca que
tiene implementaciones combinada con lenguajes
como C, Fortran y Prolog.
Actualmente se ha reiniciado la investigación en el
paradigma de Coordinación de tuplas + LINDA, sobre
todo en clusters y multiclusters con DSM.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 7
Programación Paralela con el
concepto de “bag of tasks”
Se parte del concepto de tener una “bolsa”de tareas que pueden ser
compartidas por procesos “worker”. Cada worker ejecuta un código
básico:
WHILE (true) {
obtener un task de la bolsa
IF (no hay más tareas)
BREAK; # exit del WHILE
ejecutar la tarea, incluyendo la creación de otras tareas;
}
Este enfoque puede usarse para resolver problemas con un número
fijo de tareas y también para soluciones recursivas con nuevas tareas
creadas dinámicamente.
El paradigma del bag of tasks es sencillo, escalable y favorece el
balance de carga entre los procesos.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 8
Concepto de “bag of tasks”. Ejemplo.
Consideraremos la multiplicación de 2 matrices a y b de nxn. El ejemplo
requiere n2 productos internos entre filas de a y columnas de b. Cada
producto interno es independiente y se puede realizar en paralelo.
Suponemos que se dispone de una máquina multiprocesador con PR
procesadores físicos, PR donde row es una variable local.
Notar que lo podemos implementar con un FETCH and ADD.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 9
Multiplicación de matrices con el
“bag of tasks”.
INT nextrow =0 # la bolsa de tareas
DOUBLE a[n,n], b[n,n], c[n,n];
PROCESS Worker [w=1 TO PR] {
INT row;
DOUBLE sum;
WHILE (true) {
# obtener una tarea
IF (row >= n)
BREAK;
Calcular los productos internos para c[row, *] ;
}
}
Para terminar el proceso se pueden contar los BREAK, al llegar a n se
tiene la matriz c completa y se puede finalizar el cálculo.
23-5-2005 10
Sistemas Paralelos 2005 - Clase 7
LINDA---> Primitivas para
Programación Concurrente.
LINDA ofrece una aproximación distintiva al procesamiento
concurrente: NO es un lenguaje de programación, sino un conjunto
de seis primitivas que operan sobre una memoria compartida donde
hay “tuplas nombradas” (tagged tuples) que pueden ser pasivas
(datos) o activas (tasks).
En el enfoque de LINDA (que puede agregarse como biblioteca a
cualquier lenguaje secuencial) se combinan aspectos de memoria
compartida con pasaje de mensajes asincrónicos.
Fue concebido en 1983 en la Tesis Doctoral de D. Gelernter (Univ.
New York) y sus implementaciones sobre distintos lenguajes se
desarrollaron entre esa fecha y 1989.
23-5-2005 11
Sistemas Paralelos 2005 - Clase 7
LINDA---> Primitivas para
Programación Concurrente.
El núcleo de la idea de LINDA es el espacio de tuplas compartidas
(TS) que puede verse como un único canal de comunicaciones
compartido en el que no existe orden:
Depositar una tupla (OUT) funciona como un SEND.
Extraer una tupla (IN) funciona como un RECEIVE.
RD es la primitiva que permite “leer”como un RECEIVE pero sin
extraer la tupla de TS.
EVAL permite la creación de procesos (tuplas activas) dentro de TS.
Por último IPD y RDP permiten hacer IN y RD no bloqueantes.
Si bien hablamos de memoria compartida, TS puede estar
físicamente distribuida en una arquitectura multiprocesador (con
todas las complejidades asociadas).
23-5-2005 12
Sistemas Paralelos 2005 - Clase 7
LINDA---> Primitivas para
Programación Concurrente.
El TS consta de una colección no ordenada de tuplas pasivas y
activas.
Las tuplas de datos (pasivas) son registros tagged que contienen el
estado compartido de un cómputo.
Las tuplas activas (de proceso) son rutinas que ejecutan
asincrónicamente.
La interacción se da leyendo, escribiendo y generando tuplas de
datos. Cuando una tupla proceso termina, se convierte en una tupla
de datos.
Cada tupla de datos en TS tiene la forma:
("tag", value1, ..., valuen)
El tag es un string literal que se usa para distinguir entre tuplas que
representan distintas estructuras de datos.
23-5-2005 13
Sistemas Paralelos 2005 - Clase 7
LINDA---> Primitivas para depositar y
extraer de TS.
Un proceso deposita una tupla en TS ejecutando:
out("tag", expr1, ..., exprn)
La ejecución de out termina una vez que las expresiones fueron
evaluadas y la tupla de datos resultante fue depositada en TS. La
operación out es similar a una sentencia send, excepto que la tupla
se almacena en un TS no ordenado en lugar de ser agregada a un
canal específico.
Un proceso extrae una tupla de datos de TS ejecutando:
in("tag", field1, ..., fieldn)
Cada fieldi o es una expresión o un parámetro formal de la forma ? var
donde var es una variable local en el proceso ejecutante. Los argumentos
para in son llamados template. El proceso que ejecuta in se demora hasta
que TS contenga al menos una tupla que matchee el template, y luego
remueve una de TS.
23-5-2005 14
Sistemas Paralelos 2005 - Clase 7
LINDA---> Primitivas para examinar
tuplas de datos.
La tercera primitiva básica de LINDA es rd, que se usa para examinar
tuplas de datos. Si t es un template, la ejecución de rd(t) demora al
proceso hasta que TS contiene una tupla de datos que haga matching.
Como con in, las variables en t luego son asignadas con los valores
correspondientes de los campos de la tupla de datos.
Sin embargo, la tupla permanece en TS.
Hay variantes no bloqueantes de in y rd.
Las operaciones inp y rdp son predicados que retornan true si hay una
tupla matching en TS, y false en otro caso.
Si retornan true, tienen el mismo efecto que in y rd respectivamente.
Inp y rdp proveen una manera de que un proceso haga polling sobre TS.
23-5-2005 15
Sistemas Paralelos 2005 - Clase 7
LINDA---> Primitivas para crear
procesos.
La sexta y última primitiva Linda es eval, que crea tuplas proceso. Esta
operación tiene la misma forma que out y también produce una nueva
tupla: eval("tag", expr1, ..., exprn)
Al menos una expresión es un call a una función o procedimiento. Todos
los campos de EVAL pueden ser tratados concurrentemente por procesos
diferentes y el proceso que escribe el EVAL no espera.
Cuando todos los campos son tratados (incluída la ejecución del o los
procedimientos/funciones) la tupla se convierte en pasiva (quedan sólo
datos) y se agrega a TS.
La primitiva eval provee el medio por el cual la concurrencia se puede
incorporar en un programa Linda.
23-5-2005 16
Sistemas Paralelos 2005 - Clase 7
LINDA---> Primitivas para crear
procesos.Concurrencia con EVAL.
Como ejemplo, consideremos la siguiente sentencia concurrente:
co [i := 1 to n]
a[i] := (i);
oc
Esto evalúa n llamados de en paralelo y asigna los resultados al arreglo
compartido a.
El código C-Linda correspondiente es:
for ( i = 1; i n; i++ )
EVAL("a", i, f(i));
Esto dispara (forks) n tuplas proceso; cada una evalúa un llamado de
f(i). Cuando una tupla proceso termina, se convierte en una tupla de datos
que contiene el nombre del arreglo, un índice y el valor de ese elemento
del arreglo a.
23-5-2005 17
Sistemas Paralelos 2005 - Clase 7
Generación de nros. primos con C y
LINDA. (paradigma bag of tasks)
Los workers comparten TS (bag of tasks). Aquí estarán los números
candidatos a primos. Un proceso manager debe depositarlos y recoger
los que sean confirmados como primos.
Los workers buscan un candidato y deciden si es primo por el método
habitual de dividirlo por los primos menores ya existentes. Si lo fuera,
lo agrega a la lista (compartida) de primos.
La rutina principal hace de manager. Lee los argumentos para saber
cuantos primos generar, usa EVAL para crear los workers, tiene una
tabla inicial con los primos 2 y 3, envía el primer candidato a primo(5)
usando OUT y espera con IN recibir los primos que se vayan
generando. Cada primo que recibe lo agrega a TS. Cuando la cuenta de
recibidos llega a limit, imprime y termina.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 18
Números primos con C y LINDA. El Main
Real_main(INT argc, CHAR *argv[ ] ) {
INT primes[ limit] = {2,3}; /*tabla de primos*/
INT limit, numworkers, i, isprime;
INT numprimes=2, value=5;
limit = atoi (argv[ 1]) ; /*se lee cuantos generar */
numworkers= atoi (argv[ 2] );
/* Crear los workers y poner el primer primo en TS */
FOR (i=1; i numprimes ) { /* necesito otro primo */
numprimes++;
RD ( “prime” , numprimes, ?primes[numprimes]);
}
}
OUT (“result”, candidate, isprime); /*se envia el resultado al manager */
}
23-5-2005 21
Sistemas Paralelos 2005 - Clase 7
Coordinación basada en Tuplas:
Modelos relacionados.
Hay numerosas implementaciones con variantes de
LINDA (en general con extensiones y mejoras). Entre
ellas:
• Replicación de espacios de tuplas.
• Operaciones de READ colectivas.
• Soporte para fault tolerance en DSM de clusters.
• Soporte para ambientes móviles.
• Operaciones de acceso seguro.
• Soporte para agentes móviles
Ejemplos: TuCSoN (Tuple centers spread over networks),
JAVA Spaces, IBM TSpace
Sistemas Paralelos 2005 - Clase 7
23-5-2005 22
Coordinación basada en Tuplas:
Modelos relacionados.
Cuando se manejan implementaciones con múltiples
espacios de tuplas, puede haber diferentes enfoques:
1- Que la ubicación de las tuplas sea transparente al
usuario el sistema debe manejar la migración de
tuplas.
2- Cada agente tiene asignado un espacio de tuplas y
se ejecuta en èl. Si quiere acceder a otro espacio de
tuplas, previamente debe migrar a èl.
3- El programador debe manejar la ubicación de las
tuplas y referirse explícitamente a la misma.Paralelos 2005 - Clase 7
Sistemas
23-5-2005 23
Coordinación basada en Canales. El
modelo CSP y el Lenguaje OCCAM
El modelo basado en canales considera a los
procesos como actividades de cómputo de “caja
negra” que se caracterizan por su comportamiento
de E/S.
Los procesos se coordinan siendo uno entrada de la
salida de otro, mediante la definición de alguna forma
de canal virtual.
La coordinación por canales es un concepto antiguo,
que nace en el CSP de Hoare (fines de los 70). CSP es
quizás el modelo más influyente para el cómputo
concurrente.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 24
El lenguaje CSP de Hoare.
CSP (Hoare 1978) fue uno de los desarrollos fundamentales en
Programación Concurrente. Muchos lenguajes reales (OCCAM,
ADA, SR) se basan en CSP.
La idea básica de Hoare fue la de comunicación guardada: es decir
pasaje de mensajes con waiting selectivo.
Canal: link directo entre dos procesos en lugar de mailbox global.
Son half-duplex y nominados.
Sentencias de Entrada y Salida ( ? ! ) : único medio por el cual los
procesos se comunican.
Efecto de la comunicación sentencia de asignación distribuida.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 25
El lenguaje CSP de Hoare.
Formas generales de sentencias de comunicación:
Destino ! port(e1, ..., en);
Fuente ? port(x1, ..., xn);
Destino y Fuente nombran un proceso.
port es un canal de comunicación simple en el proceso destino o un
elemento de un arreglo de ports en el proceso destino.
Los ports son usados (declarados) para distinguir entre distintas clases
de mensajes que un proceso podría recibir.
Dos procesos se comunican cuando ejecutan sentencias de
comunicación que hacen matching.
A! canaluno(dato); #el proceso A envia por canaluno
B? canaluno(resultado); #el proceso B recibe por canaluno
Sistemas Paralelos 2005 - Clase 7
23-5-2005 26
El lenguaje CSP de Hoare. Primeros
ejemplos.
Server que calcula el Máximo Común Divisor de dos enteros con
algoritmo de Euclides:
GCD espera recibir entrada en su port args desde un único cliente.
Envía la respuesta al port result del cliente.
Process GCD {
INT Id, x, y;
do true Client[*] ? args(Id, x,y);
#Lo que sigue se repite hasta que x==y
do x > y x := x - y;
• x S1;
•B2; comunicación2----> S2;
FI
Process Copy {
CHAR buffer[80];
INT front = 0, rear = 0, count = 0
do count 0; East ! buffer[front]
•
count := count - 1;
front := (front + 1) MOD 80;
od
}
Sistemas Paralelos 2005 - Clase 7
23-5-2005 28
Intercambio de valores entre dos
procesos en CSP.
Supongamos dos procesos que intercambian valores:
Process P1 {
INT value1 = 1, value2;
IF P2 ! value1 ---> P2 ? value2;
P2
• ? value2 ---> P2 ! value1;
FI
}
Process P2 {
INT value1 , value2=2;
IF P1 ! value2 ---> P1 ? value1;
P1
• ? value1 ---> P1 ! value2;
FI
}
Esta solución simétrica NO tiene deadlock porque el no
determinismo en ambos procesos hace que se acoplen las
comunicaciones correctamente.
23-5-2005 29
Sistemas Paralelos 2005 - Clase 7
CSP: Generación de números primos:
la criba de Eratóstenes.
Idea: generar todos los primos entre 2 y n
2 3 4 5 6 7 ... n
Comenzando con el primer número, 2, recorremos la lista y
borramos los múltiplos de ese número. Si n es impar:
2 3 5 7 ... n
Pasamos al próximo número, 3, y borramos sus múltiplos.
Si seguimos hasta que todo número fue considerado, los que
quedan son todos los primos entre 2 y n.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 30
La criba de Eratóstenes: solución
paralela en CSP.
Process Sieve[i = 2 TO L] {
INT p, next;
Sieve[i-1] ? p # p es primo
DO Sieve[i-1] ? Next ---> #recibe el proximo candidato
IF (next MOD p) 0 ---> #podría ser primo
Sieve[i+1] ! Next; #entonces lo pasa
FI
OD
}
El número total L de procesos Sieve debe ser lo suficientemente
grande para garantizar que todos los primos hasta n se generan.
23-5-2005 31
Sistemas Paralelos 2005 - Clase 7
El lenguaje de programación OCCAM
Hoare introdujo CSP como lenguaje formal que sigue el
modelo de coordinación por canales con pasaje de
mensajes sincrónicos, pero nunca fue implementado.
OCCAM es un lenguaje real, que implementa lo esencial
de CSP sobre una arquitectura “modelo” que
físicamente se ha desarrollado y que son los trasputers.
Trasputers + OCCAM constituyen una combinación que permite
hablar de “sistema multiprocesador para procesamiento
concurrente”, donde tanto la arquitectura como el lenguaje son
simples y perfectamente adecuadas a la programación
concurrente con mensajes sincrónicos.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 32
El lenguaje de programación OCCAM.
OCCAM es un lenguaje simple con una sintaxis rígida:
Cada proceso primitivo, constructor o declaración ocupa una
línea.
Se usa : al final de una declaración.
Hay una rígida indentación.
Los procesos y los caminos de comunicación entre ellos son
estáticos (definidos al momento de la compilación).
Un programa en OCCAM tiene un número fijo de procesos .
El modelo de comunicación es sincrónico por canales half
duplex.
Las sentencias básicas (asignación y comunicación) son
vistas como procesos primitivos. Sistemas Paralelos 2005 - Clase 7
23-5-2005 33
Conceptos del lenguaje de
programación OCCAM
Occam no soporta recursión o cualquier forma de creación o
nombrado dinámico. Esto hace que muchos algoritmos sean
difíciles de programar.
Sin embargo, asegura que un compilador Occam puede determinar
exactamente cuántos procesos contiene un programa y cómo se
comunican uno con otro.
Esto, y el hecho de que distintos constructores no pueden
compartir variables, hace posible para un compilador asignar
procesos y datos a procesadores en una máquina de memoria
distribuida tal como un transputer.
23-5-2005 34
Sistemas Paralelos 2005 - Clase 7
El lenguaje de programación OCCAM
Las unidades básicas de un programa Occam son declaraciones y tres
"procesos" primitivos: asignación, input(receive),output (sync_send).
Los canales son declarados globales a los procesos . Sin embargo,
cada canal debe tener exactamente un emisor y un receptor.
Los procesos primitivos se combinan en procesos
convencionales usando constructores (sentencias
estructuradas). Estos incluyen un constructor secuencial SEQ,
un constructor paralelo PAR similar a la sentencia co, y una
sentencia de comunicación guardada.
Un constructor puede ser precedido por declaraciones de
variables y canales; el alcance de estos ítems es el constructor.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 35
El lenguaje OCCAM: constructores
SEQ y PAR
En la mayoría de los lenguajes, el default es ejecutar sentencias
secuencialmente; el programador tiene que decir explícitamente
cuándo ejecutar sentencias concurrentemente.
Occam toma una aproximación distinta: no hay default.
En lugar de esto, contiene dos constructores básicos: SEQ para
ejecución secuencial y PAR para ejecución paralela. Por ejemplo, el
siguiente programa incrementa x, luego y:
INT x,y :
SEQ
x := x + 1
y := y + 1
23-5-2005 36
Sistemas Paralelos 2005 - Clase 7
El lenguaje OCCAM: constructores
SEQ y PAR
En el ejemplo anterior, dado que las dos sentencias acceden
variables distintas, pueden ser ejecutadas concurrentemente. Esto
se expresa por:
INT x,y :
PAR
x := x + 1
y := y + 1
Lo que cambia es el nombre del constructor, para indicarle al compilador
y el monitor de ejecución si puede haber concurrencia.
PAR no es tan poderoso como la sentencia co pues los procesos Occam
no pueden compartir variables.
23-5-2005 37
Sistemas Paralelos 2005 - Clase 7
Comentarios sobre el constructor PAR
en OCCAM
Los procesos especificados usando PAR ejecutan con
igual prioridad y sobre cualquier procesador.
El constructor PRI PAR puede usarse para especificar
que el primer proceso tiene la prioridad más alta, el
segundo la siguiente, etc.
El constructor PLACED PAR puede usarse para
especificar explícitamente dónde es ubicado y por lo
tanto ejecutado cada proceso
23-5-2005 38
Sistemas Paralelos 2005 - Clase 7
El lenguaje de programación OCCAM:
otros constructores
El constructor IF se usa para alternativas:
es similar a la sentencia IF guardada que conocemos,
pero hay dos diferencias: las guardas son evaluadas en
el orden en que están listadas, y al menos una guarda
debe ser TRUE.
El constructor CASE es una variante de IF que puede
ser usada para alternativas múltiples.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 39
El lenguaje de programación OCCAM:
otros constructores
El constructor WHILE es uno de los mecanismos de
iteración; es como la sentencia while de Pascal.
El constructor ALT soporta comunicación guardada.
Cada guarda consta de un input process, una expresión
booleana y un input process, o una expresión booleana
y un SKIP (lo cual se reduce esencialmente a una
expresión booleana pura).
Sistemas Paralelos 2005 - Clase 7
23-5-2005 40
Replicadores en OCCAM.
Occam también contiene un mecanismo interesante llamado replicador.
Es similar a un cuantificador y se usa del mismo modo.
Por ejemplo, lo siguiente declara un arreglo pepe de 21 elementos e
iterativamente asigna un valor a cada elemento:
[20] INT pepe :
SEQ i = 0 FOR 10
pepe[i] := i
Como vemos, solo el límite superior del arreglo se declara; el límite
inferior es implícitamente 0 para todos los arreglos. Las matrices se
declaran como arreglos de arreglos.
Un replicador no agrega nueva funcionalidad al lenguaje, solo es una
abreviación para un conjunto de componentes. Occam requiere que el
límite superior sea una constante, y por lo tanto un replicador siempre
puede ser expandido para dar un programa equivalente pero más largo.
23-5-2005 41
Sistemas Paralelos 2005 - Clase 7
Comunicación y sincronización en
OCCAM
Como dijimos, las sentencias en los distintos constructores
de Occam no pueden compartir variables. Para
comunicarse y sincronizar, deben usar canales. Una
declaración de canal tiene la forma:
CHAN OF protocol name :
El protocolo define el tipo de valores que son transmitidos
por el canal.
Pueden ser tipos básicos, arreglos de longitud fija o
variable, o registros fijos o variantes.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 42
Comunicación y sincronización en
OCCAM
Los procesos pueden ser creados con el constructor
PAR.
Los canales son accedidos por los procesos primitivos
input (?) y output (!).
A lo sumo un proceso puede emitir por un canal, y a lo
sumo uno puede recibir por un canal.
Dado que el nombrado es estático, un compilador
Occam puede forzar este requerimiento.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 43
Comunicación y sincronización en
OCCAM. Un ejemplo.
WHILE TRUE
BYTE ch :
SEQ
keyboard ? ch
ch ! screen
Aquí, keyboard y screen son canales que se asume que están
conectados a dispositivos periféricos.
Aunque Occam no define mecanismos de E/S como parte del
lenguaje, provee mecanismos para ligar canales de E/S a
dispositivos.
El sistema de desarrollo en transputer, por ejemplo, contiene una
librería de procedures de E/S de modo de vincular canales lógicos y
dispositivos físicos.
23-5-2005 44
Sistemas Paralelos 2005 - Clase 7
Comunicación y sincronización en
OCCAM. Un ejemplo.
El programa anterior usa un buffer simple, ch.
Puede convertirse en un programa concurrente que use doble buffering
empleando dos procesos, uno para leer desde el teclado y uno para
escribir en la pantalla. El proceso se comunica usando un canal adicional
comm; cada uno tiene un carácter local ch:
CHAN OF BYTE comm :
PAR
WHILE TRUE
BYTE ch :
SEQ
keyboard ? ch
comm ! ch
WHILE TRUE
BYTE ch :
SEQ
comm ? ch
23-5-2005 keyboard ! ch 45
Sistemas Paralelos 2005 - Clase 7
Uso del constructor ALT en OCCAM
El constructor ALT soporta comunicación guardada. Cada guarda consta
de un input process, una expresión booleana y un input process.
Puede usarse un replicador como abreviatura, por ejemplo, para esperar
recibir entrada de uno de un arreglo de canales. Por ejemplo, lo siguiente
implementa un alocador de recursos simple:
ALT i = 0 FOR n
avail > 0 & acquire[i] ? unitid
SEQ
avail := avail - 1 -- and select unit to allocate
reply[i] ! Unitid
release[i] ? unitid
avail := avail + 1 -- and return unit
23-5-2005 46
Sistemas Paralelos 2005 - Clase 7
Uso del constructor ALT en OCCAM.
Comentarios.
Acquire, reply y release son arreglos de canales, con un
elemento para cada cliente i.
Se necesitan arreglos pues un canal puede ser usado
por solo dos procesos.
Occam no permite mensajes nulos (señales) de modo
que se debe enviar algún valor por el canal acquire
aunque no se use este valor.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 47
Uso del constructor ALT en OCCAM.
Comentarios.
No se permiten output processes en guardas de un
constructor ALT.
Esto hace que algunos algoritmos sean duros de
programar, pero simplifica la implementación.
Esto último es especialmente importante pues Occam es el
lenguaje de máquina del transputer.
Las guardas en un ALT son evaluadas en orden
indefinido(no determinístico).
El constructor PRI ALT puede usarse para forzar que las
guardas sean evaluadas en el orden deseado.
Sistemas Paralelos 2005 - Clase 7
23-5-2005 48
Proceso reloj en OCCAM.
Occam también contiene una facilidad de timer.
Un timer es una clase especial de canal.
Un proceso hardware está siempre listo para enviar hacia algún canal
timer declarado en un programa. Si un proceso declara el canal timer
myclock, puede leer la hora ejecutando:
myclock ? time
El proceso también puede demorarse hasta que el reloj alcance un cierto
valor ejecutando:
myclock ? time AFTER value
Aquí, value es un tiempo absoluto, no un intervalo.
Un timer también puede usarse en una guarda en un constructor
ALT; esto sirve para programar un interval timer.
23-5-2005 49
Sistemas Paralelos 2005 - Clase 7
Coordinación por canales: Modelos
relacionados
Si bien la relación natural ha sido CSP-OCCAM, también
aparece CSP combinado con JAVA.
Asimismo ADA adopta los conceptos de coordinación por
canales de CSP, pero le agrega más riqueza semántica y
adopta un modelo más complejo para la concurrencia.
Una realización del modelo de coordinación por canales
es el modelo IWIM (idealized worker, idealized manager)
que emplea el lenguaje de coordinaciòn Manifold.
LEER
Sistemas Paralelos 2005 - Clase 7
23-5-2005 50
Comentarios sobre el tema de
Coordinación
Parallel mobile code.
Message oriented Middleware (MOM)
Grid Middleware.
23-5-2005 51
Sistemas Paralelos 2005 - Clase 7
Próximas Clases
1- Veremos modelos orientados a objetos, en
particular Objetos Distribuidos y Objetos Activos.
2- Luego modelos de procesamiento paralelo con
lenguajes de alto nivel en diferentes paradigmas.
3- Por último modelos abstractos como BSP ,
LOGP, QSM y basados en Grafos.
4- Por último trataremos de hacer una
comparación global de los sistemas paralelos y
sus modelos asociados.
23-5-2005 52
Sistemas Paralelos 2005 - Clase 7