El protocolo de coherencia de caché Firefly es el esquema utilizado en la estación de trabajo multiprocesador DEC Firefly , desarrollado por el Centro de investigación de sistemas DEC . Este protocolo es un protocolo de coherencia de caché de escritura y actualización de 3 estados. A diferencia del protocolo Dragon , el protocolo Firefly actualiza la memoria principal y las cachés locales en la transición del bus de escritura y actualización. Por lo tanto, los estados de limpieza compartida y modificación compartida presentes en el caso del protocolo Dragon no se distinguen en el caso del protocolo Firefly.
En este protocolo, se pueden asignar los siguientes estados a cada bloque:
Estos estados corresponden a los estados Exclusive , Shared y Modified del protocolo MESI . Este protocolo nunca causa invalidación, por lo que el estado Invalid no aparece aquí.
Las solicitudes del lado del procesador o solicitudes de la CPU son los accesos que el procesador realiza a sus propias cachés. Estas se pueden clasificar en 4 tipos de solicitudes, a saber:
Las solicitudes del lado del bus son las solicitudes generadas en respuesta a las solicitudes del lado del procesador para mantener la coherencia de la memoria caché. El espía de las memorias caché y la memoria las vigila y se toman las medidas adecuadas. En el protocolo Firefly, se clasifican en dos tipos:
1. BusRd : Solicitud que indica que hay una solicitud de lectura a un bloque de caché realizada por otro procesador y ese procesador no tiene los datos.
2. BusWr/BusUpdt : Solicitud que indica que hay una solicitud de escritura a un bloque de caché realizada por otro procesador y todos los demás cachés deben actualizar sus copias del bloque.
Para identificar qué transiciones se deben realizar, el protocolo detecta el uso compartido mediante una línea de bus especial denominada CopiesExist . Todos los demás cachés espían todas las operaciones de memoria y lanzan CopiesExist(C) si detectan un "golpe de espía", es decir, si tienen una copia de los datos en su propio caché.
Una flecha que va de la nada a un estado representa un bloque recién cargado.
En caso de que el procesador lea un bloque incorrectamente y no haya ninguna copia del bloque en ninguna otra caché, se comprueba la línea CopiesExist (C) y C es LOW. Luego, el bloque se coloca en la caché y el estado se establece como Valid . Si ya hay una copia en algunas cachés (C es HIGH), entonces el bloque se coloca en la caché en el estado Shared .
En caso de error de escritura en un bloque, si no hay ninguna copia del bloque en ninguna caché (C es LOW), el bloque se coloca en la caché en estado Dirty . Si ya hay una copia del bloque en algunas cachés (C es HIGH), entonces el bloque se coloca en la caché en estado Shared y los cambios se reflejan en la memoria.
Si un bloque ya está almacenado en caché en estado válido , una escritura del procesador cambia el estado a estado sucio , ya que ninguna otra caché tiene la copia de los datos. Esta escritura no se realiza en la memoria.
Si un bloque se almacena en caché en el estado Sucio y se produce un error de escritura en el procesador, el estado permanece como Sucio .
Si el bloque está en estado compartido y hay un acierto de escritura del procesador, y si ya hay una copia en algunas cachés (C), el bloque permanece en estado compartido . Si no hay ninguna copia del bloque en ninguna caché (!C), el bloque se escribe en estado válido , ya que es la única copia "válida" presente en las cachés.
Si se produce un impacto de lectura de CPU, el bloque permanece en el estado en el que se encuentra, tal como en el protocolo Dragon.
Si el bloque está en estado compartido y hay una solicitud BusRd o BusWr, el bloque permanece en estado compartido.
Si el bloque está en estado sucio y otro procesador lo lee o escribe, a solicitud de otro procesador, pasa al estado compartido y los cambios se reflejan en la memoria principal.
Si el bloque está en estado válido y otro procesador lo lee, pasa al estado compartido. Si se intercepta otra solicitud de escritura del procesador, el bloque se actualizará y, como ahora se está compartiendo, también pasa al estado compartido.
A diferencia de MESI, en el protocolo de actualización Firefly, la propagación de escritura se asegura actualizando directamente todas las demás copias en una solicitud de escritura por parte de los procesadores (PrWr).
1. Debido al hecho de que existen copias actualizadas de los datos en cachés, hay menos errores de coherencia que en las políticas de escritura-invalidación.
2. Se requiere un mayor ancho de banda de bus que en los protocolos de invalidación, ya que estos últimos solo envían una señal o comando en el bus que es interceptado por otros procesadores, lo que hace que invaliden sus propias copias de los datos. En cambio, en los protocolos de actualización, el nuevo valor de los datos debe enviarse junto con la señal BusUpdate para permitir que la memoria y otras memorias caché espíen y actualicen sus datos.
3. La actualización de los datos en cada escritura hace que algunos datos que ya no son necesarios permanezcan en la memoria caché, lo que puede provocar que se eliminen algunos datos "útiles".
{{cite book}}: |journal=ignorado ( ayuda )