Sunteți pe pagina 1din 8

En este segundo ejemplo de protocolos de coherencia, vamos a analizar el

protocolo estndar SCI (Scalable Coherent Interface) de la IEEE. En este


protocolo la informacin de coherencia se distribuye entre las caches
formando listas doblemente ligadas, este protocolo es usado en la maquina
NUMA-Q de sequent, NUMA-Q es un multiprocesador pequeo con 32
procesadores, estos 32 procesadores estn distribuidos en una red anillo de
8 nodos, cada nodo consiste en una tarjeta con 4 procesadores, y los
enlaces de la red son de 1 Gb/s. Cada nodo se conecta a la red (al anillo)
mediante un interfaz, denominado IQ-link. Este dispositivo encamina los
paquetes y tambin gestiona la coherencia, para ello utiliza una cache de 32
MB, llamada cache de acceso remoto, en donde se guardan los boques de
datos que se han trado desde otros nodos. La cache remota y las caches
internas cumplen el principio de inclusin, sea, si se reemplaza un bloque
en la cache remota, se debe invalidar ese bloque en las caches internas, y si
se modifica un bloque en una cache interna, hay q actualizar el estado de
ese bloque en la cache remota. Los bloques son de 64 bytes. La coherencia
de los datos se mantiene de manera jerrquica, dentro de cada nodo
mediante los snoopy locales, y entre los nodos mediante el directorio
distribuido por los IQ-link, que implementa el protocolo SCI, con listas
distribuidas en las caches.
SCI: estados y operaciones

El estado de un bloque va a estar repartido en MP y en las caches. En la


parte de directorio que esta junto a MP, se indica la direccin de la primera
copia y el estado del bloque. Un bloque puede estar en alguno de estos 3
estados:

Home: no existe ninguna copia en ninguna cache (la lista esta vaca)
Fresh: existen copias y todas son iguales y coherentes con la
informacin de la MP.
Gone: la informacin de MP no est actualizada, sea el bloque esta
modificado en las caches.

En esta parte del directorio no se utilizan los estados de tipo busy.


En las caches tambin se guarda informacin sobre los bloques, se utilizan 7
bits y el estndar SCI define 29 estados normales y muchos estados
transitorios. Los estados permanentes de un bloque estn divididos en dos
partes:

La posicin que ocupa el bloque en la lista de copias, que puede ser:


Only (cuando solo hay una copia), Head (cuando es la primera copia),
Mid (cuando es una copia intermedia) o Tail (cuando es la ltima
copia).
El estado: Dirty (M), Fresh (S), Valid (S), Exclusive (E), Stale

Por lo tanto el estado de un bloque puede ser: head-dirty, tail-valid En la


siguiente tabla se presentan los estados ms utilizados:

Por ejemplo si en la MP el estado del bloque es Home, quiere decir que no


hay copias.
Si en la MP el estado del bloque es Fresh, quiere decir que hay copias de ese
bloque y son coherentes. Puede haber una sola copia, por lo que su posicin
ser only, por lo tanto su estado ser only-fresh, si hay 2 copias, el estado
de la primera ser head-fresh y la segunda tail-valid.
Si en la MP el estado del bloque es gone, quiere decir que el bloque esta
modificado en las caches y la informacin de la MP no est actualizada, si
hay una sola copia el estado de esa copia ser only-dirty, si hay dos copias
modificadas el estado de la primera ser head dirty y de la segunda tailvalid y as.
Cuando se combina los estados exclusive y Stale es para la comparticin de
datos, sea cuando un bloque se comparte solo entre dos procesadores,
entonces cuando uno escribe, la copia del otro pasa a estado Stale (copia
vieja) pero sin borrar los enlaces, as cuando el segundo quiere usar el
bloque, ya sabe dnde ir a buscarlo, sin tener que consultar el directorio.
Para mantener la coherencia de los bloques hay que realizar muchas
operaciones de comunicacin. El SCI define 3 funciones de coherencia para
realizar todas esas funciones:

Insertion o List Construction: para aadir una copia a la lista.


Deletion o Roll-out: para eliminar una copia de la lista.
Reduction o Purge: para invalidar el resto de las copias de la lista.

En cuanto a la comunicacin todas las operaciones son del tipo


pregunta/respuesta.
No utiliza NACK para asegurar la ejecucin atmica de las operaciones, sino
bferes.
Aplicando el estndar SCI se pueden definir diferentes protocolos: minimal
(no admite copias), typical, full

Lecturas (fallo)
Como en los ejemplos anteriores L (local) es el nodo que ejecuta la
operacin, H (home) es el nodo que tiene la variable (bloque) en memoria, y
R (remote) es el nodo que tiene la primera copia del bloque. Se va a realizar
una lectura en L, pero la variable (el bloque) no est en la cache, por lo que
se debe conseguir el bloque de datos que contiene la variable, y colocarlo
en la primera posicin de la lista de copias, usando la funcin List
Construction:
1.- Se reserva sitio en la cache para el bloque, y se pone en estado busy
(1a).
2.- Se enva una peticin a H (1b). Cuando llega la peticin, el estado del
bloque en el directorio H puede ser uno de los siguientes:

Home: Por lo tanto no existen copias del bloque en las caches. Por lo
tanto esta ser la primera copia. Por ello, se cambia el estado de
Home a Fresh y el puntero a la primera copia apuntara a L (2a). Por
ltimo se enva el bloque de MP (2b). Cuando llega a L, el bloque se
carga en la cache en estado only-fresh. Como no hay mas copias no
es necesario guardar punteros (3).

Fresh: Por lo tanto existen varias copias del bloque en las caches de
los procesadores, estas copias estn unidas en una lista, y tenemos
que situar a la nueva copia como primera copia de la lista. Para ello,
se modifica el puntero para que apunte a la nueva copia (2a), y se
enva el bloque de datos que est en MP ya que al ser su estado fresh
quiere decir que es coherente, tambin se enva la direccin de la
anterior cabeza de la lista (R), para que L se comunique con l para
actualizar los enlaces de la lista (2b). Cuando la respuesta de H llega
a L, se carga el bloque en la cache, y se mantiene el estado busy,
luego L enviara un mensaje al antiguo cabeza de la lista R, para
indicarle quien es ahora la nueva cabeza (3). Cuando llegue el
mensaje a R, se modificara el estado del bloque y los enlaces (4a).

Luego, R enva un mensaje ACK a L (4b). Para terminar la operacin L


recibe el mensaje y cambia el estado del bloque a Head-Fresh y el
puntero de la siguiente copia apuntara a R.

Gone: Quiere decir que la copia adecuada del bloque de datos no es


la de la MP, sino la que est en la cache en la cabecera de la lista. El
proceso es el mismo que el anterior, salvo la obtencin del bloque,
que debe provenir de R ya no de H, por lo tanto cuando se actualice
el estado del bloque y el enlace en la antigua cabeza de lista, R
enviara a L, el bloque de datos junto con el mensaje ACK. El estado
del bloque en la cache de L ser finalmente Head-Dirty (el bloque
esta modificado)

Escrituras
En el protocolo SCI, solo el cabeza de la lista de copias puede modificar el
bloque, adems como es un protocolo de invalidacin, habr que invalidar
todas las copias, y quedar como nica copia. Se distinguen estos casos:
1. (acierto/cabeza), cuando la escritura es en la copia que est en la cabeza
de la lista. Se escribe y se invalida el resto de copias (INV): ->Purge
2. (fallo), cuando el bloque sobre el que se quiere escribir no est en la
cache, por lo tanto se tiene que conseguir el bloque y colocarlo como
cabeza de la lista de copias (List Construction); y luego se invalidad el resto
de copias: ->List construction + Purge
3. (acierto/intermedio), cuando el bloque que se quiere modificar se
encuentra en una posicin intermedia de la lista, ya que solo puede escribir
el cabeza de la lista, se debe hacer lo siguiente, (a) sacar la copia de la lista
de copias (Roll-out) y (b) efectuar las operaciones del caso 2: ->Roll-out +
List construction + Purge
Analizando el primer caso: para mantener la coherencia solo se tiene que
invalidar las copias restantes, para ello se ejecuta la funcin de coherencia
purge, segn el estado del bloque el procedimiento es el siguiente (4
posibilidades):
1.- El estado de la copia de la cabeza es only-fresh, es decir es la nica
copia, de todas maneras se tiene que cambiar el estado del bloque, tanto en
la cache como en el directorio, en la cache se debe poner en estado onlydirty y en el directorio junto a MP en estado Gone. Se enva un mensaje a H,
para que cambie el estado del bloque de fresh a gone, y con la confirmacin
(ACK) que llega desde el directorio, se termina la operacin.

2.- El estado de la copia de la cabeza es only-dirty. Es el caso ms simple,


solo hay una copia, y adems ya est modificada por lo tanto en el
directorio de MP estar en estado Gone, por lo tanto no hay que hacer nada
para mantener la coherencia.
3.- El estado del bloque en la cabeza es Head-Fresh, ahora si como hay ms
de una copia, hay que invalidar el resto de copias. Primero hay que avisarle
al directorio (1b) para que cambie el estado del bloque de fresh a gone,
cuando llegue la confirmacin del directorio (2b), se pasara a invalidar las
copias de la siguiente manera:
- Se enva un mensaje de INV al segundo de la lista (3), cuando llegue
el mensaje a R1 se invalidara la copia en la cache (estado=I y
punto=null) y en la respuesta (4b) se enva la confirmacin ACK de la
invalidacin y la direccin de la siguiente copia de la lista.
-Se repite el procedimiento con las dems copias, la respuesta de la
ltima copia (tail), indicara que ya no hay ms copias para invalidar.
Desde el comienzo el estado del bloque pasa a ser busy y se
mantiene hasta el final que pasa a ser only-dirty.

4.- Por ltimo, el estado de la copia de la cabeza es Head-Dirty, por lo tanto


en el directorio el bloque ya est en estado gone, por lo tanto solo basta con
ejecutar la funcin purge, como en el caso anterior.

En el segundo caso (fallo), una escritura con fallo en cache, se tiene que
conseguir una copia del bloque y ponerse en la cabeza de la lista (List
construction), se cambia el estado a Gone en el directorio en MP, y purge
para invalidar el resto de copias.
Por ultimo en el tercer caso, cuando hay un acierto en la cache, pero el
bloque no est en la cabeza de la lista, como solo se puede modificar la
copia que est en la cabeza de la lista, para poder escribir hay que sacar la
copia de la lista (Roll-out) luego introducirla de nuevo, ahora en la cabeza de

la lista (Lis-construction). Para sacar un bloque de la lista, hay que ejecutar


la funcin de coherencia Roll-out, de la siguiente manera:

1.- Se envan mensajes desde L a R1 y R2, anterior y siguiente de la lista (L


tiene ambas direcciones), para que actualicen sus punteros, ya que estas
dos copias deben apuntarse mutuamente. Cuando se reciben esos
mensajes, se actualizan los punteros y se envan los mensajes de
confirmacin ACK, mientras no se reciban ambas respuestas, el bloque se
mantiene en estado busy o transitorio.
Si en la lista solo hay dos copias, el procedimiento es el mismo pero solo con
R1, que cambiara el estado del bloque en la cache a only-x|*-*
2.- Cuando llegan los dos ACK, el bloque queda fuera de la lista de copias.
La operacin de Roll-out puede producir deadlock (punto muerto), cuando
dos procesadores contiguos quieren abandonar la lista, se envan
mutuamente los correspondientes mensajes, y se quedan esperando la
respuesta del otro, por lo tanto el sistema se ha bloqueado, el bloqueo se
puede evitar si se obliga a contestar este tipo de mensajes a pesar de estar
en estado busy, y se establece un sistema de prioridades, por ejemplo, la
copia que est ms cerca de la cabeza de lista tiene prioridad para hacer
roll-out.

Actualizacin de la MP
Para terminar con las principales operaciones de coherencia tenemos que
analizar el reemplazo de un bloque en la cache. A pesar de que la copia del
bloque sea coherente con MP, hay que ejecutar la funcin roll-out para
eliminar el bloque de la lista de copias, y actualizar los punteros de la lista.
Si el bloque que se reemplaza est en estado only-dirty tenemos que
guardar los datos en MP y actualizar la informacin del directorio (en el nodo
H).
Un caso particular de la funcin Roll-out, es cuando el bloque que se quiere
eliminar esta en la cabeza de la lista, en este caso se hace lo siguiente:
1.- Se enva un mensaje de control al segundo de la lista para que cambie
de estado: Mid (Tail)-Valid (Fresh) Head (Only)-Dirty (Fresh).Mientras tanto,
el bloque est en estado busy.

2.- Cuando llega la respuesta de este, se enva un mensaje a H, para que


actualice el puntero en el directorio, la operacin termina cuando llega el
ACK del directorio.

Atomicidad y Carreras
Las operaciones de coherencia no son atmicas por lo que pueden ocurrir
interferencias entre ellas, adems en el directorio no se utilizan estados
busy, para evitar el problema de carreras, el procedimiento es el siguiente:
a) si no se puede procesar una peticin porque en ese momento el bloque
est en estado busy se almacena en un bfer para ser tratada
posteriormente; y b) si la peticin que llega no es coherente con los datos
que tenemos, simplemente se rechaza.
Veamos tres ejemplos:
1.- Se est aadiendo una copia ms, en L1, a la lista de copias de un
bloque de datos, y se est ejecutando la funcin list construction, ya se ha
avisado a H, y este ha actualizado el puntero a la nueva cabeza y ha
respondido con la direccin del procesador que era la cabeza anterior, la
copia de L1 todava est en estado busy, porque an no ha terminado la
operacin. Mientras se desarrolla esa operacin, el procesador L2 lee una
variable de ese bloque y falla (no est en la cache), por lo que enva a H una
peticin de bloque, H responde a L2 con la cabeza de la lista que es L1, y
ahora apunta a L2 como cabeza de la lista, cuando L2 recibe la respuesta
enva un mensaje a L1 (new head), pero cuando el mensaje llega a L1 el
estado del bloque todava es busy. L1 en lugar de rechazar el mensaje,
guarda la peticin para tratarla ms tarde, si hubiera otra peticin llegara a
L2 ya que es la nueva cabeza de lista, y as los procesadores irn formando
una lista provisional. Cuando termine la operacin de L1, se procesara el
mensaje pendiente de L2, y as la cabeza de la lista se ira moviendo hasta
completar la lista definitiva.
La misma estrategia se utiliza en otros casos, por ejemplo cuando se est
ejecutando la funcin purge.

2.- La cabeza de la lista de copias de un bloque tiene que escribir e invalidar


todas las copias. Su estado es head-fresh, antes de comenzar a invalidar las
copias, enva un mensaje a H para que cambie el estado del bloque de fresh
a gone, pero al llegar a H, el estado del bloque no es Fresh sino Gone, lo que
ha pasado es que un procesador que no estaba en la lista ha producido una
escritura (en fallo) y se ha dirigido al escritorio, para situarse en la cabeza

de la lista (list-construction), por lo tanto ha cambiado el estado y tambin


el puntero, para que apunte a la nueva copia. En el directorio no se utilizan
estados transitorios (busy), pero se detecta que la peticin que llega no es
coherente con la informacin en el directorio, por lo tanto se rechaza la
peticin enviando un mensaje NACK, el que crea que estaba en la cabeza
de la lista ya no est y deber intentarlo de nuevo, pero de otra manera
(Roll-out + list construction + purge).
3.- En el ltimo caso, hay que reemplazar en una cache un bloque de datos
que est en la cabeza de una lista, ya se ha separado del segundo de la lista
y mientras se est comunicando con el directorio, para terminar la
operacin, otro procesador se ha querido meter como cabeza de la lista, y
ya est en el directorio como nueva cabeza de lista, entonces cuando llega
la peticin Roll-out del antiguo cabeza de lista, la peticin no es coherente
con la informacin del directorio, por lo que se rechaza (NACK), luego va a
llegar el mensaje del nuevo cabeza de lista al anterior cabeza de lista, es
necesario enviar una respuesta especial: donde est el verdadero segunda
copia de la lista.

S-ar putea să vă placă și